/u/244992/crop5f76fde777756_cropped.png?f=community)
Ik ben op zoek wat de best practice is met betrekking tot het gebruik van indexes in Elasticsearch.
Situatie: Mysql database met daarin onder andere de volgende tabellen:
Optie 1:
Elke tabel krijgt een eigen index in Elasticsearch en wanneer bijvoorbeeld alle producten doorzocht moeten worden van een `company_id` zal dit toegevoegd moeten worden in de query voor Elasticsearch:
Optie 2:
Elke tabel krijgt in combinatie met de `company_id` een eigen index in Elasticsearch. Hierdoor hoeft er niet meer gefilterd te worden op de `company_id` in de query voor Elasticsearch:
Optie één heeft als voordeel dat onderhoud makkelijker zal zijn en is meer overzichtelijk. Optie twee heeft als voordeel dat er niet meer per query gefilterd hoeft te worden op de `company_id` en mijn gevoel zegt (dit heb ik nog niet getest) dat dit de performance ten goede komt. Echter heb ik mijn twijfels over het aantal indexes in Elasticsearch. Als er namelijk 1000 `company_id` zijn, dan zijn er een veelvoud indexes in Elasticsearch voor elke tabel in Mysql.
Ik heb hier en hier het een en ander gelezen, maar dit lijkt alweer achterhaalt te zijn.
Uiteraard begrijp ik dat dit af hangt van een hoop variabele zoals server capaciteit, nodes, etc. Maar wellicht dat iemand mij kan vertellen of optie één of twee überhaupt een goed idee is. En misschien dat er zelfs een optie drie is?
Situatie: Mysql database met daarin onder andere de volgende tabellen:
- products
- suppliers
- contacts
- customers
- orders
- ...
- ...
Optie 1:
Elke tabel krijgt een eigen index in Elasticsearch en wanneer bijvoorbeeld alle producten doorzocht moeten worden van een `company_id` zal dit toegevoegd moeten worden in de query voor Elasticsearch:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| GET products/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"description": "debitis natus debitis omnis"
}
}
],
"filter": [
{
"term": {
"company_id": "pdbywhyroa5hqs"
}
}
]
}
}
} |
Optie 2:
Elke tabel krijgt in combinatie met de `company_id` een eigen index in Elasticsearch. Hierdoor hoeft er niet meer gefilterd te worden op de `company_id` in de query voor Elasticsearch:
code:
1
2
3
4
5
6
7
8
| GET pdbywhyroa5hqs_products/_search
{
"query": {
"match": {
"description": "debitis natus debitis omnis"
}
}
} |
Optie één heeft als voordeel dat onderhoud makkelijker zal zijn en is meer overzichtelijk. Optie twee heeft als voordeel dat er niet meer per query gefilterd hoeft te worden op de `company_id` en mijn gevoel zegt (dit heb ik nog niet getest) dat dit de performance ten goede komt. Echter heb ik mijn twijfels over het aantal indexes in Elasticsearch. Als er namelijk 1000 `company_id` zijn, dan zijn er een veelvoud indexes in Elasticsearch voor elke tabel in Mysql.
Ik heb hier en hier het een en ander gelezen, maar dit lijkt alweer achterhaalt te zijn.
Uiteraard begrijp ik dat dit af hangt van een hoop variabele zoals server capaciteit, nodes, etc. Maar wellicht dat iemand mij kan vertellen of optie één of twee überhaupt een goed idee is. En misschien dat er zelfs een optie drie is?
/u/84769/crop5f8b3cbb73ded_cropped.png?f=community)
:strip_icc():strip_exif()/u/5964/crop56503163e97a5.jpeg?f=community)
:strip_icc():strip_exif()/u/6907/crop565ea06cc073d_cropped.jpeg?f=community)