Лучше ли хранить целые числа вместо полного текста?

Я пытаюсь собрать решение для отчетности с использованием ES. Поскольку мой опыт работы с ES довольно простой, я хотел бы знать, имеет ли значение значение, если я использую целые числа при фильтрации.Лучше ли хранить целые числа вместо полного текста?

Я знаю, каковы будут значения моих фильтров и что я не буду допускать полнотекстовый поиск.

Поэтому в моем запросе я могу либо иметь

{ 
    "filter" : { 
    "term" : { "gender" : 1 } 
}

или

{ 
    "filter" : { 
    "term" : { "gender" : "male" } 
}

Будет ли быстрее использовать целое число вместо строки поиска?

Кроме того, я полагаю, что с использованием целого числа было бы лучше для дискового пространства, не так ли?

И, наконец, мне просто лучше использовать MySQL в таком случае - где полнотекстовый поиск не требуется?

Большое спасибо заранее,
Angel

источник

2017-01-16 AngelP

Для фильтров это, скорее всего, чтобы сделать разницу нет. Однако следует иметь в виду, что во время агрегации поля значений, привязанные к doc (например, неаналитические), будут загружаться в карту памяти на куче, называемую глобальными ординалами. В зависимости от количества возможных значений (которые, по-видимому, для пола, по-видимому, очень малы), которые могут оказывать сильное давление на JVM.

Возможно, вы попытаетесь сопоставить это как булево поле, потенциально. Если бы вы это сделали, вы бы сэкономили немного места, или если бы вы отображали его как целое число. Но с точки зрения запросов, это должно иметь значение.

Что касается MySQL против ES, это сложнее и гораздо более тонкий вопрос. Это зависит от (помимо всего прочего) от того, что вы пытаетесь сделать, сколько данных вы работаете, и требуют ли вам транзакционных гарантий и/или MVCC. Оба MySQL и ES будут хорошо работать с таким фильтром (если вы добавите вторичный индекс по полу в MySQL ... который по сути будет B-Tree-версией отношения, отображаемого Lucene). Основываясь на информации, которую вы предоставили, на самом деле нет веской причины предпочесть один инструмент над другим. Вам нужно либо предоставить больше контекста, либо (возможно, даже лучше) дать ему выстрел в обоих и посмотреть, с кем вы счастливее.

Удачи.

источник

2017-01-16 15:32:32 evanv

Wow Спасибо за это! Я предполагаю, что в конце второго абзаца вы подразумеваете «это не должно иметь никакого значения»? В основном весь модуль отчетности, над которым я работаю, собирает тонны записей журнала из «озера данных», обрабатывает и подготавливает их для фильтрации. Идея состояла в том, чтобы обработанные журналы nginx/squid/etc сохранялись в их соответствующих таблицах в MySQL, но мы перешли в денормализованный вид ES-типа, где документ типа пользователя будет иметь пользовательские атрибуты, а затем массивы вложенные объекты для журналов nginx, журналов кальмаров и т. д. в минуту. Имеет ли это смысл? – AngelP

«Я предполагаю, что в конце второго абзаца вы подразумеваете« это не должно иметь значения »- вы правы, да. – evanv

Я бы склонялся к ES вместо MySQL на этом. Данные регистрации обычно не требуют долговечности и serializibaility гарантирует, и если вам нужно будет искать свои журналы, в ES будет намного проще сделать это. Кроме того, я предполагаю, что вы захотите закончить журналы через определенное время. В ES это очень просто справляться.В MySQL удаление данных из таблицы не восстанавливает дисковое пространство. Поэтому вам нужно периодически запускать таблицу оптимизации, чтобы вызвать уплотнение, которое блокирует вашу таблицу для записи во время ее запуска. Если вам не нужны гарантии, предоставленные MySQL, я бы, вероятно, использовал ES – evanv

Лучше ли хранить целые числа вместо полного текста?

ответ

Смежные вопросы