Блог

Изучая альтернативы Hadoop, я наткнулся на интересный проект Plasma, распределенную файловую систему, на основе которой разворачивается NoSQL-СУБД и фреймворк Map/Reduce. Его особенность: хорошая сбалансированность, отсутствие определенной кривизны Hadoop, и например работа с файлами практически неограниченного размера. Автор этого проекта Gerd Stolpmann имеет богатый опыт в разработке и развертывании подобных систем, и в этой связи интересно его весьма оригинальное мнение о тренде развития серверных технологий.

[spoiler]Вот как Stolpmann рассуждает. После того, как он разработал распределенную файловую систему PlasmaFS и реализовал на ее основе схему map/reduce, стало интересно, а насколько сложно или легко поверх такой системы организовать хранилище ключ-значение? Насколько развивающиеся сегодня сложные серверные технологии упрощают создание распределенных систем?

За счет реализации в PlasmaFS транзакционной работы библиотека обработки БД ключ-значение заняла всего две тысячи строк кода! При этом обеспечен высокий уровень целостности данных, практически неограниченная масштабируемость по операциям чтения и очень высокая производительность по записи. То есть наличие качественной платформы делает возможной быструю реализацию фич, которые сами по себе крайне сложны. А в результате сортировка 100 Гб данных, распределенных по 10 файлам, потребовала 37 мин 45 сек для Hadoop и 32 мин 55 сек для Plasma.

За счет того, что серверная функциональность выносится в различные уровни базовых платформ (скрывается от разработчика все глубже), получается, что map/reduce реализована в библиотеке, в которой даже нету никакого сетевого кода. Фактически это новая парадигма NoServer (not only server). С одной стороны, код привязан к родительским технологиям, но зато файловый сервер при этом превращается в черный ящик, как и СУБД -- к движку можно обращаться по сети через простой API, а как это работает там внутри, программисту не важно. NoServer предлагает следующий шаг: так как функции платформы низкоуровневые, у разработчика появляется большая свобода действий. Взамен SQL-запросов предлагаются стандартные файловые операции, дополненные транзакционной поддержкой. В результате получается возможность быстро реализовывать трудоемкие вещи. На мой взгляд, NoServer -- это нечто вроде PaaS, где "пользовательские" сервисы предоставляются в виде API для программистов.

База ключ-значение оказалась самым простым примером, и Stolpmann довольно подробно рассказывает о возможном применении PlasmaFS. Он в частности отмечает, что если создается OPTP-система, РСУБД пока наилучший вариант. Но если требуется сверхскоростная производительность по достаточно простым операциям чтения/записи, с гарантией ACID, а также особенно важна скорость разработки, NoSQL/NoServer представляются очень соблазнительными альтернативами.

Свежая новость в тему: Sauce Labs, два года назад перешедшая с MySQL на NoSQL CoachDB, сегодня снова возвращается на MySQL. Главные претензии к CoachDB (несмотря на заметный выигрыш в производительности) -- излишне большое время даунтайма, а сервисы Sauce Labs к этом крайне чувствительны. Инженеры меняли железо, долго перенастраивали CoachDB, переписывали софт, но это не помогло.
Простои же и подтормаживания, судя по всему, связаны с проблемами при работе CoachDB с относительно медленными дисками, сложностями с индексацией, требовавшими перезапуска СУБД, и периодическими клинчами, связанными с некорректной обработкой запросов.