Индексирование кэширование против

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

пример: скажем, я использую NEST для ElasticSearch, который будет хранить и возвращать POCOs; если я затем запрошу ElasticSearch и верну мне POCO, разве это не считается использованием кэшированного объекта, возвращенного из ElasticSearch?

на данный момент я храню данные в кэше, используя интерфейс ICacheManager, который у меня есть.. что-то вроде этого:--2--> 

return CacheManager.Get(cacheKey, () =>
{
    // return something...
});

станет ли это избыточным с помощью ElasticSearch?

редактировать

спасибо всем вам за ответы. Я полностью осознаю, что такое кэш и уже понял общая идея индекса для текстового поиска, поэтому мне было только интересно, удваивается ли индекс как кэш уже и, следовательно, сделает любой другой кэш избыточным. В конце концов, я не хотел бы хранить 2 кэша в памяти (пример: ElasticSearch + Redis), когда один будет делать все хорошо. Я думаю, что теперь у меня есть лучшая идея; особенно когда я понял, что не все поля всегда хранятся в индексе, и поэтому нам нужно получить объект из кэша или прямо из БД в любом случае - по крайней мере в некоторых случаях. Спасибо всем!

11
caching elasticsearch indexing

3 ответов

вся цель кэша-вернуть уже запрошенные данные как можно быстрее. Одним из ограничений кэшей является то, что они не могут быть слишком большими, так как время поиска увеличится и, таким образом, победит цель иметь кэш в первую очередь. Тем не менее, неудивительно, что если вы планируете иметь несколько миллионов / миллиардов записей в своей БД, будет не сложно индексировать их все, но будет трудно кэшировать их все, хотя, поскольку ОЗУ получает дешевле и дешевле, вы сможете хранить все необходимое в памяти. Вам также нужно спросить себя, Должен ли ваш кэш быть распределен по нескольким хостам или нет (сейчас или в будущем).

учитывая, что поиск и запросы в ES чрезвычайно быстры (+ES приносит вам гораздо больше преимуществ в дополнение к этому, например, оценка), т. е. обычно быстрее, чем получение тех же данных из вашей БД, было бы целесообразно использовать ES в качестве кэша. Одна проблема, которую я вижу, является общей, т. е. как только вы начнете дублировать данные (DB -> ES), вам нужно убедиться, что оба магазина не выходят из синхронизации.

теперь, если в дополнение вы бросаете кэш в эту смесь, это третье хранилище данных для обслуживания и обеспечения соответствия с основным хранилищем данных. Если вы знаете, что ваши данные довольно стабильны, то есть написаны, а затем не обновляются часто, тогда это может быть нормально, но вам нужно постоянно помнить об этом при разработке вашего доступа к данным стратегия.

как сказал @paweloque, в конце концов все зависит от вашего точного варианта использования. Каждая проблема отличается, и я могу засвидетельствовать, что после нескольких десятков проектов вокруг ES за последние пять лет или около того я никогда не видел два проекта, настроенных одинаково. Кэш может иметь смысл для некоторых конкретных случаев, но не для всех остальных.

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

наконец, я бы добавил еще одну вещь: добавление кэша или индекса следует рассматривать как оптимизацию производительности вашего программного стека. Как вы, наверное, знаете поговорку "преждевременная оптимизация-это корень все зло", вы должны сначала пойти только с вашей базой данных, измерить производительность, проверить ее, а затем засвидетельствовать, что она может не поддерживать нагрузку. Только тогда вы можете решить бросить на него кэш и / или индекс в зависимости от потребностей. Опять же, нагрузочный тест, измерение, а затем решить. Если у вас есть только десять пользователей, делающих несколько запросов в день,наличие только БД может быть прекрасно. Вы должны понять, когда и почему нужно добавить еще один слой на Вавилонскую башню, но самое главное вы необходимо добавить один слой за раз и посмотреть, как этот слой улучшает/ухудшает стабильность стека.

и последнее, но не менее важное: вы можете найти некоторые онлайн-статьи от людей, которые использовали ES в качестве кэшей (в основном

12

Ваш вопрос:

Q. В чем реальная разница между решением кэширования и решением индексирования?

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

индексирование производится на всех данных, чтобы сделать это поиск быстрее. Простая хэш-таблица/HashMap имеют хэш-индексы, а в массиве 0s и 1s являются индексами.

вы можете индексировать некоторые столбцы, чтобы найти их быстрее. Но кэш-это место, где вы хотели бы иметь свои данные, чтобы получить их быстрее. Обычно кэш-это ОЗУ, а база данных - с жесткого диска

кэш также обычно является хранилищем значений ключей, поэтому, если вы знаете ключ, то извлеките его из кэша, не нужно запускать запрос. В NHibernate и EntityFrameworks запрос кэши подключаются с запросами в качестве ключей, и все данные кэшируются. Теперь ваши запросы будут извлекаться из кэша вместо того, чтобы запускать его через базу данных.

5

интересный вопрос! Ну, вы можете на самом деле использовать elasticsearch для реализации кэша. Он предоставляет некоторые функции с witch вы можете истекать документы, но я не уверен, что они хорошо подходят для истечения срока действия кэша. Проблема в том, что elasticsearch не построен, чтобы быть решением кэширования. Это сладкое пятно-индексирование и поиск документов.

индексирование-это задача построения индекса, как это делается для книг: вы читаете весь текст и записываете, на какой странице слова были найдены. Это позволяет нам в дальнейшем очень быстро находить позиции слов в тексте.

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

однако вы можете записывать документы в elasticsearch и использовать идентификатор документа для его чтения. Например, вы можете использовать elasticsearch в качестве магазина который может использоваться как кэш.

1