Накладные расходы будут заключатся в том, что ключом будет текстовое поле (чтобы был аналог key-value). Пусть даже мы возьмем хеш-ключ с высокой селективностью. Получим бинарное дерево. А поиск в бинарном дереве имеет скорость O(log2(N)), что в принципе очень хорошо. Пусть сюда же будет хранение кеша (что несомненно увеличивает скорость обработки запроса), но не знаю, как в посгрес, но мускуль обрабатывает запрос прежде чем отдать ответ из кеша, чтобы понять что ответ не изменился. Отсюда следующие накладные расходы: мы храним таблицу на жестком диске, мы храним индекс, мы храним кеш, мы делаем запрос к жесткому диску, если нет в кеше, мы каждый раз обрабатываем sql-запрос, чтобы понять какие данные хотим получить. Для хеш-таблицы (именно такие key-value я рассматриваю) мы имеем скорость выборки O(1), все данные всегда в памяти + если нам необходимо, то сбрасываем дампы на диск. Конечно, есть еще memory хранилища в РСУБД, но я все таки предпочту использовать специализированное решение, чем делать свой велосепед. В целом, я думаю можно настоить мускуль\постгрес на приемлемые скорости работы, но все таки это решение похоже на забивание гвоздей телескопом.
В принципе есть возможность все уместить в память для кеша. Если перестанет умещаться, то вертикальное масштабирование, а потом горизонтальное. А что Вы скажете про монго? Вроде как гибридное решение он вполне не плох. Часто используемые данные в памяти, остальные на диске + автошардинг из коробки (на прошлом проекте использовали самописный шардинг для mysql — это ад. Все дико неудобно, постоянно надо думать о том на какой шарде что находится. в монго тоже не стоит забывать, но для простых случаев даже не обязательно думать о том, что у нас несколько серверов)
Ну и скорость работы у него — одна из самых высоких. По некоторым бенчмаркам его обходит только мемкеш (и то не по всем, поэтому сомневаюсь в их честности)
Ну сам еще не до конца определился, но вроде все сводится к тому, что идеальное хранилище для сессий — редис. Подводных камней по отзывам сильно не заметно + к концу года обещают первый стейбл кластера, что позволит не писать свою обертку с использованием консистивного хеша, а заюзать все из коробки для горизонтального масштабирования и высокой доступности.
Интересное решение, но уж слишком много нужно писать для его запуска, нет времени, чтобы разобраться досконально, а не разобравшись можно написать фигню ) Но спасибо )
Токио судя по бенчмаркам и отзывам вообще не рассматриваю. Уж очень много постов о том, что он кривой при больших нагрузках. если отзывов много, значит так и есть.
Я просто исходил из того, что моного шардится и находится на другом сервере. По этому пункту они в с кешом в равных условиях. Но если кешу требуется O(1) как хеш таблице, то mongo явно больше, так как там используется b-tree (получается o(logN), поравьте если я ошибаюсь), а кеширования запросов вроде нет. Вот отсюда и возник вопрос кеширования результатов запросов к монго.
Хм. А если таких запросов будет миллион? Каждый раз считать и тратить на это 1 мс? Или один раз посчитать и кинуть в кеш, а потом брать оттуда. Или Mongo использует что-то для кеширования результатов?
www.percona.com/live/mysql-conference-2012/sessions/caching-memcached-redis Вот кстати очень интересные результаты. Мемкешд медленней, но стабильней, а редис большую часть времени был быстрее, но периодами проседал ниже мемкешда. Правда потом был тест разных версий редиса. Там вроде ситуация улучшилась
А есть ли какие-то бенчмарки надежные по скорости? Просто облазил все и везде результаты разные. Очень смущает то, что мемкешд простой как веник, но медленней, чем redis, у которого функциональных возможностей на порядок больше. Если действительно так, то именно такое решение и буду использовать.
Ну не прямых селектов. Аггрегаций. На сколько я понимаю быстрее залезть в хештаблицу и взять значение, чем вызывать мап\редьюс. Или я не прав? Все таки монго хоть и хранит все данные в памяти, но алгоритм их выборки не может быть быстрее O(1) (насколько помню из универского курса такой для хеш таблиц)
Ну хотя бы объясните почему Вы его хвалите. Если первый пункт мне понятен и я в принципе согласен, то второй — не понятно совсем. Ладно редис, но почему монго? Разве это будет эффективно для кеша данных? Вы же когда разрабатывали такую архитектуру из чего-то исходили, а не просто сказали «А здесь мы будем использовать редис. потому что так прикольно». Вот именно эти рассуждения мне и интересны.
С Mongo уже определился. Hbase как бы не привлекал (не хочу начать сравнивать и расстраиваться )), но на монго уже часть проекта написано ) переделывать пока не хочется
Но о протухании данных надо будет заботиться самому, так как там, на сколько я знаю, нет механизма инвалидации по времени? Или я не прав? В итоге, при хранении сессии мне нужно будет заботиться о том, чтобы чистить от старых сессий, пользователи которых уже не заходят?