​​И первый публичный анонс нашего pub/sub-сервера. Сервер - PubSubRT, протокол - PSRT (IESG approved, port 2873)

В чем особенности сервера:

1) Минимально простая конфигурация. На производительность влияет только один параметр - data queue. Чем он меньше - тем меньше latency, но клиент может дольше ждать перед отправкой сообщения

2) Работает максимально быстро, даже с большими пейлоадами. И да, latency на хорошей сети редко поднимается выше 0,5 ms (для мелких пейлоадов - в пределах 30-40 микросекунд)

3) Это не "черный ящик". максимальный мониторинг всего, что происходит внутри

4) Жесткое слежение за latency, warnings в логи, как только превышается допустимый параметр

5) Никаких "таблиц подписки" - только b-trees. Клиенты могут задать миллионы подписок на разные топики, но если сообщения не ходят сразу в миллион клиентов бродкастом - сервер этого не замечает.

Latency между паблишером и конкретным подписчиком мы считаем, как время с момента получения от паблишера первого байта OP_PUBLISH и до ухода последнего байта в дата-сокет подписчика

В чем особенности протокола. Основная особенность одна - мы использовали два сокета (на один порт) и отказались от карусели OP-ACK. Аргумент против один: это усложняет написание надежного клиента, впрочем клиенты на Rust и Python уже вполне надежные. Теперь аргументы в пользу:

- В Pub/Sub пуши от сервера приходят только когда вы получаете сообщение. поэтому пусть себе и ходят по выделенному сокету данных

- По сокету управления все операции - атомарные. Карусель OP-ACK на клиенте тоже не нужна, что намного облегчает логику

- Благодаря двум сокетам, сервер может посылать ACK на операции контроля прямо в то время, пока клиент по второму сокету скачивает большой пейлоад

- Внезапно, но есть куча клиентов, которые просто отправляют данные и ни на что не подписываются. В PSRT данные на сервер можно пушить хоть UDP-фреймами, с ACK или без

- Нет retains. На высоконагруженных Pub/Sub от них всё равно рано или поздно отказываются, потому что это обычно операции с диском

- Очень жесткий контроль таймаутов. Дохлый клиент будет с сервера немедленно выброшен. Дохлый сервер будет немедленно переподключен клиентом

- Максимально простой запуск TLS

- Репликация и HA из коробки. В сервере мы ее пока не открывали, но в будущем думаю да. Протокол репликации открыт

- Логическая совместимость с MQTT - те же топики, те же маски

Все это уже работает в продакшне у клиентов. Реальное ускорение с пейлдоадами >10kb на медленных каналах (нестабильный 1Mbit) - в 5-10 раз быстрее, чем MQTT. Наша EVA ICS уже получила поддержку PSRT в дополнение к MQTT, релиз выйдет примерно через месяц.

https://github.com/alttch/psrt

Graph Databases Blog Posts

4 blog posts exploring different ideas behind graph databases:

* Graph Fundamentals — Part 1: RDF
* Graph Fundamentals — Part 2: Labelled Property Graphs
* Graph Fundamentals — Part 3: Graph Schema Languages
* Graph Fundamentals — Part 4: Linked Data

Complex and Simple Models of Multidimensional Data : from graphs to neural networks

A mini-workshop on applications of graphs in biology. 1 December, free, but registration is mandatory.

Одна из самых главных методик для меня, когда я готовлюсь к дизайн интервью, я читаю Post-mortems. Нет ничего приятнее, захватывающее и полезнее, чем смотреть как падают системы, с грохотом, по разным причинам. Они читаются как страшилки, а то и хорошие сказки на ночь. Хорошая коллекция есть у Dan Luu (https://github.com/danluu/post-mortems). Один из моих любимых это

Pentium division bug

Процессор неправильно делил очень редкие числа. Баг был в том, что часть таблицы для деления неправильно подгружалась в Programmable Lookup Array. Тестирование из-за симметричности таблицы было сделано только на первой её половине, а неправильные значения подгружались только во второй.



Но, наверное, хочется поделиться своей, одной из самых запоминающихся историй, когда я работал в Яндекс.Поиске (публикую с разрешения своего бывшего тех лида)

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

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

Случайно нажал на группировку по хостам, и увидел, что за последний день два хоста падают, одни и те же. И вроде бы даже машинки здоровые, не поломаные, диски, CPU, RAM, всё работает как часы.

Зашёл на машинку, увидел, что coredump отложился. Взял его, подключился к монитору, налил кофе и решил посмотреть, что сломалось.

Падало где-то в кишках итераторов, которые ищут по предложениям, "Интересно", -- подумал я, этот код оттестирован лучше всего в поиске, что же пошло не так.

Шарды, хранящие кусочек интернета, как правило имеют одним из индексов обычный из слов в номера предложений и позиций. Индекс важный, крупный, здоровый.

Потыкался минут 5-10 в gdb, отковырял запрос, он был что-то в духе "ящерица аброния". "Хороший запрос", -- подумал я тогда. И даже как-то захотелось дальше копать.

Начал смотреть, где падает, итератор попытался поискать слово синоним "ящурный", и почему-то не нашёл, хотя слово точно есть в индексе.

Дальше я ушел, погулял по практически пустому офису в 10 вечера. Так и не понял в чём проблема, создал баг, пошёл спать.

На утро я проснулся со странным ощущением в голове. Далее прям похожая картинка из мультфильма Рататуй, когда Эго попробовал блюда, что-то меня осенило с утра. "Это же последнее слово из толкового словаря Даля", -- вспомнил я. Как-то в детстве просто любил листать словари, интересно, что было в конце. И у меня тогда родилась идея :)

Так получилось из-за скорости, что индекс хранил 29 бит для индексации слов, а 35 бит были для всего остального. Да вроде всё хорошо, уже пару лет в проде, должно работать как следует. Тем не менее, полмиллиарда уникальных слов не хватило для нескольких миллионов документов и 29 бит переполнились. В итоге позиции предложений для нулевых индексов стали содержать позиции предложений переполненных, и так как некоторые предложения не существовали (слова не сходились), то всё съезжало.

Баг не всегда воспроизводился, но в данном случае произошло, что

ящерица находится очень в конце индекса
аброния находится очень в начале

Понятное дело, что и после ящурный и до абронии было много других странных несуществующих слов, но этого хватило, чтобы найти переполнение и соответственно баг в индексаторе.

Слава богу таким эффектом пострадали только десяток шардов, и это было не очень незначительным. Через пару месяцев после перестройки всех индексов панелька с падениями всё так же показывала редкие значения, но на этот раз это всё были машинки, которым стало просто плохо.

Я вспоминаю поиск, где мне было весело. В Google всё как-то стабильно работает, таких историй намного меньше

Интересный движ намечается в январе 2022 года — Data Engineer Zoomcamp

Это 9 недельный курс в формате zoom-лекций и практических занятий по дата инжинирингу. Примечательно что он абсолютно бесплатный для всех, нужна лишь предварительная регистрация по ссылке.

У этой инициативы уже есть полупустой репозиторий на гитхабе: https://github.com/DataTalksClub/data-engineering-zoomcamp, там же можно ознакомиться подробнее с предстоящими темами для изучения.

Старт намечен на 17 января 2022 года

[article]
https://blog.twitter.com/engineering/en_us/topics/infrastructure/2015/building-distributedlog-twitter-s-high-performance-replicated-log-servic

Ещё успел завести и немного потыкать вот эту штуку https://github.com/flekschas/jupyter-scatter
Сразу некоторое разочарование, что нет ховеров и нельзя экспортировать выделение куда-то вне виджета. Пока потенциал этой штуки не раскрыл. Потом посмотрим. Теперь в планах соединить графовые и текстовые признаки, доделать кластеризацию и какую-то интерпретацию кластеров. Потом уже можно будет снова качать данные и обновлять выводы.

All of NoSQL is because of this… | Max De Marzi
https://maxdemarzi.com/2023/02/27/ragedb-needs-worst-case-optimal-joins/

Building a large scale unsupervised model anomaly detection system — Part 1 | by Anindya Saha | Apr, 2023 | Lyft Engineering
https://eng.lyft.com/building-a-large-scale-unsupervised-model-anomaly-detection-system-part-1-aca4766a823c

Hands-on with Apache Iceberg on Your Laptop: Deep Dive with Apache Spark, Nessie, Minio, Dremio, Polars and Seaborn | by Alex Merced | Data, Analytics & AI with Dremio | Sep, 2024 | Medium
https://medium.com/data-engineering-with-dremio/hands-on-with-apache-iceberg-on-your-laptop-deep-dive-with-apache-spark-nessie-minio-dremio-c5d689b01730