Согласованность кэширования и статический объект с nHibernate / ASP.NET

Question

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

У меня есть определенные экземпляры объектов, которые используются несколькими другими объектами в моей системе. Так, например ..

class Template {
  // lots of data
}

class One {
  IList<Template> Templates { get; set; }
}
class Two {
  IList<Template> Templates { get; set; }
}
class Three {
  IList<Template> Templates { get; set; }
}

Итак, некоторые экземпляры Template будут использоваться очень, очень часто . (подумайте, каждые 20 секунд), и это включает в себя много вещей, которые должны быть математически вычислены.

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

Лучше ли я просто оставить все для кэширования 2-го уровня в nHibernate? Или мне разумнее извлечь объект Template и сохранить его в статической переменной при запуске моего приложения ASP.NET и обновить эту переменную, если она изменится?

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

Answer 1

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

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

У вас есть три варианта:

Кэш 1-го уровня Для каждого соединения / сеанса, которые вы делаете, NHibernate всегда будет кэшировать уникальный объект, который он выбрал. Каждый раз, когда вы пытаетесь получить одно право на основе его идентификатора (первичного ключа), он сначала проверяет свой кэш первого уровня. Это не относится к коллекциям объектов, если только вы не можете заставить NHibernate получать только «идентификаторы» для коллекции и получать их один за другим (обычно очень медленно)

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

пользовательский кеш Вы всегда можете позаботиться о кэшировании себя, однако, таким образом, вам нужно соответствующим образом смоделировать свои классы (сохраняя объекты Template, а коллекции отслеживают только идентификатор вместо объектов Template). Если вы выполните такой рефакторинг, кэш 2-го и 1-го уровня все равно будет одинаково полезен.

Я приведу вам пример, показывающий, о чем я говорю:

if One содержит шаблоны с идентификатором [1,2,3,4] Два содержит шаблоны с идентификатором [2,3] Три содержит шаблоны с идентификатором [3,4,5]

Чтобы NHibernate знал, что нужны шаблоны 1,2,3,4, ему необходимо выполнить запрос к базе данных. 1,2,3,4 будут кэшироваться здесь индивидуально. Чтобы на самом деле знать, что для Two нужны сущности 2 и 3, ему все равно необходимо выполнить запрос к базе данных. Это не может знать, что 2,3 также является частью коллекции в два. Если он не будет извлекать их из кэша, потому что он выберет объекты Template, принадлежащие классу Two, следовательно, полные данные Вот почему кеширование здесь вам не поможет.

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

Answer 2

Статические переменные будут меньше стресса для вашего сервера, однако это налагает некоторые ограничения, в частности, будет гораздо сложнее масштабировать (веб-сад / ферма), если вам не нужно масштабировать, это вариант, который вы ' ищем