https://www.opennet.dev/openforum/vsluhforumID3/111457.html Компания Bloomberg перевела СУБД Comdb2 (https://bloomberg.github.io/comdb2/) в разряд открытых проектов. Comdb2 относится к категории реляционных кластерных СУБД, позволяющих развернуть БД поверх нескольких узлов кластера и обеспечивающих высокий уровень отказоустойчивости и производительности. Ключевой задачей Comdb2 является предоставление простой и надёжной распределённой системы, позволяющей обратиться к данным или внести изменение, подключившись к любому узлу, и получить автоматическую синхронизацию изменений на всех остальных узлах кластера, в том числе территориально разделённых. Разработка СУБД Comdb2 ведётся компанией Bloomberg c 2004 года. Код написан на языке Си и распространяется (https://github.com/bloomberg/comdb2) под лицензией Apache 2.0. <br><br><br>Comdb2 предоставляет достаточно простую и ясную логику организации работы кластера: достаточно запустить Comdb2 на одном узле, создать БД и определить в настройках (простой файл со списком хостов) на каких ещё узлах обеспечить хранение данной БД. После https://www.opennet.dev/openforum/vsluhforumID3/111457.html#81 Thu, 15 Jun 2017 19:25:18 GMT &gt; WAL нельзя реплицировать по нодам<br><br>Лол. А авторы этой комдб не знают и реплицируют. И все реплицируют.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#80 Thu, 15 Jun 2017 18:45:11 GMT И еще, ты упустил момент про ACID. Что будет если одна нода передаст другой ноде WAL и сразу упадет? Верно, у одной будет коммит, у другой все свалится. Теперь вопрос на мильон, какой ответ отдать клиенту? Тот, что говорит, мол все отлично! Или тот, что говорит, извини, но я упала. Причем, я упала клиент узнает через несколько секунд, минут и т.д. и т.п. (мало ли, БД под нагрузкой, вот и думает много).<br><br>Все эксперты, могут взять карандаш и начать писать свою БД с поэтессами и шахматами.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#79 Thu, 15 Jun 2017 18:34:33 GMT &gt; О каких случаях речь? Эти алгоритмы могут реплицировать wal, что достаточно для <br>&gt; субд.<br><br>В comdb2 WAL флешится раз в 10 секунд. WAL нельзя реплицировать по нодам, т.к. нужно делать для каждой ноды merge, что еще более затратней.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#78 Thu, 15 Jun 2017 18:32:50 GMT &gt;20к<br><br>На SSD. Сравни с этим (уже давал линк): https://web.archive.org/web/20140809204443/http://symas.com/mdb/microbench<br><br>Так что на HDD будет те же 2к, может 3к от силы. Откуда взял инфу автор статьи, я не знаю, может сам тестил.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#77 Thu, 15 Jun 2017 17:26:39 GMT Почитал я эту статью, а там не 2к записей в секунду, а 20к. Уже похоже на правду. Ну и получается, что ты тут обосновывал даже не производительность этой базы, а опечатку автора статьи. Т.е. как бы лужу газирнул.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#76 Thu, 15 Jun 2017 07:47:17 GMT О каких случаях речь? Эти алгоритмы могут реплицировать wal, что достаточно для субд.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#75 Thu, 15 Jun 2017 07:46:35 GMT Читаем внимательно - транзакция идет на всех кластерах одновременно. Пока на все не легло - не коммитит. <br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#74 Thu, 15 Jun 2017 07:45:39 GMT &gt; Каким образом? Волшебным?<br>&gt; Все равно будет какой то промежуток когда где-то данные уже есть, а <br>&gt; где-то их еще нет.<br><br>Пока данные не разойдутся по всем узлам, коммит не будет подтверждён и операция INSERT не завершится.<br> https://www.opennet.dev/openforum/vsluhforumID3/111457.html#73 Thu, 15 Jun 2017 07:36:37 GMT &gt;но если операция INSERT успешно завершена, то изменения сразу становятся видны для запросов в любых частях кластера.<br><br>Каким образом? Волшебным?<br>Все равно будет какой то промежуток когда где-то данные уже есть, а где-то их еще нет.<br>