Gerçek bir örnekle açıklamaya çalışacağım, çünkü aldığınız cevap ve cevaplar size yardımcı görünmüyor.
Elasticsearch'ü indirip başlattığınızda, varsa mevcut bir kümeye katılmaya çalışan veya yeni bir küme oluşturan bir elasticsearch düğümü oluşturursunuz. Diyelim ki yeni başladığınız tek bir düğmeyle kendi yeni kümenizi oluşturdunuz. Verimiz yok, bu nedenle bir dizin oluşturmamız gerekiyor.
Bir indeks oluşturduğunuzda (ilk dokümanı da indekslediğinizde otomatik olarak bir indeks oluşturulur) kaç kırıktan oluşacağını tanımlayabilirsiniz. Bir sayı belirtmezseniz, varsayılan parça sayısı: 5 primer olacaktır. Bunun anlamı ne?
Bu, elasticsearch'in verilerinizi içerecek 5 birincil parça oluşturacağı anlamına gelir:
____ ____ ____ ____ ____
| 1 | | 2 | | 3 | | 4 | | 5 |
|____| |____| |____| |____| |____|
Bir dokümanı her indekslediğinizde, elasticsearch, hangi birincil kırığın o dokümanı tutması gerektiğine karar verir ve orada dizine ekler. Birincil parçalar verilerin bir kopyası değildir, verilerdir! Birden fazla parçaya sahip olmak, tek bir makinede paralel işlemeden yararlanmaya yardımcı olur, ancak asıl mesele, aynı kümede başka bir elasticsearch örneği başlatırsak, parçaların küme üzerinde eşit bir şekilde dağıtılacağıdır.
Düğüm 1 daha sonra örneğin sadece üç parça tutacaktır:
____ ____ ____
| 1 | | 2 | | 3 |
|____| |____| |____|
Kalan iki kırık yeni başlayan düğüme taşındığından:
____ ____
| 4 | | 5 |
|____| |____|
Bu neden oluyor? Elasticsearch dağıtılmış bir arama motoru olduğundan ve büyük miktarda veriyi yönetmek için birden fazla düğüm / makineden yararlanabilirsiniz.
Her elasticsearch indeksi, verilerin saklandığı yer olduğu için en az bir birincil parçadan oluşur. Bununla birlikte, her parça bir maliyete sahiptir, bu nedenle tek bir düğümünüz varsa ve öngörülebilir bir büyümeniz yoksa, tek bir birincil parçaya sadık kalın.
Başka bir kırık türü de bir kopyadır. Varsayılan 1'dir, yani her birincil parça aynı verileri içeren başka bir parçaya kopyalanır. Çoğaltmalar arama performansını artırmak ve başarısızlık için kullanılır. Bir çoğaltma parçası hiçbir zaman ilgili birincilin bulunduğu düğümde tahsis edilmeyecektir (orijinal verilerle aynı diske yedek koymak gibi bir şey olacaktır).
Örneğimize geri dönelim, 1 çoğaltma ile her düğümde tüm dizine sahip olacağız, çünkü ilk düğümde 2 çoğaltma parçası ayrılacak ve ikinci düğümdeki birincil parçalarla tamamen aynı verileri içereceklerdir:
____ ____ ____ ____ ____
| 1 | | 2 | | 3 | | 4R | | 5R |
|____| |____| |____| |____| |____|
Birinci düğümdeki birincil kırıkların bir kopyasını içerecek olan ikinci düğüm için aynı:
____ ____ ____ ____ ____
| 1R | | 2R | | 3R | | 4 | | 5 |
|____| |____| |____| |____| |____|
Bunun gibi bir kurulumla, bir düğüm aşağı inerse, tüm dizine sahip olursunuz. Çoğaltma parçaları otomatik olarak primer olur ve düğüm başarısızlığına rağmen küme düzgün şekilde çalışır:
____ ____ ____ ____ ____
| 1 | | 2 | | 3 | | 4 | | 5 |
|____| |____| |____| |____| |____|
Sahip olduğunuzdan "number_of_replicas":1, kopyalar hiçbir zaman birincil öğelerinin bulunduğu düğümde ayrılmadığından atanamaz. Eğer 5 atanmamış kırıkları, kopyaları gerekecek ve küme durumu olacak yüzden YELLOWyerine GREEN. Veri kaybı yok, ancak bazı parçalar atanamayacağı için daha iyi olabilir.
Kalan düğüm yedeklendiğinde, kümeye tekrar katılacak ve kopyalar yeniden atanacaktır. İkinci düğümdeki varolan kırık yüklenebilir, ancak düğüm çalışmıyorken yazma işlemleri büyük olasılıkla gerçekleştiği için diğer kırıklarla eşitlenmeleri gerekir. Bu işlemin sonunda, küme durumu olur GREEN.
Umarım bu sizin için bir şeyleri açıklığa kavuşturur.
