2016-02-12 2 views
7

Я создаю веб-приложение, которое вкратце берет довольно плохо структурированные данные на SQL Server и через Node.JS переносит его на MongoDB. Причина, по которой я нуждаюсь в этом, заключается в том, что мне нужен доступ к данным из довольно плохо написанного приложения, которое является центральным для организации, которая У меня нет возможности изменять код на, из которого вводятся исходные данные. После перевода я могу сделать свое приложение тем, что ищет бизнес.SQL Server Realtime Push Notifications to Node.JS

В настоящее время мое приложение опроса SQL Server каждые 30 минут на изменения, а затем обновление моего MongoDB через Node.JS, и из-за объема данных нежелательно опросить гораздо чаще.

Что должно произойти, чтобы иметь реальные уведомления времени от SQL Server толкаемого моего приложения Node.js в некотором роде является ли активным или пассивным закончиться не Node.js, так что он может обновить свою базу данных Монго.

Библиотека узлов Я использую, чтобы получить данные есть: https://github.com/patriksimek/node-mssql

Несколько возможных идей, которые я имел были:

  • Have SQL Server отправить уведомление о какой-то моей службе NodeJS HTTP Конечная точка
  • У NodeJS выполняется потоковый запрос, который будет выполняться на моем конце каждый раз при внесении изменений.
  • Запишите приложение на C#, которое следит за этими изменениями и отталкивает их в конечную точку HTTP NodeJS.

Есть несколько вещей, которые, кажется, говорят об этом, но большинство из них, похоже, говорит об изменениях в точке происхождения источника данных (которые я не могу изменить), а не от самого SQL Server.

+0

Благодарим за редактирование @JamesZ, заставляя меня звучать умнее, чем я действительно XD – Nitroware

+1

Это действительно важный вопрос. Я хотел бы, чтобы он получил больше внимания. –

ответ

0

Я должен предисловие к этому, сказав, что у меня нет решения в режиме реального времени. Если есть решение в реальном времени, я этого не знаю. Я просто расскажу об уменьшении нагрузки опроса.

Я предполагаю, что у вас есть контроль над самим SQL-сервером. Вы можете настроить что-то в SQL Server, чтобы отслеживать изменения и получать опрос, чтобы посмотреть только на изменения, еще не вытащенные узлом.

У вас есть контроль над процессом обновления/вставки? Если вы это сделаете, легко поместите код отслеживания изменений вместе с кодом вставки/обновления. Я предполагаю, что вы этого не делаете, и в этом случае я бы рекомендовал * посмотреть на triggers. Это, в основном, прослушиватели событий, привязанные к таблицам, которые позволяют выполнять SQL до, во время или после вставки/обновления таблицы, и дают вам доступ к данным, которые изменяются/вставляются с использованием таблиц и inserted.

* Триггеры: не понравилось сообществу SQL Server для гневных причин, некоторые из которых обсуждаются on this SQLServerCentral article. Суть вещей: их трудно отлаживать, они замедляют работу, когда они становятся частью операции записи, и будьте осторожны, чтобы не создавать циклические триггеры (обновляется таблица1, которая запускает тригг, который обновляет таблицу1, которая запускает тригг и т. Д.). Таким образом, если вы выполняете отслеживание изменений с помощью триггеров в таблице, создайте отдельную таблицу, в которой эти изменения будут отслеживаться, а разрешит триггер обновить/вставить эту таблицу.

Теперь вы можете настроить таблицу треков изменений, которую запускает триггер с внесенными изменениями, и когда они были сделаны, и, возможно, даже поле bit, чтобы сказать, еще ли Node потянул эти изменения. Теперь все, что вам нужно сделать, это заставить Node посмотреть на эту таблицу и только внести изменения, которые она еще не втянула. Эта таблица, вероятно, скоро станет огромной и, следовательно, медленной для опроса, поэтому я бы порекомендовал поставить index на флаг или поле, в котором указывается дата внесения изменения. Теперь, поскольку опрос выполняется быстро, вы должны иметь возможность уменьшить интервал.

Это не идеальное решение, и может быть много работы, поэтому, вероятно, лучше подождать некоторое время и посмотреть, есть ли у кого-нибудь лучшее решение.