feedmetoo

https://sigmodrecord.org/publications/sigmodRecord/2406/pdfs/04_Surveys_Stonebraker.pdf - обзорная статья от авторитетов индсутрии - Павло и Стоунбрейкера.

Цитата для привлечения внимания. Срывают покровы:

There have been major new ideas in DBMS architectures put forward in the last two decades that reflecting changing application and hardware characteristics. These ideas range from terrific to questionable, and we
discuss them in turn.

Вкратце:

Data Models & Query Languages

* MapReduce dead.
* Hadoop dead.
* Spark & Flink doing well.
* RocksDB ... rocks for embedded use-case.
* Для современной СУБД хорошо бы иметь API хранилища для разработки своего.
* json > xml.
* ACID это хорошо и нужно.
* wide column db are dead.
* text search engines где-то сбоку и без транзакций.
* array db интересные и хорошие но только для своих областей - научные и подобные данные натурально ложатся на модель хранения "массив".
* vector db специальный случай массива - одноразмерный. привлекают самое большое внимание разработчиков и инвесторов сегодня. Много ML use-case'ов.

The key difference between vector and array DBMSs is their query patterns. The former are designed for similarity searches that find records whose vectors have the shortest distance to a given input vector in a highdimensional space.

* graph db - развивают совсем другую модель хранения. От этого другой API запросов. Узкоспециализированные сценарии использования.

SQL:2023 introduced property graph queries (SQL/PGQ) for defining and traversing graphs in a RDBMS

===

A reasonable conclusion from the above section is that non-SQL, non-relational systems are either a niche market or are fast becoming SQL/RM systems

System Architectures

Глава написана хорошо - даже не буду ее конспектировать - рекомендуется к прочтению полностью 🙂

NewSQL vendors also incorrectly anticipated that inmemory DBMS adoption would be larger in the last decade. Flash vendors drove down costs while improving storage densities, bandwidth, and latencies. Higher DRAM costs and the collapse of persistent memory(e.g., Intel Optane) means that SSDs will remain dominant for OLTP DBMSs.

The aftermath of NewSQL is a new crop of distributed, transactional SQL RDBMSs. These include TiDB [141],
CockroachDB [195], PlanetScale [60] (based on the Vitess sharding middleware [80]), and YugabyteDB [86]. The major NoSQL vendors also added transactions to their systems in the last decade despite previously strong
claims that they were unnecessary. Notable DBMSs that made the shift include MongoDB, Cassandra, and DynamoDB. This is of course due to customer requests
that transactions are in fact necessary. Google said this cogently when they discarded eventual consistency in
favor of real transactions with Spanner in 2012 [119].

At the present time, cryptocurrencies (Bitcoin) are the only use case for blockchains. In addition, there
have been attempts to build a usable DBMS on top of blockchains, notably Fluree [25], BigChainDB [12], and ResilientDB [136]. These vendors (incorrectly) promote
the blockchain as providing better security and auditability that are not possible in previous DBMSs.

Ну и в заключение нестареющие мудрости:

* Never underestimate the value of good marketing for bad products.

* Beware of DBMSs from large non-DBMS vendors.

* Do not ignore the out-of-box experience.

* Developers need to query their database directly

* The impact of AI/ML on DBMSs will be significant

Вчера вышел релиз #go 1.23 - самый спорный релиз на моей памяти https://go.dev/doc/go1.23

В нём стали доступны функции-итераторы https://go.dev/doc/go1.23#language, добавление которых вызвало довольно много негативной реакции в сообществе https://www.gingerbill.org/article/2024/06/17/go-iterator-design/

Помимо пакета нового пакета iter в пакеты slices и maps много новых функций типа Backward, Chunk, Values, Keys и Collect

Так же в этом релизе добавлена функциональность сбора телеметрии тулчейна Go. Телеметрия отключена по умолчанию и собирает анонимную информацию о параметрах go и gopls (https://go.dev/doc/telemetry). Одно время обсуждения самой возможности были довольно бурными https://www.reddit.com/r/golang/comments/10z5ig1/googles_go_may_add_telemetry_reporting_thats_on/ . Телеметрия не затрагивает результат сборки.

Посмотреть на статистические выкладки телеметрии и скачать собранный датасет можно вот тут https://telemetry.go.dev/

Список багов, пойманных телеметрией https://github.com/golang/go/issues?q=label%3Agopls%2Ftelemetry-wins

Из менее противоречивых изменений мне приглянулись
⁃ Новый флаг go mod tidy -diff - печатает изменения, которые произойдут при go mod tidy и возвращает exit_code=1 если такие изменения есть. Сильно упрощает проверки в CI
⁃ Новый флаг go env -changed - печатает изменения в go env, сделанные с помощью -w
⁃ Упрощена работа с time.Timer и time.Ticker - теперь вызовов .Reset и .Stop достаточно для корректного сброса и остановки - не надо вытаскивать stale значения из каналов
⁃ Новый пакет unique, который позволяет интернировать comparable значения
⁃ Новый пакет structs с маркерным типом structs.HostLayout для контроля memory layout структур
⁃ В go.mod корневых модулей (не зависимостей) можно использовать директиву godebug (https://go.dev/doc/godebug), которая позволяет включать старое runtime поведение некоторых частей стандартной библиотеки. Например, новое поведение таймеров можно отключить вот так

godebug(
asynctimerchan=1
)


⁃ В net/http добавили много утилит для работы с cookie и поле Request.Pattern, которое содержит паттерн роута из http.Mux. Ждём когда chi будет выставлять его тоже
⁃ Новая функция os.CopyFS, которая копирует содержимое fs.FS в локальную директорию. Писать распаковщики zip никогда не было так просто!
⁃ Максимальная глубина стека для runtime/pprof увеличина до 128 фреймов (да, я упирался в глубину стека на трейсах 😔)
⁃ Новые функции atomic.And и atomic.Or (и комплиментарные методы), которые позволяют атомарно применять битовые маски

Интерактивные заметки к релизу https://antonz.org/go-1-23/

Пока меня тянет на низкоуровневое программирование, вот вам интересное видео с недавней конференции GOTO о том, как докладчик участвовал в соревновании на то, чтобы сделать максимально быструю агрегацию файла с миллиардом строк с информацией о погоде на Java. На старте время выполнения занимало 5 минут, а в конце — 1,5 секунды.

Если лень смотреть, вот саммари (простите за стиль, я сделал транскрипцию видео, а потом суммаризировал в Claude и подправил стиль, но все-таки немного кривовато):

Задача:
Обработать файл с миллиардом строк погодных данных, содержащий названия городов и температуры. Базовая реализация занимала около 5 минут.

Наблюдение, обучение, адаптация, эксперименты (06:07):
Первым этапом все стали загружать свои версии на GitHub и делиться базовыми, самыми простыми оптимизациями.

"You don't have to be an engineer to be a racing driver, but you do have to have Mechanical Sympathy" (08:00):
Автор объясняет важность понимания работы процессора и памяти для оптимизации кода.

Температура как Int (09:32):
Оптимизация, заключающаяся в использовании целых чисел вместо чисел с плавающей точкой для представления температуры.

Memory-mapped файлы (10:37):
Использование этой техники для быстрого доступа к данным файла.

Использование unsafe (11:54):
Применение небезопасных методов Java для прямого доступа к памяти.

SWAR (13:31):
Использование техники SIMD (Single Instruction, Multiple Data) для обработки нескольких байтов одновременно.

Безстроковая обработка (17:22):
Оптимизация, позволяющая избежать создания объектов String.

Бесветвленное программирование (18:18):
Техника оптимизации, позволяющая избежать условных переходов в коде.
Вот тут классно: автор решил не использовать if-ы. Процессор пытается предсказать код, который будет выполняться далее, еще до выполнения if-а. Если он ошибется, это приведет к падению производительности. Это может не сильно влиять в общем случае, но если вы уже боретесь за секунды оптимизации, то имеет смысл.

Парсинг температуры (20:35):
Детальное описание оптимизированного алгоритма парсинга температуры.
Мы знаем формат строк, мы знаем разделитель, мы можем переписать parseInt так, чтобы это выполнялось гораздо быстрее с помощью булевой логики.

Отслеживание данных (30:14):
Реализация собственных хэш-таблиц.

Выбор JVM (36:22):
Эксперименты с различными реализациями Java Virtual Machine.

Graal и нативная компиляция (37:21):
Использование GraalVM для компиляции Java-кода в нативный исполняемый файл.

Итоги (39:38):
Краткое изложение основных оптимизаций и их влияния на производительность.

Результаты (40:50):
Финальные результаты соревнования, где время выполнения было сокращено с почти 5 минут до примерно 1,5 секунд.

https://www.youtube.com/watch?v=EFXxXFHpS0M

Как известно все новое это хорошо забытое старое, потому начну рассказ со времен когда люди еще не ставили nginx перед апачем. И когда шутник даже через крайне узкий канал мог делать slowloris: в кучу потоков делаем большой post запрос отправляя тело по байту в минуту, а сервер вынужден из-за этого аллоцировать кучу ресурсов.

Собственно в http/2 настолько намудрили в протоколе, что переизобрели эту атаку. Для этой атаки нам понадобятся два фрейма: HEADERS и CONTINUATION. Первый посылает в упакованном виде заголовки для запроса/ответа и содержит флаг "будет ли еще", ну а второй соответственно досылает еще (если не влезли в первый пакет) и имеет аналогичный флаг. Интересно, а что же будет если просто посылать CONTINUATION фреймы с флагом "жди еще"? Правильный ответ на этот вопрос с собеса "it depends":

Самый примитивный вариант это просто выжраная память под хранение этих заголовков для будущего запроса

Вот в случае Go чуть интереснее, он, конечно, выплюнет ошибку, что достиг лимита заголовков, но цикл парсинга не остановит (который крутится до получения флага "на этом все") и проц умрет быстрее

Самый веселый вариант конечно же в Node.js — там напрограммировали рейс и если сначала послать фрейм "щас еще докину заголовков", а потом разорвать коннект то нода просто упадет с коркой

https://nowotarski.info/http2-continuation-flood-technical-details/

Пикодата, in-memory data-grid.

Немного выпал и не писал, много проектов. Добрался, наконец, до видео доклада Кости Осипова о Пикодате. Кстати, где был доклад - тоже интересно само по себе. Это была первая встреча нового комьюнити разработчиков СУБД - Database Internals Meetup. Свежая история, дело было в офисе Яндекса, драйвером, как я понимаю, выступили ребята из YDB.

Доклад ретроспективный, несмотря на название. Пикодата - осносительно новый продукт поверх Тарантула. Грубо, для каждой отдельной ноды взяли Тарантул, но поверх натянули “кластерную” обёртку - и всё вместе получилось Пикодата. Про то, как выбирали подходы к работе со схемами данных, как обжигались о Lua, как в новом продукте стали использовать Rust, и какой подход к конфигурации и управлению кластером. Немного про логику “втянуть данные поближе к приложению”, “уволить С++ программистов”, бесперспективность GC-рантаймов для high performance задач.

Видео никто не любит, но на ускоренной промотке до вопросов уложитесь примерно за 20 минут, я проверял. Инжой. Не оставляю надежды сделать пикодатовский ресёрч-клауд в рамках образовательного клауда devhands.io.

https://www.youtube.com/watch?v=_UNok-uXql4

Балансировка нагрузки

Комьюнити-чат образовтельного проекта приносит интересные ссылки и обсуждения.
Началось с обсуждения твита кого-то из Амазона, о том, что обычный алгоритм round robin (последовательно раскидывает нагрузку по всем нодам) даёт сильные “перекосы” в нагрузке. Предлагался альтернативный способ: выбирать случайно пару нод для балансировки, и из этой пары уже выбирать ту ноду, которая нагружена меньше.

Это безусловно шаг вперёд, но вообще ход рассуждений нужен следующий: давайте учитывать нагрузку и производительность. Ведь как только мы заявили требование "хочу уметь выбрать наименее загруженный", мы автоматически получаем требование сбора метрик, причем собирать нужно реалтайм. А как только ты собрал такие метрики реалтайм - открывается масса других возможностей, не только просто взять два и выбрать наименее загруженный.

Тот же Weighted Round-Robin (распределение нагрузки с динамическими весами) даёт отличные результаты, причем конечный результат заметно улучшается даже без реалтайма. Вот на этой уже довольно древней Хайлоад-конфе Юра Насретдинов, на тот момент ещё сотрудник Badoo, рассказывает, как он динамически раз в 15 минут пересобирает веса и регенерит их для LTM - и это даже нормально работало: https://www.youtube.com/watch?v=jHYzy6DDo9c.

А ещё прикольная статья с анимационной иллюстрацией алгоритмов балансировки (RR, WRR, Least connections, Latency-based). В конце страницы отличный “симуляционный” плейграунд на яваскрипте, можно выбрать любой алгоритм, плотность входящих запросов и смотреть, как наполняются очереди (и дропаются заявки от переполнения).
Сама статья здесь: https://samwho.dev/load-balancing/, ссылки изначально нашел Андрей Л, участник буткемпа, вот в этом канале: https://t.me/ThePr0Ger.

----
https://devhands.io/ru/ - образовательные треки по хайлоаду, системному дизайну, linux и другим advanced темам
https://t.me/feedmeetoo - интересные статьи, ссылки, презентации