Когда речь заходит о нереляционных базах данных, не все видят две стороны одной медали: многие упускают из виду то, что у этих баз данных есть не только преимущества, но и недостатки, которые могут стать источником множества проблем 😉.
Управление схемой БД
В каждой нереляционной базе данных реализован свой подход к схеме. В одних схемы нет вовсе (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-свойства.
Читайте также:
- Почему в базе данных происходит взаимоблокировка?
- Моделирование связей графа в DynamoDB
- Скрытые алмазы: уведомления об изменениях в БД
Читайте нас в Telegram, VK и Яндекс.Дзен
Перевод статьи Maciej Szymczyk: 5 Pitfalls of NoSQL Databases
