Elasticsearch, hızlı gerçek zamanlı arama işlevselliği sağlamak için Apache Lucene kullanılarak oluşturulmuş, açık kaynaklı, dağıtılmış tabanlı bir arama ve analiz motorudur. Varsayılan olarak belge odaklı, ölçeklenebilir ve şemasız bir NoSQL veri deposudur. Elasticsearch, büyük veri kümeleriyle geniş ölçekte çalışacak şekilde tasarlanmıştır. Bir arama motoru olarak, birden fazla düğümde yatay olarak ölçeklenebilen hızlı indeksleme ve arama yetenekleri sağlar. JSON Utanmaz fiş: , bulutta gerçek zamanlı bir indeksleme veritabanıdır. Yalnızca arama için değil aynı zamanda toplamalar ve birleştirmeler için de optimize edilmiş dizinleri otomatik olarak oluşturarak, nereden geldiğine ve hangi formatta olduğuna bakılmaksızın uygulamalarınızın verileri sorgulamasını hızlı ve kolay hale getirir. Ancak bu yazı, bazı geçici çözümleri vurgulamakla ilgilidir. , Elasticsearch'te gerçekten SQL tarzı birleştirmeler yapmak istiyorsanız. Rockset Veri İlişkileri Neden Önemlidir? Veri ilişkilerini yönetmenin önemli olduğu, birbirine oldukça bağlı bir dünyada yaşıyoruz. İlişkisel veritabanları ilişkileri yönetme konusunda iyidir ancak sürekli değişen iş gereksinimleri nedeniyle bu veritabanlarının sabit şeması, ölçeklenebilirlik ve performans sorunlarına yol açar. NoSQL veri depolarının kullanımı, geleneksel veri işleme yaklaşımlarıyla ilişkili çeşitli zorlukların üstesinden gelme yeteneklerinden dolayı giderek daha popüler hale geliyor. Kuruluşlar, verileri analiz etmek için toplama, birleştirme ve filtreleme özelliklerinin gerekli olduğu karmaşık veri yapılarıyla sürekli olarak uğraşmaktadır. Yapılandırılmamış verilerin patlamasıyla birlikte, veri analitiği amacıyla farklı kaynaklardan gelen verilerin birleştirilmesini gerektiren kullanım senaryolarının sayısı giderek artıyor. Birleştirmeler öncelikle bir SQL konsepti olsa da NoSQL dünyasında da aynı derecede önemlidir. SQL tarzı birleştirmeler, Elasticsearch'te birinci sınıf vatandaşlar olarak desteklenmez. Bu makalede, normalleştirme, uygulama tarafı birleştirmeleri, iç içe geçmiş belgeler ve üst-alt ilişkiler gibi çeşitli teknikler kullanılarak Elasticsearch'te ilişkilerin nasıl tanımlanacağı tartışılacaktır. Ayrıca her bir yaklaşımla ilişkili kullanım durumları ve zorluklar da incelenecektir. Elasticsearch'te İlişkilerle Nasıl Başa Çıkılır? Elasticsearch ilişkisel bir veritabanı olmadığından, birleştirmeler SQL veritabanındaki gibi yerel bir işlevsellik olarak mevcut değildir. Depolama verimliliğinden ziyade arama verimliliğine daha fazla odaklanır. Saklanan veriler, hızlı arama kullanım durumlarını desteklemek için pratik olarak düzleştirilir veya normalleştirilmez. Elasticsearch'te ilişkileri tanımlamanın birden fazla yolu vardır. Kullanım durumunuza bağlı olarak, verilerinizi modellemek için Elasticsearch'te aşağıdaki tekniklerden birini seçebilirsiniz: Bire bir ilişkiler: Nesne eşleme Bire-çok ilişkiler: İç içe geçmiş belgeler ve ebeveyn-çocuk modeli Çoka çok ilişkiler: Normalleştirme ve uygulama tarafı birleştirmeleri Bire-bir nesne eşlemeleri basittir ve burada fazla tartışılmayacaktır. Bu blogun geri kalanında diğer iki senaryoyu daha ayrıntılı olarak ele alacağız. Elasticsearch'te Veri Modelinizi Yönetme Elasticsearch'te verileri yönetmeye yönelik dört yaygın yaklaşım vardır: denormalizasyon Uygulama tarafı birleştirmeleri İç içe geçmiş nesneler Ebeveyn-çocuk ilişkileri denormalizasyon Denormalizasyon, veri kümelerinin sorgu zamanında birleştirilmesi gerekli olmadığından Elasticsearch'te en iyi sorgu arama performansını sağlar. Her belge bağımsızdır ve gerekli tüm verileri içerir, böylece pahalı birleştirme işlemlerine olan ihtiyaç ortadan kalkar. Denormalizasyon ile veriler indeksleme sırasında düzleştirilmiş bir yapıda saklanır. Ancak bu, belge boyutunu artırır ve her belgede yinelenen verilerin depolanmasına neden olur. Disk alanı pahalı bir ürün değildir ve bu nedenle endişe edilecek bir durum değildir. Denormalizasyon için Kullanım Durumları Dağıtılmış sistemlerle çalışırken ağdaki veri kümelerine katılmak zorunda olmak önemli gecikmelere neden olabilir. Verileri denormalize ederek bu pahalı birleştirme işlemlerinden kaçınabilirsiniz. Çoka çoğa ilişkiler, veri düzleştirme yoluyla ele alınabilir. Verilerin Normalleştirilmesiyle İlgili Zorluklar Verilerin düzleştirilmiş belgelere çoğaltılması, ek depolama alanı gerektirir. Verileri düzleştirilmiş bir yapıda yönetmek, doğası gereği ilişkisel olan veri kümeleri için ek yüke neden olur. Programlama açısından bakıldığında, denormalizasyon ek mühendislik yükü gerektirir. Birden fazla ilişkisel tabloda depolanan verileri düzleştirmek ve bunu Elasticsearch'te tek bir nesneye eşlemek için ek kod yazmanız gerekecektir. Verileriniz sık sık değişiyorsa, verilerin normalleştirilmesi iyi bir fikir değildir. Bu gibi durumlarda, denormalizasyon, verilerin herhangi bir alt kümesi değiştiğinde tüm belgelerin güncellenmesini gerektirecektir ve bu nedenle bundan kaçınılmalıdır. Düzleştirilmiş veri kümelerinde daha fazla veri indekslendiğinden indeksleme işlemi daha uzun sürer. Verileriniz sık sık değişiyorsa bu, indeksleme oranınızın daha yüksek olduğunu gösterir ve bu da küme performansı sorunlarına neden olabilir. Uygulama Tarafı Birleştirmeleri Belgeler arasındaki ilişkinin korunmasına ihtiyaç duyulduğunda uygulama tarafı birleştirmeleri kullanılabilir. Veriler ayrı indekslerde saklanmakta olup sorgulama süresi boyunca uygulama tarafından birleştirme işlemleri gerçekleştirilebilmektedir. Ancak bu, arama sırasında uygulamanızdan belgeleri birleştirmek için ek sorguların çalıştırılmasını gerektirir. Uygulama Tarafı Birleştirmeleri için Kullanım Örnekleri Uygulama tarafı birleştirmeleri verilerin normalleştirilmiş kalmasını sağlar. Değişiklikler tek bir yerden yapılır ve belgelerinizi sürekli güncellemenize gerek yoktur. Bu yaklaşımla veri fazlalığı en aza indirilir. Bu yöntem, daha az belge olduğunda ve veri değişiklikleri daha az sıklıkta olduğunda işe yarar. Uygulama Tarafı Birleştirmeleriyle İlgili Zorluklar Uygulamanın, arama sırasında belgeleri birleştirmek için birden fazla sorgu yürütmesi gerekir. Veri kümesinde çok sayıda tüketici varsa aynı sorgu kümesini birden çok kez yürütmeniz gerekir; bu da performans sorunlarına yol açabilir. Bu nedenle bu yaklaşım, Elasticsearch'ün gerçek gücünden yararlanamaz. Bu yaklaşım uygulama düzeyinde karmaşıklığa neden olur. Belgeler arasında ilişki kurmak amacıyla birleştirme işlemlerini uygulamak için uygulama düzeyinde ek kod yazılmasını gerektirir. İç İçe Yerleştirilmiş Nesneler Dizideki her nesnenin ilişkisini korumanız gerekiyorsa iç içe yaklaşım kullanılabilir. İç içe geçmiş belgeler dahili olarak ayrı Lucene belgeleri olarak depolanır ve sorgulama sırasında birleştirilebilir. Bunlar birden fazla Lucene belgesinin tek bir blokta saklandığı dizin zamanlı birleştirmelerdir. Uygulama açısından bakıldığında blok tek bir Elasticsearch belgesine benziyor. Bu nedenle, tüm veriler aynı nesnede bulunduğundan sorgulama nispeten daha hızlıdır. İç içe geçmiş belgeler bire çok ilişkilerle ilgilenir. İç İçe Yerleştirilmiş Belgeler için Kullanım Durumları Belgeleriniz nesne dizileri içerdiğinde iç içe belgeler oluşturmak tercih edilir. Aşağıdaki Şekil 1, Elasticsearch'teki iç içe türün, nesne dizilerinin ayrı Lucene belgeleri olarak dahili olarak indekslenmesine nasıl izin verdiğini göstermektedir. Lucene'de iç nesneler kavramı yoktur, dolayısıyla Elasticsearch'ün orijinal belgeyi dahili olarak düzleştirilmiş çok değerli alanlara nasıl dönüştürdüğünü görmek ilginçtir. İç içe geçmiş sorguları kullanmanın bir avantajı, nesneler arası eşleşme yapmaması, dolayısıyla beklenmeyen eşleşme sonuçlarının önlenmesidir. Nesne sınırlarının farkında olup aramaları daha doğru hale getirir. Şekil 1: İç içe yaklaşım kullanılarak Elasticsearch'te ayrı Lucene belgeleri olarak dahili olarak indekslenen nesne dizileri İç İçe Yerleştirilmiş Nesnelerle İlgili Zorluklar Yuvalanmış bir nesnenin eklenmesi/güncellenmesi/silinmesi için kök nesnenin ve onun yuvalanmış nesnelerinin tamamen yeniden dizinlenmesi gerekir. Başka bir deyişle, bir alt kayıt güncellemesi tüm belgenin yeniden indekslenmesiyle sonuçlanacaktır. İç içe geçmiş belgelere doğrudan erişilemez. Bunlara yalnızca ilgili kök belgeden erişilebilir. Arama istekleri, yalnızca arama sorgusuyla eşleşen iç içe yerleştirilmiş belgeleri döndürmek yerine belgenin tamamını döndürür. Veri kümeniz sık sık değişiyorsa iç içe geçmiş belgelerin kullanılması çok sayıda güncellemeyle sonuçlanacaktır. Ebeveyn-Çocuk İlişkileri Üst-alt ilişkiler, ilişkileri olan nesneleri tek tek belgelere (üst ve alt) tamamen ayırmak için yararlanır. Bu, belgeleri ayrı ayrı güncellenebilen ayrı Elasticsearch belgelerinde ilişkisel bir yapıda saklamanıza olanak tanır. birleştirme veri türünden Belgelerin sık sık güncellenmesi gerektiğinde ebeveyn-çocuk ilişkileri faydalıdır. Bu nedenle bu yaklaşım, verilerin sık sık değiştiği senaryolar için idealdir. Temel olarak, temel belgeyi ebeveyn ve alt öğeyi içeren birden çok belgeye ayırırsınız. Bu, hem ana hem de alt belgelerin birbirinden bağımsız olarak dizine eklenmesine/güncellenmesine/silinmesine olanak tanır. Ana ve Alt Belgelerde Arama Dizin oluşturma ve arama sırasında Elasticsearch performansını optimize etmek için genel öneri, belge boyutunun büyük olmamasıdır. Belgenizi ayrı belgelere bölmek için ebeveyn-çocuk modelinden yararlanabilirsiniz. Ancak bunun uygulanmasında bazı zorluklar var. Sorgu süresi boyunca bunlara katılmanın bellekte ve verimli olabilmesi için üst ve alt belgelerin aynı parçaya yönlendirilmesi gerekir. Alt belgenin yönlendirme değeri olarak üst kimliğin kullanılması gerekir. alanı, Elasticsearch'e ana belgenin kimliğini ve türünü sağlar; bu da dahili olarak alt belgeleri ana belgeyle aynı parçaya yönlendirmesine olanak tanır. _parent Elasticsearch, karmaşık JSON nesnelerinden arama yapmanızı sağlar. Ancak bu, verimli bir şekilde sorgulama yapmak için veri yapısının kapsamlı bir şekilde anlaşılmasını gerektirir. Ebeveyn-çocuk modeli, arama işlevini basitleştirmek için birden fazla filtreden yararlanır: sorgusu has_child Sorguyla eşleşen alt belgeleri olan ana belgeleri döndürür. sorgusu has_parent Bir üst öğeyi kabul eder ve ilişkili üst öğelerin eşleştiği alt belgeleri döndürür. sorgusu inner_hits sorgusundan ilgili alt bilgileri getirir. has_child Şekil 2, bire çok ilişkileri göstermek için ebeveyn-çocuk modelini nasıl kullanabileceğinizi göstermektedir. Alt belgeler, üst belgeyi etkilemeden eklenebilir/kaldırılabilir/güncellenebilir. Aynı durum, alt öğeleri yeniden indekslemeden güncellenebilen ana belge için de geçerlidir. Şekil 2: Bire çok ilişkiler için ebeveyn-çocuk modeli Ebeveyn-Çocuk İlişkilerindeki Zorluklar Birleştirme işlemi nedeniyle sorgular daha pahalıdır ve bellek yoğundur. Sorgu zamanında birleştirilmesi gereken ayrı belgeler oldukları için ebeveyn-çocuk yapılarının ek bir yükü vardır. Ebeveynin ve onun tüm çocuklarının aynı parçada bulunduğundan emin olmanız gerekir. Belgelerin ebeveyn-çocuk ilişkileriyle saklanması uygulama karmaşıklığını içerir. Çözüm Doğru Elasticsearch tasarımını seçmek, uygulama performansı ve sürdürülebilirlik açısından kritik öneme sahiptir. Elasticsearch'te veri modelinizi tasarlarken, burada tartışılan dört modelleme yönteminin her birinin çeşitli avantaj ve dezavantajlarına dikkat etmek önemlidir. veri modelleme Bu makalede, iç içe geçmiş nesnelerin ve ebeveyn-çocuk ilişkilerinin Elasticsearch'te SQL benzeri birleştirme işlemlerini nasıl mümkün kıldığını araştırdık. Uygulama tarafı birleştirmeleriyle ilişkileri yönetmek için uygulamanıza özel mantık da uygulayabilirsiniz. Elasticsearch'te birden fazla veri kümesini birleştirmeniz gereken kullanım durumları için, performanslı sorgulamayı etkinleştirmek üzere bu veri kümelerinin her ikisini de Elasticsearch dizinine alıp yükleyebilirsiniz. Elasticsearch'ün, SQL veritabanındaki gibi birleştirmeleri yoktur. Belgelerinizde ilişki kurmaya yönelik olası geçici çözümler olsa da, bu yaklaşımların her birinin sunduğu zorlukların farkında olmak önemlidir. Rockset ile Yerel SQL Birleştirmelerini Kullanma Gerçek zamanlı analiz için birden fazla veri kümesini birleştirmeye ihtiyaç duyulduğunda, yerel SQL birleştirmeleri sağlayan bir veritabanı bu kullanım durumunu daha iyi işleyebilir. Elasticsearch gibi Rockset de veritabanlarından, olay akışlarından ve veri göllerinden gelen veriler üzerinde indeksleme katmanı olarak kullanılır ve bu kaynaklardan şemasız alıma izin verir. Rockset, Elasticsearch'ün aksine, birleştirmeler de dahil olmak üzere olanağı sunarak verilerinizi nasıl kullanabileceğiniz konusunda size daha fazla esneklik sağlar. tam özellikli SQL ile sorgulama da yayınlandı. Burada
