вместо планок могу рекомендовать упражнения Бубновского — помогает лучше.
Я делаю много упражнений на пресс и на длинные мышцы спины, для этого достаточно турника или станка для гиперэкстензий.
Если работаешь 12-14 часов — значит и во время обеда, в дороге, в другом городе, в массажном кресле и т.д. Монитор очень хорошая вещь если хочешь отделить рабочее время от нерабочего, у меня такой цели не стоит.
Скорости мало не бывает, на мой взгляд, секунд 10-20 он поднимается из высшей точки в низшую. Достаточно тихий. Всё очень приемлемо, но чутких родственников в той же комнате вы разбудите.
Каждый инстанс самотюнится чтобы использовать фактически доступные ресурсы. Виртуализация не нужна. Постоянно ведётся измерение disk bandwidth и инстанс ограничивает write throughput чтобы подстроиться под bandwidth
6) Не просто консистентны, транзакционны. Не надо забывать что вторичные индексы в первую очередь хранятся в оперативной памяти. Это просто ещё одно lsm-дерево со своим level0, так что это не сверхзадача — сделать обновление нескольких индексов в памяти по принципу «всё или ничего». Но технически это устроено не так. Фактически при вставке данных в vinyl вставка осуществляется не в lsm, а в transaction-local дерево. То есть в tarantool lsm-дерево никогда не содержит грязных данных. Перемещение из transaction-local памяти в lsm осуществляется при commit'е. Этот подход мы унаследовали от sophia engine, и это, по моим оценкам, было наиболее значимой инновацией в sophia по сравнению с классической архитектурой управления транзакциями. Хотя транзакционный менеджер sophia мы конечно переписали, в нём не было поддержки gap locks.
4) Шардинг, конечно, работает с винилом точно так же как он работает с memtx, т.к. шардинг и как реализация и как концепция находится «поверх» storage engine. Да, выходит так что у нас три уровня шардинга: между несколькими машинами, между несколькими инстансами на одной машине, и между разными range одного space'а. Это всё работает незаметно для пользователя.
3) Tuple cache. Структура данных — модифицированное дерево отрезков. В tuple cache хранятся уже несжатые данные, но не блоками, а индивидуальными объектами. Если range read читает несколько таплов, они соединяются в цепочку и образуют отрезок. Таким образом, данные уже готовы к отправке по сети. В кэш данные попадают только при чтении. При этом, если читается несуществующее значение, то оно также укладывается в кэш, т.к. чтение несуществующих значений из lsm очень дорогая операция.
При обновлении значения, которое присутствует в кэше, значение из кэша удаляется. Хранить его более не имеет смысла т.к. новое значение присутствует в level0 lsm дерева, Который и так в памяти.
2) Про разрешение конфликтов. У нас стандартный optimistic transaction scheduler. Это означает, что одновременно с одними и теми же данными могут работать много транзакций. Для «открытых» транзакций в виниле, изменяющих один и тот же ключ, побеждает транзакция первой пришедшая к финишу. Конфликтная транзакция абортится. После коммита мы сохраняем в каждой операции в LSM дереве id транзакции, которая внесла данное изменение. Это позволяет реализовать поддержку consistent snapshot для чтения, и чтения в виниле (Read-only transactions) не блокируют писателей и не оставляют блокировок.
Второй вопрос состоит в том, задумывались ли мы над различными стратегиями compaction и различными ручками тюнинга. Есть понимание, что различные стратегии сompaction — cassandra-specific костыль родившийся из-за непонимания на этапе реализации LSM в cassandra «общего» случая оценки эффективности LSM деревя для любого workload'а. В настоящее время уже выведено достаточно теории которые позвоялют автоматически выбрать оптимальную стратегию в зависимости от workload'а. Мы тажке решили развиваться по пути автоматического тюнинга compaction strategy. Фактически у нас микс leveled и tiered, на последнем уровне у нас всегда только один run file, за счёт этого достигается минимальный space amplification, за счёт не очень больших дополнительных затрат по write amplification. Также недавно мы добавили compaction randomization — это стратегия, с помощью которой мы снижаем «волновой», «шквальный» эффект который compaction имеет на write bandwidth. У нас реализован write throttling — это автоматическое квотирования новых записей в зависимости от write bandwidth. В общем, мы прикладываем максимум усилий для того чтобы тюнинга много не требовалось.
1) В первом вопросе два вопроса. Первый — про time series support. Для нормальной поддержки time series нужно решить два принципиальных вопроса:
— сжатие временных рядов. Мы используем алгоритм компрессии общего назначения, zstd, но для временных рядов могут использоваться специализированные (дифференциальные) алгоритмы сжатия. Мы не проверяли относительную эффективность специализированных алгоритмов и zstd, пока до этого не дошли руки, возможно там существует принципиальный выигрыш в степени сжатия.
— учёт того что данные во временных рядах не пересекаются по диапазону во время compaction. Этот учёт у нас реализован за счёт функционала Ranges, т.к. каждый range — это отдельное lsm дерево, мы автоматически исключим из compaction старые диапазоны time series. Там ещё возможен тюнинг и дальнейшее снижение compaction overhead — думаю ещё можно выиграть до 50% write bandwidth специализированными алгоритмами, но принципиально этот вопрос учтён.
Резюмируя, таким образом, пригодность винила для time series: эффективность ниже чем у полностью специализированного time series storage engine, по моим оценкам в 1.5-2 раза, тем не менее достаточно высокая в сравнении с lsm общего назначения или тем более btree. Сравнение и бенчмаркинг мы ещё не проводили, поэтому подтвердить свои слова цифрами пока не могу, это оценки на основе понимания внутреннего устройства некоторых time series движков.
Спасибо за отзыв. Статьи появятся, стабильный релиз вышел меньше года назад, внедрениям надо поработать в проде чтобы у сообщества появился опыт работы с технологией. Пока что приходите с вопросами в чат.
Спасибо за комментарий. По поводу вывода сделанного в №3: он безапеляционный почему-то, наверное поэтому неправильный ). Нет, конечно же проблема многоверсионности не решается отдельно от формата хранения, как и проблема бэкапа, и LSM предлагают очень элегантное решение для обеих проблем. Префиксная компрессия, да, есть у многих вендоров, нет, «отлично сжимает secondary indexes» — поверхностное утверждение, зависит от index fanout, а главное, что префиксная компрессия усложняет код (удачи в реализации итератора в обратном порядке) при этом с точки зрения сжатия не лучше обычной компрессии при достаточно больших страницах. В общем, мне кажется, Вам стоит покопать дальше, а именно в сторону эксплуатации, чтобы разобраться в ценностях на которые мы ориентировались. Иногда может показаться что чем больше «обвес» в виде разных видов компрессии, кэширования и т.д. тем лучше. Нет, это количественный подход к решению, не качественный. Качественные решения, это например архитектура вторичных ключей и range tuple cache в Vinyl. Это ранжирование, которое позволяет адаптировать compaction для разных нагрузок (в rocksdb для этого в какой-то момент говорили о page stitching, реализовали ли его или нет я не знаю). Наконец, это compaction scheduler, который учитывает характер нагрузки, а не только форму дерева. В общем, одним из посылов статьи было то, что LSM — greenfield в области оптимизации, и обвешивать его btreeшными оптимизациями неправильно.
Я делаю много упражнений на пресс и на длинные мышцы спины, для этого достаточно турника или станка для гиперэкстензий.
При обновлении значения, которое присутствует в кэше, значение из кэша удаляется. Хранить его более не имеет смысла т.к. новое значение присутствует в level0 lsm дерева, Который и так в памяти.
— сжатие временных рядов. Мы используем алгоритм компрессии общего назначения, zstd, но для временных рядов могут использоваться специализированные (дифференциальные) алгоритмы сжатия. Мы не проверяли относительную эффективность специализированных алгоритмов и zstd, пока до этого не дошли руки, возможно там существует принципиальный выигрыш в степени сжатия.
— учёт того что данные во временных рядах не пересекаются по диапазону во время compaction. Этот учёт у нас реализован за счёт функционала Ranges, т.к. каждый range — это отдельное lsm дерево, мы автоматически исключим из compaction старые диапазоны time series. Там ещё возможен тюнинг и дальнейшее снижение compaction overhead — думаю ещё можно выиграть до 50% write bandwidth специализированными алгоритмами, но принципиально этот вопрос учтён.
Резюмируя, таким образом, пригодность винила для time series: эффективность ниже чем у полностью специализированного time series storage engine, по моим оценкам в 1.5-2 раза, тем не менее достаточно высокая в сравнении с lsm общего назначения или тем более btree. Сравнение и бенчмаркинг мы ещё не проводили, поэтому подтвердить свои слова цифрами пока не могу, это оценки на основе понимания внутреннего устройства некоторых time series движков.