- PVSM.RU - https://www.pvsm.ru -
В последнее время все больше говорят про «NoSQL» — прямо «модный» тренд образовался. «Технологию» начинают активно использовать известные авторитетные компании, в т.ч. в высоконагруженных проектах с немалыми объемами данных — и кто-то восхищается, а кто-то обливает себя бензином и факелом выпрыгивает с 35 этажа с криком: "SQL ACID [1] forever!"
Причем о каком бы продукте не говорили, будь то MongoDB [2] или Cassandra [3] — нередко приходится наблюдать прямо таки религиозную восторженность и трепет, как будто речь идет о чем-то новом и священном.
А особенный трепет вызывают мелькающие в сети мозгораздирающие эскизы архитектур, типа кружочка из датацентров, работающих в «мастер-мастер репликации» на нескольких континентах:
Но… когда начинаешь серьезно использовать «новую» технологию в боевых проектах, понимаешь, откуда это все пошло [4], в чем причина тех или иных архитектурных решений: колечек датацентров и прочая мистика — формируется практическое и простое, «мурочное» понимание — которым хочется поделиться с коллегами, дабы не наделали архитектурных ошибок и не поплыли на плоту через океан. Об этом, в принципе, статья.
Ну вроде все предусмотрено — атомарность, согласованность, изоляция транзакций и надежность фиксации. Пробуй, строй, эксплуатируй. В ISO SQL прописали уровни изоляции транзакций [5] — ну что еще не хватило для полного счастья, когда можно все детерминировать?
Что вызвало причину появления «CAP ереси» [6] в стиле выбери только 2 из трех? :-)
Ответ очевиден — бизнесу нужны новые, «сверхзвуковые» возможности хранилищ данных:
Из популярных:
А электронный бизнес требует и требует:
Понятно, что этот поток требований медленно, но верно вел к суициду… но
… Но если долго просить программистов сделать невозможное — они сделают!
Не все знают, что для полноценного программирования достаточно языка C, а для людей с чувством прекрасного можно излить душу и на C++ — так нет, под давлением бизнеса: «как можно программировать быстрее и чтобы все могли?» — родились технологии, которые на мощном железе сейчас даже уже работают: C#, java, python, ruby ...
Так вот, прошло не так много времени, как в начале нынешнего столетия появились «NoSQL» продукты [10] и стало возможным:
Причем, судя по всему, кашу заварил Amazon с DynamoDB [4]:
DynamoDB is the result of 15 years of learning in the areas of large scale non-relational databases and cloud services.
а затем идеи стали клонироваться в виде фейсбуковской Cassandra [11]:
Apache Cassandra was developed at Facebook to power their Inbox Search feature by Avinash Lakshman (one of the authors of Amazon's Dynamo) and Prashant Malik. It was released as an open source project on Google code in July 2008.
И конечно без Google BigTable [12] тут не обошлось.
Что же это за «серебряная пуля» такая?
При углубленном изучении «NoSQL» продуктов, а последний продукт с которым я плотно работал был Amazon DynamoDB (очень похожий на Apache Cassandra) — стали проявляться «скрытые подводные камни и ограничения», которые никак кроме как «платой за вседозволенность» не назовешь:
А читать, по умолчанию, устаревшую неконсистентную информацию :-) А как вы хотели — информация же распространяется с ограниченной скоростью. Ну конечно можно поставить флажок и прочитать только что записанную информацию — но придется подождать-с.
Но опять-таки, нужно знать, что информации нужно время — чтобы она разошлась по континентам и приложение должно уметь это обработать (видим переключение ответственности, блин… снова на программиста :-) ).
Устойчивость к разделению кластера реализована за счет технологий, похожих на версионность — но периодически нужно будет запускать поиск рассогласований типа «Anti-entropy using Merkle trees».
Можно, но конфигурировать остальные ноды все-таки придется, иногда с ломом и паяльником.
А дальше — интереснее.
В наших проектах мы используем DynamoDB — передовое «NoSQL» решение от Amazon. Давайте рассмотрим его более подробно ниже.
Число, строка, бинарные данные. Забудьте про DATETIME (их можно эмулировать таймстампом, но становится иногда не по себе).
Индексы нужно указать сразу, их должно быть не более — 5 на таблицу. Причем добавлять их в существующую таблицу — нельзя, нужно ее удалять, пересоздавать и перезаливать туда данные. Спокойный сон архитектору — обеспечен.
Можно хранить любой объем данных, но… размер одной «строки таблицы» с именами и значениями «колонок» не должен превышать 64КБ. Правда число «колонок» не ограничивается.
И на одной ноде кластера (c одним значением основного индекса hash key) при наличии дополнительных индексов нельзя [13] хранить больше 10ГБ, так то.
Видимо зря написал «колонок». В «NoSQL» нередко понятия схемы данных просто нет, поэтому в каждой «строке таблицы» могут быть разные «колонки» или «атрибуты».
Можно выбрать данные [14] только по одному индексу (есть еще основной (hash key) индекс, но диапазонные выборки делать по нему нельзя — только константные). Отсортировать — только по одному индексу.
Забудьте про сложные «WHERE, GROUP BY», не говоря о подзапросах — «NoSQL» движки из просто эмулируют и могут выполнять очень медленно.
Можно выполнять более сложные выборки [15] — но методом полного сканирования таблицы (пресловутый table scan) и затем поэлементной фильтрации результатов на серверной стороне, что и долго и дорого.
Транзакции… иногда они нужны :-), а гарантируется лишь атомарное обновление отдельных сущностей (есть правда приятные плюшки с чтениями-инкрементами за одну операцию). Так что транзакции придется эмулировать — а то вы хотели, если данные «размазаны» по 20 серверам/датацентрам всего земного шарика?
Нередко в «NoSQL», в т.ч. DynamoDB начинаю глумиться над основателями реляционной [16] теории [17] и создавать в строках ужасы типа:
user=john blog_post_$ts1=12 blog_post_$ts2=33 blog_post_$ts3=69…
где $ts1-3 — таймстампы публикаций пользователя в блог.
Да, удобно получить список публикаций за один запрос. Но работа программиста — увеличивается.
1) Прежде чем выбирать для проекта «NoSQL» хранилище, вспомните причины появления франкенштейна подобного класса продуктов, что часто это не что иное, как набор «memcached» подобных серверов с надстроенной довольно простой логикой и, соответственно — сохранение данных и простые выборки будут, действительно, летать, а что-то посложнее… придется шаманить на стороне приложения.
2) Еще раз перечитайте теорему Брюера [6] и найдите подвохи :-)
3) Внимательно посмотрите документацию по используемому продукту — особенно ограничения. Скорее всего вы встретите множество сюрпризов — и к ним нужно будет аккуратно подготовиться.
4) И посмотрите напоследок в глаза Кодду
Да, вы получите очень надежное, высокодоступное, поддерживающее гибкие схемы репликации современное решение — но платить, увы, придется жесточайшей денормализацией и усложнением логики работы приложения (в т.ч. эмулировать транзакции, жонглирование тяжелыми данными внутри приложения и т.п.). Выбор — за вами!
Всем удачи!
Автор: AlexSerbul
Источник [18]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/nosql/43146
Ссылки в тексте:
[1] SQL ACID: http://ru.wikipedia.org/wiki/ACID
[2] MongoDB: http://www.mongodb.org/
[3] Cassandra: http://cassandra.apache.org/
[4] откуда это все пошло: http://www.allthingsdistributed.com/2007/10/amazons_dynamo.html
[5] уровни изоляции транзакций: http://ru.wikipedia.org/wiki/%D0%A3%D1%80%D0%BE%D0%B2%D0%B5%D0%BD%D1%8C_%D0%B8%D0%B7%D0%BE%D0%BB%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D1%82%D1%80%D0%B0%D0%BD%D0%B7%D0%B0%D0%BA%D1%86%D0%B8%D0%B9
[6] «CAP ереси»: http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP
[7] Oracle RAC: http://ru.wikipedia.org/wiki/Oracle_RAC
[8] MySQL cluster: http://www.mysql.com/products/cluster/
[9] galera cluster for mysql: http://codership.com/content/using-galera-cluster
[10] продукты: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
[11] Cassandra: http://en.wikipedia.org/wiki/Apache_Cassandra
[12] Google BigTable: http://en.wikipedia.org/wiki/BigTable
[13] нельзя: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI.html#LSI.ItemCollections.SizeLimit
[14] Можно выбрать данные: http://docs.aws.amazon.com/amazondynamodb/latest/APIReference//API_Query.html
[15] более сложные выборки: http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LowLevelPHPScanning.html
[16] основателями реляционной: http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4%D0%B4,_%D0%AD%D0%B4%D0%B3%D0%B0%D1%80
[17] теории: http://en.wikipedia.org/wiki/Christopher_J._Date
[18] Источник: http://habrahabr.ru/post/193360/
Нажмите здесь для печати.