Якщо новий документ індексується за індексом Elasticsearch, то він доступний для пошуку приблизно 1 секунду після роботи з індексом. Однак його можна змусити зробити цей документ доступним для негайного пошуку за допомогою виклику _flushабо _refreshроботи з індексом. У чому різниця між цими двома операціями - результат, здається, однаковий для них, документ можна відразу шукати.
Що саме робить кожна з цих операцій?
Документація ES не здається глибоко вирішити цю проблему.
Відповіді:
Відповідь, яку ви отримали, є правильною, але я думаю, що варто трохи детальніше обговорити її.
Оновлення ефективно викликає повторне відкриття зчитувача індексу люцену, завдяки чому моментальний знімок даних, за яким ви можете шукати, оновлюється. Ця особливість люцену є частиною люцену поблизу api в режимі реального часу.
Elasticsearch оновлення робить ваші документи доступні для пошуку, але не переконаєтеся , що вони будуть записані на диск в постійному сховищі, так як він не викликає FSYNC, таким чином , не гарантує довговічність. Що робить ваші дані довговічними - це фіксація люцену, яка є набагато дорожчою.
Незважаючи на те, що ви можете зателефонувати люцену повторно відкриватися щосекунди, ви не можете зробити те ж саме при фіксації люцену.
Потім через люцені ви можете отримати доступні нові документи для пошуку майже в режимі реального часу, досить часто відкриваючи дзвінки, але вам все одно потрібно зателефонувати коміту, щоб переконатися, що дані записуються на диск та синхронізуються, таким чином, безпечно.
Elasticsearch вирішує цю "проблему", додаючи журнал транзакцій на осколок (фактично індекс люцену), де зберігаються операції запису, які ще не були здійснені. Журнал транзакцій є синхронізованим та безпечним, таким чином Ви отримуєте довговічність у будь-який момент часу, навіть для документів, які ще не були скоєні. Ви можете шукати документи майже в режимі реального часу, оскільки оновлення відбувається автоматично щосекунди, і ви також можете бути впевнені, що якщо трапиться щось погане, журнал транзакцій можна буде відтворити, щоб відновити втрачені документи. Приємна річ журналу транзакцій полягає в тому, що його можна використовувати внутрішньо для інших речей, наприклад, для забезпечення отримання в режимі реального часу за допомогою ідентифікатора .
Elasticsearch врівень ефективно викликає Lucene фіксацію, і порожніє також журнал транзакцій, так як тільки дані відбувається на рівні Lucene, довговічність може бути гарантована самою Lucene. Флеш також виставляється як api, і його можна налаштувати, хоча зазвичай це не потрібно. Промивання відбувається автоматично залежно від того, скільки операцій додається до журналу транзакцій, наскільки вони великі та коли відбулося останнє змивання.
Оновлення спричиняє запис нового сегмента, тому він стає доступним для пошуку.
Флеш спричиняє фіксацію люцену. Це набагато дорожче.
Для більш докладної інформації я написав статтю, яка висвітлює дещо з цього: Elasticsearch знизу вгору :)
Оновити :
Флеш :
Сегмент входить до складу люцену. Незмінні сегменти роблять кеші сторінок ОС завжди чистими.
Translog є частиною Elasticsearch. Translog націлений на довговічність.
Довідково:
_flushта / або,_refreshа потім викликаю_countapi, щоб порівняти кількість документів у старому та новому, очікуючи, що вони будуть рівними. Але це не так. Мені доводиться викликати ці API в циклі багато разів (з паузою в 1 секунду в кінці кожної ітерації), поки elasticsearch нарешті не отримає правильний підрахунок документів. Чи є спосіб викликати якийсь API і підтвердити, що підрахунок документів є точним?