Марш против RDBMS или проекты распределенных хранилищ (key-value stores)

[@DYPA]

code.google.com/p/redis/

Redis is a key-value database. It is similar to memcached but the dataset is not volatile, and values can be strings, exactly like in memcached, but also lists and sets with atomic operations to push/pop elements.

Redis is pretty fast!, 110000 SETs/second, 81000 GETs/second in an entry level Linux box.

для php есть готовый класс code.google.com/p/redis/source/browse/trunk/client-libraries/php/redis.php

зы пока присматриваюсь к проекту

[@aleks_raiden]

интересно очень, спасибо, посмотрим

[@aleks_raiden]

интересно — почему SET (запись) настолько больше производительность, чем GET. Собрал вот на хостинге у себя, вроде работает, без проблем. Попробую написать чат на этом, может не придется Java поднимать (хотя там больше фишек конечно). Скоро напишу тогда отдельный пост

[@dymdym]

по НЕреляционные базы уже наслышаны, а вот привести пример применения в проекте, только не гипотетический, а реального применения

[@iZENfire]

В J2ME MIDP есть хранилище Record Management System (RMS). Вот это и есть реальное применение.

[@svdesign]

Мы используем CouchDB для хранения регистрационных данных пользователей. Это как бы портал с централизованной регистрацией, и всем сайтам которые являются частью портала мы раздаем эту информацию о пользователях элементарно делая http запросы к серверу CouchDB. С помощью функций Map мы получаем пользователей по тем или иным критериям (аналог sql WHERE conditions), а задав функцию Reduce мы что-то вычисляем, например число мальчиков или девочек :)

[@aleks_raiden]

спасибо за прекрасный реальный пример! может напишете как то статью об этом?

[@eapotapov]

Для аналогичных целей мы используем MemcacheDB.
Первоначально для всего использовался связка mysql+memcache, естественно активно применяли шардинг, но когда число пользователей перешло за полтора миллиона, поняли что систему авторизации надо перевести на что-то простое и быстрое.
Главная проблема с которой стокнулись — ошибка connection timed out при росте MemcacheDB базы данных на модуле pecl-memcache на PHP.
Пытались достигнуть стабильности несколько дней, менятяя таймауты, версии MemcacheDB, собирая отдельные компоненты из разных версий.
В итоге, отчаяшись написали письмо Steve Chu, автору MCDB — и, о чудо, через день пришел ответ с рекоммендацией использовать модуль pecl-memcached (http://pecl.php.net/package-info.php?package=memcached) от небезызвестного Andrei Zmievski, использующий libmemcached в качестве средства соединения с memcache.
В итоге авторизация уже два месяца стабильно работает на memcachedb показывая значительно лучшие результаты по сравнению с mysql+memcache

[@svdesign]

У меня назрел вопрос, что будет с вашей базой MemcacheDB если случайно пропадет питание? Какойто бекенд существует для персистентного хранения данных?

[@aleks_raiden]

MemcacheDB is a distributed key-value storage system designed for persistent. It is NOT a cache solution, but a persistent storage engine for fast and reliable key-value based object storage and retrieval. It conforms to memcache protocol(not completed, see below), so any memcached client can have connectivity with it. MemcacheDB uses Berkeley DB as a storing backend, so lots of features including transaction and replication are supported.

что будет с обычной базой? аналогично.

[@svdesign]

Так это по сути тоже самое что использовать BDB4 напрямую, там ведь совсем тупое хранилище, никаких стуркут, только ключ-значение. Теоретически, если бы вы использовали Berkeley DB напрямую из PHP, то работало бы все быстрее, но, так как мир не идеален, пришлось бы столкнуться с проблемами блокировки файловой системы при паралельных запросах. MemcacheDB по сути ничего общего, кроме протокола обмена, с настоящей Memcached не имеет :)

[@eapotapov]

Вообще тут две вещи.
1. Делать репликацию на еще один мцдб для быстрого восстановления.
2. Дублировать все в бэкэнд в виде мускуля и по крону раз в день проверять целостность например.
Вообще я тут статейку накатал как мы делали, сейчас в течении получаса в блог засуну свой :)

[@Psih]

Согласен с вами, но мне бы вот хотелось бы узнать, как например хранить данные скажем чата двух юзеров. Как потом выбрать эти записи? Или скажем есть список статей. А как выбрать все статьи постранично? В итоге нужно где-то хранить набор ключей всех статей.
Автор! Пример, причём реальный, в студию! Я вот не понимаю как можно тот же memcachedb использовать без таблицы-связки в MySQL между к примеру юзером и контентом.

[@Psih]

Чёрт, коммент глупый вышел. Вопросы все адресованы автору.

[@aleks_raiden]

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

В чем проблема чата двух юзеров? Если есть теги — помечаем ими записи, если есть функция в хранилище — выборки по диапазону ключей — еще легче (а это есть, например, в EHcache). Мемкешем также все пользуются и отлично работает.

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

[@aleks_raiden]

это не НЕреляционные БД. это другое.
Вы видимо никак не разработчик веб-систем, иначе не было бы таких вопросов.
Любой кеш (система кеширования) использует такое, мемкешед, ehcache и прочие. многие поисковые системы использую как хранилище данных такое (Nutch). Google использует.

[@CAH4A]

Допустим у меня список именно таких ключ/поле записей. Они записывались в архаичном порядке.
Нужно получить десятую страницу по двадцать записей в каждой, отсортированных по полю.

Придётся ли получать все записи, сортировать, а потоп отсчитывать с 200ой по 220ую?

[@aleks_raiden]

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

мап/редуце вам в помощь, выше писали про CouchDB к примеру, решается. В чем проблема сразу хранить блоками по 10 — 20 — 50 записей, и выбирать их вместе.

[@CAH4A]

одна запись изменилась == переписать все 20?

[@aleks_raiden]

а если записи не могут изменятся? Это лог или что-то еще?
Храните связанные списки — ключ (хеш временного интервала) => список ключей (ключ => хеш статьи) и потом выборка связанных. Задачу сразу нужно проектировать под реализацию

[@el777]

Можно так же добавить Mnesia — распределенная БД на Эрланге. Что интересно для нее есть плагин реализующий помимо стандартного API доступ с помощью SQL.

[@wolf13h]

ayende.com Oren Eini пишет сейчас как раз такую штуку на .Net причем в данный момент идет планирование и он описывает в постах все архитектурные решения

[@neithere]

MongoDB:

mongodb.org/ — оф. сайт
github.com/mongodb — код (текущая версия — 0.8)

Есть обвязки для Java, Python, Ruby, C++, PHP, Erlang, Factor и др.
Обвязку для Python я недавно тестировал в домашних условиях; очень простой, гибкий, удобный API.

Сравнивать с CouchDB довольно сложно. Пока не берусь это делать.

Вот что они сами о себе пишут:

MongoDB is a high-performance, open source, schema-free document-oriented data store that's easy to deploy, manage and use. It's network accessible, written in C++ and offers the following features:

* Collection oriented storage — easy storage of object-style data
* Full index support, including on inner objects
* Query profiling
* Replication and fail-over support
* Efficient storage of binary data including large objects (e.g. videos)
* Auto-sharding for cloud-level scalability (Q209)

[@aleks_raiden]

ага, интересная система, я о ней писал — разработчики — это стартап создавший свою платформу CloudComputing — abrdev.com/?p=409 (10gen платформа)

[@aleks_raiden]

хотя странно, раньше была вся платформа, теперь переключились только на базу что ли

[@m007]

Это по сути объекто-ориентированная БД не key-value хранилище данных.
Вот еще одна разработка объектно-ориентированного хранилища

hivext.ru/index.php/Структуры
и пример как создавать типы и объекты через консоль
forum.hivext.ru/index.php?topic=6.msg9#new

[@Valery35]

А как документировать такие структуры? В rdbms ER модель, а тут как?
Я не из бюрократических соображений а про то, как один человек может написать о данных так, чтобы разработчик клиента понял, что ему надо открывать-сохранять.

Bigtable (GFS, Google AppEngine), AmazonS3 — это из этой же оперы или не совсем?

[@aleks_raiden]

а в чем проблема? ER модели надо как раз потому что структура в БД очень сложная часто, здесь все намного проще. В чем проблема вести нормальную документацию?

Да, как раз из той.

[@iZENfire]

Представьте себе, что таблица key-value store — это полностью нормализованная РСУБД «в пределе». ;)

[@Quessir]

Скорее полностью денормализованная. )

[@iTon]

не надо терминами бросаться без головы… Что значит полсностью нормализованная? 5 ил 6 -ая нормальные формы… По контексту наверно полностью денормализованная. Но радости то от этого мало, ибо при денормализации страдает целостность данных.