Исследования баз данных

У меня есть безумное желание знать всё. Не уметь, не делать, но знать точно. И вот одно из них связано с исследованием баз. На работе чаще всего проповедую подход boring technology, а вот в homelab можно оторваться. И даже когда что-то делаешь, всё равно потом отказываешься в пользу PostgreSQL или SQLite или ClickHouse. Такой вот швейцарский нож, который зарекомендовал себя на все случаи жизни.

Есть даже более радикальные мысли о том, что что достаточно PostgreSQL или вот такое же мнение на русском. И это правда так по простой причине: большинство компаний не упираются в пределы вертикального масштабирования данной базы. А если упираются, то скорее всего разработчики сделали что-то не так. На такую радикальную мысль стоит давать кучу оговорок, но лень.

Но меня что-то понесло, написать хотелось о другом — о лучшем инструменте и техническом блоге по тестированию баз данных: https://jepsen.io/. Выход каждой статьи в блоге для меня праздник, потому что ребята закапываются в эмуляцию потери пакетов, случайных задержек, битых файлов, и это всё в собственных коробках. А также радостно возвращают это всё разработчикам, которые чинят довольно оперативно.

Последние три исследования:

1. https://jepsen.io/analyses/mariadb-galera-cluster-12.1.2 — потери записи при сетевых сбоях.
2. https://jepsen.io/analyses/nats-2.12.1 — потеря записей, если файлы побились на меньшинстве нод из кворума.
3. https://jepsen.io/analyses/tigerbeetle-0.16.11 — база, которая позиционировалась под финансовые данные, могла не запуститься на bitflip или не имела механизма для замены сломанной ноды. Тут стоит отметить, что почти все баги уже успели поправить.

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

@chernov_sharit