Шаблон для очень медленного сервера БД

Question

Я создаю сайт Asp.net MVC, где у меня есть быстрый выделенный сервер для веб-приложения, но база данных хранится на очень занятом сервере Ms Sql, который используется многими другими приложениями.

Также, если веб-сервер работает очень быстро, время отклика приложения будет медленным, в основном из-за медленного ответа от сервера БД.

Я не могу изменить сервер БД, поскольку все данные, введенные в веб-приложении, должны прибыть туда в конце (по причинам резервного копирования).

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

Для меня не важно иметь непосредственное соответствие между прочитанными данными БД и вставленными данными: думайте как чтение вопросов в StackOverflow и новых вставленных вопросов, которые не нужно отображать сразу после вставки).

Я подумал создать промежуточную службу WCF, которая будет обмениваться и синхронизировать данные между медленным сервером БД и локальным (может быть Sqllite или SqlExpress).

Каким будет лучший шаблон для этой проблемы?

Answer 1

Какое у вас узкое место? Чтение данных или запись данных?

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

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

Answer 2

Однажды у меня возникла эта проблема, и мы решили пойти на комбинацию хранилищ данных (то есть время от времени извлекать данные из базы данных и сохранять их в отдельной базе данных только для чтения) и очереди сообщений через службу Windows. (для обновлений.)

Это сработало на удивление хорошо, поскольку MSMQ обеспечивал надежную доставку сообщений (обновления не были потеряны), а хранилище данных обеспечивало доступность данных в локальной базе данных.

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

С другой стороны, это решение является масштабируемым и может быть относительно простым в реализации. (Например, вы можете использовать службы интеграции для доставки данных в хранилище и использовать слой BL для обработки изменений.)

Answer 3

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

Answer 4

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

Таким образом, вы получаете быстрый локальный sql-сервер, и данные на корректно сохраняются в медленном резервном сервере.

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

Answer 5

Вам также следует учитывать задействованные сетевые коммутаторы. Если сервер БД общается с несколькими веб-серверами, это может быть ограничено скоростью сетевого соединения. Если они подключены только через сетевой коммутатор на 100 МБ, то вы также можете захотеть обновить его.

Answer 6

Интересно, не могли бы вы улучшить его, добавив файл MDF на своей веб-стороне вместо того, чтобы иметь дело с сервером на другом IP ...

Просто добавьте SQL 2008 Server Express Edition и попробуйте, пока вы не передадите 4 ГБ данных, с вами все будет в порядке, конечно, есть и другие ограничения, но только для скорости это, почему бы не попробовать?

Answer 7

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

• Создание репликации моментальных снимков с веб-стороны (издатель) на сторону сервера базы данных (подписчик). Вам понадобится платная версия SQLServer на веб-сервере. Я никогда не работал над такой конфигурацией, но она может использовать много ресурсов веб-сервера в запланированное время синхронизации
• Создание репликации слиянием (или транзакцией, если требуется) между стороной сервера базы данных (издатель) и стороной сети (подписчик). Затем можно использовать бесплатную версию MS-SQL Server и запланировать запуск процесса синхронизации в соответствии с допустимым уровнем потери данных в случае сбоя веб-сервера.