Врядли сегодня найдется тот, кто еще не слышал про , или, как их называют в народе, NoSQL. Те, кто успел попробовать продукты вроде , и других, обнаружили некторые сложности при решении привычных задач — выборка списков и поиск.
В этой статье мы рассмотрим принципы решения типичных задач в key-value базах данных.
Основная сложность
Восновном, все key-value базы данных представляют из себя распределенные хеш-таблицы. Это самая сильная их сторона, т.к. предоставляет высокую и крайне упрощает . Тем не менее, это свойство всплывает на поверхность, когда Вам необходимо работать со списками. В MySQL следующие задачи решаются в два счета:
- Выбрать 10 последних пользователей
- Выбрать Самые популярные посты в блоге
- Найти продукты, для которых оставлено более 3х комментариев
- Полнотекстовый поиск
- Поиск по любому свойству (найти пользователя, email которого такой-то)
Но в key-value подобные задачи вызывают удивление и большие трудности. В двух словах, key-value базы данных совсем не предназначены для таких задач. Но это только на первый взгляд, ведь формулировать задачи можно по-разному. Стратегия решения будет зависеть от конкретной ситуации.
И так, по порядку:
Поиск по ключу
Существует класс задач, когда Вам необходимо делать выборку одного объекта не по первичному, а вторичному ключу (например, поиск пользователя по email’у, поиск автора по никнейму т.п.). Принцип решения этой задачи следующий: после создания нового объекта, Вам необходимо создать ссылки на его первичный ключ для всех его свойств, по которым придется делать выборку. Например мы создаем пользователя:
user_134: {
name: Den,
email: golotyuk@gmail.com
}
И дублируем ключ email:
user_email_golotyuk@gmail.com: {
id: 134
}
Теперь, Вы сможете сделать выборку данных пользователя по его почтовому адресу в два этапа.
Использование РСУБД
Если Вам нужен MySQL — используйте его, не стреляйте по воробьям их танка
Существует класс задач, для которых можно и нужно использовать РСУБД, такие как MySQL и Postgres. Если Вам необходимо делать выборки списков с фильтрами и сортировками, то Вам следует использовать более подходящую для этого РСУБД. Хороший пример — это посты в блоге. (выборки, которые скорее всего нужно будет делать — самые новые, самые популярные, самые комментируемые записи и т.п.).
Подход довольно простой, но на практике очень часто задачи сильно переплетены, и в итоге Вы можете прийти к тому, что РСУБД возьмет все задачи обратно на себя. В этом случае следует подумать о гибридном решении:
Гибридное решение — дополнительная РСУБД
Это решение представляет из себя смесь key-value и РСУБД. Все данные Вы храните в key-value, но те свойства, по которым понадобиться делать агрегатные выборки дублируете в РСУБД (с указателем на ключ). Т.о. Вы сохраните key-value базы данных и сможете решить свою задачу. Сложность тут заключается в том, что Вам придется следить за синхронизацией данных в обоих базах данных, что может сильно усложнить логику приложения.
Полнотекстовый поиск и выборки с задержками
Одна из частых задач — полнотекстовый поиск. Существуют отличные решения — Sphinxsearch, Solr и другие. К сожалению, ни одно из них еще не поддерживает индексацию key-value баз данных, но зато все предоставляют интерфейсы для ручной индексации. Вам нужно будет только описать реализацию для конкретного набора данных (например, с помощью XmlPipe в Sphinx’e).
Наряду с полнотекстовым поиском часто стоят и задачи, связанные с агрегатными выборками, которые не критичны к текущему состоянию данных. Например, когда Вы строите рейтинг пользователей (или постов в блоге, или продуктов в магазине или …), Вы можете спокойно использовать данные по состоянию на прошлый час(день/неделю/…). В качестве решения Вы можете использовать полнотекстовые серверы по их непрямому назначению. Многие из них поддерживают разнообразные фильтры и сортировки, которых достаточно для решения 90% задач подобного рода.
Распределенные выборки
Некоторые key-value базы данных позволяют делать выборки списков встроенными средствами. Масштабирование этого решения будет выглядеть как запросы ко всем узлам сети и агрегирование результатов на бекенде. В крупных масштабах это может быть очень затратная операция, поэтому это решени слеудет оптимизировать. Во многих случаях Вы можете обойтись без запросов ко всем узлам, а сделать выборку только на одном из них (например — выбрать случайное фото).
Что еще сюда можно добавить?
Related posts:
Комментариев нет:
Отправить комментарий