Распределенные базы данных
Предупреждение: написано в стиле заметок на полях и воспроизводит ход размышлений автора, у читателей процесс размышления, равно как и наличие этого самого процесса и его результаты, могут отличаться!
Посещавшие меня мысли о распределенных базах данных и их применимости начинают обретать законченные черты, а значит, самое время сделать соответствующую реализацию. Поскольку я уже знаю ответ на вопросы "что, как, зачем", то можно погуглить для ознакомления с уже существующими реализациями и лежащими в их основе концепциями.
Основная идея состоит в том, что распределенная БД отнюдь не предполагает и не требует распределенную СУБД. Посмотрим на это утверждение с такой стороны - информация первична, а способ ее представления - вторичен. Например, из споры можно "восстановить" бактерию, а бактерии вовсе незачем раздуваться до размеров материка, когда можно просто превратить себя в спору и с попутным ветром этот материк перелететь, после чего "ожить". А дальше - интереснее. Процесс репликации базы данных вполне себе аналог полового размножения (т.е. обмен генетической информацией), к примеру, инфузорий, а создание копии базы, разумеется, - бесполого. Поскольку и образование цисты предусмотрено природой, получается, что инфузория вполне достойный ориентир для нас. Из аналогии сразу получаем практическое следствие - результат скрещивания двух БД может быть идентичен одному из "родителей" или иметь признаки обоих. Весьма доступно и возражений не вызывает. Так и хочется сразу же проанализировать доминантные признаки, но это уже детали реализиции алгоритма разрешения конфликтов при репликации. Есть чему порадоваться - мы нашли простой и хорошо изученный аналог того, что обычно представляется в совершенно запутанном виде.
А теперь самое время поискать аналог инфузории в программном обеспечении. Уже понятно, что распределенные именно СУБД - ошибка эволюции и на них мы смотреть не будем.
Гугл сразу же выдал ссылку, да еще перевод предложил, притом забавный:
Кликабельная ссылка: Thoughts On The Design Of The Fossil DVCS
В свете наших биологических аналогий ошибка перевода очень "даже в тему" оказалась. Каким-то образом гугл сделал потрясающую вещь, сумев найти в тексте ключевую фразу:
Подробности можем прочитать по ссылке, хотя процитированная выше фраза исчерпывающе объясняет концепцию.
Таким образом, вместо решения сложнейшей и бесполезной задачи создания распределенной СУБД широко известный в узких кругах DRH сделал распределенную БД. Интересно, как он мыслил, явно ведь каким-то другим путем шел.
Можно и других примеров поискать, но как раз с fossil и SQLite я близко знаком, да и программистов, способных излагать идеи настолько доступно, как это делает DRH, долго по сусекам скрести.
Кандидат на распределенную реализацию у меня уже давно напрашивается, и это будет веб-сервис. В настоящий момент реализация существует и уже лет 5 верой и правдой служит одному из сотовых провайдеров. Попробую решить следующую задачу - реализовать втрое больший функционал за втрое меньшее время, на втрое более простой схеме БД и втрое меньшим объемом кода - причем так, чтобы новой версией было втрое легче пользоваться. А почему бы и нет?
Посещавшие меня мысли о распределенных базах данных и их применимости начинают обретать законченные черты, а значит, самое время сделать соответствующую реализацию. Поскольку я уже знаю ответ на вопросы "что, как, зачем", то можно погуглить для ознакомления с уже существующими реализациями и лежащими в их основе концепциями.
Основная идея состоит в том, что распределенная БД отнюдь не предполагает и не требует распределенную СУБД. Посмотрим на это утверждение с такой стороны - информация первична, а способ ее представления - вторичен. Например, из споры можно "восстановить" бактерию, а бактерии вовсе незачем раздуваться до размеров материка, когда можно просто превратить себя в спору и с попутным ветром этот материк перелететь, после чего "ожить". А дальше - интереснее. Процесс репликации базы данных вполне себе аналог полового размножения (т.е. обмен генетической информацией), к примеру, инфузорий, а создание копии базы, разумеется, - бесполого. Поскольку и образование цисты предусмотрено природой, получается, что инфузория вполне достойный ориентир для нас. Из аналогии сразу получаем практическое следствие - результат скрещивания двух БД может быть идентичен одному из "родителей" или иметь признаки обоих. Весьма доступно и возражений не вызывает. Так и хочется сразу же проанализировать доминантные признаки, но это уже детали реализиции алгоритма разрешения конфликтов при репликации. Есть чему порадоваться - мы нашли простой и хорошо изученный аналог того, что обычно представляется в совершенно запутанном виде.
А теперь самое время поискать аналог инфузории в программном обеспечении. Уже понятно, что распределенные именно СУБД - ошибка эволюции и на них мы смотреть не будем.
Гугл сразу же выдал ссылку, да еще перевод предложил, притом забавный:
Ископаемое: размышления по поводу дизайна ископаемой DVCS
Исходный язык: английский
Мы утверждаем, что ископаемые не основывается на SQLite на всех и что ископаемые не основывается на распределенной базы данных, поскольку NoSQL ископаемого представляет собой распределенную NoSQL...
Fossil: Thoughts On The Design Of The Fossil DVCS
We claim that Fossil is not based on SQLite at all and that Fossil is not based on a distributed NoSQL database because Fossil is a distributed NoSQL ...
www.fossil-scm.org/index.html/doc/tip/www/theory1.wiki
Кликабельная ссылка: Thoughts On The Design Of The Fossil DVCS
В свете наших биологических аналогий ошибка перевода очень "даже в тему" оказалась. Каким-то образом гугл сделал потрясающую вещь, сумев найти в тексте ключевую фразу:
We claim that Fossil is not based on SQLite at all and that Fossil is not based on a distributed NoSQL database because Fossil is a distributed NoSQL database.
Подробности можем прочитать по ссылке, хотя процитированная выше фраза исчерпывающе объясняет концепцию.
Таким образом, вместо решения сложнейшей и бесполезной задачи создания распределенной СУБД широко известный в узких кругах DRH сделал распределенную БД. Интересно, как он мыслил, явно ведь каким-то другим путем шел.
Можно и других примеров поискать, но как раз с fossil и SQLite я близко знаком, да и программистов, способных излагать идеи настолько доступно, как это делает DRH, долго по сусекам скрести.
Кандидат на распределенную реализацию у меня уже давно напрашивается, и это будет веб-сервис. В настоящий момент реализация существует и уже лет 5 верой и правдой служит одному из сотовых провайдеров. Попробую решить следующую задачу - реализовать втрое больший функционал за втрое меньшее время, на втрое более простой схеме БД и втрое меньшим объемом кода - причем так, чтобы новой версией было втрое легче пользоваться. А почему бы и нет?
Comments