Проблемы производительности с зависимостями от внешних данных

У меня есть приложение, которое взаимодействует с несколькими внутренними и внешними источниками, используя службы SOAP, REST или просто хранимые процедуры базы данных. Очевидно, что производительность и стабильность являются основными проблемами, с которыми я имею дело. Даже когда конечные точки работают наилучшим образом, для больших наборов данных я легко вижу вызовы, которые занимают 10 секунд.

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

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

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

Я говорю о 50 тысячах пользователей и как минимум 10 конечных точках, которые ужасно медленные и иногда могут занимать минуту для одного звонка. Может ли что-то вроде Quartz дать мне нужный мне масштаб? И как мне обойти график, ставший единственной точкой отказа?

Я просто ищу что-то, что не требует сложного обслуживания и ускоряет хотя бы некоторые из менее сложных подсистем, если не большинство. Какие-либо предложения?


person Langali    schedule 15.08.2009    source источник
comment
Пожалуйста, объясните, что делают эти 50 000 пользователей. Как они взаимодействуют с этими данными из нескольких источников? Вы активно извлекаете все эти данные по запросу?   -  person John Saunders    schedule 15.08.2009
comment
Рассматривайте его как портал, на котором пользователь может заказывать продукты, совершать платежи, настраивать продукт, просматривать отчеты об использовании, получать оповещения, обновлять/откатывать, использовать билеты и т. д. Это типичное приложение J2EE, похожее на банковский портал, но очень разнообразное. . В настоящее время все извлекается по запросу.   -  person Langali    schedule 15.08.2009
comment
Хорошо, см. мой ответ ниже, и дайте мне знать, если у вас есть дополнительные вопросы.   -  person John Saunders    schedule 15.08.2009


Ответы (1)


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

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

Вы не указали, какие платформы используете. Если вы используете SQL Server 2005 или более позднюю версию, я бы рекомендовал службы SQL Server Integration Services (SSIS) для обновления хранилища данных. Он создан именно для таких вещей.

Конечно, в зависимости от вашего выбора платформы могут быть более подходящие альтернативы.


Вот некоторые ресурсы по службам SSIS и хранилищам данных. Я знаю, что вы заявили, что не будете использовать продукты Microsoft. Я включаю эти ссылки в качестве ориентира: это продукты, о которых я говорил выше.

person John Saunders    schedule 15.08.2009
comment
Похоже, он может делать то, что я ищу, но продукты Microsoft не вариант. Подойдет ли ESB вроде ServiceMix или даже RabbitMQ? - person Langali; 15.08.2009
comment
Я не знаком с такими. Я рекомендую вам изучить то, что может делать SSIS — отчасти это те функции, которые вам следует искать. Некоторые из ваших текущих проблем будут связаны с получением данных и их очисткой. SSIS — это инструмент ETL, который может это сделать. Затем вы могли бы сделать так, чтобы ваши 50 000 пользователей извлекали свои данные из хранилища данных, оптимизированные для доступа на чтение и запрос, и обновлялись так часто, как это необходимо. - person John Saunders; 15.08.2009