четверг, 27 мая 2010 г.

Масштабируемые СУБД

Статья здесь: PAPER: HIGH PERFORMANCE SCALABLE DATA STORES

Хотелось бы перевести как "хранилища данных", но такой термин существует и означает нечто иное; скорее, термин СУБД подходит, хотя я знаю, что под таковыми в русскоязычной литературе обычно (ошибочно) подразумевают реляционные СУБД, а то и вовсе объектно-реляционные (что, в общем-то, самой грязной воды маркетинг). Насчет высокой производительности вопрос спорный, все зависит от задач. Вот так название статьи и превратилось в "Масштабируемые СУБД".

Авторы выделяют четыре класса систем:
  • Key-value stores: Redis, Scalaris, Voldmort, and Riak.
  • Document stores: Couch DB, MongoDB, and SimpleDB.
  • Record stores: BigTable, HBase, HyperTable, and Cassandra.
  • Scalable RDBMSs: MySQL Cluster, ScaleDB, Drizzle, and VoltDB.

К сожалению, некоторые из этих продуктов закрытые, а некоторые - сырые и глючные, но что есть, то есть. Уж не знаю, почему из обзора выпала MemcachedDB. Думаю, статья полезна в качестве шпаргалки по особенностям вышеназванных систем.

8 комментариев:

995533 комментирует...

Хотелось бы увидеть статью о кластере MySql. Разные решения и их отличия

Печников Алексей комментирует...

Признаться, я весьма презираю ту технологическую нечистоплотность, на волне которого широко распространился и MySql. Уточню, что знаком с ним не по наслышке, в том числе доводилось заглядывать и в исходники - и если некоторые возможности интересны концептуально, то реализация часто ужасает.

Так что лучше спросите о кластере SQLite (скоро ждем юбилейную версию 3.7, разработка которой началась в преддверии десятилетия проекта) или хотя бы PostgreSQL (ждем версию 9, к сожалению, ничего революционно нового там не будет, а лишь игра "в догонялки" с другими СУБД). А еще интереснее поговорить о самой идеологии распределенных систем, которая вовсе не зависит от способа хранения данных (и тем паче от выбора конкретной СУБД, если таковая в проекте вообще есть). Кое-что на эту тему я уже писал, но с тех пор некоторые мысли мне удалось точнее сформулировать. Для начала посмотрите заметку Распределенные базы данных Пожалуй, лучшей известной мне реализацией распределенной системы с использованием реляционной БД является именно fossil, с его концепцией синхронизации сущностей. Также ознакомьтесь с моей утилитой sqlite3-rdiff - она может быть легко адаптирована для любой СУБД, выполняя репликацию на логическом уровне (а это гарантирует целостность данных, в отличие от других способов). В определенных случаях эта утилита способна выполнять и master-master репликацию, причем у меня есть основания полагать именно эти случаи оптимальной реализацией master-master архитектуры.

995533 комментирует...

О выборе базы сейчас нет смыла думать, проект написан на 50%.

Читал много статей про отказоустойчивые системы с MySQL и чем больше читаю тем больше пугаюсь ))

Дело в том что проект у нас отвечает за бизнес процесс и потер данных крайне недопустима! + ко всему простой тоже недопустим. и все же уверен решение есть, так как не один десяток крупных проектов используют именно MySQL.

Буду искать варианты реализации в дальнейшем готов поделиться опытом реализации.

Печников Алексей комментирует...

Не видел ни одной успешной системы, обрабатывающие в MySQL бизнес-критичные данные. Высокая доступность для MySQL в некотором виде организуется (и то, если посмотреть, облачные сервисы от Амазон периодически "падают"), но гарантий сохранности нет. Уверен, если нужно хранить важные данные, MySQL - ошибочный выбор. Как раз одна из моих претензий к нему связана именно с ощутимой вероятностью повреждения данных, это происходит периодически, после чего админы привычно разворачивают бэкап. Посмотрите историю различных проектов, использующих MySQL - форумы, блоги, днс-сервера, etc. - у всех у них (зачастую неоднократно) "падала" база. Так что зря вы смотрите на крупные проекты, но с маловажными данными, это совсем другая область применимости, где оперируют вероятностными показателями надежности, принимают модель "согласованности в конечном счете" и проч. Думаете, почему крупный бизнес избегает оперсорс решений?.. Во многом именно из-за того, что разработчики при проектировании и разработке ПО не обеспечивают надежность хранения и обработки информации. Сейчас появилось много видов приложений, где потеря информации - дело обычное (все виды социальных сетей и многие другие), но для бизнеса нужно другое - гарантия высокой доступности при полном ACID. А вы сейчас фактически изобретаете "вечный двигатель" на MySQL - какое-то время он покрутится, но что потом?..

Hubbitus комментирует...

Последнее заявление как минимум странное. Тот же Facebook работает на MySQL и ничего, никто ни разу не жаловался. И если бы там пропала часть данных, думаю бы по федеральным каналам даже у нас показали бы. Вконтакте, катсти, если мне не изменяет память, тоже на нем же.

Печников Алексей комментирует...

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

Очевидно, к использованию в качестве единственной и основной БД проекта мускуля все это отношения не имеет ни малейшего.

Hubbitus комментирует...

Ну кеширование-то никто не отменял...
Но откуда данные о задержках и внешней проверке данных вне СУБД?

Печников Алексей комментирует...

Так это вовсе не секрет: Архитектура Facebook


(C) Alexey Pechnikov aka MBG, mobigroup.ru