Версия 02:35, 4 декабря 2022

Топовая Бунинская конференция, самая распиаренная и самая отъевшаяся — к счастью, до вменяемых пределов, в отличие от еврогейских, где вообще всё коммерциализировано вусмерть и даже докладчики доплачивают за участие. :-)

Общее впечатление: на удивление, довольно бодро. Весенний хайлоад — 2021, перенесённый на весну 2022 — был значительно тухлее, на нём я тоже выступал, но о докладах даже заметок себе вменяемых не оставил.

Вообще, прошлые хайлоады я не мог отделаться от мысли, что каждый год выступают одни и те же лица с одними и теми же темами докладов — Сысоев и nginx, постгрес-про, mysql, куратор, erlyvideo, одноглазники с java-микросервисами, какое-нибудь badoo на php… в общем всё норм, но уже поднадоедало. Что случилось сейчас — не знаю, возможно, «одни и те же лица» уехали в сторону горы Арарат. :-) хотя Максим Лапшин с erlyvideo был. :-) но так или иначе, повторюсь — некое ощущение новизны всё-таки было. А может, это меня отпустило.

Проходила конференция снова в Крокусе, стоила для участников, кажется, 60к (в 2013 было 21к… инфляция :D). Организация была вполне приличная, всего хватало — и места, и плюшек, и еды, и гардеробов, и стоек регистрации. От практики раздачи тонн макулатуры, видимо, отказались, и слава богу, спину ей только оттягивать. Залов параллельно было аж 8, но, к счастью, «основных» 4 — в общем, угрызаемо.

День 1

Exadata для PostgreSQL

Константин Аристов (Скала^р) — Наша Машина Баз Данных (это как Oracle Exadata, только для PostgreSQL) и система управления к ней

Почему я пошёл это слушать: да потому что я ещё лет 10 назад, работая в CUSTIS, говорил, что кому-нибудь надо сделать аналог Exadata, но на PostgreSQL :)

Для тех, кто не знает, что такое экзадата: это такой шкафчик с ораклом, стоящий примерно 1 млн $ (последние версии уже, кажется, под 2 ляма) и логически представляющий из себя единый экземпляр СУБД. Ну, то есть, на самом деле это просто стандартная 42-местная серверная стойка с готовым отказоустойчивым кластером из обычных серверов и RDMA (RoCE) свичей. Внутри крутится Linux и на нём сам Oracle, но не совсем простой — там есть деление на узлы хранения и узлы вычисления — по сути, собственная программная СХД. Также этот шкафчик можно покупать в конфигурациях 1/2, 1/4, 1/8 стойки и гибких, добавляя по вкусу нужных узлов.

Ну вот… вроде как свершилось, СКАЛА-Р сделала ПАК на базе постгри :) на самом деле это, конечно, не совсем экзадата — объёмы меньше, распределённости самой постгри там нет и SDS под постгрёй тоже нет (вот куда Vitastor-то надо впилить, да). Вместо всего этого в стойку просто ставится несколько «модулей» по 3 2U сервера с постгрей — в каждом 1 мастер, 1 синхронная реплика и 1 асинхронная реплика на 48c 768G RAM + 10-20 TB SSD серверах. И Corosync. Рядом ставится «модуль» управления, свичи, зарезервированные через MLAG и СХД (HDD полка + 2 головы) для бэкапов через pgpro backup (в том числе с PITR). Из интересного: сходимость MLAG-а оказалась неожиданным критерием выбора свичей и, кроме Mellanox, тут победили некие неназванные свитчи российского производителя «Vendor #1». Характеристики свича: ПСП=92, с 32 портами и поддержкой RSTP. Загадка, что же такое «92»… рядом в табличке указан Mellanox SN2100 с цифрой «100», значит, это гигабит на порт, что ли?

Заявленные показатели — 70000 попугаев (TPS) в pgbench TPC-B на БД размером 12 ТБ («RW-тест на БД >= 1 ТБ», хз, что это). По методике тестирования — сослались на доклад Андрея Николаенко с PG Day’17 — «Об эталонном тестировании PostgreSQL» (я открыл, слегка вырвиглаз). Как сравнить с Exadata — не понятно, но вообще в топовых конфигурациях Exadata обещают чуть ли не 4 миллиона TPS :) у IBM Pure Data (видимо тоже что-то похожее) заявки более скромные, от 34 до 205 тысяч TPS. В общем, как относиться к этим 70 тысячам, решайте сами.

Для OLAP-нагрузки сами Скала-МБД не рекомендуют, рекомендуют чуть другой комплекс — Скала МБД8 («Машина Больших Данных»). Exadata же OLAP ест.

Дальше докладчик рассказывал про инструменты управления всем этим добром — сначала рассматривали SeveralNines, ScaleGrid, awide.io (по сути pgadmin+pgwatch), в итоге всё, как мы любим — сделали свой велосипед Скала-р Спектр. Что-то упомянул про какие-то нелинейные переходы между состояниями в системе управления, тут «што ты токое» я не особо понял, ну, видимо, и фиг с ним. Плюс упомянул, что ещё хотели сделать комплекс Скала-500 с NVMeoF, но что-то случилось 24 февраля и планы были нарушены. :-) и в конце вспомнил про opengauss, какой-то форк устаревшей постгри от китайцев. Фиг знает, зачем, типа, что, видимо, думали в его сторону тоже.

Мы смогли запустить Debezium

Александр Горякин (Tarantool) — Репликация между SQL- и NoSQL-базами данных: туда и обратно

Фуфло какое-то, по названию доклада мы с Максом было подумали, что сейчас нам тарантулы расскажут про какой-то новый офигенный инструмент репликации, который они сделали и который умеет и так, и эдак, и вообще лучше всего, что есть в природе.

Вместо этого… Oracle GoldenGate? IBM InfoSphere CDC? «Что-то дорого». Да ну? Но уже стало понятно, что рассказ не про «репликацию между базами данных», а конкретно про оракл. Прям CUSTIS-ом повеяло, там тоже с голденгейтом игрались…

Далее: ну, можно написать самим на pglogrepl+pgproto, «но типа это самопис, костыли и ведёт к зоопарку» — так стоп, а при чём тут постгря, если вы из оракла мигрировали :)

В итоге просто заюзали Debezium (на Java), сначала Embedded, потом Server. Посокрушались, что API Oracle LogMiner депрекейтнутое, а API Oracle XStream открывается по лицензии голденгейта, которая стоит вагон денег. На этом всё в общем и остановилось.

В начале ещё упомянули три «подхода к репликации»: ETL, отслеживание изменений на триггерах (change tracking) и расшифровка WAL-ов базы (change data capture), и что они выбрали последний. Ну да, Debezium это оно, ок.

GeeseFS — ФС из S3

Мой доклад — GeeseFS: ФС из S3, или Параллелизм гусей в природе

Обзор архитектуры тарантула

Константин Перепелица (Tarantool) - Архитектура надёжной In-Memory-СУБД на примере Tarantool

Форк nginx (ООО Веб Сервер)

Иван Полуянов, Валентин Бартенёв (Web Server LLC) - Дорогая, я форкнул nginx

Стородж Яндекса может всё

Вадим Зотеев (Яндекс) - Балансировка нагрузки в мульти-эксабайтном сторадже

- Дети, в какой стране самые красивые игрушки? - В СССР! - А в какой стране самая нарядная одежда? - В СССР! - А в какой стране самые счастливые дети?... Вовочка, что ты плачешь? Вовочка: - Хочу в СССР!..

Жизнь перф инженера в Pg Pro

Михаил Жилин (Postgres Pro) — Аномальные случаи высокой нагрузки в PostgreSQL, и как мы с ними справились

Заинтересовался, посмотрел постфактум. Просто рассказ про несколько случаев тормозов постгри, которые он ловил. Практической пользы для пользователя postgresql почти нет, польза разве что в том, что если видишь тормоза — можно обновиться, можно попробовать заюзать обычный linux-овый perf (perf record и т.п) и иногда даже что-то с ним найти. Иногда может помочь уменьшение объёма DDL. Остальное — чисто разработческая жизнь, про то, как они (или не они) что-то нашли и оптимизировали. Но почему бы и нет — в принципе, доклад прослушал с интересом.

Случаи из рассказа:

• GetSnapshotData в perf — MVCC-снимки (решение — обновиться до pg 14+, возможно сделать repeatable read)
• Тормоза подтранзакций (покрутить slru_buffers_size_scale)
• Кэш каталога (не юзать DDL, проверять инвалидации по pgpro_stats)
• Тормоза от auditd, пойманные через perf
• Какой-то нюанс отображения pg_stat_activity, который уже почти запатчили
• Оптимизация visibility bitmap-ов в index-only сканах, которую тоже уже почти запатчили

Хранилище почты mail.ru

Виктор Могилин (mail.ru) - Хранилище для Почты

SPQR для постгри

Денис Волков, Кирилл Решке (Yandex Cloud) - SPQR: горизонтальное масштабирование PostgreSQL

Пытался смотреть доклад в режиме вытесняющей многозадачности параллельно со сцыллой.

Как сцилла стояла раком

Илья Орлов (STM Labs) - Укрощение мифического чудовища: реальный опыт промышленного использования ScyllaDB без прикрас

ZFS в ZFS → WA и тормоза

Андрей Копейко (VK) — Как «добиться» времени записи 200 мс на NVMe-дисках

Не смотрел, но упомяну, ибо смотрел коллега. Чуда, увы, не произошло, ничего гениального типа внутренних алгоритмов работы SSD в докладе не было. Вместо этого классическое: ZFS со сжатием, в нём Proxmox, в виртуалке опять ZFS со сжатием, в ней TimescaleDB опять со сжатием, а в неё заливаем 28 ТБ данных.

Вуаля, вот ваши тормозные чтения с NVMe. И заодно удроченный на 50 % паспортного TBW за 10 месяцев диск.

Ну а что вы хотели. WA оно такое. Надо было ещё Ceph поставить, смогли бы и секунды добиться… :)

День 2

?

Егор Хайруллин (Яндекс) - Как перейти от batch к streaming на примере рекламной контент-системы

Graphviz от безопасника ядра

Александр Попов (Positive Technologies) - Безопасность ядра Linux: в теории и на практике

Примитивные хаки k8s

Лев Хакимов - Хакнуть K8s: разбор пэйлоадов и способов защиты

DBA ловит тормоза диска через eBPF

Пётр Бобров (QIWI) - Мониторинг черных ящиков и котов в мешке через eBPF

MVCC в тарантуле

Александр Ляпунов (Tarantool) - Как работает MVCC в In-Memory-СУБД

Экодиктант за 2 месяца

Станислав Жуковский, Василий Шалимов (Старботс РФ) - Экодиктант 2021: highload-проект с нуля за 2 месяца

DNS-aaS через SDN

Георгий Меликов (VK Cloud) - Полная изоляция клиентов в облаке для сервисов без изоляции на примере DNS