Изменения

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

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

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

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

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

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

** Theta Sketch: вроде бы это обобщение алгоритма K минимальных значений. Типа, мапим каждое значение в хеш, равномерно распределённый в диапазоне чисел (0, 1). Сохраняем K+1 минимальных значений таких хешей. После чего число уникальных будет примерно равно K/(kK+1-ый минимальный хеш). Вот статья про эту тету https://github.com/apache/datasketches-website/blob/master/docs/pdf/ThetaSketchFramework.pdf— кстати, в докладе он принцип работы этого алгоритма не объяснил, это я уже тут для отчёта докурил :-)

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

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

== Шардирование: с нуля до Яндекс Диска Петабайт в УДБ на ХДД ==

== Хадуп Ну, реально пока не петабайт, а 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 плохо работает с синхронной репликацией.

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

По сути это 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 ДЦ. Непорядок.

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

'''Александр Снопов (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 до состояния полноценной кластерной ФС, тогда будет ещё лучше. [[Категория:VitaliPrivateОтчёты о конференциях]]