Что такое key=value БД? Это система управления данными, которая позволяет сохранять пары ключ=значение в постоянное хранилище, и в последствии читать эти значения по ключам. Вот так все просто! Все гениальное просто, но в чем необходимость такого крайне ограниченного на первый взгляд решения?..

Зачем нужно такое решение, если есть MySQL, PostgreSQL, Oracle…?

Решая такую простую задачу, как сохранение/чтение значений по ключу, система работает крайне эффективно, т.к. в ней отсутсвуют тяжелые слои SQL обработчиков, систем индексации, профилирования, вакуумизации (для PostgreSQL) и т.д. Подобное решение дает наиболее эффективную производительность, минимальную стоимость внедрения и масштабирования.

В каком случае необходимо использовать такое решение?

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

Пример на основе авторизации пользователя

Давайте начнем с самого ядра. Допустим у нас есть логин и пароль пользователя. Сейчас все представили себе стандартное решение - таблица в MySQL на три колонки (может быть больше трех, но это основа):

ID | login | password |

Регистрация происходит следующим образом - мы проверяем, нет ли такого же логина в таблице и вставляем новый рядок. Автризация еще проще - делаем выборку по связке логин - пароль (или хеш пароля) и все. А теперь вопрос - зачем мы использовали MySQL для решения такой задачи, если мы не использовали 99% возможностей этой РСУБД. Другими словами мы сейчас “съездили за хлебом на танке”.

Давайте ту же задачу рассмотрим в приближении БД ключ=значение:

Регистрация. У нас есть логин (уникальная колонка) и пароль. Все замечательно подходит для выбора пароля как значения, а логина - как ключа. Авторизация будет происходить следующим образом - делаем выборку по логину (это ключ) - получаем пароль, сравниваем с тем, что написал пользователь - готово.

Это решение требует некоторого расширения для использования в стандартных нуждах. Как Вы успели заметить, у нас нет поля “user_id”, без которого будет крайне трудно построить систему любой сложности. Как это решается? Средствами все той же БД, давайте посмотрим:

• Ключом будет user_id, который будет увеличиваться при каждой регистрации на 1 (текущее значение autoincrement будем также хранить в паре ключ=значение)
• Данными будет логин и пароль.
• Т.к. во время авторизации нам нужно делать выборку по логину, то нужно хранить еще одну пару: логин=user_id

Существующие технологии

Ближе к конкретике, расммотрим несколько решений баз данных ключ=значение:

• MemcacheDB - решение на основе протокола memcached. Это не решение для кеширования, просто название такое! Из сильных сторон: высокая производительность записи/чтения, обеспечение высокой надежности и доступности данных, репликация, транзакционность. Хорошим плюсом в сторону этого решения будет то, что этот продукт вышел в официальный релиз
• Redis - база данных ключ=значение с дополнительными возможностями работы со списками и стеками. Из плюсов - высокая производительность, поддержка репликации, работа со списками и стеками, множество клиентских API для различных платформ (PHP, Ruby, Python, Perl, Java и другие)
• CouchDB - решение, написанное на языке Erlang. Плюсы - отличная работа пол нагрузками (в основе - паралельный язык), поддержка инкрементальной репликации, доступ по протоколу HTTP
• Tokyo Cabinet - высокопроизводительное решение с расширенными возможностями. Из отличительных сторон - крайне высокая производительность (бенчмарк), поддержка сжатия данных, Hash и B+tree алгоритмы доступа к данным, поддерживает манипуляции со списками записей.
• BerkeleyDB - устоявшийся продукт. Сильные стороны: текущая версия перевалила за 4 (что является показателем стабильности) поддержка репликации, внутренне кеширование, транзакционность, и много другое. Это решение зачастую используется, как прослойка для хранения данных, на основе которой строится интерфейсная и операционная часть.

Расширенный список решений

Преимущества баз данных ключ=значение

И так, если у Вас стоит задача хранить определенные значение по ключу, почему стОит использовать БД ключ=значение?

• РСУБД (RDBMS) слишком медленные, имеют тяжелую прослойку SQL движков, тяжело масштабируются
• РСУБД не достаточно хороши в плане показателя concurrency (обработка одновременных запросов)
• Слишком большая стоимость решения РСУБД для хранения мелких порций данных
• Нет необходимости в SQL запросах, индексах, триггерах, хранимых процедурах, временных таблицах, видах и т.д.
• БД ключ=значение легко масштабируемы и высокопроизводительны ввиду своей легкости

Итог

При построении масштабируемой системы вопрос стоимости расширения зачастую не ставиться или игнорируется. Экономя время на анализе во время разработки, вы теряете время и деньги, масштабируя решения, которые не предусмотрены для возложеных на них задач. Использовать РСУБД для хранения пар ключ=значение и чтений значений по ключу - это показатель того, что Вы действуете крайне не эффективно. Тем не менее, думайте заранее - если Вам необходимо делать выборки списков или строить графики статистики, Вам придется использовать реляционные СУБД (для чего они собственно и нужны)

Статьи по теме

• PHP + Redis платформа “Ключ=Значение”
• NoSQL - подходы к решению типичных задач
• Mongo DB - документо-ориентированная база данных и MySQL