Вопрос архитектуры

Question

У меня общий вопрос по архитектуре, надеюсь, ребята, могут мне помочь. Итак, сначала немного базового фона. У меня есть клиентская база среднего размера, использующая мой флагманский продукт, который в основном представляет собой бухгалтерское программное обеспечение crm Это продукт на базе Windows, и они размещают данные на своих серверах (обычно в своих офисах).

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

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

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

Проблема заключается в том, что запросы к нашей базе данных с веб-сайта, а также из службы загрузки истекают. Каждый раз, когда мы делаем новую версию, мы расширяем подмножество данных (т.е. добавляем новую таблицу или 2). Так что сразу после релиза нас засыпают загрузками. Поэтому наш сайт в последнее время не работает. Я думаю, что слишком много трафика происходит с одной базой данных, с точки зрения загружаемых данных и поиска данных для веб-сайта.

Мы бы хотели, чтобы подмножество данных было максимально синхронизировано с данными о флагманских продуктах.

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

Какие пути я могу исследовать на долгосрочную и краткосрочную перспективу?

Cheer.

Answer 1

Если закачки не должны быть доступны мгновенно (можно немного подождать, прежде чем вы выберете данные), я настоятельно рекомендую поставить перед ними очередь, используя MSMQ / WCF. Это может помочь вам ограничить потребление этих данных.

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

• Убедитесь, что вы не используете технологию, которая не соответствует задаче (например, Access или Sqlite).
• Рассмотрите возможность оптимизации базы данных для Вставляет, а затем реплицирует эту базу данных в другие базы данных, которые вы можете использовать для выбора.
• Если у вас огромное количество данных, рассмотрите возможность создания кластера
• Рассмотрите возможность перехода на облачную службу данных, такую ​​как Amazon SimpleDB или Azure Data Services

Answer 2

Где твоя бутылочка? Это проблема пропускной способности вашего соединения с данными, проблема на вашем сервере баз данных или на вашем веб-сервере и т. Д.

Какое программное обеспечение базы данных вы используете? Если это доступ или что-то в этом роде, он должен идти, в пользу или что-то более корпоративное, например, sql server или подобное.

Все ли клиенты пытаются загрузить данные одновременно? Можете ли вы как-то их пометить, возможно, загрузив их в произвольное время в течение дня или в случайное время в определенном окне.

Поможет ли кластеризация вашего веб-сервера или сервера БД?

Можете ли вы реализовать какую-то очередь через msmq, как уже упоминалось, или использовать biztalk или аналогичный продукт. Таким образом, клиент может представить свои результаты и забыть об этом, тогда программное обеспечение очереди обрабатывает фактическую доставку.

Answer 3

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