Антипаттерны использования NoSQL и сравнение с традиционными базами данных

NoSQL это не продукт, не технология, и даже не концепция. Это даже не подход к проектированию. Это, скорее, декларация отказа от некоторых паттернов проектирования, господствовавших в разработке клиент-серверных систем долгие годы. 

Я в IT с 1990 года, c 2000 консультирую разнообразные интернет-стартапы по вопросам построения эффективных и безопасных серверных систем, сейчас являюсь CTO проекта inCaller (http://www.incaller.org) — уникального мобильного приложения для повышения эффективности телефонных звонков за счет добавления метаданных (текст и стикеры) прямо к стандартному вызову. Вот так:

Так вот. Из своего опыта могу точно сказать, что NoSQL является очень мощным средством повышения производительности высоконагруженных систем и уменьшения совокупной стоимости владения. И, поверьте, на свете есть люди, которые умудряются извлекать прибыль, используя NoSQL в своих проектах. Ну или сокращать убытки, по крайней мере.

Мощь NoSQL проистекает из отказа от "лишних" возможностей, присущих РСУБД. Для правильного применения NoSQL в проекте требуется изменение парадигмы проектирования, смягчение — вплоть до полного отказа от — требований к консистентности и поддержка в коде операций, которые при использовании РСУБД возлагаются на нее. 

Решение избегать NoSQL — это не трусость, это осторожность. 

Если выбор пал на NoSQL, то остается вопрос как же выбрать NoSQL СУБД под свою задачу? На http://nosql-database.org/ есть список LIST OF NOSQL DATABASES. Больше 225. Даже просто прочесть его — тяжелая работа. Для меня же реальный выбор NoSQL СУБД — это выбор между Aerospike и Cassandra.

На самом деле, конечно, не между именно Aerospike и Cassandra, а между read и write optimized.

Write-optimized СУБД, наиболее развитой из которых мне представляется Cassandra, быстро — сюрприз — пишут данные на диск. Достигается это в первую очередь тем, что данные пишутся в ближайшую же пригодную для этого область на диске. Это не совсем корректное утверждение, но оно довольно близко к истине. 

Естественно, при использовании такого подхода поиск данных при чтении не является тривиальной задачей — зачастую для чтения приходится сделать более одного шага, и некоторые из этих шагов представляют собой отдельную операцию чтения с диска.

Конечно, для улучшения ситуации Cassandra осуществляет периодически компакстинг данных, но даже это не очень помогает. Пишет Cassandra быстро, хорошо настроенная — очень быстро, но чтение — особенно идущее параллельно с записью — может “подтормаживать”.

Если это вас не устраивает — вы всегда можете выбрать read-optimized СУБД, например — Aerospike.

Aerospike не очень популярен в сообществе, и связано это с тем, что только два года назад этот продукт стал доступен широким кругам разработчиков. До того это был исключительно коммерческий продукт, и цены, мягко говоря, “кусались”. Нет, существовала и бесплатная версия, но ограничения на ее использование были таковы, что никому в голову не приходило попытаться строить на ней свой проект.

Однако это в прошлом. Сегодня Aerospike это СУБД с открытым исходным кодом и бесплатной community версией. Вы можете сами изучить список отличий платной версии от бесплатной на сайте Aerospike, и убедиться — возможностей бесплатной версии вполне хватает для использования в серьезных проектах.

Но мы отвлеклись. Aerospike — это write-optimized СУБД, которая просто работает. Вы создаете кластер, вы загружаете в него данные, и вы их используете. Из всех кластерных read-optimized NoSQL СУБД, с которыми пришлось иметь дело автору — а это больше десятка наименований — Aerospike обеспечивает наилучшую производительность, наилучшее масштабирование, наилучшие средства мониторинга и управления.

Особенно впечатляет производительность. Достигается она с помощью следующих приемов:

Индекс, по которому осуществляется поиск данных, всегда находится в памяти.

Индекс этот однозначно определяет сервер, диск и смещение на диске, по которому данные могут быть найдены в один шаг.

Нельзя сказать, что эти приемы влияют на скорость записи негативно — при записи Aerospike тоже демострирует впечатляющие результаты.

Но, например, если у вас закончилась оперативная память — Aerospike просто перестанет принимать запросы на запись, не смотря на то, что место на диске еще есть.

Или, если в выделенной под хранилище Aerospike области диска закончилось непрерывное неиспользуемое место в ее (области) конце, Aerospike тоже откажется записывать новые данные, пока вы не проведете процедуру дефрагментации и компактинга. Процедура запустится автоматически, но - с низким приоритетом, чтобы не мешать чтению.

Эти (и еще некоторые менее заметные) особенности делают Aerospike read-optimized СУБД. По мнению автора :)

Возвращаясь к началу, при выборе продукта следует учитывать его особенности, и в первую очередь, его ориентацию на запись или чтение. Условно говоря, вы будете выбирать между Cassandra и Aerospike. На практике, скорее всего, тоже, особенно если проведете нагрузочное тестирование.

А как же опыт использования традиционных РСУБД?  Многие годы волнующий умы программистов, системных администраторов и devops'ов вопрос: что быстрее — MySQL или PostgreSQL? С моим коллегой Александром Чистяковым, инженером по эксплуатации inCaller, мы провели настоящий поединок между MySQL и PostgreSQL. 

Во время доклада на недавней конференции "Российские интернет-технологии ++"  мы запустили синтетический тест, эмулирующий нагрузку "обычного стартапа", и вывели на большой экран текущие графики, отображающие скорость и нагрузку. За время сорокапятиминутной сессии мы обнаружили, что:

1) Мы не умеем настраивать ни MySQL, ни PostgreSQL. Настройки, которые мы делали на протяжении сессии, не привели к существенному изменению скорости взаимодействия с базой данных

2) MySQL оказался незначительно быстрее PostgreSQL: 25-30Krps против 20-25Krps

3) Аудитория очень благосклонно принимает такого рода доклады. Впрочем, это был последний доклад секции конференции, и, возможно, слушатели просто устали от умных слов и перегруженных информацией слайдов и хотели просто поучаствовать в шоу.)

А по NoSQL я также сделал доступной свою презентацию “NoSQL — неспроста ли это "ЖЖЖ"?”, которая доступна на Slideshare.  

Может возникнуть вопрос, почему мы в компании inCaller уделяем столько внимания вопросам производительности разных СУБД? Почему мы тратим заметные людские и вычислительные ресурсы на их исследования?

Ответ очень прост — мы работаем в стартапе и строим высоконагруженную отказоустойчивую систему.

Стартап — это значит нам надо реализовывать наши идеи как можно скорее, сокращая цикл придумали-реализовали-показали пользователям.

Высокая нагрузка и отказоустойчивость — это значит нам требуется распределенная обработка данных, горизонтальное масштабирование и взаимозаменяемость узлов системы.