Масштабируемые СУБД
Статья здесь: PAPER: HIGH PERFORMANCE SCALABLE DATA STORES
Хотелось бы перевести как "хранилища данных", но такой термин существует и означает нечто иное; скорее, термин СУБД подходит, хотя я знаю, что под таковыми в русскоязычной литературе обычно (ошибочно) подразумевают реляционные СУБД, а то и вовсе объектно-реляционные (что, в общем-то, самой грязной воды маркетинг). Насчет высокой производительности вопрос спорный, все зависит от задач. Вот так название статьи и превратилось в "Масштабируемые СУБД".
Авторы выделяют четыре класса систем:
К сожалению, некоторые из этих продуктов закрытые, а некоторые - сырые и глючные, но что есть, то есть. Уж не знаю, почему из обзора выпала MemcachedDB. Думаю, статья полезна в качестве шпаргалки по особенностям вышеназванных систем.
Хотелось бы перевести как "хранилища данных", но такой термин существует и означает нечто иное; скорее, термин СУБД подходит, хотя я знаю, что под таковыми в русскоязычной литературе обычно (ошибочно) подразумевают реляционные СУБД, а то и вовсе объектно-реляционные (что, в общем-то, самой грязной воды маркетинг). Насчет высокой производительности вопрос спорный, все зависит от задач. Вот так название статьи и превратилось в "Масштабируемые СУБД".
Авторы выделяют четыре класса систем:
- 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. Думаю, статья полезна в качестве шпаргалки по особенностям вышеназванных систем.
Comments
Так что лучше спросите о кластере SQLite (скоро ждем юбилейную версию 3.7, разработка которой началась в преддверии десятилетия проекта) или хотя бы PostgreSQL (ждем версию 9, к сожалению, ничего революционно нового там не будет, а лишь игра "в догонялки" с другими СУБД). А еще интереснее поговорить о самой идеологии распределенных систем, которая вовсе не зависит от способа хранения данных (и тем паче от выбора конкретной СУБД, если таковая в проекте вообще есть). Кое-что на эту тему я уже писал, но с тех пор некоторые мысли мне удалось точнее сформулировать. Для начала посмотрите заметку Распределенные базы данных Пожалуй, лучшей известной мне реализацией распределенной системы с использованием реляционной БД является именно fossil, с его концепцией синхронизации сущностей. Также ознакомьтесь с моей утилитой sqlite3-rdiff - она может быть легко адаптирована для любой СУБД, выполняя репликацию на логическом уровне (а это гарантирует целостность данных, в отличие от других способов). В определенных случаях эта утилита способна выполнять и master-master репликацию, причем у меня есть основания полагать именно эти случаи оптимальной реализацией master-master архитектуры.
Читал много статей про отказоустойчивые системы с MySQL и чем больше читаю тем больше пугаюсь ))
Дело в том что проект у нас отвечает за бизнес процесс и потер данных крайне недопустима! + ко всему простой тоже недопустим. и все же уверен решение есть, так как не один десяток крупных проектов используют именно MySQL.
Буду искать варианты реализации в дальнейшем готов поделиться опытом реализации.
Потеря десятка или даже тысячи комментариев затронет лишь ничтожную часть пользователей, и то не факт, что хоть кто-то из них это заметит, а при обнаружении сбоя можно восстановить из логов - ну не будут видны эти комментарии час или день.
Очевидно, к использованию в качестве единственной и основной БД проекта мускуля все это отношения не имеет ни малейшего.
Но откуда данные о задержках и внешней проверке данных вне СУБД?