Реализация распределённой децентрализованной отказоустойчивой БД для небольших объёмов данных — что посмотреть?
Думаю, как реализовать subj. в небольшой локалке (~ 10 компов) равноправных компов, изолированной от инета.
Для чего нужно: на каждом компе запущена прога, которой нужны файлы конфигурации (небольшие, до 1КБ, немного, до 10-ти штук) и небольшая БД (явно не Big Data, 5-7 таблиц на несколько сотен строк максимум). Эти самые файлы и БД одинаковые на всех компах. Нужно сделать, чтобы обновления всего этого дела, будучи отредактированы на одном любом компе, распространялись автоматом на остальные компы. Часть которых может быть в данный момент выключена.
Сервер выделить не получается -- каждый комп может быть выключен. Хотя 2-3 компа -- менее вероятно, скорее всего постоянно будут работать, но не факт.
Что есть готового, чтобы это реализовать?
Вроде, Redis + Redis Sentinel может, но кажется из пушки по воробьям, нет? К тому же, вроде он с Windows не очень дружит.
Спасибо, очень интересный проект. Тем более есть .NET клиент.
Для меня тут главное то, что нужно всё-таки выделить группу компов в качестве серверов Zookeeper, и сервис будет работать, только если более половины серверов включены:
How do I size a ZooKeeper ensemble (cluster)?
A 3 server ensemble (you need to jump to 3 and not 2 because ZK works based on simple majority voting) allows for a single server to fail and the service will still be available.
How ZooKeeper Works
ZooKeeper runs on a cluster of servers called an ensemble that share the state of your data. (These may be the same machines that are running other Hadoop services or a separate cluster.) Whenever a change is made, it is not considered successful until it has been written to a quorum (at least half) of the servers in the ensemble.
А у меня возможна ситуация, когда во всей локалке включен только один комп, на нём редактируется конфигурация, и хотелось бы, чтобы когда подтянутся остальные, конфигурация обновилась на них автоматом.. Похоже, не подходит.
tsul: Zookeeper идеально подходит для вашей задачи... просто задача у вас совсем не идеальная.
Вы сейчас не обращаете внимание на огромное количество проблем, которые возможны с таким распределенным и децентрализованным изменением данных, которое вы хотите реализовать. А разработчики Zookeeper об этом подумали.
Например, на сервер А записали конфигурацию А1, но он не успел ее распространить по остальным компьютерам, поскольку его выключили. Независимо от этого почти одновременно на сервер В записали конфигурацию В1, а на сервер С - конфигурацию С1. Сразу после этого сервера А снова включили. А теперь вопрос - какой должна стать новая конфигурация: А1, В1 или С1?
И ведь это еще не самая запутанная ситуация.
Roman_Kh: Да как раз, в общем-то, обращаю.. Скорее, поверхностно просмотрел доки по Zookeeper.
Не будь конфликтов, уже сейчас бы начал писать свой велосипед, как xmoonlight советует.
Вообще, да, думал в-основном про парные конфликты, про тройные нет) В любом случае, при конфликтах нужно вмешательство пользователя.
Спасибо еще раз за наводку, буду изучать глубже.
Roman_Kh: Подумал вот: может быть и так, что включили половину компов, поменяли на них конфигурацию C -> C1, затем их выключили, включили оставшиеся, поменяли на них C -> C2, затем включили всё.
ex Software Engineer at Reddit TS/React/GraphQL/Go
RavenDB имеет master-master репликацию и разворачивается очень быстро.
Сервер БД можно развернуть внутри самого приложения (embedded), что избавляет от установки доп. программ.
Сделать TCP/UDP-манагера (файловый и БД клиент): системный сервис, который будет принимать команды от других ПК по TCP/UDP на репликацию и обновления как файлов, так и запросов к БД, а также отправлять broadcast-запрос при включении на проверку/загрузку новых изменений к себе.
Проще всего - поднять нормальный микро-сервер с пассивным охлаждением на Gigabyte BRIX или подобной платформе и "не взрывать" мозг ни себе, ни людям.
В том-то и дело, что свой велосипед писать не хочется. Как его начинать, примерно понятно, вы правы. Сервис/TCP/UDP/broadcast и т.п. БД можно хоть в SQLite. Но дальше идут конфликты, а отсюда получается, что нужна версионность изменений и т.п. Потому как разрешение конфликтов - дело пользователя. И нужна аккуратная синхронизация. Хоть git прикручивай. Или вообще Dropbox/ownCloud и нафиг конфликты.
Поднять микро-сервер было бы хорошо, но что есть, то уже есть. За наводку на Gigabyte BRIX спасибо.
Мозг никому "взрывать" не хочу, спрашиваю тех, кто имел дело с подобным.
tsul: тогда самое простое решение - через сервер с пассивкой 24/7 где-нить в шкафчике и вопрос сразу решится, т.к. будет все централизованно и как положено.
PS: Последний уходящий - выдёргивает ключ-флешку из серва и закрывает помещение)
Простой
