https://edu.postgrespro.ru/postgresql_internals-15.pdf - Прекрасная книга про PG. Не перевод. Кто хочет изучить устройство PG рекомендую. Концепции работы СУБД не особо рассматриваются. Речь идет о том как работает именно PG. Внутренности работы описаны здорово.

https://habr.com/ru/companies/sberbank/articles/753404/ - перевод этой статьи.

https://www.youtube.com/watch?v=vpbmYA0Wsbg - Ignite community мне очень нравится тем, что мы делаем очень много докладов про дизайн компонентов СУБД. Позволяет лучше понимать код проекта и суть решений.

Андрей Гура с Лешей Гончаруком рассказывают про устройство PDS.
Смотрите - это очень интересно.

Кто знает подобные доклады про другие СУБД - шлите линки в комментариях.

https://assets.amazon.science/dc/2b/4ef2b89649f9a393d37d3e042f4e/amazon-aurora-design-considerations-for-high-throughput-cloud-native-relational-databases.pdf - ребята из VK показали пейперы в которых Amazom описал дизайн Aurora - клаудной СУБД совместимой с MySQL и PostgreSQL. Познавательно

https://pages.cs.wisc.edu/~yxy/cs764-f20/papers/aurora-sigmod-18.pdf - второй пейпер про Аврору.

https://dl.acm.org/doi/pdf/10.1145/2882903.2903741 - дизайн SnowFlake. Легко читается - много интересных мыслей и хороших решений по дизайну системы.

https://raft.github.io/raft.pdf описание Raft’а

Описание как работает хранение BLOB'ов в Windows Azure Storage. Очень интересное хотя и непростое чтиво.

Если кто знает хороший пейпер с общим описанием работы кодов Рида-Соломона - пишите в комментариях.

Описание дизайна всего S3 хранилища от Windows Azure Storage. Количество инфы и интересных тем зашкаливает. Очень интересно.

Несколько КПДВ цитат:

> WAS provides high availability with strong consistency guarantees. This combination seems to violate the CAP theorem

> This redundancy provides essential data recovery protection against disasters such as earthquakes, wild fires, tornados, nuclear reactor meltdown, etc.

Особенно интересует что скрывается под "etc" :)

Подход к разработке распределенной системы управления облачными сервисами описан в статье "Experience with Rules-Based Programming for
Distributed, Concurrent, Fault-Tolerant Code".

Ключевые абстракции:

1. event - внешнее событие, которое необходимо обработать.
2. condition - условие которое проверяется перед запуском action.
3. action - действие которое выполняется в ответ на событие.
4. rule = condition + action.
5. goal - цель(которую нужно достичь) действия.

На этих штуках строятся управляющие механизмы. Сверху всем этим управляет простая штука которая маршрутизирует события и управляет жизненным циклом.

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

Недостатки - сложно увидеть общую картину. Построить в голове полный flow процесса. Кажется, будет сложней тестировать и отлаживать если чето идет не так.

Очень близко к акторам и FSM (что и упоминается в статье), но акценты расставлены по-другому.

Очень люблю хорошо структурированные описания архитектур.

C FoundationDB знаком неблизко, но кажется стоит познакомиться поближе.

Слышал, про использования в высоконагруженном финтехе. В пейпере говорят, что в Apple используют.

Очень интересно было сравнивать решения принятые в FDB и Ignite. Когда сделаем выпуск подкаста про FDB должно выйти ОЧЕНЬ интересно.

Design Principles:

* Divide-and-Conquer (or separation of concerns). FDB decouples the transaction management system (write path) from
the distributed storage (read path) and scales them independently.

* Make failure a common case

* Fail fast and recover fast. To improve availability, FDB strives
to minimize Mean-Time-To-Recovery (MTTR).

* Simulation testing. FDB relies on a randomized, deterministic
simulation framework for testing the correctness of its distributed database.

Видео из 2019 - больше бизнесовое и архитектурное чем техническое. Этим и зашло. "Top Ten Big Data Blunders".

Кажется, что многие ошибки, особенно в консервативных бизнесах актуальны и сейчас.

Список такой (пояснения по ним доставляют отдельно):

Blunder #1: Not Planning to Move EVERYTHING to the Cloud
Blunder #2: Not Planning for AI/ML to be Disruptive
Blunder #3: Not Solving your REAL Data Science Problem
Blunder #4: Belief that Traditional Data Integration Techniques Will Solve Issue #3
Blunder #5: Belief that Data Warehouses will Solve all your Problems
Blunder #6: Belief that Hadoop/Spark will Solve all your Problems
Blunder #7: Belief that Data Lakes will Solve all your Problems
Blunder #8: Outsourcing your new stuff to Palantir, IBM, Mu Sigma...
Blunder #9: Succumbing to the "Innovator's Dilemma"
Blunder #10: Not Paying Up for a Few "Rocket Scientists"
Blunder #11 (Bonus): Working for a Company That is not Trying to do Something about the "Sins of the Past"


Заметки на полях:

* Понравился тон и скорость выступления. В моем понимании именно так надо общаться с большими начальниками которым продаешь технологии.

* Ошибки и провалы некоторых архитектур, например, КМД (Корпоративная Модель Данных) я предсказывал с теми же аргументами что и профессор.

Если кто не знает - Стоунбрейкер основатель Ingres (из которого вышел postgres) и кучи других СУБД. Обладатель премии Тьюринга. Короч очень авторитетный в мире баз данных.

https://youtu.be/KtpG4wJhohU?si=W1L9X2k1lUjlrFvO - тизер нового выпуска!

https://youtu.be/LkGNUSFU3Ls?si=7jV7QPp28F_M09u2 - db.podcast #2 - FoundationDB

https://youtu.be/U6mrLzES0dU?si=IgeY4EGYrEHEpbk7 - сказ про benchmark driven development

Классика разработки СУБД - ARIES - читать непросто, да и статья обьемная - но знать надо. Рекомендую к ознакомплению:

https://dl.acm.org/doi/pdf/10.1145/128765.128770

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

В этом выпуске мы даже писали код! И даже запускали его!!!

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

Если когда-то возникал вопрос "Как ConsumerGroup'ы работают в Кафке?" - то вот ответ:

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

А я, в свое время, чинил конкаррент багу в этом протоколе - https://github.com/apache/kafka/commit/00374c3ddf6c4ecc96f58c6685fd107500b976cd