Кэширование против индексации
В чем реальная разница между решением для кэширования и решением для индексирования? Мне кажется, что решение для индексирования на самом деле кешируется с возможностью запуска поисковых запросов (например, Elastic Search). Будет ли когда-либо существенная причина использовать как решение для кэширования, так и решение для индексирования в одном и том же проекте, или же решение для индексирования делает любое другое кэширование избыточным?
Пример: скажем, я использую NEST для ElasticSearch, который будет хранить и возвращать POCO; если я затем запрашиваю ElasticSearch и мне возвращают POCO, разве это не считается использованием кэшированного объекта, возвращенного из ElasticSearch?
На данный момент я храню данные в кеше, используя интерфейс ICacheManager, который у меня есть... примерно так:
return CacheManager.Get(cacheKey, () =>
{
// return something...
});
Станет ли это излишним с ElasticSearch?
РЕДАКТИРОВАТЬ
Спасибо всем вам за ответы. Я полностью осведомлен о том, что такое кеш, и уже понял общую идею индекса для текстового поиска, поэтому мне было только интересно, будет ли индекс уже удваиваться как кеш и поэтому сделает любой другой кеш избыточным. В конце концов, я бы не хотел хранить в памяти 2 кэша (например, ElasticSearch + Redis), когда все будет хорошо. Я думаю, что теперь у меня есть идея получше; особенно когда я понял, что не все поля всегда хранятся в индексе, и поэтому нам нужно получить объект из кэша или напрямую из БД в любом случае - по крайней мере, в некоторых случаях. Спасибо всем!
3 ответа
Цель кеша - как можно быстрее вернуть уже запрошенные данные. Одно из ограничений кэшей заключается в том, что они также не могут быть слишком большими, так как время поиска увеличилось бы и, таким образом, отменило бы цель иметь кэш в первую очередь. При этом неудивительно, что если вы планируете иметь несколько миллионов / миллиардов записей в своей БД, вам не составит труда проиндексировать их все, но будет трудно их кэшировать, хотя, поскольку объем оперативной памяти увеличивается дешевле и дешевле, вы можете хранить все, что вам нужно в памяти. Вы также должны спросить себя, должен ли ваш кеш распределяться по нескольким хостам или нет (сейчас или в будущем).
Учитывая, что поиск и запросы в ES чрезвычайно быстры (в дополнение к этому ES даёт вам гораздо больше преимуществ, таких как скоринг), то есть обычно быстрее, чем извлечение тех же данных из вашей БД, имеет смысл использовать ES в качестве кеша, Одна проблема, которую я вижу, является распространенной, то есть, как только вы начинаете дублировать данные (DB -> ES), вы должны убедиться, что оба хранилища не синхронизируются.
Теперь, если, кроме того, вы добавите кеш в эту смесь, это будет третье хранилище данных, которое нужно поддерживать и которое будет соответствовать основному хранилищу данных. Если вы знаете, что ваши данные довольно стабильны, то есть записаны, а затем не часто обновляются, тогда это может быть хорошо, но вы должны помнить об этом все время при разработке стратегии доступа к данным.
Как сказал @paweloque, в конечном итоге все зависит от ваших конкретных вариантов использования. Все проблемы разные, и я могу засвидетельствовать, что после нескольких десятков проектов вокруг ES за последние пять лет я никогда не видел двух проектов, настроенных одинаково. Кеш может иметь смысл для некоторых конкретных случаев, но не для других.
Вы должны тщательно продумать, как и где вам нужно хранить ваши данные, кто запрашивает их (и с какой скоростью), кто создает / обновляет их (и с какой скоростью), но, в конце концов, наилучшей практикой является сохранение Ваш стек максимально компактен с минимальным количеством необходимых компонентов, каждый из которых является потенциальным узким местом, которое вы должны понимать, интегрировать, поддерживать, настраивать и отслеживать.
Наконец, я бы добавил еще одну вещь: добавление кеша или индекса должно рассматриваться как оптимизация производительности вашего программного стека. Как вы, наверное, знаете, распространенное высказывание "Преждевременная оптимизация - корень всех зол", вы должны сначала использовать только свою базу данных, измерить производительность, протестировать нагрузку, а затем убедиться, что она может не поддерживать нагрузку. Только тогда вы можете решить использовать кеш и / или индекс в зависимости от потребностей. Снова, загрузите тест, измерьте, затем решите. Если у вас есть только десять пользователей, делающих несколько запросов в день, вполне может быть достаточно иметь только БД. Вы должны понять, когда и почему вам нужно добавить еще один слой в вашу Вавилонскую башню, но самое главное, вам нужно добавлять один слой за раз и посмотреть, как этот слой улучшает / ухудшает стабильность стека.
Наконец, что не менее важно, вы можете найти некоторые онлайн-статьи от людей, которые использовали ES в качестве кэшей (в основном хранилища ключей и объектов и кэши объектов).
Ваш вопрос:
В. Какова реальная разница между решением для кэширования и решением для индексирования?
О. Простое отличие состоит в том, что кэш используется для хранения часто используемых данных, чтобы быстрее обслуживать одни и те же запросы. По сути, ваш кеш быстрее, чем ваш основной магазин, но меньше по размеру, поэтому данные, которые он может хранить (учитывая, что он будет дороже)
Индексирование производится по всем данным, чтобы сделать их поиск более быстрым. Простые Hashtable/HashMap имеют хеш-коды в качестве индексов, а в массиве 0 и 1 являются индексами.
Вы можете проиндексировать некоторые столбцы, чтобы искать их быстрее. Но кеш - это место, где вы хотели бы, чтобы ваши данные извлекали их быстрее. Обычно кэш-память - это оперативная память, а база данных - от жесткого диска
Кэш также обычно является хранилищем значений ключей, поэтому, если вы знаете ключ и извлекаете его из кэша, нет необходимости выполнять запрос. В NHibernate и EntityFrameworks кеши запросов подключаются с запросами в качестве ключей, а все данные кэшируются. Теперь ваши запросы будут извлекаться из кэша, а не запускаться через базу данных.
Интересный вопрос! Ну, вы могли бы на самом деле использовать эластичный поиск для реализации кэша. Он предоставляет некоторые функции, с помощью которых вы можете истечь документы, но я не уверен, хорошо ли они подходят для истечения срока действия кэша. Проблема в том, что эластичный поиск не предназначен для кэширования. Это сладкое место индексации и поиска документов.
Индексирование - это задача создания индекса, как это делается для книг: вы читаете весь текст и записываете, на какой странице были найдены слова. Это позволяет нам позже быстро находить позиции слов в тексте.
Elasticsearch предоставляет набор инструментов, который позволит вам определить, как индексировать и обрабатывать текст, то есть применять основы. Затем на следующем шаге он предоставит вам различные типы запросов для поиска ваших документов.
Вы можете, однако, записать документы в asticsearch и использовать идентификатор документа, чтобы прочитать его. Таким образом, вы можете использовать эластичный поиск в качестве хранилища, которое можно использовать в качестве кэша.