Комментарии 61

Расскажите, пожалуйста, более подробно, как именно хранятся профили и сессии в базе: это два поля — ключ и профиль целиком, например, как json, или же несколько атрибутов профиля хранятся в кортеже или все атрибуты? А что вы предлагаете делать, когда структура атрибутов меняется?

Ключ и профиль в виде упакованного value. Так сделано, потому что в те старые времена Тарантул не умел еще работать эффективно с JSON. Сейчас можно заливать JSON. Он хранится внутри эффективно. Кроме того, можно заранее разбить на поля, если уверены, что структура никогда не поменяется. Плюс, сейчас у нас в разработке проект Bastida — это система поверх Тарантула, которая позволяет на том же JSON описывать преобразование полей, так, чтобы на лету менять структуру и чтобы старые приложения бы не надо было переделывать. Bastida обрабатывает 2 миллиона преобразований в секунду на одном ядре процессора, т.е. готова к почти любым нагрузкам.

Денис. спасибо. А когда примерно появится в открытом доступе Bastida?

Но вы можете начинать использовать упрощенный вариант Bastida. Вот он: https://github.com/tarantool/avro-schema. Начните с ним играться. Если появятся вопросы, то дайте знать — и я вас добавлю в чатик разработчиков и кастомеров Тарантула. Там помогут.
К недостаткам надо добавить поддержку только одной ОС — Linux. Винда не поддерживается.
Интересно, можно ли запустить тарантул на десятке с её линукс-режимом)
Free BSD еще поддерживается и OS X. Винда в процессе :) Вообще, список всего основного, подо что собраны бинарники, вот тут: https://tarantool.org/download.html. Кстати, поддерживается ARMv7, т.е. можете ставить Tarantool на IoT устройства. И это активно уже используется.
FreeBSD, OS X. Все из той же оперы. Есть такие организации, где WIndows Server корпоративный стандарт. Так что накрывайте всех. Берите пример с Redis.
Была новость, что Билайн начинает использовать Tarantool, а там Win-стек стандарт.
А в качестве языка хранимых процедур и запросов что? Своя разработка или что-то существующее? Насколько отличается от SQL?
Кроме того, можно писать хранимки прямо на C. Это хардкор, конечно. Но такая возможность есть. И мы сами ее используем для расширения функционала. Кроме того, SQL в процессе. Скоро будет.
если допилите mysql поверх этой штуки то просто выбора мне не оставите.
Я понимаю, что это прозвучит сейчас странно, но все же.

Извините, я в С'ях не силен, а можно на Rust'e?
Поверх Тарантула можно на любом языке писать. Внутри можно пока лишь на Lua, C, Swift.

Мутновато. В аутентификации у вас мухи с котлетами перемешаны — а требования к хранению профилей сильно отличаются от требований к хранению аутентификационных токенов (или айдишников сессий).


К профилям обращаются редко — только при входе на сайт. А токены можно кешировать локально (на несколько секунд), токены можно терять, токены можно вообще не хранить, если нет нужды в досрочной инвалидации сессий. И даже в этом случае может оказаться предпочтительнее хранить именно досрочно инвалидированные токены.

Что есть вход на сайт? Ввод логина и пароля? Это крайне редкое действие. Кука живет почти вечно, особенно, если пользователь часто пользуется. К профилям обращаются на каждый хит к любой странице сайта — надо шапку нарисовать, где счетчики, данные про мультиавторизацию и проч. Ключи к сессиям надо хранить на сервере, чтобы на каждый хит сверять. Кэшировать локально где? На фронт-сервере? А что делать, когда запрос пришел на другой фронт-сервер? Опишите, если не сложно, детальнее вашу архитектуру аутентификации, о которой вы говорите.

есть база профилей пользователей, которая часто вычитывается и редко обновляется
есть сессионный ключ, который записывается в куку, и фронтенду требуется по этому ключу получить userId, а по нему — профиль для рендера страницы.
Я верно изложил требования?
Теперь — что можно сделать по этому поводу:


  • кеш над базой профилей — можно на выделенном железе, можно прямо на фронтенде, если позволяет объем оперативной памяти и механизм инвалидации.
  • база профилей имеет специфический профиль нагрузки и легко шардируется — так что, быть может, кеш и не нужен.
  • Можно использовать локальный кеш со временем инвалидации порядка 1 секунды — пользователь не заметит (хотя возможны варианты), но бэкенд гарантированно получит не больше одного запроса в секунду с этого пользователя
  • sticky sessions — т.е. балансировка по IP. Так можно избежать дублирования информации в локальных кешах, а также проблемы инвалидации.
  • если нужны "долгоиграющие" кукисы — то можно подсмотреть у OAuth2 механизм двух токенов. Т.е. по длительным кукисам, которые хранятся в базе, выдается еще один короткоживущий токен (скажем, минута) на основе HMAC userId+expirationTime. При логауте можно просто стереть его из кукисов браузера. Либо хранить короткоживущие токены в in-memory кеше.
Давайте закроем на секунду глаза на то, что вы непонятно откуда выдумали вот это требование «которая часто вычитывается и редко обновляется», потому что как минимум, счетчики в шапке обновляются часто.

А дальше просто — дело вкуса.

Кто-то предпочитает зоопарки из баз с шардингом и кэшей, а кто-то ставит 8 самых дешевых supermicro сервера с Тарантулом, которые сразу и база и кэш в одном лице обслуживают по профилям весь огромный портал и едят по 15% CPU каждый.

При том, что с зоопарками кто-то получает дополнительные различные чудеса в виде «инвалидации порядка 1 секунды — пользователь не заметит».

А теперь давайте из зоопарка уберем требование «которая часто вычитывается и редко обновляется» и все станет совсем грустно.

С авторизацией разобрались, а вот "нам нужна база, в которую много пишем, много читаем, и чтобы быстро работало" — это уже главный вопрос жизни, вселенной и всего такого :-)


Если не секрет, чем платит тарантул за свою скорость? Вконтакте, например, использует интересную архитектуру СУБД — из read-only "основной базы" + in-memory cache + лог транзакций. Плюсы — работает быстро, минусы — основную базу надо регулярно перестраивать (до того, как закончится память во встроенном кеше) и очень длинный холодный старт, если база перестраивалась давно.

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

т.е. все данные должны влезать в память. понятно.

Угу. Профилей у нас 500 гигов. Сессий вообще меньше сотни. Все на одну машину залезает. Мы пошардили просто just in case.

Привет,


Сходу не нашел в доках: есть ли в тарантуле возможность индексации и быстрого поиска по вложеным в строчки массивам?
Сейчас поясню:
Есть набор сущностей типа: {name: "a", "genres": ["genre1","genre2","genre3",...],"packages":["pack1","pack2",...], "year": "2015",...}
Сущностей в системе порядка 100к. В каждой сущности около 5 вложенных массивов, в каждом порядка 10 элементов.


Нужно уметь отдавать 10k rps с одной машинки ответы на запросы типа
"отдай все записи у которых в genres есть "genre1" и в "packages" есть "package1" или "package2" и т.д. + сортировка + пэйджинг.

10 миллиардов записей получится. Жалко рам так тратить… А планы по такой фиче есть?

Json — 2к, в бинарном виде в 1к ± влезет.


Если не секрет, когда планируете?

10 терабайт. Многовато для in-memory :-)

Точно по срокам сказать не могу. У нас в приоритетах — дисковое хранилище (vinyl), SQL и полноценное кластерное решение. Кстати vinyl решит вашу проблему, когда надо много памяти.

Именно! Конечно, на практике записей там поменьше, но порядки такие, да.


Пока все идет к написанию своего кэша. Протип на гошке с ц++ по рпс в принципе устраивает, но очень не хочется изобрести новый велик :)

Драйвер написали коммьюнити. Насколько я знаю, он нестабильный. Но попробовать можно.
>Второй движок дисковый. Он позволяет всё хранить на диске. Причем можно использовать как SSD, так и винчестеры.

О чем эта фраза? Просто маркетинг или он как-то на низком уровне накопители может использовать?
Смотрите, у Тарантула есть два движка — memtx и vinyl.

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.
Спасибо.
Получается это техническое преимущество.
Об этом и надо было авторам в статье писать, а не маркетинговыми фразами раскидываться)
А если сервер ляжет, сколько данных можно потерять, по обоим движкам?
Денис, совершенно ламерский вопрос: а если объем данных превышает доступный Тарантулу объем памяти, то что с ним делает memtx? И как это отражается на производительности?
Выдает ошибку. Ровно также, как если заканчивается диск в любой не in-memory базе данных.
Какие есть инструменты в Tarantool для ручной работы? Например, просмотр текущего состояния, работы с таблицами, статистикой? Например, как phpmyadmin или HeidiSQL — менеджеры БД для некоторых штучных операциях и визуального контроля.

Есть консоль tarantoolctl, в которой можно сделать все что угодно руками. Есть еще https://github.com/tarantool/prometheus — это для мониторинга и метрик.
То есть GUI нет? Это не супер обязательно, по позволяет визуально представлять ситуацию и работать с данными от случая к случаю, то есть изредка. Документация по консольным утилитам вылетает из головы через неделю…

Это желательно для комфортной разработки. И обязательно для больших проектов.
Довольно странно, что нет ни слова о сравнении с Berkeley DB. Есть такая информация?
У нас в Почте@Mail.Ru раньше сессии и профили хранились в Berkeley DB. После перевода на Тарантул доступ к ним ускорился в десятки раз. Опубликованных бенчмарков нет, давно было дело уже. Но самая главная проблема BDB на мой вкус не только в скорости, а в том, что у нее нет репликации (возможно, сейчас есть, но на тот момент не было) и после рестарта файлики BDB превращаются в тыкву (или в мясо — как кому удобней). Все потому, что для обновления файлов используется mmap, который применяет изменения в неопределенные моменты времени. Соответственно, после жесткого рестарта (который иногда случается) данные частично теряются. Причем, теряются не последние изменения, и даже не случайные изменения, а просто куски файликов базы данных, которые переводят базу в неконсистентное состояние и ее надо восстанавливать из бэкапа.
Это новое решение на основе sphia. В целом, все открыто, код можно подиффать. Релиз с vinyl будет уже совсем скоро.
Вопрос: есть ли в Tarantool какие то алгоритмы сжатия в памяти данных в связи с тем, что как правило БД всегда хорошо сжимаются? Если нет, то есть ли идеи такой разработки?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
1999
Местоположение
Россия
Сайт
www.1c-bitrix.ru
Численность
201–500 человек
Дата регистрации

Блог на Хабре