автор
Вот вы часто создаете проекты? И, наверное, везде применяете базу данных, в частности, MySQL (а кто-то и PostgreSQL). Но вот что интересно, по опыту да и просто после чтения описания различных архитектур видно, что далеко не везде в проекте нужны ключевые особенности баз данных, во многих случаях базу используют просто как некоторое хранилище обычных данных. Например, в системах кеширования базы обычно не применяются, более того, кеширование как раз используют для того, чтобы избежать лишних запросов. А что используют для кеширования наиболее часто? Memcached. А что это такое? Это распределенная система хранения данных на основе хеш-таблицы. В общих чертах, это просто хранилище пар ключ-значение, над которыми можно производить только основные операции — запись, чтение, удаление и проверку на присутствие. Да-да, нет никаких фильтров, выборок, сортировки, самый максимум — система тегов для выборки одним запросом всех связанных записей. И во многих случаях такого функционала вполне достаточно.

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

Вторым критерием или особенностью является распределённость. Для СУБД это часто решается достаточно сложно или при помощи сторонних средств. Хранилища данных строятся на основе DHT (Distributed Hash Table) и изначально готовы к распределенной работе, обеспечивая масштабируемость и устойчивость к отказам отдельных узлов. В одних системах это решается за счет среды (например, если хранилище работает поверх Erlang VM), вторые используют встроенные средства распределенной работы (например, JGroups для систем на Java), либо собственные решения, как Memcached.

Немаловажна и полная готовность таких систем для работы в Cloud-среде, не даром именно такое хранилище работает у Amazon (S3 и SimpleDB). Всем известный BigTable от Google также, по большей части, как раз система хранения и обработки пар ключ/значение. Из-за простоты и даже тривиальности API (но не всегда и внутреннего устройства, хотя оно и проще чем у стандартных SQL DB) решения отлично масштабируются (как на чтение, так и на запись), в том числе и динамически, без перерыва в работе. Так что если у вас есть или будет кластер, присмотритесь к таким решениям. Но есть один момент, о котором стоит упомянуть — очень часто такие системы работают только с хранением данных в памяти, если же требуется постоянное хранение, используются бек-енд системы, в том числе и хранение в обычной реляционной базе данных, хотя это часто может налагать ограничения на данные и их параметры (а также замедляет работу).

Для чего же можно такое применить? Да везде, где у вас есть потребность хранить большое (практически неограниченное) количество данных, которые могут быть разбиты на отдельные независимые блоки. Это могут быть отдельные статьи, фотографии, видео или другие большие бинарные объекты, записи в логе, профайлы пользователей, сессионные данные (кстати, мы раньше анонсировали свою экспериментальную открытую разработку, сессионный сервер на Java для распределенного хранения сессий РНР приложений, аналогичное решение есть в промышленном Zend Platform). В большинстве случаев все ограничивается либо набором бинарных данных, либо текстовой строкой с данными или кодом в сериализированном виде, поэтому данные можно как использовать дальше в программе обработки, либо сразу отдать клиенту — именно так делает плагин для Nginx, который смотрит в Memcached и, если там есть запрашиваемый контент, отдает напрямую, минуя вообще обращение к вашему скрипту. Сейчас я, к примеру, проектирую чат-сервер, там как раз в качестве основного хранилища данных будет использован распределенный кеш (Java-система, использующая кеш с репликацией через JGroups), который по сути такое же хранилище данных в виде ключ и значение.