Прежде чем мы предметно обсудим эти интересные NoSQL-расширения для MySQL, очень полезно предварительно, хотя бы в двух словах, рассмотреть саму парадигму NoSQL и её тренды развития: как по причине аналогичной функциональности предлагаемых для рассмотрения плагинов, так и из-за необходимости далее по тексту ссылаться на некоторые её особенности.
Начнем с того, что в сфере индустрии баз данных 20 век прошел под знаком SQL, ставшим универсальным стандартом взаимодействия с БД. Но 21 век привносит уже новые вызовы и проблемы, о которых в эти, ещё совсем недавние времена, даже и не задумывались.
Конечно, стандартный MySQL не предназначен для подобных нагрузок, поэтому уже более 5 лет, под руководством разработчика Марка Каллагана, идет интенсивная доработка MySQL под собственные экстремальные потребности Facebook (за историей этого проекта можно наблюдать на странице MySQL@Facebook). И ключевую суть новых решений здесь реализуемых можно обозначить коротким термином — NoSQL.
Поэтому давайте попробуем кратко определить, что такое NoSQL сегодня. Иногда принято считать, что это примитивные нереляционные базы данных, построенные на хранении последовательностей «ключ-значение», но это не всегда так. Концепция NoSQL гораздо шире этого частного случая и включает в себя следующие известные способы её реализации:
Более подробно о NoSQL, его разновидностях и основах я писал ранее вот здесь. Ещё одна хорошая стартовая страница с коллекцией материалов по NoSQL
Все эти направления — это уже классика NoSQL, хотя как можно здесь видеть, всё это достаточно разные технологии, — использованные в них решения иногда прямо противоположны по своим подходам.
NewSQL — это ещё более рыхлая для точного определения новейшая концепция, но общая её суть сводится к тому, что «это тот же NoSQL, но разумно усовершенствованный элементами классического SQL». Другая попытка определить NewSQL звучит чуть иначе, заходя с другой стороны: «это существенно оптимизированные решения на базе SQL, которые могут потягаться своими возможностями с NoSQL» (одноименный проект нового SQL-синтаксиса NewSQL не имеет никакого отношения к этой парадигме).
Иначе говоря, это здравая попытка достичь некой «золотой середины», баланса, между двумя полюсами: богатством SQL и минимализмом NoSQL. Попытаться сочетать преимущества масштабируемости и скорости NoSQL, при этом максимально сохраняя плюсы широкой функциональности традиционного SQL — главная цель движения NewSQL.
И достигнуть этого можно как минимум двумя путями:
В качестве ярких примеров из первой группы, кроме уже упомянутого CQL, я хочу привести Google Query Language (GQL) и Drizzle. Давайте для прикладной иллюстрации этой вариации NewSQL немного остановимся на идеологии Drizzle.
GRANT
и ALTER
, команда SHOW
, убрана поддержка предварительно подготовленных запросов, ограничений ACL
и многое другое, что существенно замедляет работу сервера БД.Кстати говоря, симптоматично, что этот самый классический SQL сейчас на Западе часто демонстративно начинают обозначать словом OldSQL, желая подчеркнуть, что в современном мире больших нагрузок и скоростей этот вид языка запросов отчасти устарел и теряет свою актуальность.
Какова конечная цель и результат этого стремления к минимализму?
Повышение производительности примерно в 3 раза по сравнению с MySQL 5, при том, что на Drizzle, в отличие от радикального NoSQL, можно запустить многие обычные MySQL-ориентированные движки (CMS), правда, в некоторых случаях нужны их минимальные переделки. Возможностей этого усеченного подмножества SQL вполне хватает для большинства рядовых веб-приложений. А какой выигрыш в скорости этот подход даёт!
Кому интересны детали — концептуальные отличия между OldSQL, NewSQL и NoSQL рассмотрены в данной презентации (PDF), здесь по-русски или частично здесь
Что касается примеров ко второму типу решений NewSQL (по моему личному мнению наиболее перспективному) — то именно им и посвящена оставшаяся часть этой статьи на примере MySQL.
~
Читать этот материал дальше. Оглавление этой серии статей — здесь.
2 комментария
Пара замечаний:
1. Redis - это не key-value хранилище. Если называть key-value все, что дает доступ к данным по ключу, тогда и Couch с Mongo относятся к этому типу.
2. "Либо разработка гибридных систем, в которых параллельно доступны сразу несколько интерфейсов доступа к единой базе данных." -- дело вовсе не в интерфейсах. Основная проблема SQL - невозможность горизонтального масштабирования операций записи и join'ов, собственно эти проблемы и пытаются решить в NoSQL СУБД.
Насчет 1 - в этой более общей классификации так и есть.
2 - ваше горизонтальное масштабирование - это узко об NoSQL, - там же, прочтите внимательно, проблематика у меня рассматривается шире, и я не даром упомянул текущее тренд-смещение в сторону NewSQL (в варианте гибридных БД), а также кратко пояснив причину, почему именно так происходит.
Одним словом, рекомендую просто перечитать более внимательно что там написано, нет смысла это повторять по второму кругу ещё и в комментариях.