что такое нереляционная база данных
Что такое NoSQL
Это нереляционные базы данных.
Когда мы разбирали виды баз данных, то сказали, что они бывают реляционные и все остальные. Реляционные — самые распространённые, вы встретите их под капотом большинства сайтов, чаще всего они управляются через систему MySQL.
Но одно решение не может подходить всем и всегда. Сегодня поговорим обо всех остальных вариантах, которые собраны под единым большим термином NoSQL — это общее название для нереляционных баз данных.
Способ организации данных
В SQL-базах всё просто: есть, условно говоря, таблицы, и есть связи между ними. Все данные хранятся в этих таблицах.
В NoSQL-базах всё иначе — там может не быть таблиц, а вместо них — свои модели данных. Каждая из них подходит под свои задачи, универсальной нет. Вот основные модели:
Ключ-значение
У каждой записи есть название поля и его значение. Например:
name: ‘Миша’
today: ‘9/09/2020’
president: ‘Путин’
writer: ‘Пушкин’
pogoda: ‘ну такая’
Первая часть — это ключ, вторая часть — значение. И можно подсыпать сколько хочешь новых ключей.
Это полезно, например, для словарей или механизмов автозамены: «Если встретилось такое слово — замени на вот такое».
Колонки
Представьте себе одну огромную таблицу, в которой хранятся все данные в базе. Отличие от традиционной схемы в том, что в SQL-базах работа идёт со строками, а здесь — с колонками. Например, если в такую базу занести список из 250 лучших фильмов с названиями, актёрами и режиссёрами, то все названия можно получить с помощью только одного запроса и одного обращения к базе. В случае с SQL таких обращений к базе было бы 250 — по одному на каждую строку.
Графы
Если ваши данные можно представить в виде графа или дерева, то вам подойдёт и база данных с таким же подходом к хранению и поиску.
Дерево — это когда данные хранятся по системе «родитель — отпрыски». Есть некий родительский кусок данных, у него есть связанные с ним отпрыски. У тех тоже могут быть свои отпрыски и так далее. Каждая единица данных может быть чьим-то отпрыском (но только кого-то одного) и иметь сколько-то собственных отпрысков.
В деревьях удобно хранить данные, например, для поисковых алгоритмов. В «деревьях» также хранятся файлы на вашем компьютере: есть корневой каталог, в нём вложенные папки, в них ещё папки, в них файлы. Один и тот же файл не может храниться одновременно в двух местах.
Графы — это когда данные связаны вообще как хочешь. Один кусок данных может быть связан с любыми другими в любом количестве и в любом направлении. Дерево — частный случай графа.
❤️ Про деревья мы недавно писали: что такое Trie и как работает бустинг
Документы
Вот это космос, смотрите.
Если мы храним данные в таблице, у нас есть столбцы и строки. И если у нас про кого-то есть данные, а про другого нет, — где-то в таблице будут пропуски. А если в таблице нет нужного столбца, а нам нужно положить в неё новый тип данных, нам придётся создавать новый столбец, и он для всех будет пустым:
| Имя | Возраст | Город | Роль |
| Миша | 35 | Брянск | Редактор |
| Женя | Москва | Директор | |
| Родион | Ульяновск |
Реляционная БД заставляет нас заранее придумывать, как будет работать база данных; какие там будут поля; какие допустимы типы данных. Например, в таблицу выше уже не добавишь информацию о том, что Родион носит бороду — точнее, добавить-то её можно, но тогда у нас появится куча пустых ячеек. А если этих столбцов нужно добавлять много? Это крайне нерационально.
Теперь представьте, что есть механизм, который позволяет хранить эти данные в более свободном формате. Например:
name: Миша
age: 35
city: Брянск
job: Редактор
stickerpack: Доктор Хаус
Каждая из этих записей (про Мишу, Женю и Родиона) — это три отдельных документа. И база данных настолько умна, что может при необходимости распознать, что там где лежит. Если мы запросим у нее Boroda, то она прошерстит все документы и поищет там разметку со словом «Борода». В первых двух документах этой разметки не будет, а в третьем — будет. Именно этот документ нам база данных и вернёт.
Работа с SQL-запросами
Уже по названию видно, что NoSQL не поддерживает SQL-запросы. Это значит, что у каждой такой базы своя методика работы с данными и общего стандарта нет. Не получится выучить операции в Redis, который работает по принципу «ключ-значение» и быстро освоить MongoDB, где всё основано на документах.
Некоторые NoSQL-базы пытаются поддерживать что-то из SQL, но на практике это работает плохо.
Скорость и масштабируемость
Чтобы реляционная база данных могла работать с большим объёмом данных, нужно поставить железо помощнее или добавить несколько копий такой базы, чтобы можно было быстрее читать из неё.
В NoSQL-подходе базу легко разделить между несколькими компьютерами, связанными по сети. Чем больше компьютеров и чем быстрее сеть — тем больше база и скорость работы. Получается, что железо можно оставить тем же, и просто увеличить количество узлов в базе.
Надёжность и безопасность
Реляционная база данных надёжна как скала, в ней не может случиться ничего плохого, потому что она сама за этим следит. А если такое случается, то всегда можно вернуться на шаг назад и восстановить все данные без потерь. За это приходится платить скоростью работы.
NoSQL-базы относятся к этому иначе: они предлагают максимальную скорость работы, а решение всех конфликтов зависит от программиста. Если одну и ту же ячейку хотят изменить два пользователя, а программист этого не предусмотрел, то кто быстрее записал — тот и прав. Поэтому в таких базах нужно отдельно следить за надёжностью и решением конфликтов.
Применение
Обычные SQL-базы отлично подходят для типовых задач, где надёжность и предсказуемость важнее скорости. Например, для записей о пациентах, перемещениях товаров со склада или школьных оценок.
Но если вам нужна скорость, масштаб и большая мощность — посмотрите на NoSQL. Единственный минус — у каждой базы свои правила работы с данными, поэтому быстро перейти от одной к другой не получится.
Нереляционные решения БД.
Главной проблемой реляционных БД достаточно давно считается так называемое “несовпадение бремени” (impedance mismatch) между реляционной и объектно-ориентированной моделями данных.
При рассуждении о данных с точки зрения ООП (объекно-ориентированного подхода), вы представляете себе схему данных в виде дерева, или документов, или чего-то подобного.
При этом, реляционная модель оперирует отношениями (или “таблицами”).
NoSQL так же часто называются документо-ориентированными БД, и отчасти решают эту проблему.
Другой проблемой является производительность в условиях современного мира.
В современном обществе, количество информации растет экспоненциально, и банальные требования к хранению этой информации становится трудно выполнять в рамках одной или нескольких машин. К тому же, с очень большими объемами данных сложно работать: сложно добавлять новые, сложно читать старые.
Сейчас существуют такие вещи, как социальные сети, коллективные блоги, последние годы стало популярно говорить про “семантический веб”. Все эти вещи оперируют огромными объемами взаимосвязанных данных, которые постоянно читаются и обновляются.
К сожалению, реляционные СУБД значительно теряют в производительности с ростом количества данных. Большинство современных корпоративных БД (учет товаров, сотрудников, клиентов, etc) и БД веб-приложений укладываются в диапазон объема данных, при которых производительность РСУБД остается “хорошей”. Однако, скажем, объем данных того же Facebook уже находится за рамками применимости РСУБД.
Для решения проблемы хранения и обработки больших объемов данных, используется подход кластеризации: данные разносятся по многим машинам, и доступ к ним осуществляется при помощи некого балансировщика нагрузки.
Однако, при использовании РСУБД, добавление еще одного узла в кластер не сильно улучшает производительность. Соответственно, на рынке возник некий вакуум, требующий СУБД с высокой, что называется, горизонтальной масштабируемостью.
Нереляционные (NoSQL) решения так же стремятся решить и эту проблему.
Основные особенности NoSQL
Википедия определяет NoSQL-БД как “нереляционные хранилища данных, не нуждающиеся в фиксированной схеме и которые обычно избегают операций соединения (join)”.
Разных нереляционных решений существует великое множество, и объединяет их в значительной мере то, что они не используют реляционную модель.
Другой характерной чертой является высокая горизонтальная масштабируемость.
Третий фактор – отсутствие жестко заданных схем данных.
В качестве примеров NoSQL решений можно привести:
Иными словами, сейчас на рынке великое множество нереляционных СУБД.
Большинство NoSQL БД по схеме данных ориентированы на агрегаты данных, другими словами, на вложенные структуры данных. Эта особенность радикально отличает NoSQL от реляционных БД, в которых модель данных ориентированна, напротив, на нормализованные данные.
Нормализованные данные имеют несколько достоинств по сравнению с агрегатами:
С другой стороны, нормализованные данные имеют свои недостатки:
Агрегированные данные же
Сущности “заказ” (№, дата), “товар” (№, название, цена), “платеж” (№, сумма, дата). Атрибуты указаны в скобках.
В реляционной модели это может выглядеть так:
| id | date |
|---|---|
| 100 | 2008-04-15 |
| id | name | price |
|---|---|---|
| 10 | Ваза цветочная | 600 |
| 11 | Картина “море” | 500 |
| id | orderId | sum | date |
|---|---|---|---|
| 100 | 100 | 1000 | 2008-04-17 |
| 101 | 100 | 100 | 2008-04-18 |
| orderId | productId | Number |
|---|---|---|
| 100 | 10 | 1 |
| 100 | 11 | 1 |
В то же время, документно-ориентированная БД может представлять это в виде:
Модели данных
С практической точки зрения, существуют разные нереляционные модели данных.
Наиболее распространенные из них это:
Представляют собой множество бинарных кортежей, причем первый элемент кортежа считается “ключом” и имеет строковой тип данных, а второй считается “значением”, и имеет “какой-то” тип данных (то есть, СУБД не знает, что за данные в значении).
Представляют собой множество множеств бинарных кортежей ключ-значение. При этом значение само по себе есть множество множеств кортежей ключ-значение, либо скалярный тип (скажем, строка или число).
Смысл этой модели в том, что данные хранятся в виде множества “колонок”, вместо множества “строк”, как в реляционной модели.
При этом, в качестве ключей для данных в “колонке” используется само значение, которое уже определяет, к какой “строке” относится эта колонка.
Подобная организация позволяет эффективно реализовывать статистические запросы и запросы агрегатов.
Данные представляются в виде графа, где узлы и ребра имеют атрибуты.
CAP-теорема
Вся суть NoSQL-решений описывается так называемой CAP-теоремой.
В вольной формулировке, она звучит так:
СУБД должна обеспечивать:
СУБД может обеспечивать не более двух из трех вышеперечисленных.
CAP-теорема
Реляционные БД обеспечивают доступность и целостность (CA).
Cassandra, Voldemort, CouchDB обеспечивают доступность и устойчивость.
Hypertable, HBase, MongoDB, Redis обеспечивают целостность и устойчивость.
MapReduce
Основным инструментом для работы с нереляционными данными является разработанный в Google фреймворк mapReduce или его аналог.
Само понятие mapReduce происходит из функционального программирования, и это попросту композиция отображений и редукции. Сила гугловского фреймворка в том, что он эффективно работает на высокораспределенных системах.
Смысл mapReduce в том, что если есть много относительно простых вычислений, то, пользуясь mapReduce, достаточно определить две функции:
Обеспечение целостности в распределенной среде
Если у нас есть один узел с данными, то мы можем в общем-то достаточно уверенно гарантировать целостность. В распределенной среде это не совсем так. Поэтому, большинство NoSQL-СУБД гарантируют целостность “рано или поздно” (eventual consistency), то есть, если данные в системе не изменяются, то рано или поздно они станут согласованными на всех узлах.
EC обеспечивается при помощи так называемых “анти-энтропийных алгоритмов”, которые основаны на моделях распространения сплетен и эпидемиологических моделях.
Смысл алгоритма в том, что каждый узел распределенной сети по таймеру случайным образом выбирает другой узел и обменивается с ним информацией. Для этого может быть три стратегии:
push. Узел A отправляет некий хэш своих данных узлу B, узел B запрашивает у A данные, отличающиеся на A и B. Обновляется таким образом только узел B.
pull. Узел A отправляет некий хэш своих данных узлу B, а узел B отправляет узлу A данные, которые у него отличаются. Обновляется таким образом только узел A.
push-pull. Происходит и то, и другое.
Последний в среднем в 2 раза более эффективен, чем первые два.
Другие стратегии могут выбирать один из узлов кластера в качестве “арбитра”, который будет обеспечивать целостность (опять же, рано или поздно)
Реляционные и нереляционные базы данных
В IT-среде традиционно выделяют два основных типа БД: реляционные (для простоты будем называть их РБД) и нереляционные (соответственно НБД). Они имеют фундаментальные отличия, например, используются для хранения различных данных и требуют разного подхода в проектировании.
Рассмотрим каждый тип подробнее.
Отличия SQL и NoSQL
Чтобы разобраться в том, чем отличается реляционная база данных от нереляционной, необходимо в отдельности рассмотреть их особенности. В РБД хранятся структурированные данные, которые могут представлять объекты из окружающего нас мира. Так, в построенной по такой модели базе могут содержаться сведения о реальном человеке или о том, какие товары покупатель сложил в корзину в торговом центре. Эти данные обязательно группируются в таблицах в заданном формате.
НБД устроены по-другому. Типы хранящихся данных в них напрямую зависят от вида самой БД. Так, если речь идет о документно-ориентированной базе, данные в ней будут содержаться в формате иерархии и могут описывать самые разные объекты с произвольными характеристиками. В этом, пожалуй, одно из важнейших достоинств NoSQL — база позволяет хранить огромные объемы информации в виде единой сущности. Такой объем в условиях РБД пришлось бы разбить на несколько отдельных, хоть и взаимосвязанных, таблиц.
Особенности SQL
Для начала подробнее поговорим про РБД. Вся информация в БД всегда строго структурируется, она всегда связана с другими сведениями. В таблице обязательно присутствуют строки (с записями) и столбцы (с типом данных).
Информация в ячейке всегда записывается по определенному шаблону.
Целостность информации
Если говорить про целостность информации в БД, то имеется в виду, что она точна, полна и единообразна.
Чтобы поддерживать целостность в SQL, используются специальные инструменты, в том числе первичные и внешние ключи, а также специальные ограничения, к примеру, «Default».
Эти ограничения дают возможность использовать эффективные правила ко всем сведениям в таблицах базы данных, а также гарантировать точность информации.
Транзакции
Транзакцией в БД принято называть упорядоченную последовательность операторов обработки информации, которая может перевести БД из одного состояния в другое.
В РБД так может называться оператор/операторы, которые выполнены в виде последовательных операций, представляющих единую задачу.
Операторы должны выполняться одновременно и как целое. Они могут быть записаны в БД вместе или не записываются вообще ни в каком виде.
Соответствие требованиям
Чтобы соблюдать целостность, все транзакции внутри БД должны соответствовать нескольким требованиям:
Особенности NoSQL
Для сравнения SQL и NoSQL рассмотрим также особенности второго названного типа БД. В отличие от SQL, в NoSQL вся информация хранится без четко установленной структуры и явных связей между всеми данными. Здесь хранятся не какие-то структурированные и четкие таблицы, а любые сведения, которые могут быть представлены в виде текстового документа, аудиофайла или публикации в интернете.
Так как в подобных базах можно хранить практически любые данные, они широко применяются в разнообразных приложениях для ПК и смартфонов. Они идеально подходят для всех случаев, когда больше важна не структурированность понятных данных, а гибкая и легко масштабируемая БД, характеризующаяся к тому же высокими параметрами производительности.
Можно выделить несколько особенностей нереляционной базы данных.
Гибкость
Благодаря высокой гибкости NoSQL дают возможность выполнять разработку намного быстрее, допускают реализацию в несколько этапов. Модели с хорошей гибкостью подходят для хранения как неструктурированных, так и не полностью структурированных сведений.
Масштабируемость
НБД рассчитаны на масштабирование с использованием распределенных кластеров. Некоторые разработчики облачных решений проводят необходимые операции в фоновом режиме, что обеспечивает сервису максимальную управляемость.
Эффективность
Базы NoSQL оптимизируются для хранения шаблонов или конкретных данных, благодаря чему достигается значительно большая производительность, чем у РБД.
Виды SQL
Выделяют несколько наиболее распространенных и часто используемых SQL-баз:
Виды NoSQL
Выделяют несколько различных видов НБД:
На чем основывать выбор типа БД?
Некоторые представляют себе SQL vs NoSQL в качестве некоего противостояния. Однако в действительности его нет между РБД и НБД. Они в принципе используются в разных случаях:
Отличия реляционной базы от нереляционной часто используются разработчиками для решения нескольких разных проблем в рамках одного проекта. Применение РБД и НБД решений позволяет запустить БД в разных конфигурациях, обеспечить их хорошую масштабируемость и надежность.
SQL против NoSQL на примере MySQL и MongoDB
Авторизуйтесь
SQL против NoSQL на примере MySQL и MongoDB
Когда необходимо выбрать СУБД, главный вопрос обычно заключается в выборе реляционной (SQL) или нереляционной (NoSQL) структуры. У обоих вариантов есть свои преимущества, а также несколько ключевых особенностей, которые стоит иметь в виду при выборе.
Основные различия
Представьте себе город — пусть он называется Город А, где все говорят на одном языке. Все дела ведутся на нём, он используется в любой форме коммуникации — в целом это единственное средство взаимодействия и взаимопонимания для обитателей города. Изменение языка в любой из сфер деятельности собьёт всех с толку.
Теперь представьте Город Б, где все обитатели говорят на разных языках. Они совершенно по-разному взаимодействуют с окружающим миром, и для них не существует «универсального» средства общения.
Эти два примера наглядно демонстрируют различия между реляционными и нереляционными базами данных, и за этими различиями скрываются ключевые особенности обеих СУБД.
Реляционные базы данных используют структурированный язык запросов (Structured Query Language, SQL) для определения и обработки данных. С одной стороны, это открывает большие возможности для разработки: SQL один из наиболее гибких и распространённых языков запросов, так что его выбор позволяет минимизировать ряд рисков, и будет особенно кстати, если предстоит работа с комплексными запросами. С другой стороны, в SQL есть ряд ограничений. Построение запросов на этом языке обязывает предопределять структуру данных и, как в случае с Городом А, последующее изменение структуры данных может быть губительным для всей системы.
Нереляционные базы данных, в свою очередь, предлагают динамическую структуру данных, которые могут храниться несколькими способами: ориентированно по колонкам, документо-ориентированно, в виде графов или на основе пар «ключ-значение». Такая гибкость означает следующее:
Масштабируемость
В большинстве случаев SQL базы данных вертикально масштабируемые, то есть вы можете увеличивать нагрузку на отдельно взятый сервер, наращивая мощность центральных процессоров, объёмы ОЗУ или системы хранения данных. А NoSQL базы данных горизонтально масштабируемы. Это означает, что вы можете увеличивать трафик, распределяя его или добавляя больше серверов к вашей СУБД. Всё равно, что добавлять больше этажей к вашему зданию, либо добавлять больше зданий на улицу. Во втором случае, система может стать куда больше и мощнее, делая выбор NoSQL базы данных предпочитаемым для больших или постоянно меняющихся структур данных.
Структура
В реляционных СУБД данные представлены в виде таблиц, в то время как в нереляционных — в виде документов, пар «ключ-значение», графов или wide-column хранилищ. Это делает SQL базы данных лучшим выбором для приложений, которые предполагают транзакции с несколькими записями — как, например, система учётных записей — или для устаревших систем, которые были построены для реляционных структур.
В число СУБД для SQL баз данных входят MySQL, Oracle, PostgreSQL и Microsoft SQL Server. Для работы с NoSQL подойдут MongoDB, BigTable, Redis, RavenDB Cassandra, HBase, Neo4j и CouchDB.
SQL vs. NoSQL: MySQL или MongoDB
Разобравшись с ключевыми структурными различиями SQL и NoSQL баз данных, стоит внимательно рассмотреть их функциональные особенности на примере MySQL и MongoDB.
MySQL: реляционная СУБД
MongoDB: нереляционная СУБД
Какую СУБД выбрать?
MySQL — верный выбор для любого проекта, который может положиться на предопределённую структуру и заданные схемы. С другой стороны, MongoDB — отличный вариант для быстрорастущих проектов без определённой схемы данных. В особенности если вы не можете определить схему для своей базы данных, вам не подходит ни одна из предлагаемых другими СУБД или в вашем проекте она постоянно меняется, как, например, в случае с мобильными приложениями, системами аналитики в реальном времени или контент-менеджмента.
5 подводных камней нереляционных баз данных
Когда речь заходит о нереляционных базах данных, не все видят две стороны одной медали: многие упускают из виду то, что у этих баз данных есть не только преимущества, но и недостатки, которые могут стать источником множества проблем 😉.
Управление схемой БД
В каждой нереляционной базе данных реализован свой подход к схеме. В одних схемы нет вовсе (MongoDB), в других она динамична (Elasticsearch), а в третьих — напоминает схему реляционных баз данных (Cassandra). В концептуальной модели данные всегда имеют определённую структуру: сущности, поля, имена, типы, отношения. Независимо от типа базы, физическая модель является представлением концептуальной модели.
Нереляционные базы данных дают нам больше свободы в том, что касается схемы. Так в MongoDB мы можем добавить два разных документа с одинаковыми именами полей, но разными типами. Стоит ли так делать? Лучше не надо. Может ли такое случиться? Конечно, может. Но человеку свойственно ошибаться, и элементарная ошибка может поломать приложение.
Другая проблема связана с отношениями между сущностями. Даже если в БД нет связей, отношения между данными приходится документировать. Из реляционной базы данных можно сгенерировать модель «сущность — связь». В случае нереляционных баз данных это может оказаться невозможным.
При использовании нереляционных баз данных нужно помнить о проблемах, связанных со схемами управления данными и проверкой данных. Без этого данные могут «взорваться». Интересный факт: некоторые компании заменяют MongoDB на PostgreSQL (eng).
Более низкая величина погрешности
Причиной высокой производительности нереляционных баз данных является правильное моделирование, индексирование и секционирование данных. В реляционной базе данных можно добавлять столбцы, преобразовывать таблицы, перебрасывать данные из одной таблицы в другую, добавлять индекс, если забыли сделать это ранее. В нереляционных базах данных это будет невозможно ни в каких случаях. И тогда придётся задействовать внешние инструменты, такие как Apache Spark, или даже удалить и создать заново модель данных.
В Elasticsearch при отсутствии схемы или отображения индекса, приходится использовать, например, Reindex API. То есть нужно будет повторно индексировать данные в другой индекс.
В Cassandra можно лишь фильтровать по разделам и ключам кластеризации. Если к ключу забыли добавить один из столбцов, есть ещё возможность добавить индекс. Однако это может свести на нет производительность, если мощность отношения велика.
Никаких ACID
ACID-свойства упрощают написание кода. Нет необходимости обрабатывать ошибки, связанные с тем, что данные в таблице X уже имеются, а в таблице Y их ещё нет (если это вообще так и есть). Из теоремы Брюера известно, что существуют непротиворечивые и целостные в конечном итоге базы данных. Самой популярной базой данных такого типа является Apache Cassandra. Согласованность в конечном счёте требует иного подхода к моделированию данных и логике приложения. Код должен быть написан в более защитном стиле, так как нет уверенности, что только-только изменённая запись тут же будет доступна из другой части приложения. HBase является примером такой целостной базы данных, но даже в Cloudera считают, что она не заменит реляционную базу данных (eng). Некоторые базы данных позиционируют себя как непротиворечивые, да и то согласованность их обеспечивается лишь до определённых пределов. Например, MongoDB предоставляет транзакции, но транзакции с несколькими документами доступны только с версии 4.0 (eng).
Никаких нереляционных баз данных
Недостатком нереляционных баз данных является отсутствие… реляционных баз данных 😁. Нравится это кому-то или нет, но реляционные базы данных — это основа для данных. Многие аналитики используют реляционные базы данных каждый день, и изучение другого языка может отбить у них охоту пользоваться базой данных. Поэтому были созданы Spark SQL и Beam SQL.
Ограниченный анализ и/или никаких JOIN
Это небольшое обсуждение различий между системами OLTP и OLAP. Мы привыкли использовать операторы GROUP BY и JOIN, но не в каждой базе данных предусмотрены такие возможности. В силу особенностей базы данных агрегирование и слияние могут быть очень ограниченными (если они вообще возможны). В случае с Apache Cassandra необходимых аналитических возможностей часто достигают путём объединения кластера Apache Spark.
Заключение
Так стоит ли использовать нереляционные базы данных? Конечно же, стоит. Необходимо помнить, что каждая база данных создавалась для решения определённого класса задач. Повернуть «судьбу» возможно, но могут быть последствия. Шурупы легче завинчивать отверткой, гвозди забивать — молотком, а стены красить — валиком.
Интересная альтернатива — базы данных NewSQL. Примерами таких БД являются CockroachDb и Spanner. Они решают проблемы традиционных реляционных баз данных (в основном проблему масштабирования), сохраняя при этом ACID-свойства.