Уменьшить результаты запроса кэширования SQL Server

Question

У меня есть программное обеспечение, которое выполняет тяжелую обработку на основе некоторых файлов. Я должен запросить некоторые таблицы в SQL Server в процессе, и это убивает БД и производительность приложения. (другие приложения используют одни и те же таблицы).

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

Я думал об использовании Fabric AppCache (я нахожусь в стеке MS), сделал некоторые тесты, у него большое использование памяти для небольших объектов (у приложения appcache есть ~ 350 МБ использования ram без объектов). Но мне нужно сделать некоторые запросы в эти таблицы результатов (например, поиск по LastName, Ssn, BirthDate и т.д.)

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

Использование mongo в качестве хранилища кешей в этом случае является хорошим подходом? Или AppFabric Caching + поиск тегов лучше?

Answer 1

Трудно сказать, что лучше, потому что мы недостаточно знаем о ваших узких местах. Многое зависит от качества данных, которые вы обсуждаете. Если данные очень статичны и не вызываются постоянно, но для компиляции набор данных занимает много времени, хорошим решением может быть использование материализованного представления. Если эти данные часто вызывают, чем лучше кэшировать их на каком-либо сервере (например, в приложении). Существует много способов и возможностей. Но вам действительно нужно думать о сетевом трафике, спросе, размере и т. Д. И т. Д. И трудно ответить на это здесь, не зная всех деталей. Похоже, вы на правильном пути, но может быть все, что вам нужно, это всего лишь параметризованный запрос. Трудно сказать. Но я добавлю Materialized view в список, который вы только что разместили. Может быть, все, что вам нужно, это построить этот вид из всех необходимых вам данных и просто получить доступ к его содержимому.

Answer 2

Мое вопрос вам в том, каковы ваши долгосрочные цели или оценки для вашего приложения? Если это самая высокая нагрузка, которую вы собираетесь испытать, тогда настройка DB или использование MVL будет ответом. Но долгосрочное решение этого - распределенное кэширование, и вы уже думаете об этом. Ваши требования к данным - это то, что мы назвали «ссылочными данными» или «поисковыми данными», и как только вы исключите несколько запросов с ограниченными ресурсами БД, будет проблема с производительностью, и ваша БД станет узким местом производительности.

Таким образом, решение, о котором вы уже думаете, кэширует эти «ссылочные» данные в кеше без необходимости обращаться к базе данных, в то же время сохраняя кеш-синхронизацию с базой данных.

Appfabric Я бы не был слишком уверен в том, что у него будут те же проблемы с поддержкой, о которых вы упомянули. Какой у вас бюджет? Можете ли вы подумать о расходах на решение cachisng, например NCache?