В сценарии распределенного кэширования обычно рекомендуется использовать или избегать монолитных объектов, хранящихся в кеше?
Я работаю со службой, поддерживаемой схемой EAV, поэтому мы используем кэширование, чтобы минимизировать воспринимаемый дефицит производительности, налагаемый EAV при извлечении всех первичных записей и соответствующих коллекций атрибутов из базы данных. Запустим кеш при запуске сервиса.
У нас не особенно частые вызовы для всех продуктов - клиенты запрашивают различия после того, как они сначала заполняют свой локальный кэш картой объектов. Чтобы выполнить эту разность, распределенный кеш должен будет отражать изменения отдельных записей в базе данных, которые выполняются произвольно и обрабатываются для изменений, когда клиенты требуют дифференциалов.
Первой мыслью было использовать список или словарь для хранения записей в распределенном кеше - получить всю коллекцию, локально манипулировать ею или выполнить поиск в памяти, поместить всю коллекцию обратно в кеш. Дальнейшие размышления, однако, привели к идее наполнения кеша отдельными записями, каждая из которых была сделана так, чтобы их можно было извлекать из кеша / обновлять по отдельности. Это привело к размышлению о том, какой метод будет более производительным при обновлении всех данных.
Мы используем Windows Server AppFabric, поэтому нам доступна операция BulkGet. Однако я не верю, что есть какое-то массовое обновление.
Существует ли распространенное мнение о размерах объектов распределенного кэша? Если бы у нас было больше запросов на все элементы, у меня были бы проблемы с пропускной способностью сети, но, по крайней мере, на данный момент спрос на все элементы должен быть довольно минимальным.
И да, мы собираемся протестировать и профилировать каждый метод, но мне интересно, есть ли что-то за пределами текущей области мышления, чтобы рассмотреть здесь.