8 заблуждений - всё? Реальное воплощение PAXOS а

Мир меняется так стремительно, что остаётся только разводит руками.

Решил получше разобраться с известными 8ю заблуждениями, которые сформулировал в 1994 году Дойч (8е добавил Гослинг, создатель Java). Есть небольшая статья в Вики. А есть..

еще одна статья, которая называется "The 8 fallacies of distributed computing are becoming irrelevant". 

В этой второй статье говорится, что все эти заблуждения уже в общем и не заблуждения. И сети надёжны, и с латентностью разобрались, и т.д., и т.п.. А всё благодаря репликации, конкретно - благодаря технологии Active Transactional Data Replication. В самом конце статьи приводится в качестве примера гуглопродукт под название Cloud Spanner.

Стал копать. Active Transactional Data Replication - это технология, используемая в IBMвском Big Replicate (версия продукта Fusion от WANDisco). И там есть репликация типа active-active (это типа master-master?). Вот интервью с разработчиками. 

Что интересно, в Big Replicate используется протокол PAXOS. Хм. Вообще-то я раньше читал, 

что PAXOS слишком сложен для реализации, собственно из-за этого и возник Raft (есть, кстати, ещё Zab). 

Так вот, оказывается, PAXOS реализован и используется в коммерческом (не академическом) проекте. И не одном! Упомянутый выше Google Spanner тоже его использует.

А что такое Google Spanner ? Нууу, это полное великолепие. Взять хотя бы это описание. Это NewSQL СУБД, со строгой согласованностью, масштабируемая в глобальном масштабе, с синхронизацией времени с помощью GPS и атомных часов. Т.е. расхождения времени (clock skew), получается, вообще нет. И всё благодаря паксосу...?

В общем, с PAXOSом имеет смысл ознакомиться. Вот здесь интересное сравнение PAXOS и Raft.  Иииии... конечно есть альтернативная точка зрения на могущество PAXOSа . "Why would you use blockchain over a distributed consensus protocol like Paxos or Raft?",- задают вопрос на Quora. И в комментах пишут, что PAXOS плохо масштабируется по сравнению с блокчейновским консенсусом (напр., выборы лидера и отслеживание "живости" процессов требуют слишком большого количество пересылок).

Вот так. Хоть стой, хоть падай. Протокол консенсуса, который считался слишком абстрактным и сложным, вдруг лёг в основу коммерческих софтин Big Replicate и Spanner. А в этих софтинах решены чуть ли не все проблемы теории распределённых систем.    

Как написать свою ОС?

Как я уже писал, материалов по поводу написания своей (хотя б маленькой учебной) СУБД в сети маловато. А вот руководств по созданию ОС - предостаточно.

Вбиваем в Гугл "how to write an operating system" (в подсказках еще "simple operating system source code" всплывает, но это потом посмотрю). И находим массу интересных текстов. 

Скажем, вот неплохая пдфка - Writing a Simple Operating System from Scratch. Кратко описано написание загрузочного сектора в 16-битном режиме, в 32-битном защищённом режиме; написание драйверов, файловой системы, создание ядра. 

Вот  гит-книжка How to Make a Computer Operating System. А вот The little book about OS development (по аналогии с "маленькими книжками" о Redis и Mongo). Разлюли-малина. Почему ж тему написания СУБД так обделили?

Thrift, Avro и Protobuf

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

В замечательном блоге eax.me нашел упоминание о книге Designing Data-Intensive Applications за авторством Мартина Клеппманна. Блоггер отозвался о книге положительно, посоветовал подписаться на журнал Мартина.

Ну а в блоге Клеппманна обнаружилась хорошая статья, где сравниваются форматы Thrift, Avro и Protobuf. Будет время - почитаю, очень хочется в этой теме разобраться.  

GDB

Отладчик gdb, оказывается, очень мощная штука - умеет ловить сигналы, выполнять программу в обратном направлении, показывать стек и массу других интересных вещей. 

Можно почитать быстрый старт, а можно - подробную документацию.

Крамер и Маги: Concurrency

Нашел еще одну книгу по теории распределенных систем двух Джеффов: Concurrency: State models & Java programs (Jeff Magee, Jeff Kramer). По ней есть хорошая презентация Software Architecture: Modeling and Analysis, rigourous approach.   Таким образом, Джеффы подходят к вопросу с точки зрения моделирования, а не, скажем, отладки распределенных программ.

Классификации СУБД

Некто Себастьян Меньер в своем посте 2016 года привел очень хорошую, наглядную классификацию распределенных СУБД, в которую поместил в том числе и новомодный блокчейн.

А вот еще методичка по распределенным СУБД, в которой объясняется, чем отличаются между собой параллельные, сетевые и распределенные СУБД. А также есть еще масса интересной информации по распределенным СУБД.

Почему стоит писать СУБД?

Я уже упоминал статью Тома Кроули "Never Write Your Own Database". Так почему не стоит писать СУБД? А просто потому, что это очень сложное ПО, достаточно взглянуть на схему в моем предыдущем посте.

А почему, тем не менее, так много новых СУБД?  Во-первых, в "больших" СУБД масса возможностей, которые многим пользователям не нужны ("Wow, there’s a lot of stuff there that I don’t need. I wonder what I’m paying for that?"). Поэтому новая СУБД, в которой меньше лишнего, может оказаться востребованной. А во-вторых, СУБД, заточенная под какую-то конкретную задачу оказывается эффективней (в своей области), чем СУБД общего назначения.