From bcd694f556edf745ee485f776beb33f0e4a85b6b Mon Sep 17 00:00:00 2001 From: Rimian Perkins Date: Wed, 30 Dec 2020 10:13:07 +1100 Subject: [PATCH] typo! --- 004-cluster-design/004-cluster-design.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/004-cluster-design/004-cluster-design.md b/004-cluster-design/004-cluster-design.md index 5381e91..32abe35 100644 --- a/004-cluster-design/004-cluster-design.md +++ b/004-cluster-design/004-cluster-design.md @@ -35,7 +35,7 @@ There's another basic concept that's often poorly understood. There's 2 things about elasticity when you design your cluster. -The first one is horizontal scaling. You can build a cluster with virtually an infinity of hosts, depending on your needs and the bottleneck you face. Sometimes, running your dataset on a lot of small machines will provide bette performances than using a few large hosts. Sometimes, running on medium hosts with lots of disks is better. And sometimes, you'll need gonzo CPU but storage and memory won't be a problem. +The first one is horizontal scaling. You can build a cluster with virtually an infinity of hosts, depending on your needs and the bottleneck you face. Sometimes, running your dataset on a lot of small machines will provide better performances than using a few large hosts. Sometimes, running on medium hosts with lots of disks is better. And sometimes, you'll need gonzo CPU but storage and memory won't be a problem. The other one is index sharding. Elasticsearch divides indexes in physical spaces called shards. They allow you to easily split the data between hosts, but there's a drawback as the number of shards is defined at index creation. Elasticsearch default is 5 shards per index, but only your workload will help you to define the right number of shards. Thankfully, there's a way to scale existing indexes in production using reindexing and index aliases.