Как синхронизировать локальные источники данных in-memory/no-sql с центральной базой данных в режиме реального времени
У меня есть интересная проблема архитектуры.
Мой сценарий таков: мне нужно централизовать данные, которые в настоящее время хранятся в локальных базах данных SQL Server 2005, расположенных в пределах 60 витрин, которые вскоре будут удвоены до 120 витрин. В этом централизованном месте находится основная база данных SQL Server 2005. Причина не просто полагаться исключительно на базу данных SQL Server 2005 в централизованном расположении состоит в том, что если соединение WAN разорвано по разным причинам (погода, физическая линия разорвана, обслуживание и т. Д.), Витрины могут продолжать работать, используя локальные базы данных SQL Server 2005. Я говорю о критически важных данных.
Однако возникает много логистических проблем. Витрины опираются на приложения.NET для настольных компьютеров, созданные собственной командой. Эта группа использует репликацию SQL Server с локальных баз данных на централизованные базы данных. Установка новых версий этого собственного программного обеспечения и выполнение связанных сценариев SQL Server для каждой установки программного обеспечения в 60-летних местоположениях требует большой трудоемкой работы для завершения этих установок (длинные контрольные списки установки, вход на локальный сервер Remote Desktop, Dameware' вход на рабочие станции на месте, чтобы проверить, не оставили ли работники ни одно из приложений для настольных компьютеров и т. д.). Эта крайне неэффективная работа в основном выполняется по выходным и выполняется командой из 6-7 человек, которым за это не платят сверхурочно. Я из другой внутренней группы, которая реализует Java EE 6, Java SE 7 и JavaFX, хотя я знаю их боль, так как я был в этой группе. Я думаю, что есть гораздо более простое решение. Говорят о переходе всей нашей архитектуры приложений.NET на архитектуру Java EE 6, которая реализует клиентские приложения.
Моя идея заключается в следующем: внедрить встроенную /No-SQL локальную базу данных, которая остается синхронизированной в режиме реального времени с централизованной базой данных СУБД Oracle (наша компания использует либо Oracle 10g/11g, либо SQL Server 2005+). В случае выхода из строя нашей глобальной сети витрины могут продолжать бесперебойно работать с использованием локальной встроенной базы данных / без SQL. После восстановления соединения встроенная база данных / база данных без SQL сохраняет свое состояние в централизованной базе данных и восстанавливает синхронизацию в реальном времени. Я хочу, чтобы переходы соединения казались незаметными для пользователей. Я большой поклонник технологии, такой как JPA 2, которая просто переподключается после разрыва соединения.
Поскольку мы рассматриваем возможность перехода на решение на основе Java EE6, я хочу рассмотреть все технологии, которые могут работать с WebSphere v8.0.x с открытым исходным кодом. Я не хочу иметь дело с коммерческими лицензиями. Это означает, что можно рассмотреть все варианты, такие как базы данных No-SQL, базы данных in-memro, Lucene, Apache Jackrabbit, Corba/IIOP, JMS, EJB 3.1, CDI 1.0, JSF MyFaces 2.0.4, JPA 2, JAX-RS и настольные клиенты, возможно. работает на JavaFX. Единственный оставшийся вопрос заключается в том, что может сохранить данные во встроенной базе данных / без SQL и затем синхронизировать эти данные в режиме реального времени с централизованным источником данных, чтобы витрины хранилища могли оставаться работоспособными?
1 ответ
Я люблю.NET, поэтому я бы очень постарался, чтобы решение для репликации SQL Server работало, но не получилось...
Вот два решения NoSQL, которые я бы рассмотрел для репликации:
CouchDB
У них довольно хорошая репликация, и она возобновит работу с того места, на котором остановилась, когда потеряна связь. Существует кривая обучения, если вы работаете в RDBMS, но это может сработать.
MongoDB
Вы можете использовать набор реплик с Mongo, который синхронизируется с центральным (основным) узлом. Когда вторичные узлы в наборе реплик отключаются, вы можете вернуть их обратно и продолжить с того места, где остановились.
Проблема заключается в том, что, если первичный узел получает много записей, он может не иметь возможности снова синхронизироваться со вторичным узлом, который не работал в течение длительного периода времени. Он в основном запоминает все записи на главном / центральном узле, и в конце концов старые записи сбрасываются.
Генеральный Совет
И Mongo, и Couch являются базами данных документов. Если вы хотите перейти на NoSQL, вам нужно переключить весь ваш код на денормализованные структуры вместо нормализованных структур, к чему вы, вероятно, привыкли в реляционном мире.
Это большой сдвиг, и я знаю, что у меня были проблемы с нахождением моделей, с которыми я чувствую себя хорошо в мире баз данных документов.
Что касается перемещения данных в целом, я обнаружил, что Mule ( http://www.mulesoft.org/) действительно хорош в подключении очень разных типов систем / баз данных.