Изменения

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

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

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

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

При этом ещё и 11 параллельных залов. Я даже пожалел, что не заявил какую-нибудь хрень на опенсорс-трек - трек — там такую фигню рассказывали, что я бы точно смог не хуже. Не, сама идея опенсорс-трека неплохая, но те доклады бестолковые, на которые я попал, были не очень и хорошо демонстрируют механистический механический подход к опенсорсу: одни рассказывают. Вот, что опенсорс это хорошослышали, потому что признание сообщества, розовые пони и вообще, а вторые - что они попробовали давать по 100$ рандомным разработчикам модулей питона раз в неделю, и профита не обнаружили, но будут ещё пробовать. А третьи вообще вместо рассказа, КАК же они пилят этот самый опенсорс, рассказывают, что они его закрывают и продают как сборник произведений по ГК РФ - это очень важная полезно и интересная информация, которой, конечно, до этого не было ни на одной конференции (тро-ло-ло)пытаются выжать пользу просто из произвольных проектов.

== Производительность Go и аллокации ==

'''Никита Галушко (VK, ВКонтакте) — Выжимаем из Go максимум производительности''' В принципе стандартные вещи, даже не так их много было: * Small-size объекты - Мелкие объекты — до 4 машинных слова (32 байта)байт — оптимизируются* Интерфейсы медленнее из- оверхед за виртуальных вызовов* Bound check eliminationЕсли в массивах срабатывает проверка границ (не срабатывает <abbr title="Bounds Check Elimination">BCE</abbr>) — код замедляется* for i лучше по индексам быстрее, чем for по range(подозрительно, stackoverflow говорит обратное — что они не отличаются)

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

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

'''Павел Левдик (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-ка и всё было в ней, разрослось. Впилили Airflow, стали складывать в PostgreSQL. Постгря выросла до 3 ТБ, поменяли на Greenplum. Потом добавили Kafka и реалтаймовых потребителей. Потом впилили Kubernetes. Потом Minio в виде стораджа. Где-то рядом появился Spark. Вот так, слово за слово, <s>заяц получил п…ы</s> перила <s>превратились в облаке облако</s> сделали своё мини-облако. =День 2 =

<s>'''Евгений Синельников (никакБазальт СПО) — Как разрабатываются свободные проекты в команде ALT?''' Имхо крайне бестолковый доклад.По логике названия тут должно было быть что-то про процесс разработки, а по факту было про то, что вот, опенсорс не мешает ничего продавать, потому что оно продаётся как «сборник произведений», по ГК РФ являющийся самостоятельным произведением.И про то, что бизнес не понимает GPL.Ну и упомянули своё AD под линукс (ужасная виндузятская хрень)</s>.

== Устройство индексов Доклад про последнюю фичу стандарта 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 ДЦ. Непорядок.

'''Александр Снопов (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Отчёты о конференциях]]