Уважаемые разработчики системы. В общении с вами на этом форуме я составил некоторое мнение о разрабатываемой вами СГ, и хочу подвести промежуточный итог и свое видение возможных вариантов разработки/доработки СГ.
Возможны несколько основных вариантов СГ.
1. Серверный вариант с одним (центральным сервером). Функции ПО узла голосования - ключи, голосования, просмотр результатов. Функции сервера - хранение данных, обработка результатов голосований. Практически реализован (хотя я поразным причинам поработать с тестовым вариантом не смог). Основной недостаток в реальном применении - уязвимость, связанная с возможной неработоспособностью сервера.
2. Серверный вариант с большим количеством одинаковых серверов. В отличии от п.1 БД системы реплицируется на множество серверов для обеспечения надежности. Очевидный недостаток системы - постоянные финансовые траты на эксплуатацию серверов системы, хостинг это или "свои" сервера (чьи, кстати?). Учитывая предполагаемый размер БД, плата за хостинг может составлять тысячи рублей за каждый сервер в месяц, а "свои" могут обойтись еще дороже.
3. "Идеальная" распределенная СГ, построенная по принципу peer-to-peer. Система состоит из равноправных узлов (нодов), каждый из которых способен обеспечить полный функционал: ключи, голосования, БД, обработка и предоставление результатов голосований, коммуникации с другими узлами для распостранения информации в системе.
Основные недостатки такой СГ - потенциально большой сетевой трафик, непомерно нагружающий домашний/рабочий компьютер пользователя системы, то же, в большей степени, относится к размеру БД, могущему составить терабайтовый размер. В ближайшие годы не все участники голосований согласятся на такие жертвы ради удовольствия проголосовать на дому.
И еще, несмотря на доводы авторов проекта и не претендуя на объективность, для меня лично остался открытым вопрос о возможности свободной коммуникации между узлами СГ, построенной на таком принципе.
4. В ходе обсуждения в форуме я высказал идею о возможности построения распределеной СГ с серверами коммуникаций. В такой системе за равноправными узлами остается весь функционал, как и в "идеальной" p2p СГ (см. п.3), за исключением коммуникации. Узлы общаются с серверами, количество которых может быть любым. Функционал серверов - прием информации и запросов от узлов, репликация и кэширование.
Недостатки системы, как и в п.3, потенциально большие размеры БД на узлах. Сетевой трафик, очевидно меньше.
Достоинством системы считаю относительную простоту коммуникационной части, возможность отладки и использования в узлах системы почти полнофункциональных узлов "идеальной" p2p (п.3), а также низкие, по сравнению с п.2 эксплутационные расходы (регистрация доменов - 100 руб/домен на год, хостинг серверов - от 100руб./сервер на месяц).
На текущий момент (январь 2012) реализован тестовый вариант серверной СГ (п.1). Пользовательский интерфейс в ней представлен фактически в виде набора инструментов. Если стоит задача популяризации, то необходимо создавать полноценный и удобный для пользователя оконный или web интерфейс работы с системой. Он же с незначительными изменениями может быть использован во всех остальных версиях системы (п.2-4).
Учитывая недостатки п.2, а также то, что будущее все равно за распределенной СГ, не уверен, что стоит тратить силы на вариант доработки системы с п.1 на п.2. Т.е., нужно попробовать построить распределенную СГ - фактически создать ПО для узла системы. Как промежуточный вариант, можно использовать концепцию п.4, тем более, что если кол-во серверов на этапе разработки ограничить (одним?), дополнительных финансовых вложений не требуется. Но главное, если это возможно, теоретически разработать вариант хранения данных системы в некотором иерархическом или другом виде, кардинально сокращающем размеры БД системы. При решении этой задачи требуется учесть и то, что в обобщенных результатах голосований нужно отображать не только общие данные, но и срезы результатов по различным социальным группам голосовавших.
|
