Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
14.12.2016, 14:11
|
|||
---|---|---|---|
|
|||
Помогите подобрать оптимальное решение |
|||
#18+
Пишу диплом. Нужно подобрать оптимальное решение для следующей задачи: Есть ряд компаний,которые обмениваются данными о недобросовестных кредиторах в виде сообщений.(рассылка ПД клиентов)(компаний 100+) суть проблемы вот в чем,передача информации (карточек с ПД) ведется по обычной электронной почте и информация несистематизируется. При такой передаче данных возникает ряд проблем таких как:поскольку рассылка проводится в открытом виде по большому списку электронных почтовых адресов, в некоторых случаях это приводит к срабатыванию спам-фильтров на стороне получателей и неполучению ими значимой информации, добавление новых пользователей в рассылку никак не контролируется + каждый получатель самостоятельно решает как полученную информацию хранить, что затрудняет • Характер рассылок нерегулярный, необходимо • обеспечение защищенной рассылки данных внутри закрытой группы пользователей, желательно чтобы все сообщения доходили до адресатов и были ими обработаны без потерь • отслеживание добавления новых участников в рассылку • обеспечение систематизированного,централизованного хранения полученной информации на стороне пользователя с возможной последующей обработкой и поиском в массиве ранее переданной информации. т.е необходимо организовать единую защищенную автоматизированную платформу для информационного обмена между субъектами с систематизированным хранением сообщений. необходимо Организовать единую защищенную автоматизированную платформу для информационного обмена между компаниями в соответствии с имеющимися современными требованиями и технологиями. Основное требование к структуре решения – децентрализованность, то есть отсутствие выделенного «центра», агрегирующего и управляющего собранной информацией. требования к системе. Работа с базой Должна быть реализована возможность представления данных пользователю по запросу (поиск информации) Должна быть реализована возможность добавления (изменения) данных (пополнение базы) • добавление карточек "по одной" • пакетное добавление • при добавлении данных должна быть предусмотрена возможность идентификации ранее созданной карточки При добавлении данных, должна быть реализована возможность расширения карточек дополнительными полями • возможность выбора добавляемого поля из ранее зафиксированных дополнительных полей • возможность добавления новых дополнительных полей с фиксацией следующей информации: o идентификатор поля (уникален в среди всех возможных полей карточки) o наименование поля (применяется при построении GUI) Вопрос уже задавался,но неструктурированно http://www.sql.ru/forum/1242040/relyacionnaya-bd-ili-nosql Заранее спасибо за ответы. Из предложенных вариантов: использование мультимастер репликации, и RabbitMQ+MongoDB, может есть еще варианты либо какой-то из предложенных в таком контектсте не подходит? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.12.2016, 14:32
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
Совсем "без центра" не получится -- главный быть всё же должен. Другое дело, что этот "главный" может в какой-то момент отвалиться и тогда узлы должны провести "выборы" нового "главного". См. Raft . Систему же в принципе можно попробовать построить поверх Append-Only Log: The Log: What every software engineer should know about real-time data's unifying abstraction . Если планируется редактирование "карточек", то см. Operational transformation . ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.12.2016, 19:08
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
noob1111, Рассылки это решение из 90-х. Ложить файлы на ftp и не заморачиваться. По ходу доступом к ftp решится и вопрос с пользователями. Ну а вопрос с БД нужно решать уже отдельно. Тут на вкус и цвет все фломастеры разные. Одним словом можно реализовать на чем угодно. Поскольку это диплом - идите в архив и возьмите готовое решение. Чего это будет стоит уже не наше дело, но полюбому дешевле чем кто-то за вас будет решать. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.12.2016, 23:25
|
|||
---|---|---|---|
|
|||
Помогите подобрать оптимальное решение |
|||
#18+
Нахлобуч,спасибо за ответ) ссылка : The Log: What every software engineer should know about real-time data's unifying abstraction. не открывается( ... |
|||
:
Нравится:
Не нравится:
|
|||
|
14.12.2016, 23:27
|
|||
---|---|---|---|
|
|||
Помогите подобрать оптимальное решение |
|||
#18+
Злой Бобрnoob1111, . Поскольку это диплом - идите в архив и возьмите готовое решение. Чего это будет стоит уже не наше дело, но полюбому дешевле чем кто-то за вас будет решать. что за архив??? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2016, 09:52
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
НахлобучСовсем "без центра" не получится -- главный быть всё же должен. Да прям... MySQL и PostgreSQL. Часть 7. Репликация в PostgreSQL Мультимастер (Multimaster Replication).В отличие от схемы ведущий-ведомый, здесь может быть несколько ведущих узлов . Каждый ведущий узел выполняет сначала свой запрос у себя, потом синхронизирует его на другом ведущем. Недостаток в том, что возможны конфликты между ведущими узлами на уровне транзакций. В Postgres используется асинхронный мультимастер-режим. Эта схема также реализована в Bucardo, rubyrep, PgPool-II, PgCluster, Sequoia. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2016, 10:57
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
skyANAНахлобучСовсем "без центра" не получится -- главный быть всё же должен. Да прям... MySQL и PostgreSQL. Часть 7. Репликация в PostgreSQL И где противоречие? В случае с Master-Master мы имеем два ведущих, а не их отсутствие. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2016, 10:59
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
noob1111, frigate или https://web.archive.org/web/20161011081816/ https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying%5DInternet]https://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying]Internet Archive. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2016, 10:59
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
|
15.12.2016, 15:25
|
|||
---|---|---|---|
Помогите подобрать оптимальное решение |
|||
#18+
НахлобучskyANAпропущено... Да прям... MySQL и PostgreSQL. Часть 7. Репликация в PostgreSQL И где противоречие? В случае с Master-Master мы имеем два ведущих, а не их отсутствие. Я не про главный должен быть, а про получится быть "без центра" :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=33&tablet=1&tid=1547319]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
55ms |
get tp. blocked users: |
1ms |
others: | 266ms |
total: | 414ms |
0 / 0 |