Size: a a a

2021 March 09

Е

Евгений in Tarantool
Ибо тут нужно быть сенсеем, а таких мало
источник

NK

Nick Karlov in Tarantool
все техники сводятся к минимизации аллокаций, переиспользованию буферов
источник

NK

Nick Karlov in Tarantool
а вот на си достаточно написать 1-2 хранимки на 200 строк, которые умеют получать данные по итератору (периодически отдавая управление), а все остальное оставить в луа
источник

Е

Евгений in Tarantool
Nick Karlov
а вот на си достаточно написать 1-2 хранимки на 200 строк, которые умеют получать данные по итератору (периодически отдавая управление), а все остальное оставить в луа
а дайте ссылку на Ваш проект, если не секрет
источник

Е

Евгений in Tarantool
я имею в виду сайт
источник

NK

Nick Karlov in Tarantool
Евгений
а дайте ссылку на Ваш проект, если не секрет
пока могу только это выслать: https://www.highload.ru/spring/2021/abstracts/7286
www.highload.ru
Николай Карлов на HighLoad++ 2021
Рассмотрим одну из базовых задач, которую решает любая мировая биржа — быструю доставку данных о заявках до клиентов. На первый взгляд, задача не выглядит сложной, но есть отягчающие обстоятельства:- поток данных может достигать нескольких сотен тысяч запросов в секунду;- потребителей может быть сотни, а то и тысячи;- время между генерацией ордера и попаданием его конечному потребителю должно быть не более 5 мс в 99% случаев.В нашем докладе мы расскажем:- о выборе инструмента (или почему стандартные очереди не подходят для этой задачи);- об архитектуре распределенного хранилища горячих данных- о структурах хранения данных;- каким образом добавление троттлинга уменьшает задержку;- о проблемах, возникающих при горизонтальном масштабировании хранилища данных, и их решении;- о примененных оптимизациях, в разы увеличивших производительность.
источник

Е

Евгений in Tarantool
20 И 21 МАЯ 2021
источник

Е

Евгений in Tarantool
будет время, заеду послушаю
источник

Е

Евгений in Tarantool
вы молодцы в mail.ru
источник

NK

Nick Karlov in Tarantool
Евгений
будет время, заеду послушаю
я могу еще что сказать — очень (ОЧЕНЬ) важно ,в каком порядке поля в тапле
источник

NK

Nick Karlov in Tarantool
при ваших нагрузках
источник

Е

Евгений in Tarantool
Nick Karlov
я могу еще что сказать — очень (ОЧЕНЬ) важно ,в каком порядке поля в тапле
вот такого я ни в одной доке не видел, можно по подробней?
источник

NK

Nick Karlov in Tarantool
Евгений
вот такого я ни в одной доке не видел, можно по подробней?
это из области многомесячных бенчей.
Короче
1) порядок полей в индексе влияет на скорость апдейтов/вставок (в тарантуле есть несколько видов компараторов, самые быстрые — плюсовые темплейты). Индексируемые Поля должны быть в самом начале в порядке их включения в составной индекс.
2) если вам нужно поле из мзгпака, то при ваших нагрузках имеет значение, где поле находится. Мзгпак декодируется линейно от начала к концу
3) если вам какие-то поля не нужны в логике хранимок, упакуйте их в бинарь и положите в одно поле тапла. Это даст большой прирост
источник

NK

Nick Karlov in Tarantool
например, мы торговые ордера, которые 600 байтов, кладем бинарем, выделяя из них только индексируемые поля (их 3 штуки). Это дает кратный прирост перфа
источник

NK

Nick Karlov in Tarantool
опять же: при высоких нагрузках
источник

Е

Евгений in Tarantool
тут момент есть, мы не только доставляем публичные данные. Мы много считаем и торгуем. Публичные данные, это не самый сложный кейс
источник

Е

Евгений in Tarantool
Сложности начинают возникать когда происходим много событий, от 10k в сек, а их надо обсчитать и принять решение
источник

Е

Евгений in Tarantool
И главное донести результат достаточно быстро
источник

NK

Nick Karlov in Tarantool
Евгений
Сложности начинают возникать когда происходим много событий, от 10k в сек, а их надо обсчитать и принять решение
мне сложно что-то ответить, так как я не понимаю ващу задачу так, как ее понимаете вы =)
источник

NK

Nick Karlov in Tarantool
но что могу сказать — если вы оптимизируете порядок полей, исключите их из тапла путем внесения в бинарь, это вам даст прирост
источник