Hogyan válasszuk meg az Elasticsearch shard- és replikaszámát?

Question

IT Interview Practice · Accepted Answer

A primary shardokkal adatot és munkát osztunk szét; a replikákkal további másolatot és keresési kapacitást biztosítunk. Univerzális shardszám helyett a munkaterhelésből és helyreállítási igényből induljunk.

## Számoljunk első becslést

Tegyük fel, hogy a primary indexadat 120 GB, és a teszt szerint körülbelül 30 GB primary shardonként megfelelő a terheléshez:

```text
120 GB / 30 GB = 4 primary shards
1 replica per primary = 4 additional shard copies
Total = 8 shard copies, roughly 240 GB of shard data
```

Ezek feltételezett méretezési adatok. A tárhelybecslés nem tartalmazza a növekedést és a működési munkaterületet, például az indexfájlokat háttérben egyesítő segment merge helyigényét.

## Miért ne adjunk hozzá mindig több shardot?

Több shard szétoszthatja a munkát a node-ok között, de mindegyik kezelési többletet jelent, és a keresések több helyre ágazhatnak szét. Nagyobb shardok csökkentik ezt a költséget, de helyreállításuk vagy mozgatásuk tovább tarthat. A replikák redundanciát, de tárhely- és írási munkát is adnak; nem biztonsági mentések.

## A hibás esetet is teszteljük

Mérjük együtt a csúcs olvasást és írást, majd egy node elvesztését is teszteljük. A megmaradt node-oknak elég lemez, memória és számítási kapacitás kell a célidőn belüli helyreálláshoz. Növekvő időalapú adatnál a rollover egy választott feltétel elérésekor új indexet hoz létre, így segít korlátozni a méretet. Ezek a döntések felhasználó által kezelt shardbeállítású környezetekre vonatkoznak.

[Hivatalos dokumentáció](https://www.elastic.co/docs/deploy-manage/production-guidance/optimize-performance/size-shards).

Számoljunk első becslést

Miért ne adjunk hozzá mindig több shardot?

A hibás esetet is teszteljük

Kapcsolódó kérdések