Лучше, конечно же обсудить все мысли всех совместно и прийти к единому мнению. Но пока пишем каждый по своему(у вас уже начинает даже немножко получаться писать по-человечески). Но так как я пока все равно не можете
В следующих 1-2 постах я распишу алгоритм с примером записей в БД нод – так нагляднее и понятнее. А пока общие выводы о том, как должен производиться подсчет голосов) в СГ (обратите внимание - мы постепенно сближаемся во мнениях).
1. Принцип разбиения на группы подсчета – по атрибутам нод или голосующих, не важен – алгоритм подсчета и выверки результатов голосований в целом остается неизменным. Подведение итогов в каждой ноде ВСЕГДА производится по группам нод (базовый подсчет). Одновременно возможны другие варианты подсчета – см. п.4.
2. Сбор на каждой ноде ИСХОДНЫХ результатов голосования группы нод фактически есть ТОЛЬКО backup исходных голосов. В алгоритме подсчета итогов голосований на ноде ИСХОДНЫЕ (в исходном виде) данные других нод НЕ УЧАСТВУЮТ. Размер группы нод для backup-репликации, т.е. количество дополнительных записей в БД выбирается только и исключительно исходя из требуемой надежности backup голосов и величины генерируемого при этом (внутригруппового ли?) трафика. Как вариант, backup данные лучше бы вообще хранить в каком-то виде отдельно от БД для подсчета.
3. Каждая нода СГ производит подсчеты каждого уровня агрегации самостоятельно, заверяет и выдает в сеть СГ, при этом сама пользуется заверенными результатами других нод (вопрос выверки данных сейчас не рассматриваем). Результаты подсчета голосов любого уровня иерархии – это агрегация (суммирование) данных предыдущего уровня.
4. В стандартном варианте нода собирает полные данные только самого последнего уровня иерархии групп – для подведения итогов голосования всего субъекта, при этом БД получается весьма компактной. Как сказано в п.1, подведение итогов в каждой ноде всегда производится по группам нод (базовый подсчет). Заказчик при инициации голосования указывает дополнительные (нужные ему) принципы подведения итогов («приписка» голосующего к УИК/ТИК/ОИК/ЦИК или другие - при наличии требуемых атрибутов). В этом случае подсчет голосов на нодах ведется в базовом и других вариантах одновременно (в разных логических БД). Процесс и результаты базового и нужных заказчику подсчетов отображаются в приложении (в WEB) ноды.
5. Результаты голосований на ЛЮБОЙ ноде можно детализировать до любого уровня иерархии. Для этого необходимо обеспечить условия сбора данных – достаточно мощный канал для входящего трафика и необходимый размер дискового пространства для размещения БД голосований. Алгоритм подсчета голосов при этом не изменяется. Собирать более детальные (вплоть до данных голосования на каждой ноде, но не в исходном виде, если требуется) данные будут, возможно, заказчик голосования, штабы кандидатов, избирательные комиссии разного уровня.
6. Интенсивность трафика в СГ в процессе голосования можно (и нужно) регулировать. Подробности сформулирую позже.
7. Алгоритм точно подходит для открытого голосования. По-моему, вы намудрили с тайным голосованием, так как уже на первом уровне агрегации хранятся только результаты голосования без привязки к голосующим. Впрочем, подсчет голосов при тайном голосовании подлежит дальнейшему обсуждению и разработке.