Еластичний пошук, кілька індексів проти одного індексу та типи для різних наборів даних?

У мене є додаток, розроблений за схемою MVC, і я хотів би індексувати зараз декілька його моделей, це означає, що кожна модель має різну структуру даних.

• Чи краще використовувати змішані індекси, по одному для кожної моделі, або тип у межах одного індексу для кожної моделі? Обидва способи також потребують іншого пошукового запиту, я думаю. Я тільки почав з цього.

• Чи існують відмінності між обома поняттями, якщо набір даних невеликий або величезний?

Я б протестував 2-е запитання сам, чи хтось міг би порекомендувати мені якісь хороші вибіркові дані для цієї мети.

Для обох підходів є різні наслідки.

Якщо припустити, що ви використовуєте налаштування за замовчуванням Elasticsearch, наявність 1 індексу для кожної моделі значно збільшить кількість ваших осколків, оскільки 1 індекс буде використовувати 5 черепків, 5 моделей даних використовуватимуть 25 фрагментів; маючи 5 типів об’єктів в 1 індексі, все ще буде використано 5 фрагментів.

Наслідки щодо використання кожної моделі даних як індексу:

• Ефективний та швидкий пошук у індексі, оскільки кількість даних має бути меншою у кожному фрагменті, оскільки вона розподіляється за різними індексами.
• Пошук комбінації моделей даних з 2 або більше індексів генеруватиме накладні витрати, оскільки запит доведеться надсилати більшій кількості фрагментів через індекси, складати та відправляти назад користувачеві.
• Не рекомендується, якщо ваш набір даних невеликий, оскільки ви будете мати більше місця для зберігання з кожним додатковим фрагментом, який створюється, а збільшення продуктивності незначне.
• Рекомендовано, якщо ваш набір даних великий і ваші запити потребують тривалого часу, оскільки спеціальні фрагменти зберігають ваші конкретні дані, і Elasticsearch буде легше обробляти.

Наслідки щодо використання кожної моделі даних як об'єктного типу в межах індексу:

• Більше даних буде збережено в межах 5 фрагментів індексу, а це означає, що при запиті в різних моделях даних буде менше проблем, але розмір вашого фрагмента буде значно більшим.
• Більше даних, що знаходяться в черепах, займе більше часу для пошуку Elasticsearch, оскільки є більше документів для фільтрації.
• Не рекомендується, якщо ви знаєте, що ви переглядаєте 1 терабайт даних і не поширюєте свої дані за різними індексами або кількома фрагментами у вашому відображенні Elasticsearch.
• Рекомендується для невеликих наборів даних, оскільки ви не витрачаєте місця на зберігання для граничного підвищення продуктивності, оскільки кожен фрагмент займає місце у вашому обладнанні.

Якщо ви запитуєте, що занадто багато даних порівняно з невеликими даними? Зазвичай це залежить від швидкості процесора та оперативної пам’яті вашого обладнання, кількості даних, які ви зберігаєте в межах кожної змінної у вашому відображенні для Elasticsearch та ваших вимог до запитів; використання багатьох аспектів у ваших запитах значно сповільнить час вашої відповіді. На це немає прямої відповіді, і вам доведеться орієнтуватися відповідно до своїх потреб.

Незважаючи на те, що відповідь Джонатана на той час була правильною, світ просунувся і зараз, здається, люди, які стоять за програмою ElasticSearch, мають довгостроковий план відмовитись від підтримки декількох типів:

Де ми хочемо дістатися: Ми хочемо видалити поняття типів з Elasticsearch, підтримуючи ще батьків / дитину.

Тож для нових проектів використання лише одного типу на індекс полегшить можливе оновлення до ElasticSearch 6.x.

Відповідь Джонатана чудова. Я хотів би лише додати декілька інших моментів для розгляду:

• кількість фрагментів може бути налаштована під обране вами рішення. У вас може бути один індекс з 15 первинними фрагментами або розділити його на 3 індекси на 5 осколків - перспектива продуктивності не зміниться (за умови, що дані розподіляються однаково)
• подумайте про використання даних. Тобто якщо ви використовуєте kibana для візуалізації, простіше включати / виключати конкретні індекси, але типи повинні бути відфільтровані на інформаційній панелі
• збереження даних: для журналу / метричних даних програми використовуйте різні індекси, якщо вам потрібен різний період збереження

Обидві наведені відповіді чудові!

Я додаю в індекс приклад кількох типів. Припустимо, ви розробляєте додаток для пошуку книг у бібліотеці. Власнику бібліотеки є кілька запитань,

Запитання:

1. Скільки книг ви плануєте зберігати?

2. Які книги ви збираєтеся зберігати в бібліотеці?

3. Як ти збираєшся шукати книги?

Відповіді:

1. Я планую зберігати книги від 50 до 70 книг (приблизно)

2. У мене будуть книги, пов’язані з технологіями 15 к -20 к (інформатика, машинобудування, хімічна інженерія тощо), 15 к історичні книги, 10 к книг з медичних наук. 10 к мовних книг (англійська, іспанська тощо)

3. Пошук за прізвищем авторів, прізвищем автора, роком видання, прізвищем видавця. (Це дає вам уявлення про те, яку інформацію слід зберігати в індексі)

З вищенаведених відповідей можна сказати, що схема в нашому індексі повинна виглядати приблизно так.

// Це не точне відображення, лише для прикладу

            "yearOfPublish":{
                "type": "integer"
            },
            "author":{
                "type": "object",
                "properties": {
                    "firstName":{
                        "type": "string"
                    },
                    "lastName":{
                        "type": "string"
                    }
                }
            },
            "publisherName":{
                "type": "string"
            }
        }

Для досягнення вищесказаного ми можемо створити один індекс під назвою Книги і може мати різні типи.

Покажчик: Книга

Види: Наука, Мистецтво

(Або ви можете створити багато типів, таких як технології, медичні науки, історія, мова, якщо у вас є набагато більше книг)

Тут важливо зазначити, що схема схожа, але дані не ідентичні. І інша важлива річ - це загальні дані, які ви зберігаєте.

Сподіваємось, що вищесказане допомагає, коли в індексі йти різні типи, якщо у вас є різні схеми, ви повинні врахувати інший індекс. Невеликий індекс для меншої кількості даних. великий індекс для великих даних :-)