Однонаправленная синхронизация в реальном времени с sql-сервера на другой репозиторий данных

В моем предыдущем вопросе на этом портале я спросил о некотором понимании синхронизации данных между SQL Server и репозиториями данных на основе ключей и значений.

Вместо той же проблемы (односторонняя синхронизация в реальном времени из SQL в HBase или любую другую базу данных) мне нужно позаботиться о некоторых соображениях производительности и задержки, и я не нашел надежного способа сделать это.

  1. У нас есть несколько осколков данных SQL 2008, в которых данные обновляются из разных источников и обрабатываются многими процессами одновременно (и пользовательский интерфейс считывается из одних и тех же осколков).

  2. Цель состоит в том, чтобы получать все обновления в выбранных таблицах в любой момент времени и передавать их в другой источник данных практически в режиме реального времени.

  3. Количество изменений в сегментах SQL останется в диапазоне 100-500 МБ (если мы сохраним частоту в 1 минуту). Мы не хотим вносить серьезные изменения в SQL-серверы, так как откажемся от них после полной миграции системы.

  4. К сожалению, наш уровень доступа к данным перепутан на разных уровнях. В противном случае это был бы лучший способ разветвления обновлений в двух направлениях.

  5. Триггеры замедляют работу осколков и оставляют их в невосприимчивом состоянии.

  6. Не уверен, что в SQL Server 2008 есть что-то похожее на SQL Server 2005 Службы уведомлений и насколько это будет эффективно.

Любое другое инновационное решение было бы очень полезно.

Здесь моя проблема заключается не в преобразовании данных из реляционной формы в форму "ключ-значение" (это довольно просто), а в том, как получать обновления SQL Server в режиме реального времени (можно позволить задержку в 1-2 секунды). минут), не влияя на работу пользователя.


ssis sql-server-2008 data-synchronization sqlbulkcopy
person Panks    schedule 20.06.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

вы смотрели на SQL Service Broker? вот ссылка с некоторой информацией об этом: http://blogs.msdn.com/b/sql_service_broker/archive/2008/07/09/real-time-data-integration-with-service-broker-и-другие-sql-techniques.aspx

person JuneT    schedule 20.06.2011
comment
Отслеживание изменений кажется хорошим решением. Однако не нашел статистики по снижению производительности на серверах с высоким трафиком. - person Panks; 29.06.2011
comment
еще один, на который вы, возможно, захотите взглянуть, - это сбор данных об изменении сервера Sql. - person JuneT; 30.06.2011

arrow_upward
0
arrow_downward

Существуют слои данных снизу вверх: хранилище, файловая система, БД и приложение.

Наиболее эффективный способ сделать это — использовать репликацию хранилища. Он почти не влияет на производительность, может быть настроен как синхронный или асинхронный и не является бесплатным. Вы можете использовать Google SRDF или MirrorView, чтобы получить представление об этом.

Затем вы можете взглянуть на репликацию файловой системы. Это похоже на репликацию хранилища, но происходит на уровне ОС/файловой системы, потребляя ресурсы (ЦП, ввод-вывод, память) хост-системы. Дополнительную информацию можно найти в Google Symantec Storage Foundation.

На уровне БД вы можете выполнять репликацию базы данных/доставку журналов для репликации данных. SQL-сервер имеет такие возможности.

«Самое дешевое» решение было бы изменить ваше приложение, как ваше 4), но я предлагаю вам использовать очередь сообщений для репликации данных, чтобы минимизировать влияние на производительность.

person Jason    schedule 20.06.2011

arrow_upward
0
arrow_downward

Один из вариантов, на который вы, возможно, захотите обратить внимание, — это интегрированный SQL Server. Отслеживание изменений (часть SQL2008 или выше). Это невероятно эффективный способ обнаружения изменений, которые произошли в вашей базе данных SQL Server (включая удаления), он очень мало влияет на вашу SQLDB, не требует триггеров и предоставляет хороший способ, позволяющий затем переместить изменения данных в Хадуп.

Откровенно говоря, я работаю над Cotega, и мы уделяем большое внимание синхронизации данных. Я рад помочь больше, если это направление, в котором вы заинтересованы.

person Cotega    schedule 08.11.2014