Серверы веб-кэширования для SQL Server OLTP Env.рекомендации - PullRequest
0 голосов
/ 12 декабря 2011

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

У нас есть БД, которая получает около 3 ГБданные добавлялись в таблицу каждый день, и отчеты по ней были очень медленными.Данные не меняются, как только они вставляются, и никакие данные не вставляются старше недели.Строки, введенные в течение последних 3 дней, имеют тенденцию видеть тысячи вставок между десятками миллионов строк.

Я думал о том, чтобы данные за 2 недели были отправлены в MongoDB.Затем я мог бы получить данные за 2 недели в скользящем окне, которые не были переданы в Mongo, кэшироваться каким-либо программным обеспечением для кеширования, чтобы они запрашивались и отображались вместо данных, которые все время считывались из БД.Я полагаю, что таким образом мы по-прежнему получаем полное соответствие ACID, если механизм БД проверяет все данные, имеет высокую производительность чтения, поскольку он не затрагивает БД, и тогда Mongo может принять его, когда он больше не является «транзакцией».

У кого-нибудь есть рекомендуемые решения?Я смотрел на MemCached, но не совсем уверен, что это хорошее или даже правдоподобное решение.Спасибо!

Ответы [ 2 ]

2 голосов
/ 29 мая 2014

Еще одна вещь, которую вы могли бы рассмотреть, - это использовать новую функцию In-Memory OLTP в SQL Server 2014. Эта функция повышает эффективность и масштабирование рабочих нагрузок OLTP.Потенциально вы сможете получить гораздо больше от вашего существующего сервера, без необходимости учитывать конкретные механизмы кэширования.

0 голосов
/ 13 января 2012

У меня нет особого опыта работы с SQL Server, но то, что вы описываете, похоже на действительный вариант использования MongoDB.

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

MongoDB сама по себе может также выступать в качестве кеша производительности, если вы запускаете второе развертывание с отключенным ведением журнала. В этом случае запись будет осуществляться в память и сохраняться на диске только каждые 60 секунд (если не настроено иное). Это обеспечит сопоставимую производительность с memcache, который находится исключительно в оперативной памяти, и в то же время позволит вам сделать ваш стек немного проще.

Надеюсь, это поможет!

...