«Elasticsearch — ненадійна скотиняка», виснажливі контракти з Єврокомісією та мілтек-проєкт в гаражі

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

У восьмий випуск подкасту 1-2-3 Techno до нас завітав Всеволод Соловйов, CTO та co-founder Prophy Science. Він розповів про «надійність» Elasticsearch, роботу над проєктом для Збройних Сил України та співпрацю маленької компанії з бюрократичною Єврокомісією.

Гість — Всеволод Соловйов, CTO та Co-founder Prophy Science.
Ведучий — Саня Соловйов, Senior-розробник у Metabase, ex CTO Kasta.

👉 Підписуйтеся і слухайте нас на всіх платформах: iTunes, SoundCloud, Google Podcast, RSS.

У випуску обговорюємо:

00:00 Інтро
00:44 Prophy Science та Elasticsearch
44:25 Історія про фейл GitLab та партнерський блок
57:05 Miltech-проект
01:02:00 Контракти з Єврокомісією
01:34:00 Прощаємось

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

Теми: 1-2-3 techno, fail, Mobile, YouTube, АІ, відео, технології

Vadim Java Software Engineer 06.04.2024 19:18

Немного не понятно раскрыты проблемы эластика.

1. Название статьи — Эластик ненадежная скотина. Насколько я понял из разговора, когда поменяли машины на другие с ECC памятью, все стало работать норм. Так может это не Эластик скотина а старые инстансы?) В aws я тоже заметил что OpenSearch работает лучше с инстансами где есть свой SSD, а не EBS. Но это ж не делает эластик плохим. По ECC памяти, насколько я вычитал, ещё в 2013 у aws все было на ECC так как это необходимость. Никогда не работал с Hetzner, но это немного удивило.

2. По поводу пересоздания индекса. Эластик не транзакционная база, она не может быть source of truth. Возможность пересоздания индекса без даунтайма это там must have по моему) Скорость создания индекса часто можно оптимизировать — сделать меньше шарды, поиграться с parallelism/batch size и тд. По другому писать индексы чтоб вместо одного индекса на терабайт было несколько по годам или авторам.

3. Как это удалить весь шард? Сколько было реплик шарда, все реплики погибли что-ли которые были на разных инстансах?) Было ли настроено snapshot lifecycle policy?

4. Segments merging logic довольно неплохо работает. Оно старается держать количество marked as deleted документов до 30% и периодически их чистит полностью. Падение производительности я замечал когда несколько раз полностью перезаписываем 100% документов в эластике. В этой ситуации конечно раз в неделю пересоздаем индекс заново. Все это без даунтайма, просто переключаем алиас на новый индекс. Этот индекс специально разделён на два (hot и cold) и пересоздание занимает 30 мин.

5. По добавлению инстансов в кластер. Всегда можно сделать blue-green деплой и просто покопировать шарды в новый кластер) Так может даже правильнее с прод релизом где постоянно большая нагрузка.

6. Честно говоря, так и не понятно почему переезжают на Vespa. Всеволод сказал что последние 2 года все работает норм на эластике. Александр сказал что пока не делал полноценные прод тесты с Vespa. Отсутствие шардов в Vespa это ж может быть и минус. Если например в индексе эластика 2 миллиарда документов и 20 шардов, там можно заюзать роутинг который пойдёт в конкретный шард и не будет искать среди 2 миллиардов доков. Я про Vespa ниче не знаю, но интересно как это реализовано там)

Было бы очень интересно послушать про ваши прод use cases где Vespa работает лучше. Время поиска для разных типов кверей, cpu/memory utilization дата нод, время индексирования, падение производительности при увеличении updated documents. Не у конечно для полноты картины, было б цікаво добавить деталей про текущий эластик — размер индексов, количество шардов и документов и тд) Так было бы больше понятно почему эластик все-таки скотина)

Відповісти

Підтримати

Denys Developer в Plarium 06.04.2024 19:26

Эти 2 брата судя по всему документацию не читают

Vadim

Vsevolod Solovyov Reinforced Software Gardener 08.04.2024 10:14

1. Назву для випуску вибираю не я, нічого сказати не можу. У Хецнера серваки є з ECC, є без, як бажаєш. Це bare metal, в їхньому клауді все ECC.

2. Це ж не логи, мені індекси по рокам не допоможуть. Більшість запитів на пошук йде без обмеження на роки, а якщо вони і є — то це типу «останні 10-15 років». Наскільки зручно працювати, коли треба один запит слати в кілька індексів, і потім об’єднувати результати? Це точно не той шлях, який я буду розглядати першим, другим чи п’ятим. По авторам шардити неможливо, у наукової статті не один автор. Можуть бути і сотні, і тисячі.

3. Якщо чесно, я не пам’ятаю точно, який саме API виклик тоді допоміг. Я зараз полистав їх API хвилин п’ятнадцать, і можливо це був неочікуваний результат викликів cluster reroute. Три копії даних. Поки листав доки, згадав, що деякі репліки шардів випадали в UNASSIGNED, і можливо це була комбінація випадіння в unassigned і того, що одна з «живих» копій згнила? Супер-детального постмортему з усіма деталями на початку війни не робив, вибачайте. Lifecycle policy не було.

4. Так, звісно, перестворення нового індексу це переключення аліасу без даунтайму. Для основного індексу я навіть з БД всі свої дані не витягну за півгодини, вже не кажучи про те, щоб будь-який індекс встиг за цей час побудуватись, заздрю вашим півгодинам.

6. Взагалі не планував нічого про Веспу казати, тут веселих історій немає. Переїжджаємо по причинам, які не пов’язані з надійністю чи операційною складністю еластіка. У веспи дуже класна підтримка векторних полів, запитів, комбінація цього зі звичайним full-text пошуком, фільтрами, тощо. Це важливо для мого продукту, дозволяє зручно зробити те, що іншими способами незручно, дає калічні результати, або дуже довго працює. У восьмому еластіку теж з’явилась базова підтримка векторів, але порівняно з веспою воно прям еххх. Всі інші речі — приємні бонуси.

Про роутинг, який не буде ходити в інші шарди — як я вже сказав, це не мій випадок, тому не цікавився, чи є у веспи схожа функціональність.

7. У мене є наполовину написаний пост про те, як ми переїжджаємо з еластіка на веспу, але не схоже, щоб я його дописав найближчим часом. Розмір основного індексу (статті) в еластіку десять терабайт, 165 мільйонів документів (з копіями та оверхедом видалених — 620 млн).

Vadim Java Software Engineer 08.04.2024 10:57

Спасибо за Ваш ответ

2. Можно слать один запрос сразу в несколько индексов — www.elastic.co/...rch-multiple-indices.html
Или msearch если запросы разные: www.elastic.co/.../search-multi-search.html
У нас тоже много запросов без нормального фильтра по годам. Для этого есть отдельный индекс с метадатой куда мы идем сначала чтоб понять какие года надо кверить, какой роутинг и тд.

3. Мда тут конечно не понятно) Но мне кажется снова-таки из-за железа. У меня такое было при апдейте версии OpenSearch, у них был баг что миграция некоторых типов полей не работала. Пришлось создавать кластер с нуля.

4. То есть чтоб пересоздать индекс эластика, всю инфу для него надо вытянуть сначала из какой-то другой базы и нагружать прод? Можно ж хранить все в avro или parquet.

6. По векторам согласен, нам пришлось использовать Neptune как графовую базу данных для другого use-case, эластик не совсем для этого. Если Vespa умеет хорошо делать и то и другое — это гуд)

7. Выходит 65kb на один документ, еще и compressed наверно, большие статьи) Ждем топик про миграцию и удачного переезда.

Vsevolod Solovyov

Vsevolod Solovyov Reinforced Software Gardener 08.04.2024 11:33

2. Прикольно. Яку це проблему може вирішувати в моєму випадку? Можливість перестворювати індекс не за один ривок, а умовно за десять, чи ще щось?

4. Я люблю щоб було поменше рухомих частин, а не побільше. Створювати якесь проміжне сховище даних... І тепер його треба підтримувати у завжди актуальному стані. Хочеш щось поміняти, додати якесь поле — складність процесу збільшилась, затримка в реалізації збільшилась.