Как выбрать базу данных

7 типов современных баз данных: предназначение, достоинства и недостатки

Какую базу данных выбрать для проекта, чтобы работа была эффективной? Разбор достоинств и недостатков, а также примеры разных типов БД.

Артём Гогин
руководитель направления в хранилище данных в Сбербанке

Существуют сотни баз данных SQL и NoSQL. Одни популярны, другие игнорируются. Некоторые просты и хорошо документированы, а некоторые сложны в использовании. Одни имеют открытый код, а другие проприетарные. Что, возможно, наиболее важно, некоторые масштабируемы, оптимизированы, высокодоступны, а некоторые сложно масштабировать или поддерживать.

Возникает естественный вопрос: какую базу данных выбрать? Чтобы ответить на него, мы должны решить, чего мы хотим достичь с помощью базы данных. Чтобы составить представление, необходимо ответить на следующие вопросы:

Нужен ли нам аналитический доступ к базе данных?
Нужно ли нам писать или читать в реальном времени?
Сколько таблиц / записей мы хотим сохранить?
Какая доступность нам нужна?
Нужны ли нам столбцы?
Сможем ли мы получить доступ к таблицам, отфильтрованным по столбцам или по строкам?

Принимая решение, нужно помнить, что может предложить та или иная база данных. Специфика каждой БД может отличаться, но в целом существует только несколько типов, в рамках которых мы можем достичь в основном одинаковых целей. Рассмотрим их подробнее.

Реляционные базы данных SQL

Если вы когда-либо работали с базами данных, скорее всего, вы начали с этого типа, потому что он самый популярный и распространенный. Такие БД позволяют хранить данные в реляционных таблицах с определенными столбцами определенного типа. Реляционные таблицы хороши для нормализации и объединения.

Поддержка SQL
ACID-транзакции (атомарность, согласованность, изоляция и долговечность)
Поддержка индексации и разделения

Плохая поддержка неструктурированных данных / сложных типов
Плохая оптимизация обработки событий
Сложное / дорогое масштабирование

Примеры: Oracle DB, MySQL, PostgreSQL.

Документно-ориентированные базы данных

Если мы не хотим объединять несколько таблиц для получения нужных данных, мы можем взглянуть на документно-ориентированные базы данных. Они позволяют хранить записи в формате JSON. В этом формате мы можем создать сложное значение для любого ключа и сразу включить всю структуру данных в одну запись.

Нет привязки к схеме
Нет необходимости всегда писать все поля в каждой записи
Хорошая поддержка сложных типов
Подходит для OLTP

Плохая поддержка транзакций
Слабая аналитическая поддержка
Сложное / дорогое масштабирование

Базы данных в оперативной памяти

Базы данных этого типа могут предоставлять в реальном времени ответ для выбора и вставки определенных записей. Большинство из них в основном хранят данные в ОЗУ, но в некоторых случаях они также предлагают постоянное хранилище на жестких дисках или твердотельных накопителях. Большинство этих баз данных работают с записями «ключ-значение», поэтому значения можно запоминать в формате, ориентированном на документы. Но некоторые базы данных также работают со столбцами и позволяют вторичное индексирование той же таблицы. Использование ОЗУ позволяет обрабатывать данные быстро, но делает их более нестабильными и дорогостоящими.

Быстрое написание
Быстрое чтение

Труднодостижимая надёжность
Дорогое масштабирование

Примеры: Redis, Tarantool, Apache Ignite.

Базы данных с широкими столбцами

Эти базы данных хранят данные в виде записей ключ / значение на жестком диске или твердотельном накопителе. Эти решения предназначены для достаточно хорошего масштабирования, чтобы управлять петабайтами данных на тысячах общих серверов в распределенной системе. Они представляют архитектуру SSTable. Эта архитектура была разработана для двух случаев использования: быстрый доступ к ключу и быстрая запись с высокой доступностью.

Быстрая запись построчно
Быстрое чтение по ключу
Хорошая масштабируемость
Высокая доступность

Формат «ключ-значение»
Нет поддержки аналитики

Примеры: Cassandra, HBase.

Столбчатые базы данных

Иногда нам нужно быстро получить доступ к данным не с помощью определенных ключей, а с помощью определенных столбцов. В этом случае лучше отказаться от построчной вставки и перейти к пакетной записи. Пакетная вставка позволяет столбчатым базам данных готовить данные для быстрого чтения по столбцам.

Быстрое чтение столбец за столбцом
Хорошая аналитическая поддержка
Хорошая масштабируемость

Подходит только для пакетных вставок

Примеры: Vertica, Clickhouse.

Поисковая система

Если мы хотим получить доступ к данным с помощью фильтра по любому значению и даже по любому слову в столбце, мы должны вспомнить про поисковые системы. Эти базы данных выполняют индексацию каждого слова в столбцах и позволяют выполнять полнотекстовый поиск. Они идеально подходят для хранения и анализа журналов или больших текстовых значений.

Быстрый доступ по любому слову
Хорошая масштабируемость

Подходит только для пакетных вставок
Плохая аналитическая поддержка

Графовые базы данных

Для некоторых случаев подходят графовые структуры данных. Если ваши задачи требуют работы с графами, существуют специальные базы данных, которые удовлетворят ваши потребности.

Структура данных графа
Управляемые отношения между сущностями
Гибкие конструкции

Специальный язык запросов
Трудно масштабировать

Выводы

Практически любую задачу можно выполнить практически с любым типом базы данных. Вопрос в том, насколько это будет дорого и оптимизировано. Выбор инструмента, к которому вы привыкли, может сократить ваше время вывода на рынок. Но он также может стоить вам огромных денег на обслуживание и расширение вашего оборудования, которое может быть использовано неэффективно. Всегда старайтесь использовать базу данных так, как она задумана. Возможно, решение, соответствующее вашим потребностям, уже существует.

На данный момент этот блок не поддерживается, но мы не забыли о нём! Наша команда уже занята его разработкой, он будет доступен в ближайшее время.

Если вы готовитесь к собеседованию, посмотрите также статью, в которой собраны 27 распространённых вопросов по SQL и ответы на них.

Как новичку выбрать базу данных

На днях спросили у меня такую штуку и я написал страничку ответа. Потом подумал, дописал и вот готовый пост.

Рассказ нацелен на новичков. Его главная задача — сократить время растерянности и направить с правильными запросами в гугл и документацию баз. Советы, надеюсь, помогут быстро выбрать базу для хобби проекта или ненагруженного рабочего проекта.

Никакой полноты изложения. Никаких крайних случаев. Никакого хайлоада. Господа профи, поберегите, пожалуйста, пуканы 😀

Базы бывают очень разные

База, в некотором роде — центральная часть проекта. На ней сходятся вопросы безопасности, надёжности, производительности, etc. Поэтому совершенствованием и оптимизацией баз данных занято большое количество специалистов.

Поскольку проекты и задачи встречаются разнообразные, то и критерии для оптимизации баз тоже сильно отличаются. Отсюда естественным путём происходит разнообразие самих баз данных.

Новичку всё это разнообразие не нужно. Ему важно быстрее запустить проект и меньше думать о базах — и так проблем хватает. Конечно, если не стоит задача изучить именно работу с базами.

Поэтому первым делом расскажу о нетехнических эвристиках для выбора базы.

И только вторым делом — о технических.

Эвристики здравого смысла

Используйте только популярные базы

В недрах любой БД творится лютая чёрная магия, которая обеспечивает работу сложных алгоритмов поверх нескольких слоёв железа.

Если разработчики БД уверяют, что именно их БД не надо настраивать и она гарантировано работает из коробки, то они врут. Есть исключения — облака, о них позже.

Если вы возьмёте в работу БД с малым количеством документации, с малым сообществом, то в какой-то момент вы рискуете остаться один на один с проблемой, которая убивает ваш проект и которую вы не можете решить самостоятельно с разумной тратой ресурсов.

Поэтому всегда смотрим на популярность БД. Оценить её можно разными способами:

количество вопросов на stackoverflow.com;
графики на trends.google.com/trends;
звёздочки на github.com;
размер страницы на wikipedia.org;
в конце поста приведу очень краткий список, на случай если надо было выбрать вчера.

Используйте знакомые базы

Обычно задача разработки не звучит «создать проект с использованием БД X». Главное создать проект, а что внутри — важно чуть менее.

При этом, топовые базы по ключевым возможностям не сильно отличаются друг от друга: умеют хранить данные, умеют в какую-то надёжность, etc.

Поэтому, при прочих равных и при отсутствии необходимости выжать максимум из софта, хорошей стратегией будет брать базу с которой вы уже умеете работать. Это сэкономит много ресурсов.

Убедитесь, что база уже не выбрана

По аналогии с предыдущей эвристикой.

База данных, как и любой другой софт, может использоваться не только вашим проектом.

В вашей компании уже могут использовать какие-то базы. Или вы уже выбрали другой софт, который требуют конкретную базу для своей работы.

В этом случае хорошим ходом станет решение не разводить зоопарк.

Спросите профессионалов

Спрашивать не зазорно. Профи любят отвечать на вопросы, если те хорошо сформулированы и их автор не капает на мозг.

Опишите проект (дальше будут подсказки как это сделать) и задайте вопрос знакомому или отправьте его в интернеты.

Купите консультацию

Тоже не зазорно. Особенно, если с деньгами нет проблем.

Не надейтесь на авось.

Особенно, если от работоспособности проекта зависит что-то существенное: жизни людей, работа дорогого оборудования, ваша карьера 🙂

Если от вашего решения зависят жизни людей и вы недостаточно компетентны для его принятия, заплатите тому, кто компетентен.

Используйте Open Source решения

Если у вас нет огромных бюджетов. Есть исключения — облака, о них позже.

База — не то, что легко поменять на полдороги. Особенно когда вы завязались на специфические штуки конкретной реализации.

Бизнес корпоративного ПО почти всегда работает по принципу «подсадить и доить». Если в начале разработки вас устраивает текущий план оплаты, убедитесь что вас будет устраивать и 2-3 его следующих ступени.

Масштабировать железо для open source базы может оказаться значительно дешевле, чем для корпоративной.

Ну и в целом, поддерживайте open souce — это наша защита от антиутопического будущего.

Если есть деньги, идите в облака

Если убрать стоимость конфигурации, то облачная инфраструктура, навскидку, в 3-5 раз дороже чем хостинг на выделенном сервере. По крайней мере в неумелых руках.

Но большим плюсом облаков является множество стандартизированных масштабируемых решений. Если вы боитесь ошибиться в конфигурации БД, то облачная база может существенно сократить риск проблем с производительностью. За деньги, конечно.

Это как раз тот случай, когда можно поверить разработчикам БД, что та не требует настройки. Как и можно не сильно бояться завязаться на вендора — на текущий момент облачные решения близки по фунциональности к своим open source родителям.

Но помните: чтобы не завязаться жёстко на конкретное облако, тоже думать надо и архитектуру под это прорабатывать.

Технические эвристики

Тоже без сортировки. Считайте это списком вопросов, на которые надо обязательно ответить перед выбором базы данных. Равно как и перед задаванием вопросов профессионалам.

Обладают ли ваши данные специфическими свойствами?

Есть типы данных, которые очень отличаются от других и, по сути, определяют какие типы баз для них нужны. Например:

С графами лучше работают графовые базы данных.
С временными рядами лучше работают базы для временных рядов.
Для данных аналитики тоже есть свой тип баз (см. OLAP куб, например).
etc.

Если вы точно уверены в специфичном характере данных, берите такую же специфичную БД.

В остальных случаях ваш выбор с большой вероятностью будет происходить между реляционными и документо-ориентированными базами данных.

Объекты с какой структурой будут храниться в БД?

Если структура объектов фиксирована и известна, то скорее всего удобнее будет использовать реляционные БД.

Если структура объектов сложная, может часто меняться, не известна полностью, то может быть удобнее использовать документо-ориентированные БД.

Если между объектами предполагаются сложные связи, если информация о связях не должна разрушаться, должна быть надёжной, то с большей вероятностью вам подойдёт реляцонная БД. Если наоборот — документо-ориентированная.

Также обратите внимание, что некоторые базы требуют описывать схему данных заранее, а некоторые умеют определять её на ходу. Это сильно повлияет на то, как вы будете вносить изменения в код.

Насколько сложные запросы предполагаются?

Чем больше коллекций объектов и связей между объектами предполагается включать в один запрос к базе, тем с большей вероятностью лучше будет взять реляционную БД.

Или графовую базу, если всё совсем плохо и не формализировано.

Какие гарантии надёжности нужны?

Если для вас это основной критерий, платите эксперту.

Чем взрослее БД, тем она надёжнее —взрослые БД больше отлаживали, больше ошибок в них исправлено.

Реляционные базы обычно более надёжны. За ними стоит хорошая математическая теория, которая сама по себе обеспечивает дополнительную надёжность.

Какие гарантии ACID нужны?

Читаете статью на вики про ACID.
Смотрите как на эти понятия ложится ваш проект.
Читаете документацию базы и смотрите подходят ли её гарантии для вашего случая.

Какой объём данных будет храниться?

Если небольшой или средний (допустим, до терабайта), то обычно это не главный критерий.

Если больше, надо смотреть и тестировать конкретные use cases с конкретными базами.

Какая нагрузка на базу ожидается?

Опять таки, если небольшая, то это не основной критерий для выбора базы.

Проблема в том, что определить уровень нагрузки сложно — очень зависит от проекта, свойств данных, их количества, железа.

Могу предложить два подхода к оценке:

Если становится страшно, когда думаете о нагрузке, значит она большая 😀
Поставьте эксперимент: разверните базу, наполните данными, эмулируйте нагрузку и посмотрите как грузится железо и как быстро отвечает база.

Если ожидается большая нагрузка, то либо ставьте эскперементы с каждой базой-кандидатом, либо платите эксперту.

Какой тип доступа к данным предполагается?

Как продолжение предыдущего вопроса.

Чего будет больше: чтения или записи?

Есть базы заточенные на чтение данных и медленную запись. Есть, наоборот, на быструю запись и медленное чтение. Есть те, что можно оптимизировать в обе стороны.

Обращение ко всем данным будет с равной вероятностью или будут данные, с которыми будут работать значительно больше, чем с остальными?

Достаточно ли будет запустить базу на одной машине?

Или нужен кластер. Если нужен кластер, то надо через документацию и эксперименты проверять пригодность базы для распределённой работы. Не забываем про облака.

Ответ на этот вопрос, по сути, зависит от ответов на все вопросы о данных и нагрузке.

Какие средства есть для организации миграций?

Подробно про миграции я писал:

О миграциях backend
Миграции backend на практике

Ставьте эксперименты

Если сомневаетесь в определении пригодности базы по какому-либо критерию и считаете его важным для проекта — ставьте эксперименты.

Лучше потратить неделю на проверку решения, чем выкинуть полгода работы.

Не выбирайте встраиваемые базы данных

Если не уверены на 100% в том, что делаете.

Есть класс баз данных, ориентированных не встраивание в другое ПО (и на очень простые веб проекты). Это отличные базы, но если вы используете их для веба, то можете столкнуться с большими сложностями в масштабировании. Например, не сможете поднять второй процесс веб-сервера для ускорения обработки запросов.

Особо выделю SQLite. Это отличная база, её часто и справедливо рекомендуют для обучения. Но то, что удобно для обучения, далеко не всегда удобно для практики.

Если сомневаетесь, берите реляционную БД

Если до конца не ясно что выгоднее: документо-ориентированная или реляционная БД, берите реляционную.

Популярные реляционные БД давно неплохо умеют работать с документами, обычно в формате JSON, поэтому поверх их всегда можно сделать хранилище документов нормального качества. Обратное про документо-ориентированные базы, к сожалению, сказать нельзя.

Подумайте насколько удобно вам будет работать с базой

Ничто не даётся бесплатно. Чем больше может база, тем сложнее с ней может быть работать: делать запросы, мигрировать данные и схемы.

Вы можете выиграть в надёжности, но сильно потерять в скорости разработки.

Обычно, реляционные БД сложнее в обращении, чем документо-ориентированные.

Очень краткий алгоритм выбора базы

Если от проекта зависят жизни или большие деньги, нанимаем эксперта.
Если что-то уже используется, в первую очередь рассматриваем это.
Если команда умеет работать с конкретной базой, в первую очередь рассматриваем её.
Если данные специфические, ищем популярную специфическую базу.
Если структура данных не формализирована и часто меняется, берём популярную документо-ориентированную базу.
Если структура данных формализирована, редко меняется или работа с данными требует повышенных гарантий, используем популярную реляционную БД.

Краткий список популярных баз

Хороших баз много и лучше выбрать самому, но если очень горит, то вот:

Реляционные: PostgreSQL, MariaDB
Докуменнто-ориентированные: MongoDB
Графовые: Neo4j

Похожее:

О миграциях backend
Миграции backend на практике
Бесконечность схем данных
Экзокортекс: метаинформация
Тарантога: модель данных
Экзокортекс: минимальная функциональность

Нравится блог?
Делитесь постами с друзьями!

Делаем вымышленную вселенную: месяц 2
Итоги 2023 года для меня и блога
Два года пишем RFC — статистика
Делаем вымышленную вселенную: месяц 1
Про увольнение Sam Altman и регуляцию ИИ
Вымышленная вселенная, сеттинг, произведение — в чём разница?
Paul Graham: Superlinear returns
Используем DALL-E-3 для геймдева
Концепт-документ шоу настольной ролевой MMO игры
Feeds Fun — читалка новостей с тегами и ChatGPT
РПГ победившего маркетинга
Истина где-то рядом
Open source сервисы аутентификации
Эксперименты с Тарантогой закончены
Два примера overengineering из FastAPI
Глупые прогнозы об Искусственном Интеллекте
Пара слов о GitHub Сopilot
Делаем простой ИИ тамагочи на ChatGPT
Итоги 2022 года для меня и блога
OpenAI Chat для геймдева

Рассуждение на тему, какую базу данных выбирать

Я разберу в своей статьи некоторые типичные и не очень варианты выбора баз данных, а если быть более точным — подходы к выбору. Когда следует остановится на том, что используют большинство, а когда можно и задуматься над новым и неизведанным. Я опишу СУБД MySQL, PostgreSQL, MongoDB, Redis, CouchDB/PouchDB и упомяну о Aerospike с Tarantool, парочку других — но в некоторых моментах конкретный выбор не настолько принципиален. Надо понимать, что лучше изначально правильно спроектировать структуру данных, чем выбрать СУБД, а потом уже пытаться придумывать, что в ней собственно хранить.
Итак, начнем.

Небольшие отступления:

Мои выкладки не истина в последней инстанции. Какие-то выводы я делал на основе реального использования, какие-то на основе информации в интернете, обсуждения с другими людьми. Некоторые выводы сделаны на основе реальных задач, а некоторые в чисто теоретических идеях. Вся эта информация есть в том или ином виде на просторах интернета, но достаточно разрознена, я же постараюсь компактно описать в одном месте.
Я рассматриваю только те продукты, которые на момент написания статьи активно развиваются и в то же время стабильно существуют в течении длительного времени. Опять же, на мой взгляд, одним из условий выбора чего-либо для своего проекта — чтобы продукт был достаточно стабильный, рабочий, имел большое и хорошо развитое сообщество, его использование не сопряжено с многодневными танцами с бубном и т.п. И что немаловажно — должна быть возможность официально воспользоваться коммерческой поддержкой и получить тем самым гарантии от разработчика. Следует учитывать, что есть множество других вариантов, но они либо сырые и для их сопровождения в проекте придется прикладывать дополнительные и нерациональные усилия. Либо гораздо менее успешны или популярны.
Я с удовольствием почитаю ваше мнение в комментариях. И об описанных базах данных и не только. И не только я, думаю многим будет интересно почитать аргументированное мнение о какой либо базе данных.
Самое важное и еще раз — здесь не пойдет речь про крупные проекты. В таких проектах обычно уже есть свой архитектор или знающий человек и достаточно средств, чтобы обеспечить оптимальный выбор. Хотя кто знает, может мои выкладки и им пригодятся.

Теперь давайте зададим себе вопросы:

Насколько вы консервативны, хотите и любите ли вникать во что-то новое?
Хотите не думать или наоборот хотите вникнуть досконально в устройство базы данных?
Насколько хорошие программисты в вашей команде, смогут ли они грамотно составить структуру БД или они уже являются отличными специалистами по какой-то одной СУБД?

MySQL / MariaDB

Народная СУБД или «must have», есть практически на любом хостинге. Простая в установке, работает нормально без особых настроек. При должном подходе может гибко настраиваться под ваши нужды. Но есть и подводные камни, в некоторые случаях она будет тем самым узким горлышком и ваш проект будет тормозить, как бы вы не тюнинговали СУБД и структуру данных.
MySQL для вас, если:

— вы консерватор и не хотите вникать в настройки СУБД, просто поставили и работает (ну или на хостинге используете то, что дают);
— вы консерватор же, значит мыслите структурно, таблично. MySQL справится;
— в любом языке программирования, фреймворке, CMS, CMF и так далее и тому подобное — есть интеграция с MySQL.
— вы новичОк и вам нужна СУБД для управления структурными данными, желательно небольшими (до 1 — 2 гигабайт).

Минусы? Их есть и вам следует выбрать другую СУБД, если увидите важное.

— посредственная производительность. Действительно низкая, как не тюнингуй. даже кластер не поможет особо (его еще настроить надо, ага, те еще танцы с бубном). Речь о цифрах порядка 20 МБайт/сек. Из личного опыта, на SSD дисках при таком потоке MySQL упирался в свой предел, не справлялся и тормозил, причем сервис настраивался несколько лет, использовались оптимальные для нагрузки настройки. Из коробки конфигурацию, думаю будет еще меньше планку иметь;
— изменение структуры данных может быть довольно трудоемким процессом, особенно при большом количество связей между данными в разных таблицах и даже при простом добавлении полей;
— чувствительность к нестабильности сервера. Особенно это влияет при использовании XtraDB от Percona. Если неправильно завершить MySQL, можно настолько поломать таблицы и базы данных, что восстановить можно будет только из полного бекапа, конечно, если вы их регулярно делаете. И поверьте, это случается всегда в самый неожиданный момент. Есть инструменты, которые в несложных ситуациях помогут восстановить работоспособность, но они не панацея. В последних и актуальных версиях активно борются с этим, заявлена гораздо лучшая стабильность и надежность.

PostgreSQL

Своего рода мастодонт, очень старая и грамотная СУБД. Она почти как MySQL, только лучше. Но надо уметь готовить и настраивать. По мнение многих, очень стабильная СУБД, ее практически невозможно уронить, порушить таблицы как в MySQL. И это может быть для вас решающим фактором при выборе.

PostgreSQL для вас, если:

— вы консерватор (понимаю повторяюсь, но так и есть) и нужно надежное хранилище;
— вы или ваш специалист умеете настроить и использовать PostgreSQL;
— вам нужны хорошо структурированные данные, но с некоторой гибкости в схеме данных (JSON/BJSON);
— при помощи сторонних библиотек просто и удобно расширяться в кластеры и делать шардинг таблиц. И все это действительно работает.

А минусов как то вот не особо описывать… Справедливости ради, особо практики не имел, в основном сужу по рассказам знакомых:

— необходимость опыта работы с этой СУБД, чтобы приготовить ее хорошо. Иначе лучше взять MySQL или прочитать дальше;
— система авторизации по умолчанию может вызвать затруднения при использовании или настройке, далеко не всем нравится, некоторые даже очень опытные разработчики до сих пор не до конца понимают как оно там работает.

MongoDB

О, сколько копий до сих пор ломается — SQL или NoSQL… Но все же в некоторых случаях MongoDB справляются с задачей гораздо лучше, чем MySQL или PostgreSQL. Например, реальный случай, свидетелем которого я был — сбор и обработка статистики по хостингу (нагрузка на CPU, i/o, память и т.п.) — MySQL не справился от слова вообще. MongoDB справился без особых проблем. База данных достигает объема в 200-300 ГБайт, поток данных достигает 100 и более МБайт/сек. Показательно, на мой взгляд.

MongoDB для вас, если:

— у вас нет четкой, заранее описанной структуры данных или вы предполагаете, что состав данных может потом сильно изменится (конечно это можно делать в SQL, но надо мыслить другими понятиями, поменять то можно, но вопрос насколько это будет трудоемко);
— у вас планируется довольно серьезный объем данных (десятки или даже сотни ГБ), определить это даже на этапе ТЗ можно;
— вам просто хочется NoSQL, модно же;
— легко установить и попробовать, работает нормально без особых настроек. А если углубится, изучить, то настроить можно очень многое.

Минусы тоже есть.

— Нет простых транзакций. По крайней мере в том, классическом виде, какие они есть в MySQL/PostgreSQL. При добавлении множества данных, которые зависят друг от друга, могут быть определенные трудности, которые придется решать самостоятельно на уровне кода. Ну то есть вы можете и не столкнутся конечно, но…;
— связность данных практически отсутствует. Сразу приходит на ум, постоянно упоминают JOIN из SQL — вот этого по сути нет. Хотя, если быть более точным, то надо просто мыслить другими категориями;
— нужно перестраивать мышление именно под NoSQL. иначе будет сложно сопровождать — то есть хороший программист (точнее архитектор ПО) обязателен в дальнейшем.

Redis

Чаще всего эту СУБД используют в качестве кеширующего слоя для работы с данными из другой, более медленной СУБД. Лучшая замена memcached, если вам это что-то скажет. Редко, но все же может использоваться в качестве самостоятельно БД для данных. При этом Redis умеет разные типы данных, в том числе списки, очереди, умеет Pub/Sub, а еще очень просто работать с TTL (время жизни ключа). Работает в памяти, очень быстрая, умеет сохранять данные на диске, причем с поддержкой дозаписи (гораздо меньше нагружает диск) и загружать при запуске. Почти сказка.

Redis для вас, если:

— объем данных небольшой и очень простая схема, укладывающая в шаблон «ключ=значение»;
— простая реализация репликации Master — Slave. Действительно очень простая настройка, достаточно добавить в конфиг сервера указания на мастера, запустить Redis Server и данные уже реплицируются. Хотя, наверное, следует уточнить, что настроить гибкую репликацию (частичную) вряд ли получится;
— нужен Pub/Sub (очереди). Справедливости ради следует сказать, что есть отдельные системы Pub/Sub, реализующие помимо этого паттерна и другие. Redis реализует это достаточно элегантно и просто, вполне возможно вам другие не понадобятся;
— нужен кеш для более медленной СУБД или просто хотите не задумываться о скорости работы СУБД с оглядкой на ее объем. Примером может послужить сайт на Drupal, с основной базой данных в MySQL и кешем в Redis. Проводил тесты ради интереса обычным ab, скорость отдачи контента может увеличится в разы. На обычном Apache + Redis + mod_php можно достичь сравнимой производительности с Nginx + php-fpm, а если к Nginx добавить Redis…

Минусы тоже есть, как же без них.

— объем данных не должен превышать объем свободного ОЗУ на вашем сервере (на самом деле может, но тогда все они будут уходить в swap, сильно замедлять работу, в общем лучше избегать);
— в угоду производительности присутствует довольно слабая сохранность данных. То есть вполне может произойти такое, что данные добавили, а после рестарта их нет. Включение AOL (append of file) немного сглаживает ситуацию, но тогда загрузка с диска будет довольно длительной;
— транзакции и связанные данные не то, чтобы умеет. Если точнее — есть Pipeline и Multi/Exec, но это все таки не совсем транзакция в классическом понимании;
— до сих пор не умеет нормально кластер и шардинг. Нормальной реализации до сих пор нет.

Конечно можно напрячься и сделать что-то похожее на кластер при помощи специального скрипта, но на мой взгляд выглядит это довольно кривовато и неоптимально.

Альтернативы

Из личного опыта и блуждания по интернету, изучения разных статей, обзоров я встречал несколько различных вариантов, которые можно применить в случае, если вас что-то не устроило в предыдущих вариантах. Итак, встречайте еще несколько интересных проектов.

IBM Lotus Domino/Notes

На мой взгляд ярчайший пример успешного коммерческого проекта СУБД концепции NoSQL. Хотя подозреваю, что успех скорее не в его NoSQL, а в наличии полноценного сервера приложений с встроенным редактором кода и интерфейса к базе. Решение очень зрелое, существует на рынко довольно давно и поддерживается гигантом IBM — ну то есть очень даже круто. Лично участвовал в разработке двух разных систем электронного документооборота на его базе, а также сопровождал некоторые критично важные приложения в банке. Кстати, несмотря на платную политику распространения, мало кто знает, но его можно бесплатно скачать для изучения.

CouchDB

Хотите хранить документы разной структуры (ну как MongoDB, типа), но у вас нет для приложения адаптера или не хотите лишних зависимостей? CouchDB работает через http, имеет встроенный веб-сервер, обменивается в JSON. Очень удобно. Кстати умеет транзакции и можно подписываться на изменения данных. Но это не точно.

PouchDB

Это очень интересный проект, как бы аналог CouchDB, но более приземленный, встраиваемый вариант. Встроили в приложение, работает как локальная база данных, но умеет настраиваемую репликацию с CouchDB или PouchDB Server (на базе ExpressJS). PouchDB на самом деле скорее прослойка, где снаружи вы работаете с единым API, CouchDB-подобным, но внутри может быть совсем разные СУБД — и SQLite и LevelDB и браузерная база данных и MongoDB и даже MySQL. Очень пригодится, если вы делаете распределенное приложение, где обмен данными важен, но связь с сервером может быть нестабильной или эпизодической.

Aerospike

На мой взгляд отличная замена Redis в плане key/value БД. Умеет транзакции, умеет сохранность данных, умеет большой объем данных (превышающий объем доступной ОЗУ). Правда нет Pub/Sub и каких-то особых структур данных, но работает быстро и хорошо. Пожалуй единственным недостатком это слабая популярность по сравнению с Redis. Непонятно кстати почему…

Apache Cassandra

Спроектирована и работает как распределенная NoSQL СУБД для больших данных. Данные хранит в виде семейства столбцов, что сперва может изменить кардинально подход к разработке приложения. Но после ломки мышления вполне может оказаться, что это именно то, что вам надо. Заявлено простое добавление узлов на лету, высокая отказоустойчивость при выходе одного из узлов. В теории можно использовать на небольших проектах, но выглядеть будет наверное, как будто микроскопом забивать гвозди.

Tarantool

Замечательный проект от Mail.Ru. Что-то среднее между Redis/Aerospike и MongoDB… Хотя по моему сами разработчики до сих пор затрудняются провести аналогии :). Его надо уметь, а если быть более точным хотеть готовить. И речь не про настройку, а про постоянную подгонку под разработку новых версий Tarantool. Нужно хотеть вникать во внутреннее устройство этого проекта, постоянно изучать изменения его API и документации, все время подгонять код приложения под изменения. А если вы еще и хотите поучаствовать в процессе разработки, пообщаться с разработчиками в чате — тогда тем более это для вас.

А вот теперь как бы и все.

Да, я упомянул далеко не все СУБД (если смотреть на этом сайте, то там перечислено 253 названия). Надеюсь вы и не думали, что я их все перечислю?

Возможно в описании той или иной СУБД я допустил неточность и не упомянул нечто важное. Такое очень даже возможно и если так — напишите в комментариях, я с интересом почитаю.
Надеюсь мои выводы окажутся полезными и интересными.

UPD1: По поводу отказоустойчивости MySQL. Вы все правы. Я не заявляю, что InnoDB нестабильна, я лишь упомянул, что ситуация это возможна. И если она произойдет, то восстановить работоспособность никак нельзя будет, только начисто восстанавливать все целиком из бекапа. Именно об этом речь, а не о том, что вы решили будто я считаю ее нестабильной. По реальному примеру, на серверах у нас такое произошло за последний год 2 или 3 раза. На разных серверах. На сервере несколько сотен баз с разной нагрузкой, объемов и т.п. Это не значит, что у вас MySQL будет падать регулярно на виртуалке с одним-двумя сайтами, совсем не об этом речь. Как то так.

MySQL
NoSQL
MongoDB
Администрирование баз данных