Elasticsearch®, milyarlarca belgeyi kabul eden ve indeksleyen, arama, toplama ve analizler için neredeyse gerçek zamanlı olarak kullanılabilir hale getiren çok güçlü ve esnek bir dağıtılmış veri sistemidir. Bu makale, temel yeni veri girişlerine ve istekten diske kadar veri akışına odaklanarak bunun nasıl yapıldığıyla ilgilidir.
Dizin oluşturma, aşağıdakilerden oluşan nispeten basit bir üst düzey süreçtir:
Adımlara daha detaylı bakalım.
Elasticsearch, ilk olarak İndeks API'leri aracılığıyla geldiğinde dizine eklenecek gelen verileri öğrenir. Logstash, Beats ve hatta cURL gibi istemciler, işlenmek üzere kümenin düğümlerine veri gönderir. Her seferinde bir belge gönderebilirler, ancak genellikle daha az ek yük ve daha hızlı işlem için verileri toplu olarak göndermek için toplu API'yi kullanırlar. Yığınlar, yalnızca bir API çağrısında gönderilen belge gruplarıdır ve birbirleriyle ilişkili olmaları gerekmez, yani birkaç farklı dizine yönelik verileri içerebilirler.
Verileri alma verileri herhangi bir düğüme gönderilebilir, ancak daha büyük kümeler genellikle özel koordinasyon düğümleri (beslemeden çok arama için) veya hatta verileri önceden işlemek için veri ardışık düzenlerini çalıştırabilen özel veri alma düğümleri kullanır. Verinin ulaştığı düğüm ne olursa olsun, bu parti için koordinasyon düğümü olacaktır ve asıl alım işi hedef indeks verilerini tutan veri düğümlerinde yürütülse bile verileri doğru yere yönlendirecektir.
Veriler genellikle tek bir normal dizin için gelir, ancak bir veri akışına ve / veya bir besleme hattına da yönlendirilebilir. Veri akışları, çoğunlukla ölçümler ve günlükler gibi zaman serisi verilerini işlemek için yaygın olarak kullanılan bir X-Pack özelliğidir ve esasen bu alım işlemi için gerçek bir destek indeksine çözümlenir. Ardışık düzenler, belge verilerini dizinlenmeden önce işlemek için kullanılan bir işlemci koleksiyonudur.
İstek veya toplu işlem bir ardışık düzen içeriyorsa ve koordinasyon düğümü aynı zamanda bir besleme düğümü değilse, önce bir besleme düğümüne yönlendirilecek, ardından birincil düğüme gidecek gibi görünür. Koordinatörün veya besleme düğümünün onu birincil düğüme gönderip göndermediği açık değildir, ancak muhtemelen koordinasyon düğümü, yani alım düğümü boru hatlarını çalıştırır ve ardından belgeyi bir sonraki adım için koordinatör düğüme geri gönderir.
Veriler bir koordinasyon düğümüne ulaştığında, her belge besleme için doğru dizine, parçaya ve düğümlere yönlendirilmelidir. Bir toplu istek birçok dizin için veri içerebileceğinden ve tek bir dizin için birden çok belge ayrı parçalara gidebileceğinden, yönlendirme adımı belge başına çalıştırılır ve her birini doğru yere getirmek için çok önemlidir. Bu süreç "Koordinasyon Aşaması" nı başlatır.
Her belge için ilk adım, koordinasyonun belgenin gideceği gerçek hedef dizini belirlemek için sağlanan dizin, diğer ad, veri akışı vb. Dizin yoksa, oluşturulur ve ardından işlem devam edebilir. Elasticsearch'ün, herhangi bir indeksleme yapmadan önce toplu talebin ihtiyaç duyduğu tüm indeksleri oluşturmaya çalıştığını unutmayın.
Koordinasyon düğümü hedef dizini öğrendikten sonra, belge için dizinin parçasını seçmek için bir yönlendirme işlemi yürütür. Yönlendirme karmaşık olabilir ve varsayılan olarak, koordinasyon düğümü tarafından otomatik olarak oluşturulan belge kimliği tarafından yönlendirilir.
İsterseniz, istemciler kendi kimliklerini belirleyebilir ve aynı zamanda ilgili (ve hızlı bir şekilde sorgulanabilir) verileri tek bir kırıkta birlikte bulmak için kümeleme stratejileri olarak zaman damgaları, kullanıcılar, kaynak cihazlar vb. Yönlendirme için hangi alanın kullanıldığını kontrol edebilir. . Ek olarak, dizinler, belgeleri belirli parçalara zorlayan özel yönlendirmeye sahip olabilir. Ancak genel olarak her belge, hedef dizininin parçaları arasında rastgele dağıtılır.
Yönlendirme işleminin sonucu, hedef parça ve parça kimliği olacaktır, ancak parçanın kopyaları olabileceğini unutmamalıyız. Çoğaltmalar varsa, koordinasyon düğümü bunları da yönlendirme listesine dahil eder, dolayısıyla sonuç bu belgenin tüm parçalarının bir listesidir: birincil parça ve eşlemeler. Koordinasyon düğümü daha sonra bu parçaların düğüm kimliklerini arar, böylece belgeyi indeksleme için nereye yönlendireceğini bilir.
Koordinasyon düğümü bir belgenin hedef birincil parçasını ve bu parçanın düğümünü öğrendikten sonra, belge "Birincil Aşama" nın bir parçası olarak birincil dizinleme için bu düğüme gönderilir. Birincil parça, istekleri doğrular, ardından yerel olarak dizine ekler, bu da eşlemeyi, alanları vb. Doğrular. Bu işlem aşağıda daha ayrıntılı olarak açıklanmıştır.
Birincil düğümün dizinlemesi başarılı olursa, birincil parça düğümü (koordinatör düğümü değil) belgeyi paralel olarak tüm "eşzamanlı" "etkin" çoğaltmalara gönderir, bu "Çoğaltma Aşaması" dır. Birincil parça düğümü, tüm kopyaların indekslemeyi tamamlamasını bekler ve ardından bekleyen koordinasyon düğümüne bir sonuç döndürür. Toplu işteki tüm dokümanlar indekslendikten (veya başarısız olduktan) sonra, koordinatör sonuçları orijinal API çağırıcıya, yani istemciye geri gönderir.
Her belge,
birincil ve kopya parçalarının her biri tarafından ayrı ayrı dizine alınır .
Her belgenin üzerinde yaşayacağı HER parça tarafından ayrı ayrı endekslendiğini anlamak önemlidir ve ita verilen belge "dizine eklenmeden" önce bunların TÜMÜ tamamlanmalıdır. Dolayısıyla, bir dizinin çoğaltma sayısı 3 ise, bu, her belgenin hepsi ayrı düğümlerdeki dört parçaya (birincil ve üç eşleme) gidecek ve bunlar tarafından ayrı ayrı dizine ekleneceği anlamına gelir.
Elasticsearch'te gerçek bir ön işleme veya merkezi indeksleme yoktur ve küme tarafından yapılan 'iş', belirli bir indeks için kopya sayısı ile doğrusal olarak artar. Bu, yalnızca en yavaş düğüm ve parça kadar yavaş tamamlanabildiğinden, genellikle çoğu dizinleme gecikmesinin gerçekleştiği yerdir.
Koordinatör düğümü, belgeleri olabildiğince toplu olarak paralelleştirir. Belgeleri paralel olarak yönlendirilmiş birincil kırıklarına gönderir, ancak birincil parça başına yalnızca bir istek kuyruğa alıyor gibi görünür. Dolayısıyla, toplu iş, tek bir kırığa sahip tek bir dizin için 10 belgeye sahipse, bunların hepsi birer birer sırayla işlenecektir. Ancak toplu iş, her biri 5 parça içeren iki dizin için 10 belgeye sahipse ve yönlendirme, parça başına bir belgeyle sonuçlanırsa, 10 belgenin tümü paralel olarak yapılacaktır. Bu, ek birincil kırıkların işlemeyi hızlandırmasının bir yoludur.
Bir belge, içinde yaşayacağı bir parçaya sahip olan belirli bir düğüme ulaştığında, asıl belge indekslemesi yapılır. İlk adım, belgeyi translog'a yazmaktır, böylece bu noktadan sonra bir düğüm çökmesi durumunda kalıcı bir kopyası olur. Translog, Lucene'nin kendi başına yapabileceğinin ötesinde bir dayanıklılık sağlayan bir Elasticsearch özelliğidir ve güvenilir bir sistemin anahtarıdır. Düğüm, asıl indeksleme tamamlanmadan çökerse, yeniden başlatıldığında Elasticsearch, işlendiğinden emin olmak için dokümanı indeksleme sürecine yeniden oynatacaktır.
Gerçek indeksleme işleminin birkaç adımı vardır:
İkinci olarak, belge Lucene'ye aktarılır ve bu da onu 'analiz eder'. Pratikte bu, yapılandırılmış analizörün üzerinde çalıştırılması anlamına gelir ve her analizör, birlikte çok sayıda güçlü şey yapabilen belirteçlere ayırma ve filtreleme dahil olmak üzere bir dizi adım ve bileşene sahip olabilir.
Simgeleştirme, sözcükleri ayırmak için beyaz boşlukta olduğu gibi her alandaki verileri belirteçlere ayırırken, filtreleme, temel şeyleri filtrelemenin yanı sıra metni küçültme, durdurma sözcüklerini kaldırma ve kök belirleme yoluyla normalleştirme (ör. Değiştirme kelimeler 'normal' versiyonlarına, örneğin köpekler köpek olur, izlenenler izlenir vb.
Son olarak, Lucene sonuçları alır ve bu belge için depolama kayıtlarını oluşturur. Bu genellikle belgedeki her alanı, ayrıca _source ve _all gibi yeniden indeksleme için kullanılabilen özel alanları ve çok önemli ters çevrilmiş dizinin kendisini içerir.
Lucene tüm bunları bir bellek içi bölüm tampona yazar ve ardından başarılı olarak koordinasyon düğümüne geri döner. Bu tüm kopya parçalarında yapıldığında, bu belgenin indekslenmesi koordinatör düğümünden veya istemcinin bakış açısından esasen tamamlanır.
Henüz endekslenen belge, bellekte yalnızca geçici çoklu belge bölümündedir ve henüz diskte değildir ve henüz arama için uygun değildir. Bu iki şeyin gerçekleşmesi için perde arkasında iki ayrı süreç çalışıyor.
Endekslenen veriler henüz diskte değildir ve ayrıca aranabilir de değildir.
İlk işlem, verileri aranmaya hazır hale getirmek için "yenilemektir". Yenileme aralığı endeks başına ayarlanır ve varsayılan olarak 1s'dir. Çoğu kullanıcı bunu 30-60 saniye gibi çok daha yükseğe ayarlar, çünkü bu pahalı bir işlemdir ve bunu saniyede bir yapmak genel indeksleme verimini azaltabilir. Toplu dizin hızını artırmak için, sıklıkla aranmayan endekslerin aranana kadar otomatik olarak yenilenmeyeceğini unutmayın.
Yenileme aralığında, bellek tamponunun segment (ler) i birleştirilir ve dosya sistemindeki tek bir yeni segmente yazılır ve veriler aranmaya hazırdır. Ancak, bu segment artık dosya sisteminde mevcut olsa da, çoğunlukla dosya önbelleğindedir ve aslında diskte olmayabilir, bu noktada bir çökme varsa bir sorundur. Veriler mevcut, ancak güvenli değil, ancak bir çökme varsa, translog hala var ve oynatılacak ve belge yeniden indekslenecek.
Verileri diskte güvenli hale getirmek için, Lucene işlemi yapan ayrı bir Elasticsearch yıkama işlemi vardır; bu işlem, yukarıdaki segmentleri birleştirip fsyns yaparak gerçekten diskte olmalarını sağlar. Bu tamamlandığında Elasticsearch, veriler artık güvenli bir şekilde diskte olduğundan ve bir çökme sırasında kaybolmayacağından translog'u keser. Elasticsearch, kurtarma sürelerini makul tutmaya yardımcı olmak için bu yıkamaları translog boyutuna göre planlar (varsayılan maksimum 512MB'dir).
Esasen, translog tüm yeni belge değişiklikleri için ve Elasticsearch yıkamaları / Lucene taahhütleri arasında güvenilirliği korur. Translog'un kendi güvenilirlik ayarlarına sahip olduğunu unutmayın; varsayılan değer, her 5 saniyede bir diske fsync'dir.
Ayrıca Elasticsearch, genel gerçek zamanlı indekslemeyi ve arama performansını yavaşlatmadan segment sayısını (sırayla arandıklarından dolayı) en aza indirmeye çalışan kademeli bir birleştirme politikası kullanarak, segmentleri birleştirmeye devam edebilmek için arka planda iş parçacıkları çalıştırır. Bu, yukarıdaki tüm işlemlerden ayrıdır.
Genel sonuç, herhangi bir zamanda, herhangi bir belirli kullanılabilir dizinin disk üzerinde değişen boyutlarda bir dizi kalıcı bölümden ve dosya önbelleğindeki bazı yeni bölümlerden oluşmasıdır. Ayrıca, yalnızca bellekte bulunan ve yenileme aralığını bekleyen endeksli ancak henüz mevcut olmayan segmentler.
Elasticsearch indeksleme, yüksek performansı, veri güvenilirliğini ve güçlü işlevselliği dengeleyen çok hoş, ancak karmaşık, dağıtılmış bir işlemdir. Ve çok iyi çalışsa da, işler ters gidebilir ve gidebilir. Bazı sorunlar belgelerin kendisinde, diğerleri ise nesnelerin kümelenme tarafındadır.
Küme düzeyindeki sorunlar genellikle işlem sırasında parça kaybı veya hareketi ile ilgilidir. Normal akış, koordinatör düğümden birincil düğüme ve çoğaltma düğümlerine gider, ancak işlem sırasında birincil değişirse veya bir kopya kaybolursa ne olur? Belgeyi kaydetmeye çalışan çeşitli karmaşık yeniden deneme, zaman aşımı ve yönlendirme işlemleri vardır, ancak elbette başarısız olabilirler, bu nedenle istemcinin yeniden denemesi gereken nokta budur.
Bunlardan bazıları, bir çoğaltma zaman aşımı veya başarısızlık gibi, parçanın eşitlenmemiş ve geçersiz olarak bildirilmesine, dizin durumunu sarıya çevirmesine ve bir çoğaltma yeniden oluşturma planlamasına neden olur. Ağ bölümü gibi diğerleri, birincilin kendisinin geçersiz ilan edilmesine neden olur ve bu, kopyalarla konuşmaya çalıştığında keşfeder. Genel olarak, karmaşık ama sağlam bir sistemdir.
Bu süreçle ilgili birkaç iyi makale var, ancak çoğu yıllardır ve en iyileri Elasticsearch'ün çok daha önceki sürümlerini kapsar, ancak süreçler hala genel olarak aynıdır:
ELKman, ELK Yığın yönetim aracımızdır ve yukarıdaki süreçleri çalışırken görmek dahil Elasticsearch sistemlerinizi yönetmenize, ayarlamanıza, denetlemenize ve optimize etmenize yardımcı olur. ELKMan.io'da daha fazlası
Bir pazar yeri için arama oluşturmak basit bir iş değildir. Alışveriş yapanlar, Google ve Amazon'un sunduğu hız ve kaliteyi bekliyor.
ES: Elastic Search Önkoşulları Elastic Search ile ilgili önceki yazılarımızda, bir ES istemcisi kurduk ve dokümanları dizine ekledik. Şimdi, dizine alınmış belgelerimiz üzerinde arama, sıralama, sayfalandırma ve filtreleme gibi çeşitli işlemleri gerçekleştirmek için bu istemciyi kullanacağız.
MIT Seçim Laboratuvarı'nda yüksek lisans araştırmacısı ve doktora derecesi olan Jesse Clark tarafından yazılmıştır.
Oakland, CA'da halka açık verileri kullanarak hava kalitesini tahmin etmek Google ve EDF, Oakland'daki hava kirliliğini haritalama çalışmalarını yayınladığında, bu çalışmanın sonuçları büyük ilgi gördü. Yayınladıkları veriler, hava kalitesinin Doğu ve Batı Oakland'daki şehir bloklarına göre nasıl değiştiğini gösteren ilk veri kümelerinden biriydi.
Daniel Fleck ve David Lubert ile yazılmıştır Dizimizin ilk blogu, bir veri bilimi projesini uygun şekilde değerlendirmek için Net Şimdiki Değer (NPV), İç Getiri Oranı (IRR) ve Karlılık Endeksi'ni (PI) kullanmaya odaklanacaktır. Ayrıca, bir veri bilimi metodolojisinin kullanılmasının, bu aynı ekonomik ölçütlerin girdilerini daha yüksek kaliteli değerlendirmeler geliştirmek için nasıl daha da iyileştirebileceğini tartışacağız.
Öz bileşimi ve SVD için yararlı olan doğrusal cebir temel kavramını anlayın Bu makalede, öz ayrıştırma veya tekil değer ayrıştırma (SVD) gibi matris çarpanlara ayırma yöntemlerini anlamanın ilginç bir yolu olan temel kavramını öğreneceksiniz. Tanımlar Temel, vektör uzaylarını (vektör setleri) tanımlamak için kullanılan bir koordinat sistemidir.