NoSQL — no party. Что нужно знать о нереляционных базах данных

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

Пришло время для NoSQL, или в чем проблема реляционных БД

Для начала предлагаю разобраться с термином NoSQL. Может показаться, что речь идет об отсутствии SQL-запросов, но это заблуждение. С нереляционными базами данных можно общаться и с помощью привычных реквестов. Поэтому NoSQL фактически означает “Not only SQL”.

Необходимость введения отличной от SQL базы данных назревала давно. Последние 15 лет объемы данных стремительно растут. Например, Instagram в свое время вышел на уровень загрузки около 1000 фотографий и пересылки 8500 сообщений в секунду. Сегодня эти показатели в разы выше. Если обрабатывать значительные ресурсы данных классическими методами реляционных баз данных, система в конце концов остановится.

Главная проблема SQL – невозможность масштабирования. Увеличение объема данных в одном узле замедляет БД. Можно добавить память и процессоры. Однако CPU и скорость чтения дисков дошли до предела. Ситуацию усложняет необходимость создания для сервера минимум двух реплик. Это необходимо для надежности хранения данных при падении железа. К тому же один крутой сервер стоит дороже, чем несколько простых с аналогичной суммарной мощностью.

В определенный момент масштабирование SQL-баз попыталось решить технологией шардирования. В результате есть фактически несколько разных БД. А это совсем другая схема работы. Однако хуже другое – связи между образованными шардами не работают. Их невозможно масштабировать в принципе. С нереляционными базами таких проблем нет. Они стабильны с любым объемом данных.

Особенности нереляционных БД

Традиционный подход к хранению и обработке данных описывает аббревиатура ACID:

• Atomicity (атомарность);
• Consistency (согласованность);
• Isolation (изоляция);
• Durability (надежность).

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

В архитектуре NoSQL работает другой подход – CAP:

• Consistency (согласованность)
• Availability (доступность)
• Partition Tolerance (допустимость разделения).

Согласованность есть, без нее нет смысла в хоть какой БД. Однако требования менее жесткие.

Главный принцип нереляционной модели – данные распределяются между серверами. Таким образом удается масштабирование, но это приведет к нарушению целостности данных. Обращаясь к серверу, в котором данные еще не обновились, вы рискуете получить устаревшую информацию. В конце концов, лаг в актуализации реплик есть и в реляционной модели. Опыт показывает, что задержка обновления в NoSQL выше, но с каждым днем ​​разница сокращается. В настоящее время нереляционные базы декларируют Eventually Consistency. В частности, DynamoDB заявляет о лаге 10 мс. Такой показатель доступен не всегда, но все равно отличный.

Как оказалось, бизнес готов пойти на такие риски ради преимуществ NoSQL. Рассмотрим это на примере банковских транзакций. Согласованность данных здесь считается критически важной. На самом же деле банки идут на послабление. Их базы данных огромны. Потребуется много времени на обработку тысяч одновременных запросов от пользователей банкинга. Если ставить их в очередь на сверку (например, при выдаче денег в банкомате), люди могут не дождаться реакции.

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

Кроме согласованности, есть разница и в доступе к данным. Для бизнес-аналитика это важный момент, в частности во время проведения OLAP-анализа. Реляционная БД больше подойдет для выполнения сложных запросов, оценки данных с разных сторон и построения прогнозов. Хотя в бизнесе мы можем предусмотреть до 80-90% шаблонов доступа, которые будут описывать возможные запросы. Это подразумевает OLTP-подход, соответствующий нереляционной БД.

В NoSQL следует делать только те запросы, которые в принципе эффективно выполнять. Возможность запроса должна быть заложена при проектировании базы. В противном случае системе придется сканировать всю БД. Это сводит на нет все преимущества скорости обработки запросов.

Что мы имеем: реляционные базы идеальны для хранения нормализованных данных, а нереляционные — оптимальные для вычислений, особенно облачных. Это вполне отвечает современным требованиям к архитектуре приложений и очень удобно в работе.

Виды нереляционных баз данных

Существует более 200 NoSQL баз пятнадцати типов. Две трети из них приходится на четыре основные категории. Остановлюсь подробнее на каждой:

• Key-Value. Означает базу по принципу «ключ-значение». Это самая популярная NoSQL-схема. За ней работает половина нереляционных баз данных. Проще говоря, это огромная таблица, в которой одно поле является ключом, а другие – атрибутами. Пример такой БД – DynamoDB.
• Document-based. Схема хранения документов JSON объектов. Они не структурированы, каждый из них может иметь разное количество и разновидности полей, атрибутов. А это кардинально отличается от SQL, где нужно нормализовать данные с четким набором полей. Как пример – MongoDB.
• Wide column-based. Фактически это Key-Value, только транспонируемая. В этой базе ключ ищут не по строкам, а по атрибутам. Это удобно при наличии многих атрибутов, поэтому проще делать поиск колонками, чем строками. Пример такой БД – Cassandra.
• Graph-based. Это графовые базы данных. Их часто используют в соцсетях. Пригодятся для систем, где один узел имеет много типов связей. Например, когда один аккаунт связан с другими, с лайками отдельных постов, с перепостами чужих сообщений и т.п. К этому типу относится Neo4j.

Как проектировать нереляционные базы данных

Каждый тип NoSQL имеет свои особенности. Я остановлюсь на Key-Value как наиболее распространенной нереляционной базе данных. Тем более эта база есть в одном из моих проектов – а именно DynamoDB. Ее выбор, как и любой другой базы, сложно до конца назвать рациональным. На конечное решение влияет множество факторов: от бизнес-требований до пожеланий заказчика. Хотя это не отменяет попытки осознанной оценки проекта.

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

• В проекте большой датасет. Если у вас более 1 ТВ данных и их индекс не вмещается в оперативную память, лучше отказаться от реляционной модели.
• Высокая скорость апдейта. Если необходимо более 100 KUps, выбирайте NoSQL.
• Доступность. Нереляционная база может иметь фиксированную latency на уровне 2 мс и обеспечивать высокую скорость чтения, пинг, а также отсутствие блокировок. В SQL это возможно только на небольших датасетах.
• Стабильный шаблон доступа. NoSQL идеально подойдет для бизнес-приложений, где можно выделить четкие шаблоны доступа. Это могут быть запросы, которые не изменяются или изменяются медленно. К примеру, перечень определенных товаров в онлайн-магазине.
• Учет преобладает над анализом. Это упомянутый подход OLTP, связанный с шаблонами доступа.

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

В следующей части статьи я расскажу, как смоделировать базу данных на примере DynamoDB. Следите за обновлениями 😉