Кэширование архитектуры для результатов поиска в приложении ASP.NET
Ну, у Java нет псевдонимов типов, так что вам не повезло. Однако псевдонимы типов иногда можно заменить переменными типов! Таким образом, мы решаем проблему слишком большого числа обобщений с помощью еще большего количества обобщений!
Поскольку вы удалили весь контент из вашего примера, я не могу догадаться, где или имеет ли смысл вводить дополнительные переменные типа, но здесь одно возможное разложение:
class DoableImplFoo<A,B> implements Doable<Foo<A>,Foo<B>> {
public DoableImplFoo(SomePropertyOf<A,B> aAndBAreGoodEnough) { ... }
Foo<A> doIt(Foo<B> fooB) { ... }
}
Когда вы создаете экземпляры A до Bar<Baz,Qux> и B до Bar<Zot,Qux> позже, вы можете обнаружить, что снова есть какой-то шаблон, но он может быть меньше, чем вы Первоначально был.
6 ответов
Рассматривали ли вы вопрос №1 об использовании сервера состояний (даже SQL-сервера) или механизма общего кэша? Есть много из хороших , из которых можно выбрать , и Velocity становится очень зрелым - вероятно, скоро RTM. Схема аннулирования кеша, основанная на том, создает ли пользователь новый поиск, попадает ли на любую другую страницу, кроме разбивки на страницы, и, наконец, стандартный тайм-аут (20 минут) должен быть довольно успешным при очистке вашего кеша до минимального размера.
Ссылки:
Raising an idea under the "alternative" caching scheme. This doesn't answer your question with a given cache architecture, but rather goes back to your original requirements of your search application.
Even if/when you implement your own cache, it's effectiveness can be less than optimal -- especially as your search index grows in size. Cache hit rates will decrease as your index grows. At a certain inflection point, your search may actually slow down due to resources dedicated to both searching and caching.
Most search sub-systems implement their own internal caching architecture as a means of efficiency in operation. Solr, an open-source search system built on Lucene, maintains its own internal cache to provide for speedy operation. There are other search systems that would work for you, and they take similar strategies to results caching.
I would recommend you consider a separate search architecture if your search index warrants it, as caching in a free-text keyword search basis is a complex operation to effectively implement.
Поскольку вы говорите, любые идеи приветствуются:
Мы довольно успешно использовали кэширование корпоративной библиотеки для кэширования наборов результатов из результата LINQ.
http://msdn.microsoft.com/en-us/library/cc467894.aspx
Он поддерживает настраиваемые срок действия кеша, поэтому он должен поддерживать большинство ваших потребностей (с небольшим количеством настраиваемого кода). Он также имеет довольно много резервных хранилищ, включая зашифрованные резервные хранилища, если важна конфиденциальность поиска.
Он довольно полнофункциональный.
Я рекомендую комбинацию №1 и №3 :
- Кэшируйте результаты запроса на сервере.
- Сделайте результаты доступными как в виде полной страницы, так и в виде представления JSON.
- Кешируйте каждую страницу, динамически полученную на клиенте, но отправляйте ЗАПРОС каждый раз, когда страница изменяется.
- Используйте ETAG для аннулирования клиентского кэша.
Взгляните на SharedCache - он довольно просто делает 1/2 и отлично работает в системе с балансировкой нагрузки. Бесплатно, с открытым исходным кодом, и мы используем его около года без проблем.
Если вы можете подождать до марта 2010 г., .NET 4.0 поставляется с новым System.Caching.CacheProvider , который обещает множество реализаций (диск, память, SQL Сервер / Скорость, как упоминалось).
Здесь есть хорошее слайд-шоу технологии здесь . Тем не менее, это немного «катайся сам» или много на самом деле. Но, вероятно, будет много поставщиков закрытых и открытых исходных кодов, которые будут написаны для модели Provider, когда фреймворк будет выпущен.
По шести указанным вами пунктам возникает несколько вопросов
- Что содержится в результатах поиска ? Просто строковые данные или множество метаданных, связанных с каждым результатом?
- Насколько велик ваш набор? повторный поиск?
Сколько памяти вы бы использовали для хранения всего набора в ОЗУ? Или, по крайней мере, иметь кеш от 10 до 100 самых популярных поисковых запросов. Еще одна идея - быть умным и кешировать связанные поисковые запросы после первого поиска.
5-15 секунд для получения результата - это долгое время ожидания поиска, поэтому я предполагаю, что это что-то вроде поиска на сайте Expedia.com, где запрашиваются несколько источников, и возвращается много информации.
Исходя из моего ограниченного опыта, самая большая проблема с подходом к кэшированию только на стороне клиента - это Internet Explorer 6 или 7 . Я предпочитаю только сервер и HTML со всем набором результатов в кеше для разбиения на страницы, истекая через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.
Еще одна идея - быть умным и кешировать связанные поисковые запросы после первого поиска.5-15 секунд для получения результата - это долгое время ожидания поиска, поэтому я предполагаю, что это что-то вроде поиска на сайте Expedia.com, где запрашиваются несколько источников, и возвращается много информации.
Исходя из моего ограниченного опыта, самая большая проблема с подходом к кэшированию только на стороне клиента - это Internet Explorer 6 или 7 . Я предпочитаю только сервер и HTML со всем набором результатов в кеше для разбиения на страницы, истекая через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.
Еще одна идея - быть умным и кешировать связанные поисковые запросы после первого поиска.5-15 секунд для получения результата - это долгое время ожидания поиска, поэтому я предполагаю, что это что-то вроде поиска на сайте Expedia.com, где запрашиваются несколько источников, и возвращается много информации.
Исходя из моего ограниченного опыта, самая большая проблема с подходом к кэшированию только на стороне клиента - это Internet Explorer 6 или 7 . Я предпочитаю только сервер и HTML со всем набором результатов в кеше для разбиения на страницы, истекая через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.
Это что-то вроде поиска на сайте Expedia.com, при котором запрашиваются несколько источников и возвращается много информации.Исходя из моего ограниченного опыта, самая большая проблема с подходом к кэшированию только на стороне клиента - это Internet Explorer 6 или 7 . Я предпочитаю только сервер и HTML со всем набором результатов в кеше для разбиения на страницы, истекая через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.
Это что-то вроде поиска на сайте Expedia.com, при котором запрашиваются несколько источников и возвращается много информации.Исходя из моего ограниченного опыта, самая большая проблема с подходом к кэшированию только на стороне клиента - это Internet Explorer 6 или 7 . Я предпочитаю только сервер и HTML со всем набором результатов в кеше для разбиения на страницы, истекая через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.
истекает через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается. истекает через некоторый разумный период времени. Но вы, возможно, уже пробовали это и видели, как память сервера съедается.Обдумывая варианты, учтите, что ни один пользователь не хочет листать данные. Мы навязываем им это как артефакт попытки создания приложений поверх браузеров в HTML, которые по своей сути плохо масштабируются. Мы изобрели всевозможные хакерские приемы для подделки состояния приложения поверх этого, но это, по сути, сломанная модель.
Итак, пожалуйста, подумайте о реализации этого в качестве реального многофункционального клиента в Silverlight или Flash. Вы не превзойдете этот пользовательский опыт, а кэшировать данные намного большего размера просто, чем это практично на обычной веб-странице. В зависимости от ожидаемого поведения пользователя ваша общая пропускная способность может быть оптимизирована, поскольку при круговых обращениях к серверу будет получен только ограниченный набор данных вместо любых накладных расходов ASP.NET.