Проект "Свободные голосования"

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

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Файловая база будет неэффективна для распределённого хранения в p2p системе. Неэффективность связана с длительным поиском запрашиваемого ресурса. Плюс в кеше других клиентов может не оказатся запрашиваемого ресурса. И основных частей может не быть всех. Восстановление же из рековер блоков тоже не быстрое.
Объектные базы тоже не запрашивают каждый объект с диска отдельно, а сразу кортежами или блоком связанных объектов. (Вариант хранения задаётся по дефолту оптимизатором СУБД или указывается разработчиком при создании перманентного объекта.) И это при работе с локальным диском где счёт доступа к диску измеряется миллисекундами.

Массивы можно нарезать на части и хранить не у всех. А загружать уже по необходимости. Не думаю что скажем ожидание в районе часа протокола голосования прошедшего месяц назад сильно кого смутит. У пользователя же просить выделить некоторый объём дискового пространства достаточный для хранения интересующих его данных.

Андрей, не отвлекайтесь до окончания ФРЭДовской эпопеи на эти ветки форума. Это пока на очень отдалённое будущее.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

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


Ну, я все-равно не серверным вариантом сейчас занимаюсь, а на работе работаю.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

Данные по активным голосованиям всё равно будут в кеше. А по не активным если захочется их перепроверить, то несколько часов задержки особой роли не играют. Можно даже будет сделать такой тип запроса "обеспечить доступность данных, я заберу завтра около 22-00".

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

Все проблемы, что вы обсуждаете по распределенной БД, вы можете отследить на примере bitcoin.
У них была такая Эволюция:
1) вычисление на CPU, голая p2p, полная репликация;
2) использование GPU;
3) web-сервисы - услуги кошелька и доп. инфо;
4) web-пулы независимых участников;
5) мощные независимые стойки серверов (GPU, p2p, репликация);
6) неполноценный клиент - p2p и репликация;
7) клиент для мобильных систем - только p2p;
8) тонкий клиент: p2p и частичная репликация.

В итоге, сложилась система из:
- сильной обслуживающей сети (пп.4 и 5);
- и сети слабых реальных пользователей услуг (пп.6, 7 и 8).

Собственно говоря разделение frontend и backend уже разделение системы. Технически frontend может быть запущен и на другой машине. Только backend в любом случае должен работать на доверенной машине.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".

ОООООО!!! 8-О Бэкэнд-же может работать вообще на одном из распределенных серверов которые имеют дофига памяти и винтов что-бы хранить даже гигантские голосования. Мало того, это полностью вписывается в нашу концепцию.

_________________
7BF9BDC16428245B55CF04EF4A609CA44E0F6E68

В итоге остановились на BDB?

Пока да, но это не фиксировано. Пока вроде нет потребности в исполнении изощрённых запросов.

_________________
Во вселенной нет общества в котором "Vox populi, vox Dei" не переводилось бы "О, Боже, как мы в это вляпались".