Архитектура приложения - как бы вы разработали этот процесс - PullRequest
2 голосов
/ 15 октября 2008

У меня есть приложение, которое состоит из:

Центральная база данных, содержащая более 100 тыс. Записей. Количество «клиентских» баз данных, каждая из которых содержит около 10-20 тыс. Записей

Клиентские базы данных содержат сведения о контактах, каждый из которых имеет уникальный идентификатор (contactID).
Центральная база данных содержит некоторые из этих контактов, идентифицированных одним и тем же contactID.

Ночью нам нужно перебрать клиентские базы данных, запрашивая центральную базу данных на предмет обновлений для каждого контакта, а затем вносить их в клиентскую базу данных.
Центральная база данных принадлежит третьей стороне, поэтому мы ничего не можем изменить.
Компания, владеющая центральной базой данных, хочет делать это через веб-сервисы, повторяя каждый контакт.

Меня беспокоит, что это будет очень медленно делать с веб-службами, учитывая количество записей.

В настоящее время я думаю о создании файла на каждом клиенте, который содержит список всех контактов для этого клиента. Затем он будет отправлен в центральную базу данных. Центральная база данных затем обработает этот файл и отправит обратно другой файл, содержащий все обновления.

Как бы вы создали это, чтобы он работал как можно быстрее?

Ответы [ 5 ]

3 голосов
/ 15 октября 2008

Я бы не стал проходить каждую запись в сценарии, который вы описали. С веб-службами все в порядке, но вы также можете легко использовать их для массовых обновлений.

С моей головы что-то вроде этого будет работать немного лучше:

  1. Получите ' diff ', содержащий все изменения в базе данных master. Это может быть сделано до начала синхронизации и должно выполняться только один раз в день.
  2. Отправка полного списка контактов с клиента на сервер. Имея такой большой список, не имеет значения, как он отправляется, но если вам не нравятся веб-службы SOAP, подумайте о JSON. Я бы пошел с веб-сервисами для удобства. Опять же, список контактов можно подготовить заранее.
  3. Создайте список записей, которые необходимо обновить, сравнив ' diff ' со списком от клиента.
  4. Получить все обновленные данные за один раз (если вы используете MS SQL, вы можете сделать это с XML, другие службы SQL предлагают другие пути)
  5. Отправьте детали клиенту

Тот же механизм можно использовать для обновления только одной записи, вам просто нужно использовать другой список (содержащий 1 идентификатор) в п.2

1 голос
/ 15 октября 2008

Отправляйтесь массовыми переводами, где это возможно.

Открытие соединения TCP / IP - ОЧЕНЬ медленный процесс. Передача 20K идентификаторов контактов (даже если идентификатор огромен) в одном запросе WS выполняется намного быстрее, чем запросы 20K веб-службы.

Вы не хотите ждать, пока они ответят. У вас есть два вида потенциальных рабочих процессов.

  1. Ожидание занято . Вы отправляете партию. Вы проводите опрос каждые несколько минут, пока партия не будет готова. Это довольно неприглядно, но совершенно односторонне. Вы делаете всю работу, они просто отвечают «еще не сделано» или «сделано». Затем вы запрашиваете результаты своей партии.

  2. Уведомление . Вы отправляете партию, включающую некоторый адрес, по которому вы можете получить уведомление. Это может быть адрес электронной почты или URL (IP-адрес, порт и путь), по которому вы хотите получать уведомления.

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

    • Если вы решите использовать уведомление WS, у вас есть небольшая веб-служба, которая либо получает простое уведомление и выполняет запрос WS для получения результата, либо они отправляют вам весь результат.

  3. Если вы хотите быть грубым, откройте несколько сотен потоков и сделайте несколько сотен одновременных запросов. Это займет меньше времени, но затопит их сервер.

1 голос
/ 15 октября 2008

Поскольку вы относительно ограничены третьей стороной, вы можете выполнить одно из следующих действий:

  1. Попросите третью сторону создать веб-службу, которая возвращает список всех идентификаторов, данные которых были изменены в последний день.

  2. Затем вы перебираете этот сокращенный список с помощью веб-службы (которая, вероятно, намного меньше всего списка) и обновляете свои контакты соответствующим образом.

или

  1. Пусть третья сторона создаст веб-сервис, содержащий документ XML, содержащий дамп информации о контактах в их системе, которые изменились за определенный период. Затем вы обработаете этот документ, обновив свои данные.
0 голосов
/ 13 мая 2009

как насчет обмена сообщениями? На стороне центральной базы данных может быть создана система очереди сообщений для хранения событий обновления записей БД, и может быть тема для каждой клиентской базы данных, чтобы клиент мог подписаться только на эти интересные события. Очередь будет отвечать за уведомление клиента о событиях обновления записей.

0 голосов
/ 15 октября 2008

Вы можете запросить файл (XML), содержащий все детали идентификатора из центральной БД, и вы можете преобразовать его в некоторые сопоставления объектов. Затем, имея список объектов на своем конце, вы можете сравнить и обновить соответственно.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...