В этой статье мы сравним реляционные (SQL) и нереляционные (NoSQL) базы данных. Попутно рассмотрим историю их создания и сценарии вероятного использования.
Содержание:
1. На заре истории данных
2. Эволюция NoSQL
3. Теорема CAP
4. ACID и BASE
5. Дизайн нереляционного хранилища данных
6. Нереляционные базы данных против реляционных баз данных
7. Будущее нереляционных баз данных
Заключение
Прежде чем приступим к рассмотрению баз данных NoSQL, вспомним историю баз данных вообще.
Первыми появились реляционные базы данных; они (точнее, их строгое формальное обоснование) были изобретены Эдгаром Ф. Коддом в 1970 году (знаменитые 13 правил Кодда).
Реляционная база данных упорядочивает данные по строкам и столбцам, привязывая уникальный ключ к каждой строке.
Почти все реляционные системы баз данных используют язык структурированных запросов (SQL) и чрезвычайно сложны. Они традиционно являются жесткими, малоизменяемыми системами, и их возможности хранить неструктурированные или малоструктурированные данные весьма ограничены.
Вместе с тем, реляционные СУБД широко используются и незаменимы для ведения точных транзакционных записей, исторических данных и множества других вариантов использования в организациях любого размера.
В середине 1990-х, с ростом популярности интернета, реляционные базы данных перестали справляться с потоком информации, требуемой пользователями, а также с большим разнообразием типов данных, возникшим в результате этого развития. Это привело к разработке нереляционных баз данных, часто называемых NoSQL-базами.
Базы данных NoSQL обладают способностью могут быстро обрабатывать неструктурированные или слабо-структурированные данные и избегать жесткости, навязываемой SQL, заменяя «строго организованное» хранилище большей гибкостью.
Аббревиатура NoSQL впервые была использована в 1998 году Карло Строцци при названии своей легкой «реляционной» базы данных с открытым исходным кодом, в которой не использовался SQL. Это название всплыло снова в 2009 году, когда Эрик Эванс и Йохан Оскарссон использовали его для описания нереляционных баз данных.
Реляционные базы данных часто называют системами SQL. Таким образом термин NoSQL может означать либо «система без SQL», либо более общепризнаваемый перевод «не только SQL», чтобы подчеркнуть тот факт, что некоторые системы могут поддерживать языки запросов (более или менее подобные SQL).
NoSQL СУБД разрабатывалась, по крайней мере вначале, как ответ на все возрастающий объем веб-данных, как ответ на потребность в обработке неструктурированных данных и потребность в более быстрой их обработке. Модель NoSQL использует распределенную систему баз данных, то есть систему с несколькими компьютерами (серверами). Нереляционная система работает быстрее, использует ad-hoc-подход к организации данных и обрабатывает большие объемы данных разного типа. Базы данных NoSQL — лучший выбор для больших наборов неструктурированных данных по сравнению с реляционными базами данных из-за скорости NoSQL и его гибкости.
Системы NoSQL не только могут обрабатывать как структурированные, так и неструктурированные данные, но они также могут быстро обрабатывать неструктурированные большие данные (Big Data). Поэтому такие IT-гиганты, как Facebook, Twitter, LinkedIn и Google, одни из первых внедрили системы NoSQL в своих продуктах. Эти организации обрабатывают огромные объемы неструктурированных данных, координируя их майнинг, чтобы находить закономерности и извлекать бизнес-идеи. Big Data стал официальным термином в 2005 году.
Теорема CAP, также известная как теорема Брюера (в честь ее изобретателя Эрика Брюера), является важной частью нереляционных баз данных. В теореме утверждается, что распределенное хранилище данных «не может» одновременно обеспечивать более «двух из трех» установленных гарантированных свойств. Брюэр из Калифорнийского университета представил свою теорию осенью 1998 года, а в 1999 году она была опубликована как «принцип CAP». Три гарантии, которые не могут быть выполнены одновременно:
В 2002 году Нэнси Линч и Сет Гилберт из Массачусетского технологического института опубликовали формальное доказательство концепции Брюера, превратив ее в «истинную теорему».
Две самые популярные модели согласованности используют аббревиатуры ACID и BASE. Обе модели имеют преимущества и недостатки, и ни одна из них не является идеальной.
Аббревиатура ACID означает следующий набор принципов: атомарность, согласованность, изоляция и долговечность.
Концепция ACID была создана в 1983 году Тео Хердером и Андреасом Рейтером. Важность ACID заключается в том, что она обеспечивает безопасную среду для обработки данных. Это означает, что данные согласованы и стабильны в любой момент работы СУБД. Большинство графовых баз данных NoSQL (NoSQL Graph Databases) используют ограничения ACID для обеспечения безопасного и согласованного хранения данных.
Термин BASE стал популярным в 2008 году как альтернатива модели ACID. Доступность для масштабирования — важная функция для хранилищ данных, отвечающих модели BASE. Однако она не дает гарантии согласованности реплицированных данных во время записи. Модель BASE, вообще говоря, обеспечивает меньшую гарантированность, чем ACID. BASE используется в основном для агрегированных хранилищ, которые включают хранилища столбцов, документов и значений ключей.
Нереляционное хранилище данных — это, как правило, система с открытым исходным кодом, нереляционная, бессхемная (не поддерживающая схемы данных), горизонтально масштабируемая и использующая BASE для согласованности. Термин «эластичность» используется для систем хранения данных, являющихся масштабируемыми, свободными от схемы и допускающих быстрые изменения и быструю репликацию.
Вообще говоря, эти свойства были реализованы за счет проектирования хранилища данных NoSQL снизу вверх и оптимизации для горизонтального масштабирования. Эти системы часто поддерживают только низкоуровневые упрощенные API (такие как операции «получить» и «положить»). Как следствие, моделирование данных в нереляционных системах выглядит совершенно иначе, чем моделирование, используемое в реляционном мире, и следует принципиально другой философии.
NoSQL использует хранилища данных, оптимизированные для определенных целей. Обычно в NoSQL данные хранятся в одной из четырех категорий:
Хранилище «ключ-значение», также называемое базой данных ключей и значений, представляет собой систему хранения данных, предназначенную для хранения, извлечения и управления «ассоциативными массивами». Хранилище «ключ-значение» работает совершенно иначе, чем реляционная база данных. Реляционная база данных предварительно определяет структуру данных, используя набор таблиц, содержащих поля с четко определенными типами данных. Примеры реализации хранилища «ключ-значение»: Berkeley DB, Aerospike, Redis.
Хранилище документов, также называемое документно-ориентированной базой данных, представляет собой систему, предназначенную для хранения, поиска и управления «документально-ориентированной информацией», которую также называют полуструктурированными данными. Хранилища документов имеют некоторое сходство с хранилищами ключевых значений, но отличаются способом обработки данных.
Документо-ориентированная система использует внутреннюю структуру документа для идентификации и хранения. Хранилища документов сохраняют всю информацию для данного элемента в виде отдельного экземпляра в базе данных (а не разбросаны по таблицам, как в реляционных системах). Это упрощает отображение элементов в базе данных. Примеры: Cosmos DB, Elasticsearch; Aerospike также может использоваться как хранилище документов.
В хранилище с широкими столбцами используются таблицы, строки и столбцы, но, в отличие от реляционных баз данных, имена и форматы столбцов могут изменяться от строки к строке в одной и той же таблице. Они более гибкие. Хранилища с широкими столбцами часто поддерживают семейства столбцов, которые хранятся отдельно. Каждое семейство столбцов обычно содержит несколько столбцов, используемых вместе.
В пределах определенного семейства столбцов данные хранятся построчно, причем столбцы для конкретной строки хранятся вместе, а не каждый столбец отдельно. Хранилища широких столбцов, поддерживающие семейства столбцов, также называются базами данных семейств столбцов. Примеры — Azure Tables, Amazon DynamoDB.
Графовые базы данных — это, по сути, набор отношений. Каждая запись (узел) символизирует сущность (например, процесс, человека или объект). Каждая запись/узел может быть связана (соединена) с другой. Соединение называется «ребром» (edge) и представляет собой связь между двумя узлами. Каждый узел в графовой базе данных включает уникальный идентификатор, набор входящих и/или исходящих ребер и характеристики, которые представлены в виде «пар ключ-значение». Каждое ребро также имеет уникальный идентификатор, конечный и/или начальный узел и набор свойств. Примеры реализаций: Amazon Neptune, Neo4j.
У реляционных и нереляционных баз данных есть свои плюсы и минусы. В реляционных базах данных есть ограничение: каждый элемент данных может содержать только один атрибут. Возьмем пример продаж: каждая характеристика взаимоотношений клиента сохраняется в виде отдельной строки элементов в отдельных таблицах. Основные данные клиента содержатся в одной таблице, а сведения об аккаунте — в другой. Эти таблицы связаны отношениями, посредством первичных и внешних ключей.
С другой стороны, нереляционные базы данных сильно отличаются, особенно в случае хранилищ «ключ-значение». Пары «ключ-значение» позволяют сохранять несколько связанных элементов в одной «строке» одной таблицы.
Следует отметить, что нереляционная «строка» — это не то же самое, что строка в реляционной таблице. Например, в нереляционной таблице каждая строка может содержать сведения о клиенте и в то же время сведения о его контрагентах, продажах и истории платежей. Все данные одного клиента можно сохранить вместе как одну удобную запись.
Несмотря на то, что нереляционная база данных имеет определенные преимущества при хранении данных, она также имеет существенный недостаток — хранилища «ключ-значение» не могут «обеспечить» отношения между элементами. Это означает, что все данные клиента (имя, адрес, история платежей и т.д.) будут сохранены как одна запись.
В реляционной модели эти данные будут в разной степени структурированы, то есть храниться в нескольких таблицах, обеспечивая отсутствие избыточности и соблюдение целостности. Это означает, что реляционная модель имеет встроенный надежный способ обеспечения бизнес-логики и надежности на уровне движка базы данных. Например, использование первичного и внешнего ключа позволяет показать платежи в соответствующей учетной записи клиента. Поэтому реляционные базы данных остаются популярными.
Однако наивысшим приоритетом для веб-приложений является способность обслуживать большое количество пользовательских запросов, что является сильной стороной нереляционных баз данных. eBay, например, позволяет пользователям искать и просматривать опубликованные лоты. Лишь небольшое количество этих пользователей действительно будет делать ставки или бронировать товар, но в день будут просматриваться миллионы, а иногда и миллиарды страниц. eBay заинтересован в быстром отклике и хочет обеспечить быструю загрузку страницы, а не применять строгие бизнес-правила.
У нереляционных баз данных есть свои сильные и слабые стороны, как и у реляционных. Поскольку революция NoSQL продолжается, важно помнить, что «правильный инструмент для правильной работы» — это всегда полезный подход. Реляционные базы данных поддерживают точность и избыточность, в то время как нереляционные базы данных поддерживают исследования.
В настоящее время предпринимаются попытки объединить две системы баз данных. Гибридные системы добавляют функции типа SQL, такие как поддержка транзакций, объединения и настраиваемая согласованность. Кроме того, реляционные базы данных (например, Microsoft SQL Server) добавляют функции NoSQL, которые обеспечивают более прозрачную тактику при использовании горизонтального масштабирования.
Выскажем осторожное и оптимистичное предположение, что нереляционные и реляционные базы данных продолжат эклектичное слияние, добавляя сильные стороны, и, одновременно, сводя к минимуму слабые стороны друг друга.
В статье мы рассмотрели краткую историю и логику развития баз данных вообще, NoSQL в частности. Также рассмотрели наиболее важные модели NoSQL-подобных баз данных — хранилища «ключ-значение», хранилища документов, хранилища широких столбцов, графовые базы данных; обсудили достоинства и недостатки каждого подхода.
Дополнительно можно посмотреть данное видео по этой теме:
Сегодня мы поговорим о том, как выбрать лучшие курсы Power BI в Украине, особенно для…
В 2023 году во всех крупнейших регионах конкуренция за вакансию выросла на 5–12%. Не исключением…
Unicorn Hunter/Talent Manager Лина Калиш создала бесплатный трекер поиска работы в Notion, систематизирующий все этапы…
Edtech-стартап Mate academy принял решение отправить своих работников в десятидневный отпуск – с 25 декабря…
Служба безопасности Украины задержала в Киеве 46-летнего программиста, который за деньги устанавливал шпионские программы и…
IT-специалист Джордан Катлер создал и выложил на Github подборку разнообразных ресурсов, которые помогут достичь уровня…
