Когда отказаться от SQL
По мере роста и изменения технологий вполне естественно, что методы взаимодействия с ними (и сама их форма) будут трансформироваться, чтобы наилучшим образом соответствовать потребностям пользователей. Мы можем ясно видеть это на бесчисленном множестве новых языков программирования, появившихся за последнее десятилетие, каждый из которых пытается более точно отражать образ мышления программистов.
SQL, изобретенный в 70-х годах инженерами IBM, был основным продуктом технологии баз данных с момента ее создания. Создавая возможность связывать таблицы вместе, SQL упрощает доступ к связанным данным и творит чудеса с целостностью тех же данных; никакая информация не сохраняется дважды - все существует как часть отношения ко всему остальному.
Однако сейчас прошло почти 50 лет с момента изобретения SQL, и количество данных, которыми необходимо манипулировать, резко увеличилось. SQL изо всех сил пытается угнаться за растущими требованиями инженеров, использующих его, из-за более крупных серверов и более медленных скоростей. Решение этой проблемы пришло в довольно простой форме: базы данных NoSQL.
Что значит быть базой данных NoSQL?
Распространенная ошибка, которую допускают люди при рассмотрении базы данных NoSQL, - это предположение, что NoSQL означает, что в ней не будет SQL. На самом деле базы данных NoSQL - это, по сути, нереляционные базы данных. Это означает, что в них нет переплетения внешних ключей, составляющих ядро системы реляционной базы данных.
В этой статье мы будем использовать MongoDB в качестве нашей модели базы данных NoSQL, но существует множество сервисов в различных моделях, которые вы могли бы использовать. В назидание:
- Базы данных документов: MongoDB, CouchDB
- Колонка Базы данных: Apache Cassandra
- Хранилища ключей и значений: Redis, Couchbase Server
- Системы кэширования: Redis, Memcached
- Графические базы данных: Neo4J
У каждого из них есть свои преимущества / недостатки. Хранилища "ключ-значение" невероятно эффективны, если ваши данные очень простые; Базы данных документов - это хранилища без схемы, смежные с JSON, которые предоставляют данные невероятно интуитивно понятным и надежным способом.
Однако эта статья посвящена пониманию того, когда вам следует сделать выбор в пользу использования NoSQL вместо RDMS (системы управления реляционными базами данных). Имея это в виду, давайте погрузимся в то, что делает NoSQL настолько популярным в настоящий момент.
Сравнение NoSQL с реляционными базами данных
Истинное преимущество баз данных NoSQL и причина, по которой они стали популярными, - это масштабируемость. Как видно на рисунке 1, базы данных NoSQL можно увеличивать до бесконечности без значительного снижения производительности. С другой стороны, реляционные базы данных склеиваются относительно быстро. Стоит отметить, что реляционная модель имеет небольшой прирост скорости в базах данных малого и среднего размера.
Кроме того, реляционные базы данных отлично справляются с одной задачей: они извлекают определенные данные. SQL разработан для использования отношений для очень эффективного анализа и возврата определенных записей. Обратной стороной является то, что когда запись вставляется или обновляется, ей необходимо проверить и обновить все эти отношения. Для приложения с большими данными это просто не идеально. Если у вас есть миллиарды и миллиарды записей, у вас может быть много времени, затрачиваемого на вставку или обновление записей. Рисунок 2 прекрасно иллюстрирует этот момент.
Кроме того, если ваша схема часто меняется, вам нужно будет разработать схему, которая будет учитывать каждое небольшое изменение. С базой данных NoSQL у вас нет таких проблем. Данные просто помещаются на сервер в виде большого двоичного объекта. Вы получаете то, что вкладываете, и нет никаких правил о том, что можно и что нельзя вкладывать.
Последнее важное соображение - это то, о чем многие программисты предпочли бы не думать: физические ограничения. Поскольку они связаны между собой по необходимости, таблицы RDMS должны иметь возможность взаимодействовать друг с другом и сами с собой. В результате получается классическая серверная башня или отдельная большая машина.
Поскольку базы данных NoSQL просто хранят огромные объемы данных, им фактически не нужно иметь возможность общаться друг с другом; приложению просто необходим доступ к ним. В результате они могут быть распределены по нескольким машинам, каждая из которых не должна знать о других. В результате серверы NoSQL на самом деле намного дешевле и, как правило, более гибки с точки зрения занимаемого места.
Синтаксис
Как и в случае со всеми технологиями, всегда следует учитывать время, необходимое для настройки и продуктивной работы. Стоит ли выгода от переноса головной боли от переезда?
SQL - это собственный язык программирования с очень специфическим синтаксисом. С другой стороны, MongoDB использует язык, очень похожий на javascript и многие другие языки интерфейса. Данные вставляются как простые старые объекты Javascript (POJO) и извлекаются аналогичным образом.
Вот сравнение синтаксиса создания таблиц для обоих языков:
Сразу видно, что синтаксис MongoDB не только очень похож на синтаксис Javascript, но и гораздо более лаконичен. Более того, MongoDB невероятно удобочитаема и проста для понимания любым опытным программистом - для этого не нужно много времени на обучение.
Единственное примечание, которое мы видим здесь, - это строка 4: базы данных SQL допускают ограничения на данные. Это то, что можно назвать целостностью данных. SQL может дать гарантии относительно своих данных, которых нет в NoSQL. Он может выполнять проверку на стороне сервера и предотвращает повторение данных. Если один объект совместно используется многими через отношения, этот объект нужно будет много раз хранить в базе данных NoSQL. Хотя NoSQL действительно увеличивает скорость и простоту использования за счет снижения специфичности, стоит отметить компромиссы, необходимые для достижения такой же эффективности.
Этот более простой. Опять же, пример MongoDB по-прежнему выглядит как javascript, а SQL по-прежнему выглядит немного более чуждым, но в целом они очень похожи. Обновление немного сложнее:
Хотя эти двое выглядят по-разному, на самом деле они следуют схожему шаблону. Сначала они оба определяют используемую таблицу (MongoDB хранит таблицы по имени как часть переменной db). Мы вызываем update для этой таблицы, даем параметр поиска (аргумент 1 из my_table.update()) и поле / значение для обновления.
На этом этапе должно быть ясно, что MongoDB использует базовый, легко понимаемый синтаксис для выполнения большей части своей работы; Если вы уже разбираетесь в том, как работает JSON, не составит труда разобраться во второй половине дня.
Что лучше?
По правде говоря, ни то, ни другое. Эти два подхода существуют, потому что они были созданы для удовлетворения конкретных потребностей. По мере того, как глубина наших научных знаний растет, естественно, что будут возникать новые технологии для решения проблем, которые возникли с новых рубежей.
RDMS была создана, чтобы упростить отношения между элементами базы данных, сделав ее интуитивно понятной и быстрой. NoSQL пришел, чтобы решить проблему перегрузки серверов RDMS горами данных. Ключ в понимании ограничений и ограничений ваших собственных данных и в том, как лучше всего к ним подойти. В общем, задайте следующие вопросы:
- Получу ли я выгоду от установленной схемы?
- Сколько записей нужно будет хранить в моей базе данных?
- Должны ли мои данные соответствовать требованиям безопасности? (многие базы данных NoSQL - нет)
- Сколько места я смогу сэкономить, обеспечив уникальность каждого объекта в моей базе данных? Насколько я забочусь о целостности моей базы данных?
- Какие операции будут распространены в моей базе данных? Буду ли я делать много обновлений, выбора или вставки?
Когда вы ответите на эти вопросы, вы начнете видеть форму своей базы данных. На этом этапе остается просто выбрать базу данных, которая наиболее точно отражает ваши потребности. Дело не в том, что правильно или неправильно: дело в том, чтобы знать, когда использовать отвертку, а когда - молоток. В мире полно инструментов, и хорошего инженера нельзя застать мертвым, пытаясь забить гвозди гаечным ключом.
Источники
Учебники Traversy Media: Введение в базы данных NoSQL
Баннер предоставлен:
