Фэйл внедрения Tarantool

Делаю сайт по соционике mysocio.ru. Он представляет собой внешнюю справочную часть и внутреннюю социальную. Люди могут типироваться и смотреть друзей, а также следить за изменениями.

Платформа Django. Крутится все в данный момент вокруг ВКонтакте. Также имеется приложение для ВК. Самая нагруженная часть, работа с друзьями. Нужно учитывать, что они периодически добавляются и меняют тип. Это надо хранить и отображать по хронологии.

Сначала сделал все на MySql: Создал таблицу пар друзей с необходимой информацией. Пока нормализованную. Но проблема в том, что в эту таблицу самая большая нагрузка на запись и от нее нужно избавляться.

Хотел сделать красиво и решил использовать NoSql для этой части. Так как данные должны храниться, решил попробовать Tarantool. Redis не рассматривал, так как по сути они близки, но тарантул типа круче ) Установил все. Нашел адаптер для Python (был только один). Но он оказался слишком простым. Фактически не поддерживались индексы NUM64 и составные первичные ключи (не работает update и delete).

Для проверки сделал полноценную модель друзей на Tarantool с указанными выше ограничениями. Хотел было дописать адаптер, но посчитал, во сколько памяти обойдется хранение 1000 пользователей с друзьями. И почему я сразу не посчитал? В общем затея держать списки друзей с именами и типами в памяти провалилась. Одна из причин — пути к фотографиям из Вконтакте. Из-за них средний кортеж занимал до 300 байт. Если у пользователя в среднем 30 друзей в ВК с приложением, то 30*300= 10кб * 1000 = 10Мб. Вроде немного. Но я рассчитываю хотя бы на 100к аудиторию. Это уже 1Гб.

Далее была идея кэшировать только записи о пользователях. Но кэш на то и кэш, что ему не обязательно хранить все. По этой причине и здесь тарантул не подошел. Теоретически подошел конечно, так как можно использовать списки и делать выборку по множеству ключей. Но Memcache с этой задачей справится не намного медленнее. Хотя это нужно будет проводить тесты позже.

Решил пойти простым путем. Писать json-ответы ВК с друзьями в отдельную таблицу MySql и при загрузке делать запрос из социальных пользователей по ключам друзей (из MySql). Это конечно медленнее, чем брать все из памяти, но поддается кэшированию.

Правда такой подход не позволяет сортировать друзей по дате добавления и изменения типа. А дата добавления у каждой пары своя. Собственно для этих данных Tarantool и может подойти. Но пока решил оставить все на MySql и держать последовательность последних изменений в таблице вместе с json-списками UID друзей. Позже эту таблицу можно будет переложить в память и сделать очередь в Tarantool. Но пока и так все справляется. Основная цель — хранить необходимые данные с небольшим количеством операций записи, выполнена.

Есть еще вариант использовать MongoDB в качестве NoSql для работы с друзьями. Но так как основные данные хранятся в MySql, не хотелось его мешать. С ростом данных и нагрузки, будет виднее.

Выводы:

• Tarantool хорош, но хранить все данные в памяти часто не оправдано. Было бы хорошо иметь возможность иметь своп (например, месячная аудитория часто меньше 10%). Как вариант, можно реализовать его самому.
• Хранить небольшие объемы данных, такие как таблицы соответствия, проще в РСУБД и кэшировать с денормализацией мемкэшем. В основном из-за легкости внедрения. В тарантуле конечно возможностей оперирования данными больше, но и внедрять его сложнее.
• Адаптер для Python пока не доделан, что создает сложности при внедрении.