Накладные расходы на реку?

Question

Я новичок в поиске elasticsearch, но не знаю, как думать о дисковой памяти & Использование памяти при создании речки (река mysql в моем случае).

Что такое накладные расходы, связанные с рекой ?; особенно касается дискового пространства & использование памяти?This has been asked но не ответил.

Другими словами, предположим, что у меня есть таблица с тремя столбцами: primary_key (integer), url (varchar) и document_text (текст). Кроме того, предположим, что я в настоящее время выполняю полнотекстовый поиск 100% в mysql (глупо, я знаю, но только для аргументов). Каждый из трех столбцов имеет индекс на нем, а индекс document_text - полнотекстовый индекс. Это очень большая таблица, и я хочу свести к минимуму дубликаты данных.

Как я могу думать о том, что происходит с рекой mysql? С рекой я бы просто удалил полный текст индекс из столбца «document_text» & переместил его в elasticsearch (вместе с primary_key из mysql)? Elasticsearch не нужно индексировать «url», так как мы не ищем этого, правильно? Данные для document_text хранятся в mysql, но индекс хранится в elasticsearch, так что эффективно используется нулевое увеличение используемого дискового пространства?

EDIT:

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

Answer 1

Elasticsearch по умолчанию создает поле с именем «_source», которое содержит все исходные данные в формате json, которые были отправлены для индексирования. Это где данные документа будут получены с при запросе Elasticsearch:

_source

Поле _source это автоматически генерируемое поле, которое хранит фактический JSON , который был использован в качестве индексированного документа. Он не индексируется (доступен для поиска), просто сохраняется. При выполнении запросов «выборки», например, получить или выполнить поиск, поле _source возвращается по умолчанию.

Хотя очень удобно иметь место, поле источника несут хранение служебные данные внутри индекса. По этой причине его можно отключить.

http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/mapping-source-field.html

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

Мне нужно узнать больше о вашем конкретном случае использования, чтобы узнать, следует ли удалить полный текстовый индекс в mysql или нет, но в целом основная причина использования Elasticearch mysql River - облегчить поиск текста, поэтому почему оба?

Две другие мысли для вас. Во-первых, кроме тестирования и разработки, я бы не стал запускать ES на том же сервере, что и MySQL, - они будут конкурировать друг с другом за процессор, дисковое пространство и, в особенности, память и наличие на одном и том же сервере, намного сложнее их настроить ,Во-вторых, независимо от того, что вы делаете, вы занимаете значительное пространство, если индексируете большой набор документов. Вы можете ограничить это, играя в поле _source, но в конце индекс ES должен индексировать каждый токен и его местоположение - это не столько, сколько хранить полный документ, но он занимает нетривиальное пространство. Насколько это будет зависеть от ваших документов - вам нужно будет запустить индексирование теста с вашими конкретными настройками (типами полей, цепочками анализа и разумным образцом данных), чтобы пригводить грубый дисковый режим.