Highload-2023: Отчёт Виталия Филиппова — различия между версиями

Материал из YourcmcWiki
Перейти к: навигация, поиск
м
 
(не показано 68 промежуточных версий этого же участника)
Строка 1: Строка 1:
−
Как я уже [[Highload-2022: Отчёт Виталия Филиппова|писал]] в прошлогоднем отчёте - самая крупная и раскрученная конференция Бунина. Финальная стоимость выросла уже аж до 64 тыр с 60, то есть годовая инфляция по мерке Онтико в этот раз составила 6.66 %. :-)
+
Как я пишу каждый раз, включая [[Highload-2022: Отчёт Виталия Филиппова|прошлогодний отчёт]] — самая крупная и раскрученная конференция Бунина. Финальная стоимость выросла уже аж до 64 тыр с 60, то есть годовая инфляция по версии Онтико в этот раз составила 6.66 %. :-)
  
−
'''Общее впечатление:''' Неплохо - "торжество велосипедов" в докладах, всё как мы любим, но перегруженно. Слишком много народу на эту площадку.
+
'''Общее впечатление:''' Неплохо — «торжество велосипедов» в докладах, всё как мы любим, но перегруженно. Слишком много народу на эту площадку.
  
−
Реально, 3750 человек в Сколково, в котором и проходила конференция - это перебор. Если более-менее интересный доклад шёл в любом зале, кроме самого большого "Конгресс-холла" - сесть там было невозможно. Они пытались организовывать какие-то "расширительные бачки" и организовывать ретрансляции докладов рядом с залами, но это было бесполезно, ибо организовывали не в коридоре, а в маленьких отдельных комнатушках. Какой толк от расширительного бачка на 10 человек, когда не влезло 50...
+
Реально, 3750 человек в Сколково, в котором и проходила конференция — это перебор. Если чуть более, чем средне-интересный доклад шёл в любом зале, кроме самого большого «Конгресс-холла» — сесть там было невозможно. Они пытались организовывать какие-то «расширительные бачки» в виде ретрансляций докладов рядом с залами, но это было бесполезно, ибо организовывали не прямо в коридоре, а в маленьких отдельных комнатушках. Какой толк от расширительного бачка на 10 человек, когда не влезло 50…
  
−
Второй момент - совершенно упоротая топология здания. Поиск нужного зала каждый раз превращался в квест: сначала надо попытаться понять по карте, где ты находишься, решить, в какую сторону идти и с какой стороны всё обходить, а потом ещё иногда найти отдельные лестницы на второй этаж для прохода в некоторые залы (просто подняться в произвольном месте недостаточно). При этом везде столики, стенды, толпы, поэтому даже образовывались заторы и проходы становились полудуплексными. Даже в сортирах был хайлоад. Явно не хватало процессоров на все... потоки.
+
Второй момент — совершенно упоротая топология здания. Поиск нужного зала каждый раз превращался в квест: сначала надо попытаться понять по карте, где ты находишься, решить, в какую сторону идти и с какой стороны всё обходить, а потом ещё иногда искать отдельные лестницы на второй этаж для прохода в некоторые залы (просто подняться в произвольном месте недостаточно). При этом везде столики, стенды, толпы, поэтому даже образовывались заторы и проходы становились полудуплексными. Даже в сортирах был хайлоад. Явно не хватало процессоров на все… потоки.
  
−
При этом ещё и 11 параллельных залов. Я даже пожалел, что не заявил какую-нибудь хрень на опенсорс-трек - там такую фигню рассказывали, что я бы точно смог не хуже. Не, сама идея опенсорс-трека неплохая, но доклады жутковатые, хорошо демонстрируют механический подход.
+
При этом ещё и 11 параллельных залов. Я даже пожалел, что не заявил какую-нибудь хрень на опенсорс-трек — там такую фигню рассказывали, что я бы точно смог не хуже. Не, сама идея опенсорс-трека неплохая, но те доклады, на которые я попал, были не очень и хорошо демонстрируют механический подход к опенсорсу. Вот, слышали, что опенсорс это полезно и пытаются выжать пользу просто из произвольных проектов.
  
 
= День 1 =
 
= День 1 =
 +
 +
== Барсик ==
 +
 +
'''Григорий Бутейко (VK, ВКонтакте) — BARSiC — асинхронная репликация и консенсус для 70 баз данных.'''
 +
 +
Помните, я же написал выше, что конфа — торжество велосипедов. Вот, это велосипед №1, прямо с открытия.
 +
 +
Полная фигня, 150 полуляхов из 250. Технических деталей работы алгоритма в докладе было крайне мало, просто общая мысль — вот, им ничего готовое не подошло, Raft они почему-то сочли слишком сложным (Raft, сложным?!), поэтому сделали всё сами и на основе другого протокола — Viewstamped Replication аж от целой Бабы Лизы… то есть Барбары Лисков.
 +
 +
Самое смешное, что они на замену Raft-у, который им «показался слишком сложным», выбрали алгоритм, который (А) вообще не отличается от Raft по смыслу и (Б) даже сложнее, чем Raft, в деталях реализации! Это более старый алгоритм! Чувак, который придумал Raft, про этот алгоритм даже в своём диссере писал! В котором он, собственно, и придумал Raft.
 +
 +
Я про VR почитал уже после конфы. Единственное реальное отличие — то, что ноды голосуют не за первого заявившегося кандидата, а за кандидата с минимальным ID (IP-адресом). Всё остальное практически идентично, Raft Term = VR View и так далее. При этом у VR 10 типов сообщений вместо 4-х у Raft-а.
 +
 +
<blockquote>
 +
{{WikiCutBegin|Развёрнутое объяснение под катом, взял [https://groups.google.com/g/raft-dev/c/cBNLTZT2q8o отсюда]}}
 +
With apologies to Barbara, James, and Brian. VR introduced some great
 +
ideas, and VRR was a huge improvement in clarity. I think the industry
 +
would be in a better place now with respect to consensus if it had
 +
paid less attention to Paxos and more to VR.
 +
 +
You’re right, Heidi, that Raft and VR/VRR are similar, and we
 +
acknowledge this in the first page of the paper.
 +
 +
At a high level, you could argue they’re exactly the same. Lamport
 +
would probably call them both Paxos. Their messaging pattern is
 +
similar. Why they work is similar, and their proofs of correctness
 +
could be similar.
 +
 +
At a low level, you could argue they’re very different. Raft’s
 +
mechanism is compact (VRR uses 10 message types where Raft uses 4 to
 +
accomplish the same tasks). Raft spells out how to do leader election
 +
with randomized timeouts and how to avoid transferring entire logs.
 +
 +
And of course membership changes are entirely different.
 +
 +
Now (2015), there’s a huge difference in completeness. Raft has
 +
several implementations including membership changes and log
 +
compaction, some evaluation, a proof or two, my dissertation (a lot of
 +
discussion about design choices), and many online resources to help
 +
people learn. I don’t think VR/VRR is competitive with any of that
 +
currently. For example, I just searched GitHub for «Viewstamped
 +
Replication» and found only one project; searching «VRR» yields noise.
 +
 +
Paper-wise, I’m biased, but I think the Raft paper is more accessible
 +
to beginners. That’s because the Raft paper explains the why, and the
 +
VRR paper just tells you the what.
 +
 +
I also think the leader election algorithm in the original VR is
 +
better than in VRR. I discuss this in the related work in my
 +
dissertation. The original VR has the view manager tell the new leader
 +
to start, yes, but it doesn’t have to transmit any log entries. And I
 +
still don’t feel great about the leader being a function of the view
 +
(term) number. It feels misleading, since of course different servers
 +
might be in different views, especially during leader changes. But I
 +
haven’t implemented or evaluated that approach.
 +
 +
We (John and I) actually didn’t know about the VRR paper until after
 +
we had started Raft. I think the earliest time someone mentioned it to
 +
us was three days before our first paper submission on Raft, in
 +
September 2012, buried in an email with a bunch of other pointers.
 +
Would we have used VRR instead of creating Raft if we knew abut it in
 +
time? I’m not sure, but it definitely would have been a better
 +
starting point for us.
 +
 +
Know of any performance evaluation between these two protocols? Nope.
 +
Normal-case operation would be the same, so you’d probably have to
 +
compare leader changes. And I feel like that depends on the details of
 +
how you «optimize» VRR, so I don’t know if it’d be apples-to-apples.
 +
 +
Hope I haven’t offended anyone, and hope this helps,
 +
Diego
 +
{{WikiCutEnd}}
 +
</blockquote>
 +
 +
Причём аргументы, согласно которым им не подошли готовые решения, меня лично вообще не убедили. Какое-то расхождение данных и метаданных при использовании внешнего сервиса консенсуса… не, ну писать просто надо нормально, что значит — расхождение. Я же юзаю etcd в Vitastor, брат жив. Ну ладно я, ещё пример — TiDB юзает встраиваемый etcd, брат тоже жив. Всё ещё мало? Patroni/Stolon испокон веков юзают Consul/etcd. Ceph OSD хранят метаданные в Ceph Monitor-ах. Какое расхождение?!
 +
 +
Хоть бы исходники открыли, ё-моё, хоть какая-то польза была бы от этого барсика. А то ну написали тесты, ну пофаззили, ну дополнительно верифицировали на TLA+, ну молодцы. Но какой во всём этом толк, если рядом лежит штук 10 «вот таких же, только меньше, но других», тоже хорошо оттестированных за все эти годы Raft-ов…
 +
 +
== Производительность Go ==
 +
 +
'''Никита Галушко (VK, ВКонтакте) — Выжимаем из Go максимум производительности'''
 +
 +
В принципе стандартные вещи, даже не так их много было:
 +
 +
* Мелкие объекты — до 32 байт — оптимизируются
 +
* Интерфейсы медленнее из-за виртуальных вызовов
 +
* Если в массивах срабатывает проверка границ (не срабатывает <abbr title="Bounds Check Elimination">BCE</abbr>) — код замедляется
 +
* for по индексам быстрее, чем for по range (подозрительно, stackoverflow говорит обратное — что они не отличаются)
 +
* Работа со строками хорошо оптимизирована для частых сценариев
 +
 +
== Как привлекать людей в опенсорс-проекты ==
 +
 +
'''Ксения Романова (Positive Technologies) — Сообщества вокруг технологии: почему быть бесплатным недостаточно'''
 +
 +
Девушка связана с Apache Ignite и фондом Apache (туда ещё проекты умирать часто сдают), сейчас работает у позитивов.
 +
 +
Я не уверен, что доклад был именно о том, как я его окрестил, ибо изложение было довольно размытым. Но мне кажется, что это самое близкое. По-моему, она пыталась развивать стереотип о том, что опенсорс — это «бесплатные руки», и надо лучше искать эти бесплатные руки, лучше общаться с людьми и помогать им включиться в проект. «Как бы нам заполучить бесплатных разработчиков». :-)
 +
 +
С моей точки зрения — это утопия, хоть я и адепт опенсорса. Времени всем не хватает, видение развития проекта у каждого своё (1 программист пишет программу за 1 месяц, 2 — за 2 месяца), лидеры проекта душнят в пулреквестах, поэтому не стоит рассчитывать, что вы сможете найти серьёзный пул контрибьюторов среди сообщества. Проекты типа Linux — это очень редкие и крутые исключения из правил, так почти никто не умеет. Хотя, кстати, в её родном фонде Apache линукс ещё не факт, что свершился бы — они же не принимают правки от компаний.
 +
 +
Всё остальное в докладе — шелуха. Вот… сообщества… технологии… привлекать людей… модель «воронка»… модель «орбита»… людям это надо для чего-то там… компаниям это надо для чего-то там… 80% кода в опенсорс-проектах пишут единичные «герои»… Контрибьюторы классифицируются по 2 осям — качеству кода и любви к проекту… (тут я вообще чуть не взоржал)
 +
 +
Из интересного — в конце спросил у неё, а зачем компании сдают проекты в фонд Apache, в чём выгода. Так как, по-моему, проекты туда обычно сдают помирать, на кладбище. Для справки — апачи забирают все права на проект себе и даже потом правки от компаний не принимают — отправлять патчи могут только отдельные физлица-разработчики, даже если они все работают в одной компании. Она ответила, что сдают ради помощи в развитии, типа гайдлайнов/руководств по жизненному циклу проекта и ради готовой инфраструктуры разработки. Ну понятно — Apache пытается строить «завод опенсорса» и на этом в процессе делать деньги. Но вот для сдающей компании особой выгоды, мне кажется, всё-таки нет, так что скорее всего обычно действительно просто «сдают в отстойник».
 +
 +
== Дата скетчи ==
 +
 +
'''Сергей Жемжицкий (SberDevices) — Data Sketches — как съесть слона целиком (даже если он бесконечный)'''
 +
 +
В целом неплохой доклад про алгоритмы семейства Data Sketches. Ну в смысле для меня неплохой, ибо я про эти алгоритмы не знал. Я так понимаю, это новое собирательное название для уже некоторое время существующего класса алгоритмов — потоковых статистических алгоритмов.
 +
 +
TLDR — всё это реализовано в библиотеке [https://datasketches.apache.org/ Apache DataSketches] на Java и C++, бери и юзай. Даже в ClickHouse припилено уже.
 +
 +
В докладе затронуты алгоритмы:
 +
* Подсчёт числа уникальных элементов в потоке (Count-Distinct): HLL (HyperLogLog), CPC (Compressed Probability Counting), Theta Sketch
 +
** HLL: число уникальных примерно равно 2^(максимальное число идущих подряд нулей в начале хешей всех элементов + 1).
 +
** CPC: число уникальных примерно равно 2^(максимальное число идущих подряд нулей в конце хешей всех элементов, кроме хешей из всех нулей).
 +
** Theta Sketch: вроде бы это обобщение алгоритма K минимальных значений. Типа, мапим каждое значение в хеш, равномерно распределённый в диапазоне чисел (0, 1). Сохраняем K+1 минимальных значений таких хешей. После чего число уникальных будет примерно равно K/(K+1-ый минимальный хеш). Вот статья про эту тету https://github.com/apache/datasketches-website/blob/master/docs/pdf/ThetaSketchFramework.pdf — кстати, в докладе он принцип работы этого алгоритма не объяснил, это я уже тут для отчёта докурил :-)
 +
* Частота встречаемости элемента: CountMin Sketch, Misra-Gries
 +
** CountMin: берём несколько независимых хеш-функций, делаем таблицу — на каждый хеш 1 строка, и заданное K колонок. На каждое значение считаем все хеши и увеличиваем на 1 соответствующую хешу колонку в строчке этого хеша. Потом, чтобы оценить частоту встречаемости элемента, берём минимум от значений ячеек, соответствующих всем его хешам.
 +
** Misra-Gries: по ходу подсчёта сохраняем K самых часто встречаемых элементов и считаем их частоты. Если же встречаем элемент, не входящий в K, увеличиваем на 1 отдельный счётчик «всех остальных», уменьшаем на 1 все частоты K элементов, удаляем элементы с нулевыми частотами. Далее частоту встречаемости любого элемента принимаем за (счётчик «всех остальных» + счётчик самого элемента).
 +
* Квантили/гистограммы: куча странных названий, я себе из всего выписал Manku-Rajagopalan-Lindsay (MRL), но в суть расчёта докладчик уже не погружался.
 +
 +
== Катаем гусей ==
 +
 +
'''Павел Левдик (Yandex Infrastructure) — Внутри S3'''
 +
 +
Доклад про Яндексовую реализацию S3 (гусь/goose — это go+s3, название сервера). Глобально всё просто — взят уже готовый надёжный распределённый сторадж для данных, взят шардированный и реплицированный PostgreSQL, одно скрещено с другим и вот вам, пожалуйста, S3.
 +
 +
Шардирование раньше было только в виде чанков — диапазонов имён объектов в бакете. Чтобы таскать чанки с шарда на шард — мувер, чтобы порождать новые чанки почкованием — сплиттер. И то, и то — через двухфазный коммит. Но была проблема, что в такой схеме определённые паттерны нагрузки не размазывались по всему кластеру БД. Например, если юзер всегда писал новые объекты в конец бакета — эти вставки всегда попадали в один чанк и, соответственно, шард. Или, например, если юзер сначала делал алфавитный листинг всех объектов, а потом последовательно читал их — такая нагрузка тоже в каждый момент времени попадала только в один шард БД.
 +
 +
Поэтому сделали хеш-чанки (диапазоны хешей имён объектов) и такая нагрузка тоже стала размазываться. Был даже график, на котором это было видно наглядно — до переключения на ханки нагрузка шла постоянно то в 1 шард, то во 2, то в 3 и т. п., а после — равномерно во все три. То есть, все три покрашенные разными цветами линии нагрузки в разные шарды сошлись на одном уровне. Кто-то из зала не понял, что на графике изображены не листинги, а обычная нагрузка (то ли GET, то ли PUT), и спросил, так это что же, теперь листинги грузят все шарды? По факту с этим проблем нет, так как, во-первых, запрос листинга в S3 ограничен 1000 записей, во-вторых, и до перехода на ханки запросы листинга часто попадали в несколько шардов — в тех случаях, когда нельзя точно сказать, что 1000 записей можно вернуть из 1 шарда, а в-третьих, с ханками число шардов, на которые размазан каждый бакет, тоже регулируется, просто оно регулируется делением/умножением сразу в 2 раза.
 +
 +
Ещё было про счётчики и то, что они считаются через очередь. Ну ещё из интересного (для конкурентов :D) — цифры, например, 120к rps в облаке (2x за год), типичный крупный клиент > 1 ПБ и > 1 млрд объектов, и > 1000 rps.
 +
 +
Кстати, ещё Паша не упоминал, что там в PostgreSQL есть хранимки и они весьма неплохо работают. Но про это есть старый пост на хабре: https://habr.com/ru/companies/yandex/articles/417241/
 +
 +
== Неудачный опен-аут-сорс ==
 +
 +
'''Олег Балбеков (Evrone) — (Не)удачный эксперимент по выращиванию культуры Open Source'''
 +
 +
Компания — что-то среднее между заказной разработкой и аутсорсерами. Пишут сайтики на Ruby и Python. Вкратце — они проверяли на практике гипотезу, что опенсорс полезен для бизнеса, постаравшись выжать ВСЁ!!!1111 из ну, в общем-то, крох — 5 млн рублей за 5 лет.
 +
 +
Что пробовали:
 +
* Оплачивать разработку открытых проектов своими разработчиками (но не более, условно, 50% времени)
 +
* Донатить на гитхабе; разыгрывать раз в неделю по 100$ среди опенсорс-проектов
 +
* Нагонять трафик со своих открытых проектов, но его было 1%
 +
* Нагонять трафик, используя проекты как инфоповоды, но поднять удалось всего до 4.4%
 +
* Технологический пиар (выступать на конференциях) — получили некоторое внимание сообщества, но не известно, как померить
 +
* Прямые продажи (придут инженеры и наймутся, или купят). ''Ога, щаз — прим.вред.'' Получили всего 1% лидов и ровно 1 продажу за 5 лет
 +
* Косвенные продажи (подтверждение квалификации компании). Есть, но не известно, как померить
 +
* Прямой HR-маркетинг (сбор базы кандидатов). Бесконечно менее эффективно, чем HR-инструменты (через оные и так есть база в 40366 человек). Наняли всего 1 человека за 5 лет
 +
* Косвенные плюсы при найме есть. Кандидатам нравится, что в компании можно пилить опенсорс. Но не известно, как померить :-)
 +
* Обучение через открытую разработку. Писать и показывать красивый код и т. п. Резюме — эффективно, но не масштабируемо.
 +
 +
Причём по факту этим в компании занималось 2.5 человека, они ушли и всё это сдулось. Поэтому он сказал, что ''Если ты тот самый сотрудник Evrone, который бы хотел этим продолжить заниматься — Welcome, мы поддержим!'' — кажется, есть некоторые проблемы с внутренними коммуникациями в компании, если обращаться к сотрудникам приходится через Highload. :-)))
 +
 +
Но эксперимент хочет продолжить и вернуться через 3 года с новостями. Ну ждём, чо.
 +
 +
Справочно — опенсорс у них донный, фигня в духе мелких npm/pip модулей. Самый крупный проект — я спросил — какой-то линтер, что ли. Понятно, что с такой мелочи особого профита не получишь. Я потом ему задал вопрос, может вам попробовать что-то более крупное пилить? Он такой — ну, это уже продуктовая разработка. Ну конечно, продуктовая, ведь «открытое ПО» это в первую очередь что? Это в первую очередь ПО, то есть программный продукт! А для механистического подхода «просто хотим опенсорс» и всего 5 млн рублей, потраченных за 5 лет, у них весьма неплохо всё получилось.
 +
 +
== Кубернетес от перил ==
 +
 +
'''Андрей Вильмов (ПерилаГлавСнаб) — От CRM к DataLake с K8s и микросервисами'''
 +
 +
Немного напомнило старый мем и поэтому очень хотел послушать:
 +
 +
[[Файл:Консервы.png|200px]]
 +
 +
Но как ни странно, всё довольно разумно. Хотя смотрел в записи, потому что не смог попасть в зал, потому что МЕСТА НА КОНФЕРЕНЦИИ НЕ ХВАТАЛО.
 +
 +
Вкратце — была страшная старая CRM-ка и всё было в ней, разрослось. Впилили Airflow, стали складывать в PostgreSQL. Постгря выросла до 3 ТБ, поменяли на Greenplum. Потом добавили Kafka и реалтаймовых потребителей. Потом впилили Kubernetes. Потом Minio в виде стораджа. Где-то рядом появился Spark.
 +
 +
Вот так, слово за слово, <s>заяц получил п…ы</s> перила <s>превратились в облако</s> сделали своё мини-облако.
  
 
= День 2 =
 
= День 2 =
  
−
[[Категория:Конференции]]
+
== Петабайт в УДБ на ХДД ==
−
[[Категория:VitaliPrivate]]
+
 
 +
'''Антон Барабанов (Яндекс) — Петабайт в YDB over HDD в процессингах Яндекс.Метрики'''
 +
 
 +
Ну, реально пока не петабайт, а 500 ТБ, но, типа, скоро будет петабайт. Но всё равно норм. При потоке записи 20 гбит/сек. 300 дисков в инсталляции. Суть — пробовали YDB на HDD. Справилось оно в их применении в целом неплохо, правда, как обычно, всю автоматику поотрубали — распределение запросов написали своё и данные тоже сами раскладывают по отдельным дневным табличкам.
 +
 
 +
Само применение — слияние визитов за сутки в метрике. То есть, на входе большой поток посещений сайтов и покупок (или других действий), на выходе надо посещения сцепить с действием, чтобы было понятно, что конверсия произошла. Для оффлайн-покупок аналогично, но дольше период — не сутки, а 20-30 дней, и данные в метрику заливает сам магазин постфактум, возможно даже вручную. Жёстких требований реального времени нет, но некоторые есть — надо, чтобы считалось 10-15 минут, а не сутки.
 +
 
 +
С YDB сначала наткнулись на проблему потребления RAM, добавлять пришлось и RAM и CPU, так как сказали, что есть жёсткие профили виртуалок во внутреннем «облаке». В итоге CPU на 90% простаивают. Потом YDB не справилось с чтением блоков с HDD, так как читает целыми блоками и только потом понимает, что нужных данных в блоке нет, а bloom фильтр работает по полному первичному ключу, а они запрашивают по одному ID юзера. Для борьбы с этим ключи положили на SSD, данные визитов оставили на HDD. Ещё натыкались на то, что автосплит партиций по нагрузке приводил к большой нагрузке из-за compaction — сначала нагрузка растёт, партиции разделяются, потом нагрузка падает, они сливаются. Всё жрёт compaction.
 +
 
 +
На вопрос «почему не YT(saurus)» ответили «так сложилось» + YT-шники им не были готовы предоставить такой кластер :-). Не Clickhouse потому, что Clickhouse плохо работает с синхронной репликацией.
 +
 
 +
== Как разрабатывается опенсорс в АЛЬТ ==
 +
 
 +
'''Евгений Синельников (Базальт СПО) — Как разрабатываются свободные проекты в команде ALT?'''
 +
 
 +
Имхо крайне бестолковый доклад. По логике названия тут должно было быть что-то про процесс разработки, а по факту было про то, что вот, опенсорс не мешает ничего продавать, потому что оно продаётся как «сборник произведений», по ГК РФ являющийся самостоятельным произведением. И про то, что бизнес не понимает GPL. Ну и упомянули своё AD под линукс (ужасная виндузятская хрень).
 +
 
 +
== SQL-регэкспы (MATCH_RECOGNIZE) ==
 +
 
 +
'''Евгений Зверев (Яндекс) — Поиск по образцу на последовательностях строк в БД'''
 +
 
 +
Доклад про последнюю фичу стандарта SQL — MATCH_RECOGNIZE — которая почти нигде не реализована, а где реализована — наверное, честно говоря, дико тормозит. Вроде как в YDB её сделали (или сделают) и поэтому это тоже доклад про YDB. :-) но в любом случае, практическое применение выглядит крайне узким.
 +
 
 +
По сути это SQL-регэкспы — сначала ты задаёшь N WHERE-условий, а потом, ссылаясь на них, говоришь, что хочешь найти последовательность строк, где сначала идёт, например, 1 раз условие №1, потом не меньше 3 раз условие №2, и потом событие №3. SQL-конструкция сама, конечно, получается многоэтажная.
 +
 
 +
Ну ок… природа любит разнообразие.
 +
 
 +
== Индексы mail.ru ==
 +
 
 +
'''Рустем Гафаров (VK, Почта Mail.ru) — Устройство индексов в почте mail.ru'''
 +
 
 +
Вот наконец и третья часть архитектуры mail.ru, продолжение [[Highload-2022: Отчёт Виталия Филиппова#Хранилище почты mail.ru|прошлогоднего доклада]]. ''Но вот эту часть я не буду у себя нигде повторять, можно же, правда? — прим.вред.''
 +
 
 +
Резюме: LSM для бедных, с 2 уровнями (L0 и L1), снапшотами в Zepto (объектном хранилище) и WAL-ами в… Tarantool-е, в виде последовательности ключей. Ух, забористые вещества.
 +
 
 +
Ящики полностью изолированные (независимый индекс по каждому), блочного доступа к индексам нет, снапшот грузится в память целиком в B-деревья (в памяти) и на него в памяти накатывается WAL. Теоретически даже поддерживается конкурентный доступ — перед операциями проверяется, не появилось ли что новое в WAL в тарантуле. Но не нужно, индекс ящика держится открытым на 1 сервере, в целом по ящикам — LRU кэш. Посему сильно экономят, не держа в памяти ненужные индексы (неактивные ящики). Вроде как экономят на индексах 600к в год.
 +
 
 +
Называется система <s>Москито, как кто-то сказал из зала</s> Mescalito, формат XTAZ. 5 датацентров… а чего ж тогда в облаке VK нет Managed Postgres на 3 ДЦ. Непорядок.
 +
 
 +
== Велосипед от Тинькова (SAGE DB) ==
 +
 
 +
'''Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных'''
 +
 
 +
…под логи. ''Ответ — когда не взял кликхауз — прим.вред.''
 +
 
 +
Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата.
 +
 
 +
Проект SAGE у них начался в 2019, когда им не захотел продлевать лицензию Splunk. Сначала сделали на эластике, потом в силу вышеописанных архитектурных нюансов решили писать своё, допилить эластик силами 3-4 лиц не осилили бы. Сначала пробовали сделать свои обратные индексы на RocksDB, но быстро упёрлись. В итоге сделали своё подобие FDAP, но без схемы. Причём даже формат сериализации свой без декодирования и без схемы, и Flexbuffers почему-то не подошёл, хотя Flexbuffers это дословно формат без декодирования и без схемы. Тоже со сжатием (zstd + словарным для ключей) и блум-фильтрами. Общая схема в итоге похожа на Loki поверх S3.
 +
 
 +
Замеры: по скорости помедленнее эластика, условно 0.5 сек 50% квантиль против 0.15 сек. Но зато на эластике 350 серверов и 7 ПБ, а на SageDB 270 серверов и 700 ТБ. По облачным ценам экономия примерно 360 млн руб в год. Но работают пока обе схемы в параллель, полный переход ещё не состоялся, пока что все запросы зеркалируются. Пилили 3 года.
 +
 
 +
Ну хз. А чего было просто не взять Clickhouse? Ну схема, да, но ведь в логах не так чтобы прямо много разных форматов и колонок. Сложилось же бы, наверное.
 +
 
 +
== PATCH в S3 ==
 +
 
 +
'''Александр Снопов (Yandex Infrastructure) — Частичная модификация объектов в Yandex Object Storage: как мы улучшаем работу ФС поверх S3'''
 +
 
 +
Вкратце: мы запилили в S3 [https://cloud.yandex.ru/docs/storage/s3/api-ref/object/patch PATCH] и поддержали его в [https://github.com/yandex-cloud/geesefs GeeseFS].
 +
 
 +
Зачем? Затем, чтобы приблизить S3 к ФС, ибо видим потенциал в объединении некоторых юзкейсов ФС и S3. Например, в бэкапах или каком-нибудь мышином облучении / HPC.
 +
 
 +
Новый метод можно использовать как через GeeseFS, так и через обычное REST API. Ну и надо допиливать GeeseFS до состояния полноценной кластерной ФС, тогда будет ещё лучше.
 +
 
 +
[[Категория:Отчёты о конференциях]]

Текущая версия на 02:21, 2 декабря 2023

Как я пишу каждый раз, включая прошлогодний отчёт — самая крупная и раскрученная конференция Бунина. Финальная стоимость выросла уже аж до 64 тыр с 60, то есть годовая инфляция по версии Онтико в этот раз составила 6.66 %. :-)

Общее впечатление: Неплохо — «торжество велосипедов» в докладах, всё как мы любим, но перегруженно. Слишком много народу на эту площадку.

Реально, 3750 человек в Сколково, в котором и проходила конференция — это перебор. Если чуть более, чем средне-интересный доклад шёл в любом зале, кроме самого большого «Конгресс-холла» — сесть там было невозможно. Они пытались организовывать какие-то «расширительные бачки» в виде ретрансляций докладов рядом с залами, но это было бесполезно, ибо организовывали не прямо в коридоре, а в маленьких отдельных комнатушках. Какой толк от расширительного бачка на 10 человек, когда не влезло 50…

Второй момент — совершенно упоротая топология здания. Поиск нужного зала каждый раз превращался в квест: сначала надо попытаться понять по карте, где ты находишься, решить, в какую сторону идти и с какой стороны всё обходить, а потом ещё иногда искать отдельные лестницы на второй этаж для прохода в некоторые залы (просто подняться в произвольном месте недостаточно). При этом везде столики, стенды, толпы, поэтому даже образовывались заторы и проходы становились полудуплексными. Даже в сортирах был хайлоад. Явно не хватало процессоров на все… потоки.

При этом ещё и 11 параллельных залов. Я даже пожалел, что не заявил какую-нибудь хрень на опенсорс-трек — там такую фигню рассказывали, что я бы точно смог не хуже. Не, сама идея опенсорс-трека неплохая, но те доклады, на которые я попал, были не очень и хорошо демонстрируют механический подход к опенсорсу. Вот, слышали, что опенсорс это полезно и пытаются выжать пользу просто из произвольных проектов.

День 1

Барсик

Григорий Бутейко (VK, ВКонтакте) — BARSiC — асинхронная репликация и консенсус для 70 баз данных.

Помните, я же написал выше, что конфа — торжество велосипедов. Вот, это велосипед №1, прямо с открытия.

Полная фигня, 150 полуляхов из 250. Технических деталей работы алгоритма в докладе было крайне мало, просто общая мысль — вот, им ничего готовое не подошло, Raft они почему-то сочли слишком сложным (Raft, сложным?!), поэтому сделали всё сами и на основе другого протокола — Viewstamped Replication аж от целой Бабы Лизы… то есть Барбары Лисков.

Самое смешное, что они на замену Raft-у, который им «показался слишком сложным», выбрали алгоритм, который (А) вообще не отличается от Raft по смыслу и (Б) даже сложнее, чем Raft, в деталях реализации! Это более старый алгоритм! Чувак, который придумал Raft, про этот алгоритм даже в своём диссере писал! В котором он, собственно, и придумал Raft.

Я про VR почитал уже после конфы. Единственное реальное отличие — то, что ноды голосуют не за первого заявившегося кандидата, а за кандидата с минимальным ID (IP-адресом). Всё остальное практически идентично, Raft Term = VR View и так далее. При этом у VR 10 типов сообщений вместо 4-х у Raft-а.

Причём аргументы, согласно которым им не подошли готовые решения, меня лично вообще не убедили. Какое-то расхождение данных и метаданных при использовании внешнего сервиса консенсуса… не, ну писать просто надо нормально, что значит — расхождение. Я же юзаю etcd в Vitastor, брат жив. Ну ладно я, ещё пример — TiDB юзает встраиваемый etcd, брат тоже жив. Всё ещё мало? Patroni/Stolon испокон веков юзают Consul/etcd. Ceph OSD хранят метаданные в Ceph Monitor-ах. Какое расхождение?!

Хоть бы исходники открыли, ё-моё, хоть какая-то польза была бы от этого барсика. А то ну написали тесты, ну пофаззили, ну дополнительно верифицировали на TLA+, ну молодцы. Но какой во всём этом толк, если рядом лежит штук 10 «вот таких же, только меньше, но других», тоже хорошо оттестированных за все эти годы Raft-ов…

Производительность Go

Никита Галушко (VK, ВКонтакте) — Выжимаем из Go максимум производительности

В принципе стандартные вещи, даже не так их много было:

  • Мелкие объекты — до 32 байт — оптимизируются
  • Интерфейсы медленнее из-за виртуальных вызовов
  • Если в массивах срабатывает проверка границ (не срабатывает BCE) — код замедляется
  • for по индексам быстрее, чем for по range (подозрительно, stackoverflow говорит обратное — что они не отличаются)
  • Работа со строками хорошо оптимизирована для частых сценариев

Как привлекать людей в опенсорс-проекты

Ксения Романова (Positive Technologies) — Сообщества вокруг технологии: почему быть бесплатным недостаточно

Девушка связана с Apache Ignite и фондом Apache (туда ещё проекты умирать часто сдают), сейчас работает у позитивов.

Я не уверен, что доклад был именно о том, как я его окрестил, ибо изложение было довольно размытым. Но мне кажется, что это самое близкое. По-моему, она пыталась развивать стереотип о том, что опенсорс — это «бесплатные руки», и надо лучше искать эти бесплатные руки, лучше общаться с людьми и помогать им включиться в проект. «Как бы нам заполучить бесплатных разработчиков». :-)

С моей точки зрения — это утопия, хоть я и адепт опенсорса. Времени всем не хватает, видение развития проекта у каждого своё (1 программист пишет программу за 1 месяц, 2 — за 2 месяца), лидеры проекта душнят в пулреквестах, поэтому не стоит рассчитывать, что вы сможете найти серьёзный пул контрибьюторов среди сообщества. Проекты типа Linux — это очень редкие и крутые исключения из правил, так почти никто не умеет. Хотя, кстати, в её родном фонде Apache линукс ещё не факт, что свершился бы — они же не принимают правки от компаний.

Всё остальное в докладе — шелуха. Вот… сообщества… технологии… привлекать людей… модель «воронка»… модель «орбита»… людям это надо для чего-то там… компаниям это надо для чего-то там… 80% кода в опенсорс-проектах пишут единичные «герои»… Контрибьюторы классифицируются по 2 осям — качеству кода и любви к проекту… (тут я вообще чуть не взоржал)

Из интересного — в конце спросил у неё, а зачем компании сдают проекты в фонд Apache, в чём выгода. Так как, по-моему, проекты туда обычно сдают помирать, на кладбище. Для справки — апачи забирают все права на проект себе и даже потом правки от компаний не принимают — отправлять патчи могут только отдельные физлица-разработчики, даже если они все работают в одной компании. Она ответила, что сдают ради помощи в развитии, типа гайдлайнов/руководств по жизненному циклу проекта и ради готовой инфраструктуры разработки. Ну понятно — Apache пытается строить «завод опенсорса» и на этом в процессе делать деньги. Но вот для сдающей компании особой выгоды, мне кажется, всё-таки нет, так что скорее всего обычно действительно просто «сдают в отстойник».

Дата скетчи

Сергей Жемжицкий (SberDevices) — Data Sketches — как съесть слона целиком (даже если он бесконечный)

В целом неплохой доклад про алгоритмы семейства Data Sketches. Ну в смысле для меня неплохой, ибо я про эти алгоритмы не знал. Я так понимаю, это новое собирательное название для уже некоторое время существующего класса алгоритмов — потоковых статистических алгоритмов.

TLDR — всё это реализовано в библиотеке Apache DataSketches на Java и C++, бери и юзай. Даже в ClickHouse припилено уже.

В докладе затронуты алгоритмы:

  • Подсчёт числа уникальных элементов в потоке (Count-Distinct): HLL (HyperLogLog), CPC (Compressed Probability Counting), Theta Sketch
    • HLL: число уникальных примерно равно 2^(максимальное число идущих подряд нулей в начале хешей всех элементов + 1).
    • CPC: число уникальных примерно равно 2^(максимальное число идущих подряд нулей в конце хешей всех элементов, кроме хешей из всех нулей).
    • Theta Sketch: вроде бы это обобщение алгоритма K минимальных значений. Типа, мапим каждое значение в хеш, равномерно распределённый в диапазоне чисел (0, 1). Сохраняем K+1 минимальных значений таких хешей. После чего число уникальных будет примерно равно K/(K+1-ый минимальный хеш). Вот статья про эту тету https://github.com/apache/datasketches-website/blob/master/docs/pdf/ThetaSketchFramework.pdf — кстати, в докладе он принцип работы этого алгоритма не объяснил, это я уже тут для отчёта докурил :-)
  • Частота встречаемости элемента: CountMin Sketch, Misra-Gries
    • CountMin: берём несколько независимых хеш-функций, делаем таблицу — на каждый хеш 1 строка, и заданное K колонок. На каждое значение считаем все хеши и увеличиваем на 1 соответствующую хешу колонку в строчке этого хеша. Потом, чтобы оценить частоту встречаемости элемента, берём минимум от значений ячеек, соответствующих всем его хешам.
    • Misra-Gries: по ходу подсчёта сохраняем K самых часто встречаемых элементов и считаем их частоты. Если же встречаем элемент, не входящий в K, увеличиваем на 1 отдельный счётчик «всех остальных», уменьшаем на 1 все частоты K элементов, удаляем элементы с нулевыми частотами. Далее частоту встречаемости любого элемента принимаем за (счётчик «всех остальных» + счётчик самого элемента).
  • Квантили/гистограммы: куча странных названий, я себе из всего выписал Manku-Rajagopalan-Lindsay (MRL), но в суть расчёта докладчик уже не погружался.

Катаем гусей

Павел Левдик (Yandex Infrastructure) — Внутри S3

Доклад про Яндексовую реализацию S3 (гусь/goose — это go+s3, название сервера). Глобально всё просто — взят уже готовый надёжный распределённый сторадж для данных, взят шардированный и реплицированный PostgreSQL, одно скрещено с другим и вот вам, пожалуйста, S3.

Шардирование раньше было только в виде чанков — диапазонов имён объектов в бакете. Чтобы таскать чанки с шарда на шард — мувер, чтобы порождать новые чанки почкованием — сплиттер. И то, и то — через двухфазный коммит. Но была проблема, что в такой схеме определённые паттерны нагрузки не размазывались по всему кластеру БД. Например, если юзер всегда писал новые объекты в конец бакета — эти вставки всегда попадали в один чанк и, соответственно, шард. Или, например, если юзер сначала делал алфавитный листинг всех объектов, а потом последовательно читал их — такая нагрузка тоже в каждый момент времени попадала только в один шард БД.

Поэтому сделали хеш-чанки (диапазоны хешей имён объектов) и такая нагрузка тоже стала размазываться. Был даже график, на котором это было видно наглядно — до переключения на ханки нагрузка шла постоянно то в 1 шард, то во 2, то в 3 и т. п., а после — равномерно во все три. То есть, все три покрашенные разными цветами линии нагрузки в разные шарды сошлись на одном уровне. Кто-то из зала не понял, что на графике изображены не листинги, а обычная нагрузка (то ли GET, то ли PUT), и спросил, так это что же, теперь листинги грузят все шарды? По факту с этим проблем нет, так как, во-первых, запрос листинга в S3 ограничен 1000 записей, во-вторых, и до перехода на ханки запросы листинга часто попадали в несколько шардов — в тех случаях, когда нельзя точно сказать, что 1000 записей можно вернуть из 1 шарда, а в-третьих, с ханками число шардов, на которые размазан каждый бакет, тоже регулируется, просто оно регулируется делением/умножением сразу в 2 раза.

Ещё было про счётчики и то, что они считаются через очередь. Ну ещё из интересного (для конкурентов :D) — цифры, например, 120к rps в облаке (2x за год), типичный крупный клиент > 1 ПБ и > 1 млрд объектов, и > 1000 rps.

Кстати, ещё Паша не упоминал, что там в PostgreSQL есть хранимки и они весьма неплохо работают. Но про это есть старый пост на хабре: https://habr.com/ru/companies/yandex/articles/417241/

Неудачный опен-аут-сорс

Олег Балбеков (Evrone) — (Не)удачный эксперимент по выращиванию культуры Open Source

Компания — что-то среднее между заказной разработкой и аутсорсерами. Пишут сайтики на Ruby и Python. Вкратце — они проверяли на практике гипотезу, что опенсорс полезен для бизнеса, постаравшись выжать ВСЁ!!!1111 из ну, в общем-то, крох — 5 млн рублей за 5 лет.

Что пробовали:

  • Оплачивать разработку открытых проектов своими разработчиками (но не более, условно, 50% времени)
  • Донатить на гитхабе; разыгрывать раз в неделю по 100$ среди опенсорс-проектов
  • Нагонять трафик со своих открытых проектов, но его было 1%
  • Нагонять трафик, используя проекты как инфоповоды, но поднять удалось всего до 4.4%
  • Технологический пиар (выступать на конференциях) — получили некоторое внимание сообщества, но не известно, как померить
  • Прямые продажи (придут инженеры и наймутся, или купят). Ога, щаз — прим.вред. Получили всего 1% лидов и ровно 1 продажу за 5 лет
  • Косвенные продажи (подтверждение квалификации компании). Есть, но не известно, как померить
  • Прямой HR-маркетинг (сбор базы кандидатов). Бесконечно менее эффективно, чем HR-инструменты (через оные и так есть база в 40366 человек). Наняли всего 1 человека за 5 лет
  • Косвенные плюсы при найме есть. Кандидатам нравится, что в компании можно пилить опенсорс. Но не известно, как померить :-)
  • Обучение через открытую разработку. Писать и показывать красивый код и т. п. Резюме — эффективно, но не масштабируемо.

Причём по факту этим в компании занималось 2.5 человека, они ушли и всё это сдулось. Поэтому он сказал, что Если ты тот самый сотрудник Evrone, который бы хотел этим продолжить заниматься — Welcome, мы поддержим! — кажется, есть некоторые проблемы с внутренними коммуникациями в компании, если обращаться к сотрудникам приходится через Highload. :-)))

Но эксперимент хочет продолжить и вернуться через 3 года с новостями. Ну ждём, чо.

Справочно — опенсорс у них донный, фигня в духе мелких npm/pip модулей. Самый крупный проект — я спросил — какой-то линтер, что ли. Понятно, что с такой мелочи особого профита не получишь. Я потом ему задал вопрос, может вам попробовать что-то более крупное пилить? Он такой — ну, это уже продуктовая разработка. Ну конечно, продуктовая, ведь «открытое ПО» это в первую очередь что? Это в первую очередь ПО, то есть программный продукт! А для механистического подхода «просто хотим опенсорс» и всего 5 млн рублей, потраченных за 5 лет, у них весьма неплохо всё получилось.

Кубернетес от перил

Андрей Вильмов (ПерилаГлавСнаб) — От CRM к DataLake с K8s и микросервисами

Немного напомнило старый мем и поэтому очень хотел послушать:

Консервы.png

Но как ни странно, всё довольно разумно. Хотя смотрел в записи, потому что не смог попасть в зал, потому что МЕСТА НА КОНФЕРЕНЦИИ НЕ ХВАТАЛО.

Вкратце — была страшная старая CRM-ка и всё было в ней, разрослось. Впилили Airflow, стали складывать в PostgreSQL. Постгря выросла до 3 ТБ, поменяли на Greenplum. Потом добавили Kafka и реалтаймовых потребителей. Потом впилили Kubernetes. Потом Minio в виде стораджа. Где-то рядом появился Spark.

Вот так, слово за слово, заяц получил п…ы перила превратились в облако сделали своё мини-облако.

День 2

Петабайт в УДБ на ХДД

Антон Барабанов (Яндекс) — Петабайт в YDB over HDD в процессингах Яндекс.Метрики

Ну, реально пока не петабайт, а 500 ТБ, но, типа, скоро будет петабайт. Но всё равно норм. При потоке записи 20 гбит/сек. 300 дисков в инсталляции. Суть — пробовали YDB на HDD. Справилось оно в их применении в целом неплохо, правда, как обычно, всю автоматику поотрубали — распределение запросов написали своё и данные тоже сами раскладывают по отдельным дневным табличкам.

Само применение — слияние визитов за сутки в метрике. То есть, на входе большой поток посещений сайтов и покупок (или других действий), на выходе надо посещения сцепить с действием, чтобы было понятно, что конверсия произошла. Для оффлайн-покупок аналогично, но дольше период — не сутки, а 20-30 дней, и данные в метрику заливает сам магазин постфактум, возможно даже вручную. Жёстких требований реального времени нет, но некоторые есть — надо, чтобы считалось 10-15 минут, а не сутки.

С YDB сначала наткнулись на проблему потребления RAM, добавлять пришлось и RAM и CPU, так как сказали, что есть жёсткие профили виртуалок во внутреннем «облаке». В итоге CPU на 90% простаивают. Потом YDB не справилось с чтением блоков с HDD, так как читает целыми блоками и только потом понимает, что нужных данных в блоке нет, а bloom фильтр работает по полному первичному ключу, а они запрашивают по одному ID юзера. Для борьбы с этим ключи положили на SSD, данные визитов оставили на HDD. Ещё натыкались на то, что автосплит партиций по нагрузке приводил к большой нагрузке из-за compaction — сначала нагрузка растёт, партиции разделяются, потом нагрузка падает, они сливаются. Всё жрёт compaction.

На вопрос «почему не YT(saurus)» ответили «так сложилось» + YT-шники им не были готовы предоставить такой кластер :-). Не Clickhouse потому, что Clickhouse плохо работает с синхронной репликацией.

Как разрабатывается опенсорс в АЛЬТ

Евгений Синельников (Базальт СПО) — Как разрабатываются свободные проекты в команде ALT?

Имхо крайне бестолковый доклад. По логике названия тут должно было быть что-то про процесс разработки, а по факту было про то, что вот, опенсорс не мешает ничего продавать, потому что оно продаётся как «сборник произведений», по ГК РФ являющийся самостоятельным произведением. И про то, что бизнес не понимает GPL. Ну и упомянули своё AD под линукс (ужасная виндузятская хрень).

SQL-регэкспы (MATCH_RECOGNIZE)

Евгений Зверев (Яндекс) — Поиск по образцу на последовательностях строк в БД

Доклад про последнюю фичу стандарта SQL — MATCH_RECOGNIZE — которая почти нигде не реализована, а где реализована — наверное, честно говоря, дико тормозит. Вроде как в YDB её сделали (или сделают) и поэтому это тоже доклад про YDB. :-) но в любом случае, практическое применение выглядит крайне узким.

По сути это SQL-регэкспы — сначала ты задаёшь N WHERE-условий, а потом, ссылаясь на них, говоришь, что хочешь найти последовательность строк, где сначала идёт, например, 1 раз условие №1, потом не меньше 3 раз условие №2, и потом событие №3. SQL-конструкция сама, конечно, получается многоэтажная.

Ну ок… природа любит разнообразие.

Индексы mail.ru

Рустем Гафаров (VK, Почта Mail.ru) — Устройство индексов в почте mail.ru

Вот наконец и третья часть архитектуры mail.ru, продолжение прошлогоднего доклада. Но вот эту часть я не буду у себя нигде повторять, можно же, правда? — прим.вред.

Резюме: LSM для бедных, с 2 уровнями (L0 и L1), снапшотами в Zepto (объектном хранилище) и WAL-ами в… Tarantool-е, в виде последовательности ключей. Ух, забористые вещества.

Ящики полностью изолированные (независимый индекс по каждому), блочного доступа к индексам нет, снапшот грузится в память целиком в B-деревья (в памяти) и на него в памяти накатывается WAL. Теоретически даже поддерживается конкурентный доступ — перед операциями проверяется, не появилось ли что новое в WAL в тарантуле. Но не нужно, индекс ящика держится открытым на 1 сервере, в целом по ящикам — LRU кэш. Посему сильно экономят, не держа в памяти ненужные индексы (неактивные ящики). Вроде как экономят на индексах 600к в год.

Называется система Москито, как кто-то сказал из зала Mescalito, формат XTAZ. 5 датацентров… а чего ж тогда в облаке VK нет Managed Postgres на 3 ДЦ. Непорядок.

Велосипед от Тинькова (SAGE DB)

Александр Бирюков (Тинькофф) — Когда нужно делать свою базу данных

…под логи. Ответ — когда не взял кликхауз — прим.вред.

Было плюс-минус интересно послушать про устройство индексаторов логов. ElasticSearch — обратные индексы, поэтому ЖРЁТ сторадж, Loki — вообще никаких индексов, только дискретное деление по файлам, поэтому тормозит, OpenObserve — новее и круче, паркеты (Parquet), точнее FDAP (Flight, DataFusion, Arrow, Parquet — на эту же связку уже перешли InfluxDB и Parseable), в паркетах есть сжатие, блум фильтры, индексы и всё такое, но фиксированная схема и вроде как не выходит реализовать какие-то оптимизации из-за абстрактности формата.

Проект SAGE у них начался в 2019, когда им не захотел продлевать лицензию Splunk. Сначала сделали на эластике, потом в силу вышеописанных архитектурных нюансов решили писать своё, допилить эластик силами 3-4 лиц не осилили бы. Сначала пробовали сделать свои обратные индексы на RocksDB, но быстро упёрлись. В итоге сделали своё подобие FDAP, но без схемы. Причём даже формат сериализации свой без декодирования и без схемы, и Flexbuffers почему-то не подошёл, хотя Flexbuffers это дословно формат без декодирования и без схемы. Тоже со сжатием (zstd + словарным для ключей) и блум-фильтрами. Общая схема в итоге похожа на Loki поверх S3.

Замеры: по скорости помедленнее эластика, условно 0.5 сек 50% квантиль против 0.15 сек. Но зато на эластике 350 серверов и 7 ПБ, а на SageDB 270 серверов и 700 ТБ. По облачным ценам экономия примерно 360 млн руб в год. Но работают пока обе схемы в параллель, полный переход ещё не состоялся, пока что все запросы зеркалируются. Пилили 3 года.

Ну хз. А чего было просто не взять Clickhouse? Ну схема, да, но ведь в логах не так чтобы прямо много разных форматов и колонок. Сложилось же бы, наверное.

PATCH в S3

Александр Снопов (Yandex Infrastructure) — Частичная модификация объектов в Yandex Object Storage: как мы улучшаем работу ФС поверх S3

Вкратце: мы запилили в S3 PATCH и поддержали его в GeeseFS.

Зачем? Затем, чтобы приблизить S3 к ФС, ибо видим потенциал в объединении некоторых юзкейсов ФС и S3. Например, в бэкапах или каком-нибудь мышином облучении / HPC.

Новый метод можно использовать как через GeeseFS, так и через обычное REST API. Ну и надо допиливать GeeseFS до состояния полноценной кластерной ФС, тогда будет ещё лучше.

Источник — «http://yourcmc.ru/wiki/index.php?title=Highload-2023:_Отчёт_Виталия_Филиппова&oldid=15085»