Библиотека сайта rus-linux.net
Экосистема NoSQL
Глава 13 из книги "Архитектура приложений с открытым исходным кодом", том 1.
Оригинал: The NoSQL Ecosystem
Автор: Adam Marcus
Дата публикации: 7 Июля 2012 г.
Перевод: А.Панин
Дата перевода: 9 Мая 2013 г.
В отличие от большинства других проектов, описанных в данной книге, NoSQL является не инструментом, а экосистемой, сформированной несколькими аналогичными и конкурирующими друг с другом инструментами. Программные компоненты из категории NoSQL являются альтернативой реляционным системам баз данных, используемых для хранения данных и использующих язык SQL для запросов. Для понимания принципов работы систем NoSQL нам придется понять принцип работы ряда доступных систем и рассмотреть вопрос о том, как архитектура каждой из этих систем расширяет набор ее возможностей для хранения данных.
Если вы обдумываете возможность использования системы NoSQL для хранения данных, вам в первую очередь придется разобраться в обширном наборе систем NoSQL. Системы NoSQL лишены множества полезных возможностей, присущих традиционным базам данных, и операции, обычно реализуемые в рамках системы базы данных, в данном случае возлагаются на разработчиков приложений. Это потребует от вас дополнительной работы в роли системного архитектора, что в свою очередь предусматривает более глубокое понимание принципов построения таких систем.
13.1. Что в имени?
Перед рассмотрением систем NoSQL, давайте сначала разберемся с их названием. Образно говоря, система NoSQL предоставляет пользователю интерфейс запросов, не использующий язык SQL. Сообщество разработчиков систем NoSQL в общем случае рассматривает их более глобально и заявляет, что системы NoSQL являются альтернативой традиционным реляционным базам данных и позволяют разработчикам проектировать приложения, использующие не только интерфейс SQL-запросов. В некоторых случаях вы сможете заменить реляционную базу данных на альтернативную систему NoSQL, а в некоторых вам придется применять метод комбинирования и подбора систем (mix-and-match approach) для решения различных проблем, с которыми вы столкнетесь во время разработки приложения.
Перед погружением в мир систем NoSQL, давайте рассмотрим случаи, в которых язык SQL и реляционная модель будут соответствовать вашим требованиям, а также другие случаи, в которых система NoSQL может оказаться более предпочтительной.
13.1.1. Язык SQL и реляционная модель
SQL является декларативным языком для осуществления запросов данных. В декларативном языке разработчик задает действия, которые должна выполнить система вместо процедурного описания того, как система должна выполнить эти действия. Несколько примеров: поиск записи работника с идентификатором 39, выделение только информации о имени и номере телефона работника из его записи, вывод записей о работниках бухгалтерии, подсчет количества работников в каждом отделе или объединение данных из таблицы с информацией о работниках с данными из таблицы с информацией об управляющих.
В первом приближении язык SQL позволяет вам выполнить эти запросы без понимания того, как данные размещаются на диске, какие индексы используются для доступа к данным или какие алгоритмы используются для обработки данных. Важным архитектурным компонентом большинства реляционных баз данных является оптимизатор запросов, который принимает решение о том, какие из множества логически эквивалентных схем запросов следует выполнить для получения наиболее быстрого ответа на запрос. Эти оптимизаторы обычно работают лучше среднестатистического пользователя базы данных, но иногда они не располагают достаточным количеством информации или используют в значительной степени упрощенную модель системы, что затрудняет генерацию наиболее эффективного запроса.
Реляционные базы данных, наиболее часто используемые на практике, следуют реляционной модели данных. В рамках данной модели различные данные из реального мира хранятся в различных таблицах. Например, все данные работников могут хранится в таблице "Employees", а все данные отделов могут храниться в таблице "Departments". Каждая строка таблицы содержит различные свойства, хранимые в столбцах. Например, работники могут характеризоваться идентификаторами, жалованием, датами рождения, а также именами и фамилиями. Каждое из этих свойств будет храниться в столбце таблицы работников "Employees".
Реляционная модель идет рука об руку с языком запросов SQL. Простые запросы SQL, такие, как фильтры, извлекают все записи, поля которых соответствуют какому-либо выражению (т.е. идентификатор работника = 3 или жалование > $20000). Более сложные запросы заставляют базу данных выполнить дополнительную работу, такую, как объединение данных из нескольких таблиц (т.е. как называется отдел, в котором числится работник с идентификатором 3?). Другие сложные запросы, такие, как запросы вычисления сводных показателей (т.е. какова средняя зарплата моих работников?) могут приводить к полному обходу таблиц.
- Сложность ведет к непредсказуемости. Выразительность языка SQL затрудняет оценку нагрузки на систему в ходе выполнения каждого из запросов, а таким образом и оценку общей нагрузки. В то время, как более простые языки могут приводить к усложнению логики приложений, они упрощают работу систем хранения данных, которые отвечают только на простые запросы.
- Существует множество путей моделирования проблемы. Реляционная модель данных является строгой: схема, ассоциированная с каждой таблицей, задает данные в каждой строке. Если мы храним менее структурированные данные или строки со значительно различающимися столбцами, реляционная модель может оказаться излишне строгой. Аналогично, разработчики приложений могут не признать реляционную модель в качестве превосходного метода структурирования любых типов данных. Например, большая часть логики приложений разработана с использованием объектно-ориентированных языков программирования и использует такие высокоуровневые объекты, как списки, очереди и множества, а также некоторые разработчики могут пожелать продолжить использовать их постоянный уровень абстракции для ее моделирования.
- Если объем данных превышает доступный объем хранилища на сервере, таблицы из базы данных должны быть распределены между серверами. Для предотвращения объединений данных из таблиц, в ходе которых будет осуществляться их передача по сети с целью распределения данных по различным таблицам нам придется произвести денормализацию. Денормализация позволяет разместить данные из нескольких таблиц, которые могут потребоваться одновременно, в одном и том же месте. Это делает нашу базу данных похожей на систему хранения данных с идентификаторами в виде ключей, а нам остается только задуматься о том, какая из других моделей данных может подойти лучшим образом.
Отказ от рассмотрения результатов многолетнего проектирования без видимых на то причин не является разумным решением. Когда вы решаете хранить ваши данные в базе данных, рассматривайте возможность использования языка запросов SQL и реляционной модели, которые стали результатом многих лет исследования и разработки и предоставляют богатые возможности моделирования и понятные гарантии в отношении сложных операций. Системы NoSQL являются хорошим решением в том случае, если ваша задача является такой специфичной, как хранение больших объемов данных, работа под большими нагрузками или работа со сложной моделью данных, для чего язык SQL и реляционные базы данных могут быть не в достаточной степени оптимизированы.
13.1.2. Исходные данные для проектирования систем NoSQL
Системы NoSQL в большей степени создавались под влиянием документации от исследовательского сообщества. В то время, как многие документы описывали решения, положенные в основу архитектуры систем NoSQL, две системы следует выделить особо:
Система BigTable компании Google [CDG+06] представляет интересную модель данных, которая упрощает реализацию многоколоночного отсортированного хранилища данных истории. Данные распределяются по множеству серверов с использованием иерархической схемы распределения на основе диапазонов, а данные обновляются в строгой согласованности (подход, который мы обсудим позднее в Разделе 13.5).
Система Dynamo компании Amazon [DHJ+07] использует отличное от предыдущего распределенное хранилище данных с доступом на основе ключей. Модель данных системы Dynamo проще за счет установления соответствия ключей специфичным для приложений бинарным данным. Модель распределения данных более устойчива к ошибкам, но эта цель достигается путем применения подхода, заключающегося в снижении степени согласованности данных и называемого конечной согласованностью (eventual consistency).
Мы подробно рассмотрим каждое из этих решений, но важно понимать, что многие из них могут комбинироваться и подбираться друг для друга. Некоторые системы NoSQL, такие, как HBase1, реализуют архитектуру, аналогичную BigTable. Другая система NoSQL под названием Voldemort2 копирует многие возможности системы Dynamo. Также другие проекты NoSQL, такие, как Cassandra3, переняли ряд возможностей из системы BigTable (ее модель данных), а также ряд других возможностей из системы Dynamo (ее схемы распределения и поддержания согласованности данных).
13.1.3. Характеристики и соображения
Системы NoSQL оставляют в стороне мощный стандарт запросов SQL и являются более простым, но менее обобщенным решением для проектирования систем хранения данных. Эти системы были созданы с надеждой на то, что упрощение механизма обработки данных позволит архитектору лучше предугадать производительность каждого из запросов. В множестве систем NoSQL сложная логика запросов должна быть реализована на стороне приложения, в результате чего производительность запросов к хранилищу данных может быть оценена более точно из-за отсутствия значительных изменений в этих запросах.
Системы NoSQL реализуют больший набор функций, чем поддержка декларативных запросов для манипуляций реляционными данными. Семантики транзакций, постоянство значений и долговечность хранения данных являются гарантиями, требуемыми от систем баз данных такими организациями, как банки. Транзакции гарантируют, что будут записаны либо все данные, либо ничего при комбинировании нескольких потенциально сложных операций в рамках одной, аналогичной списанию денежных средств с одного счета и переводу их на другой счет операции. Постоянство значений заключается в том, что все выполняемые после обновления значения запросы будут возвращать обновленное значение. Долговечность хранения данных гарантирует то, что как только значение подвергается изменению, оно сохраняется в постоянном хранилище (таком, как жесткий диск) и может быть восстановлено в случае краха базы данных.
Системы NoSQL отказываются от некоторых из этих гарантий в обмен на улучшение производительности, что позволяет добиться допустимого и предсказуемого поведения некоторых, не имеющих отношения к банковским системам приложений. Эти ослабления гарантий вместе с изменениями модели данных и языка запросов обычно упрощают безопасное распределение базы данных по множеству машин в случае увеличения объема хранимых данных до пределов возможностей системы хранения данных отдельной машины.
Системы NoSQL находятся в большей степени на раннем этапе своего развития. Архитектурные решения описанных в данной главе систем являются реализациями требований различных пользователей. Наиболее сложной задачей при обобщении архитектурных возможностей некоторых проектов с открытым исходным кодом является то обстоятельство, что каждый проект является движущейся мишенью. Помните о том, что подробности реализации отдельных систем будут меняться. Когда вы будете выбирать систему NoSQL, вы можете использовать эту главу в качестве руководства, но не для выбора системы на основе реализуемых возможностей.
- Модель данных и запросов: Представлены ли ваши данные в виде строк, объектов, структур данных или документов? Можете ли вы осуществлять запрос к базе данных, предусматривающий расчет с объединением множества записей?
- Долговечность: При изменении значения следует ли немедленно сохранять его в постоянном хранилище? Должно ли оно храниться на нескольких машинах для восстановления в случае потери данных на одной из них?
- Масштабируемость: Могут ли ваши данные размещаться на одном сервере? Обуславливает ли количество операций чтения и записи необходимость использования множества дисков для работы под нагрузкой.
- Распределение: Необходимо ли хранить данные на нескольких серверах для масштабирования системы, доступности данных, а также долговечности их хранения? Как вы узнаете о том, какая запись находится на каком из серверов?
- Постоянство: Если вы разделили данные и скопировали их на множество серверов, то как серверы будут взаимодействовать друг с другом при изменении записи?
- Семантики транзакций: В случаях, когда вы выполняете последовательности операций, некоторые базы данных позволяют объединить их в транзакцию, которая предоставляет некоторое подмножество гарантий ACID (Атомарность (Atomic), Постоянство (Consistency), Изоляция (Isolation) и Долговечность (Durability)) для текущей и уже выполняемых транзакций. Требует ли ваша бизнес-логика этих гарантий, обычно приводящих к потерям производительности?
- Производительность отдельного сервера: Если вы хотите безопасно хранить данные на диске, какие структуры данных на диске наиболее оптимальны для нагрузок с большим количеством операций чтения и записи? Является ли операция записи на диск причиной снижения производительности?
- Анализ нагрузок: Мы будем в значительной степени обращать внимание на нагрузки, связанные с поиском данных в случаях необходимости запуска отзывчивого пользовательского веб-приложения. В ряде случаев вам может понадобиться создавать сопоставимые по размерам с хранящимися данными отчеты, например, с целью сбора статистики в отношении множества пользователей. Требуются ли в вашем случае для вашего набора инструментов подобные функции?
Хотя мы рассмотрим все эти вопросы, последние три одинаково важных вопроса будут обсуждаться в меньшей степени.
Продолжение статьи: 13.2. Модели данных и запросов систем NoSQL.