Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

02.02.2024

Масові операції в OpenSearch - практика

• Масове оновлення скриптом — може, не така вже й хороша ідея. Працює це повільно. Що таке повільно — поясню: припустимо при типовій роботі база отримує 1000 нових документів на хвилину. Логічно, що в такому разі ресурси нашої бази розраховані на таку швидкість індексації (плюс стільки, за скільки ми переплачуємо для резерву). З цього випливає, що масове оновлення буде відбуватися десь з такою самою швидкістю — теж 1000 документів на хвилину. На мільйон документів піде 17 годин. І це оптимістична оцінка, бо оновлення старих документів повільніше, ніж утворення або оновлення свіжих. Я б радив придумати, як уникнути оновлення та спиратися на дані, які вже є.

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

• З прозорістю в OpenSearch все складно. Зрозуміти, скільки залишилось трансформації, можна хіба за поточними результатами. А ще вона може зупинитись з помилкою. А дізнатись, що то була за помилка, можна тільки з журналу, бо ззовні видно тільки помилку “верхнього рівня”, типу “помилка трансформації” а в неї схована причина - “не вдалося виконати пошук”, а в неї першопричина - “запит має надто багато пунктів”. Все це можна побачити в журналі. А яке це має відношення до моєї трансформації (бо в ній запит не такий вже й складний!), та як виправити — то вже без форумів не розберешся.

• Одним словом, за зручністю та… “міцністю” до PostgreSQL тут далеко. І це такий момент БД, який я не часто чую в обговореннях — якщо до PostgreSQL майже завжди можна ставитись до бастіону надійності, де нічого непередбачуваного не відбудеться, то OpenSearch все ж тільки ще один сервіс, зі своїми багами та сюрпризами.