Комментарии 61
Расскажите, пожалуйста, более подробно, как именно хранятся профили и сессии в базе: это два поля — ключ и профиль целиком, например, как json, или же несколько атрибутов профиля хранятся в кортеже или все атрибуты? А что вы предлагаете делать, когда структура атрибутов меняется?
Lua
Мутновато. В аутентификации у вас мухи с котлетами перемешаны — а требования к хранению профилей сильно отличаются от требований к хранению аутентификационных токенов (или айдишников сессий).
К профилям обращаются редко — только при входе на сайт. А токены можно кешировать локально (на несколько секунд), токены можно терять, токены можно вообще не хранить, если нет нужды в досрочной инвалидации сессий. И даже в этом случае может оказаться предпочтительнее хранить именно досрочно инвалидированные токены.
есть база профилей пользователей, которая часто вычитывается и редко обновляется
есть сессионный ключ, который записывается в куку, и фронтенду требуется по этому ключу получить userId, а по нему — профиль для рендера страницы.
Я верно изложил требования?
Теперь — что можно сделать по этому поводу:
- кеш над базой профилей — можно на выделенном железе, можно прямо на фронтенде, если позволяет объем оперативной памяти и механизм инвалидации.
- база профилей имеет специфический профиль нагрузки и легко шардируется — так что, быть может, кеш и не нужен.
- Можно использовать локальный кеш со временем инвалидации порядка 1 секунды — пользователь не заметит (хотя возможны варианты), но бэкенд гарантированно получит не больше одного запроса в секунду с этого пользователя
- sticky sessions — т.е. балансировка по IP. Так можно избежать дублирования информации в локальных кешах, а также проблемы инвалидации.
- если нужны "долгоиграющие" кукисы — то можно подсмотреть у OAuth2 механизм двух токенов. Т.е. по длительным кукисам, которые хранятся в базе, выдается еще один короткоживущий токен (скажем, минута) на основе HMAC userId+expirationTime. При логауте можно просто стереть его из кукисов браузера. Либо хранить короткоживущие токены в in-memory кеше.
А дальше просто — дело вкуса.
Кто-то предпочитает зоопарки из баз с шардингом и кэшей, а кто-то ставит 8 самых дешевых supermicro сервера с Тарантулом, которые сразу и база и кэш в одном лице обслуживают по профилям весь огромный портал и едят по 15% CPU каждый.
При том, что с зоопарками кто-то получает дополнительные различные чудеса в виде «инвалидации порядка 1 секунды — пользователь не заметит».
А теперь давайте из зоопарка уберем требование «которая часто вычитывается и редко обновляется» и все станет совсем грустно.
С авторизацией разобрались, а вот "нам нужна база, в которую много пишем, много читаем, и чтобы быстро работало" — это уже главный вопрос жизни, вселенной и всего такого :-)
Если не секрет, чем платит тарантул за свою скорость? Вконтакте, например, использует интересную архитектуру СУБД — из read-only "основной базы" + in-memory cache + лог транзакций. Плюсы — работает быстро, минусы — основную базу надо регулярно перестраивать (до того, как закончится память во встроенном кеше) и очень длинный холодный старт, если база перестраивалась давно.
Привет,
Сходу не нашел в доках: есть ли в тарантуле возможность индексации и быстрого поиска по вложеным в строчки массивам?
Сейчас поясню:
Есть набор сущностей типа: {name: "a", "genres": ["genre1","genre2","genre3",...],"packages":["pack1","pack2",...], "year": "2015",...}
Сущностей в системе порядка 100к. В каждой сущности около 5 вложенных массивов, в каждом порядка 10 элементов.
Нужно уметь отдавать 10k rps с одной машинки ответы на запросы типа
"отдай все записи у которых в genres есть "genre1" и в "packages" есть "package1" или "package2" и т.д. + сортировка + пэйджинг.
10 миллиардов записей получится. Жалко рам так тратить… А планы по такой фиче есть?
О чем эта фраза? Просто маркетинг или он как-то на низком уровне накопители может использовать?
memxt — умолчательный движок, хранит копию датасета в памяти, пишет каждую транзакцию на диск
vinyl — дополнительный движок, хранит датасет на диске в log structured tree, пишет каждую транзакцию на диск
Основное отличие vinyl и традиционных B+ tree based движков таких как InnoDB в MySQL или Postgres в том, что любая изменяющая операция приводит лишь к записи в журнал, но не меняет сам dataset. Сам dataset перестраивается в фоне. Движок вырос из LevelDB by Google и RocksDB by Facebook, построенных на тех же принципах — максимизируем скорость записи. В vinyl учли ошибки обоих и сделали более производительный движок.
Благодаря такой архитектуре, вы можете хранить большие наборы данных на обычных магнитных дисках (HDD), которые в 10 раз дешевле твердотельных (SSD), потому что запись всегда линейная, а HDD оптимизирован как раз под линейную запись. При этом, чтение можно будет кэшировать в памяти, а в последствии и на SSD.
Tarantool: примеры использования