Я присоединился к новой компании, где я наблюдал приведенный ниже вариант использования.
Вариант использования: - Таблица содержит около 500 ГБ данных.Данные - это события действий пользователя для каждого действия пользователя.Цель состоит в том, чтобы проанализировать счет активности для различных перестановок и комбинаций для любого заданного диапазона дат.Таким образом, данные дополнительно поступают в эластичный (и lucene в другом аналогичном сценарии использования).
Насколько я понимаю, для такого сценария DB достаточно сам по себе. Но когда я пытаюсь запросить DB для конкретной перестановкии комбинация для данного диапазона данных чертовски медленная и большую часть времени получает тайм-ауты.
Но когда я получаю ту же комбинацию с упругой (или люценовой), она намного быстрее.Здесь не требуется поддержка полнотекстового поиска.
Не уверен, что вызывает эластичность (или lucene) намного быстрее, чем БД на основе SQL, даже для обычного (не полнотекстового) поиска?
что может быть вероятной причиной того же?Я могу подумать о двух причинах здесь
- Elastic (или lucene) хранит данные в сжатом виде.Так может быть, поиск здесь быстрее?
- Elastic может помочь достичь параллелизма с данными, хранящимися в нескольких сегментах по умолчанию.Но в люцене я даже не вижу параллелизма.