Изменения

Перейти к: навигация, поиск

Highload-2023: Отчёт Виталия Филиппова

630 байтов добавлено, 22:25, 1 декабря 2023
Нет описания правки
== Петабайт в УДБ на ХДД ==
'''Антон Барабанов (Яндекс) — Петабайт в YDB over HDD в процессингах Яндекс.Метрики'''
Ну, реально пока не петабайт, а 500 ТБ, но, типа, скоро будет петабайт. Но всё равно норм. При потоке записи 20 гбит/сек. 300 дисков в инсталляции. Суть — пробовали YDB на HDD. Справилось в их применении в целом неплохо, правда, как обычно, всю автоматику поотрубали — распределение запросов написали своё и данные тоже сами раскладывают по отдельным дневным табличкам.
Суть - проверялиСамо применение — слияние визитов за сутки в метрике. То есть, как YDB справится с работой на HDD. Справилось в их применении в целом неплоховходе большой поток посещений сайтов и покупок (или других действий), правдана выходе надо посещения сцепить с действием, как обычночтобы было понятно, всю автоматику поотрубали и распределение запросов написали своёчто конверсия произошла. Хотя на вопрос "почему Для оффлайн-покупок аналогично, но дольше период — не YT(saurus)" ответили "так сложилось" :сутки, а 20-)30 дней, и данные сливает сам магазин постфактум, возможно даже вручную. Не Clickhouse потомуЖёстких требований реального времени нет, что Clickhouse плохо работает с синхронной репликациейно некоторые есть — надо, чтобы считалось 10-15 минут, а не сутки.
Само применение - слияние визитов за сутки в метрике. То есть, С YDB сначала наткнулись на входе большой поток посещений сайтов проблему потребления RAM, добавлять пришлось и RAM и покупок (или других действий)CPU, так как сказали, что есть жёсткие профили виртуалок во внутреннем «облаке». В итоге CPU на выходе надо посещения сцепить 90% простаивают. Потом YDB не справилось с действиемчтением блоков с HDD, чтобы было понятнотак как читаем целыми блоками и только потом понимает, что конверсия произошла. Для оффлайн-покупок аналогичноданных нет, но дольше период - не суткиа bloom фильтр работает по полному первичному ключу, а 20-30 днейони запрашивают по одному ID юзера. Для борьбы с этим ключи положили на SSD, и данные сливает сам магазин постфактум, возможно даже вручнуювизитов оставили на HDD. Жёстких требований реального времени нетЕщё натыкались на то, но некоторые есть что автосплит партиций по нагрузке приводил к большой нагрузке из- надоза compaction — сначала нагрузка растёт, чтобы считалось 10-15 минутпартиции разделяются, а не суткипотом нагрузка падает, они сливаются.Всё жрёт compaction/
С YDB сначала наткнулись на проблему потребления RAM, добавлять пришлось и RAM и CPU, т.к. сказали, что есть жёсткие профили виртуалок во внутреннем "облаке". В итоге CPU на 90% простаивают. Потом YDB На вопрос «почему не справилось с чтением блоков с HDD, тYT(saurus)» ответили «так сложилось» + YT-шники им не были готовы предоставить такой кластер :-).к. читаем целыми блоками и только потом понимаетНе Clickhouse потому, что данных нет, а bloom фильтр Clickhouse плохо работает по полному первичному ключу, а они запрашивают по одному ID юзера. Для борьбы с этим ключи положили на SSD, данные визитов оставили на HDDсинхронной репликацией. Ещё натыкались на то, что автосплит партици
== Как разрабатывается опенсорс в АЛЬТ ==

Навигация