Elasticsearch'te Veri Modelleme: İç İçe Sorguları ve Ebeveyn-Alt İlişkileri Kullanma

Elasticsearch'te veri modelleme, ilişkisel veritabanlarıyla uğraşırken olduğu kadar açık değildir. Veri normalleştirmesine ve SQL birleştirmelerine dayanan geleneksel ilişkisel veritabanlarının aksine, Elasticsearch, ilişkileri yönetmek için alternatif yaklaşımlar gerektirir.

Elasticsearch'te ilişkileri yönetmek için dört yaygın geçici çözüm vardır:

• Uygulama tarafı birleştirmeleri

• Veri denormalizasyonu

• İç içe alan türleri ve iç içe geçmiş sorgular

• Ebeveyn-çocuk ilişkileri

  
  

Bu blogda, iç içe alan türünü ve üst-alt ilişkileri kullanarak veri modelinizi ilişkileri yönetecek şekilde nasıl tasarlayabileceğinizi tartışacağız. Bu iki tekniğin mimarisini, performans sonuçlarını ve kullanım örneklerini ele alacağız.

İç İçe Alan Türleri ve İç İçe Sorgular

Elasticsearch, nesnelerin diğer nesneleri içerebildiği iç içe geçmiş yapıları destekler. İç içe alan türleri, ana belgedeki, kendi farklı alanlarına ve türlerine sahip olabilen JSON nesneleridir. Bu iç içe geçmiş nesneler, yalnızca iç içe geçmiş bir sorgu kullanılarak erişilebilen ayrı, gizli belgeler olarak değerlendirilir.

İç içe alan türleri, veri bütünlüğünün, yakın eşleşmenin ve hiyerarşik yapının önemli olduğu ilişkiler için çok uygundur. Bunlar, tek bir ana varlığın olduğu bire bir ve bire çok ilişkileri içerir. Örneğin, bir kişiyi ve birden fazla adresini ve telefon numarasını tek bir belgede temsil etmek.

Elasticsearch, iç içe alan türleri ile tüm belgenin yanı sıra ana ve iç içe geçmiş nesneleri tek bir Lucene bloğunda ve segmentinde saklar. Bu, ilişki bir belgeyle sınırlı olduğundan sorgu hızlarının daha yüksek olmasına neden olabilir.

İç İçe Alan Türü ve İç İçe Sorgu Örneği

Yorum içeren bir blog yazısı örneğine bakalım. Aynı belgede kolayca sorgulanabilmeleri için yorumları blog yazısının altına yerleştirmek istiyoruz.

GITHUB JULIE-MILLS

 { "post_id": "1", "title": "Introduction to Elasticsearch Data Modeling", "content": "Exploring various data modeling options in Elasticsearch.", "comments": [ { "comment_id": "101", "text": "Great overview of data modeling!" }, { "comment_id": "102", "text": "Looking forward to more content." } ] }

İç İçe Alan Türlerinin ve İç İçe Sorguların Avantajları

İç içe geçmiş nesne ilişkilerinin faydaları şunlardır:

• Veriler aynı Lucene bloğunda ve segmentinde depolanır: İç içe geçmiş nesnelerin aynı Lucene bloğunda ve segmentinde saklanması, veriler yan yana yerleştirildiğinden daha hızlı sorgulara yol açar.
• Veri bütünlüğü: İlişkiler aynı belge içerisinde sürdürüldüğü için iç içe sorgularda doğruluk sağlanabilir.
• Belge veri modeli: Belgeleri ve iç içe geçmiş verileri sorguladığınız NoSQL veri modeline aşina olan geliştiriciler için kolaydır.

İç İçe Alan Türlerinin ve İç İçe Sorguların Dezavantajları

• Güncelleme verimsizliği : Bir belgenin iç içe nesneler içeren herhangi bir bölümündeki güncellemeler, eklemeler ve silme işlemleri , belgenin tamamının yeniden indekslenmesini gerektirir; bu, özellikle belgeler büyükse veya güncellemeler sık yapılıyorsa, bellek açısından yoğun olabilir.

  
  

• İç içe geçmiş büyük alanlarla sorgu performansı : Özellikle büyük iç içe geçmiş alanlara sahip belgeleriniz varsa, bunun performansa etkisi olabilir. Bunun nedeni, arama isteğinin belgenin tamamını almasıdır.

  
  

• Birden çok düzeyde iç içe yerleştirme karmaşık hale gelebilir : Sorguları birden çok düzeye sahip iç içe geçmiş yapılar arasında çalıştırmak yine de karmaşık hale gelebilir. Bunun nedeni, sorguların iç içe geçmiş sorgular içinde iç içe geçmiş sorgular içerebilmesi ve bunun da kodun daha az okunabilir olmasına yol açabilmesidir.

Ebeveyn-Çocuk İlişkileri

Ebeveyn-çocuk eşlemesinde belgeler ebeveyn ve alt türlere göre düzenlenir. Her alt belgenin bir ana belgeyle doğrudan ilişkisi vardır. Bu ilişki, alt belgedeki üst öğenin kimliğiyle eşleşen belirli bir alan değeri aracılığıyla kurulur. Ebeveyn-çocuk modeli, ebeveyn ve alt belgelerin bağımsız olarak mevcut olduğu merkezi olmayan bir yaklaşımı benimser.

Ebeveyn-çocuk birleşimleri, varlıklar arasındaki bire çok veya çoktan çoğa ilişkiler için uygundur. Şirketler ve kişiler arasında ilişkiler oluşturmak istediğiniz ve belirli şirketlerdeki kişilerin yanı sıra şirketleri ve kişileri de aramak istediğiniz bir uygulama hayal edin.

Elasticsearch, ebeveynlerin hangi çocuklara bağlı olduğunu takip ederek ve her iki varlığın da aynı parçada bulunmasını sağlayarak ebeveyn-çocuk birleşiminin performans göstermesini sağlar. Elasticsearch, birleştirme işlemini yerelleştirerek, performans darboğazı olabilecek kapsamlı parçalar arası iletişim ihtiyacını ortadan kaldırır.

Ebeveyn-Çocuk İlişkilerine Örnek

Blog yazıları ve yorumları için ebeveyn-çocuk ilişkisi örneğini ele alalım. Her blog yazısının yani ebeveynin, yani çocukların birden fazla yorumu olabilir. Ebeveyn-çocuk ilişkisini oluşturmak için verileri aşağıdaki gibi indeksleyelim:

 PUT my-index-000001 { "mappings": { "properties": { "post_id": { "type": "keyword" }, "post_id": { "type": "join", "relations": { "post": "comment" } } } } }

Bir ana belge şuna benzeyen bir gönderi olacaktır:

 { "post_id": "1", "title": "Introduction to Elasticsearch Data Modeling", "content": "Exploring various data modeling options in Elasticsearch." }

Alt belge daha sonra onu üst belgeye bağlayan post_id'yi içeren bir yorum olacaktır.

 { "comment_id": "101", "text": "Great overview of data modeling!", "post_id": "1" }

Ebeveyn-Çocuk İlişkisinin Faydaları

Ebeveyn-çocuk modellemenin faydaları şunlardır:

• İlişkisel veri modeline benzer : Üst-alt ilişkilerde üst ve alt belgeler ayrıdır ve benzersiz bir üst kimlikle bağlanır. Bu kurulum ilişkisel veritabanı modeline daha yakındır ve bu tür kavramlara aşina olanlar için daha sezgisel olabilir.

  
  

• Güncelleme verimliliği : Alt belgeler, ana belgeyi veya diğer alt belgeleri etkilemeden eklenebilir, değiştirilebilir veya silinebilir. Bu, özellikle sık sık güncellenmesi gereken çok sayıda alt belgeyle uğraşırken faydalıdır. Bir alt belgeyi farklı bir üst öğeyle ilişkilendirmenin, yeni üst öğe başka bir parçada olabileceğinden daha karmaşık bir süreç olduğunu unutmayın.

  
  

• Heterojen çocuklar için daha uygundur : Alt belgeler ayrı olarak depolandığından, özellikle önemli boyut farklılıklarına sahip çok sayıda alt belgenin olduğu durumlarda, bunlar bellek ve depolama açısından daha verimli olabilir.

Ebeveyn-Çocuk İlişkilerinin Dezavantajları

Ebeveyn-çocuk ilişkilerinin dezavantajları şunlardır:

• Pahalı, yavaş sorgular : Belgeleri ayrı dizinlerde birleştirmek, sorgu yürütme sırasında hesaplama işini artırır ve yine performansı etkiler. Elasticsearch , ebeveyn-çocuk sorgularının, iç içe geçmiş nesnelerin sorgulanmasından 5-10 kat daha yavaş olabileceğini belirtiyor.

  
  

• Eşleme yükü : Ebeveyn-çocuk ilişkileri daha fazla bellek ve önbellek kaynağı tüketebilir. Elasticsearch, özellikle yüksek hacimli belgelerde büyüyebilen ve önemli miktarda bellek tüketebilen ebeveyn-çocuk ilişkilerinin bir haritasını tutar.

  
  

• Parça boyutu yönetimi : Hem üst hem de alt belgeler aynı parçada bulunduğundan, küme genelinde eşit olmayan veri dağıtımı riski vardır. Özellikle çok sayıda alt öğeye sahip ana belgeler varsa, bazı parçalar diğerlerinden önemli ölçüde daha büyük hale gelebilir. Bu, Elasticsearch kümesinin yönetilmesinde ve ölçeklendirilmesinde zorluklara yol açabilir.

  
  

• Yeniden dizin oluşturma ve küme bakımı : Verileri yeniden dizine eklemeniz veya parçalama stratejisini değiştirmeniz gerekiyorsa üst-alt ilişki bu süreci karmaşık hale getirebilir. Bu tür işlemler sırasında ilişki bütünlüğünün korunduğundan emin olmanız gerekir. Parçanın yeniden dengelenmesi veya düğüm yükseltmeleri gibi rutin küme bakım görevleri daha karmaşık hale gelebilir. Bu süreçlerde ebeveyn-çocuk ilişkilerinin bozulmamasına özellikle dikkat edilmelidir.

  
  

Elasticsearch'ün arkasındaki şirket olan Elastic , ebeveyn-çocuk ilişkileri yoluna girmeden önce her zaman uygulama tarafı birleştirmeleri, veri denormalizasyonunu ve/veya iç içe geçmiş nesneleri yapmanızı önerecektir.

İç İçe Sorguların ve Ebeveyn-Alt İlişkilerin Özellik Karşılaştırması

Aşağıdaki tablo, veri modelleme yaklaşımlarını yan yana karşılaştırmak için iç içe alan türleri ve sorguların özelliklerinin ve üst-alt öğe ilişkilerinin bir özetini sağlar.

İlişki Modelleme için Elasticsearch'e Alternatifler

Elasticsearch, iç içe geçmiş sorgular ve üst-alt ilişkiler de dahil olmak üzere SQL tarzı birleştirmeler için çeşitli geçici çözümler sağlarken, bu modellerin iyi ölçeklenemediği tespit edilmiştir. Uygulamaları geniş ölçekte tasarlarken, yerel SQL birleştirme yetenekleri olan Rockset ile alternatif bir yaklaşımı düşünmek mantıklı olabilir.

Rockset, derinlemesine yuvalanmış JSON verileri de dahil olmak üzere her türlü veri üzerinde SQL araması, toplamalar ve birleştirmeler için tasarlanmış bir arama ve analiz veritabanıdır. Veriler Rockset'e aktarılırken, hızlı erişim için verileri depolamak ve indekslemek için kullanılan veritabanının temel veri yapılarında kodlanır. Rockset, SQL tabanlı sorgu iyileştiricisini kullanarak, birleştirmeler de dahil olmak üzere hızlı sorgulara izin verecek şekilde verileri indeksler. Sonuç olarak, SQL birleştirmelerini desteklemek için önceden veri modellemeye gerek yoktur.

Elasticsearch'ün zorluklarından biri, veriler güncellendiğinde ilişkinin verimli bir şekilde nasıl korunacağıdır. Bunun nedenlerinden biri, Elasticsearch'ün verileri değişmez segmentlerde depolayan ve tüm belgelerin yeniden indekslenmesi gerekmesine neden olan Apache Lucene üzerine kurulmuş olmasıdır. Rockset, tüm belgeleri yeniden indekslemeye gerek kalmadan alan düzeyindeki güncellemeleri verimli bir şekilde destekleyebilmek için Meta tarafından açık kaynaklı ve veri mutasyonları için oluşturulmuş bir anahtar-değer deposu olan RocksDB'yi kullanıyor.

Gerçek Dünyadan Bir Örnek Kullanarak Elasticsearch ve Rockset'in Karşılaştırılması

Elasticsearch'teki ebeveyn-çocuk ilişkisi yaklaşımını Rockset'teki bir SQL sorgusu ile karşılaştıralım.

Yukarıdaki ebeveyn-çocuk ilişkisi örneğinde, iki belge türü oluşturarak birden çok yorum içeren gönderileri modelledik:

• gönderiler veya ana belge türü

• yorumlar veya alt belge türleri

  
  

Ana ve alt belgeler arasındaki ilişkiyi kurmak için benzersiz bir tanımlayıcı olan ana kimlik kullandık. Sorgu zamanında belirli bir gönderiye ilişkin yorumları almak için Elasticsearch DSL'yi kullanırız.

Rockset'te, gönderileri içeren veriler tek bir koleksiyonda, ilişkisel dünyadaki bir tabloda, yorumları içeren veriler ise ayrı bir koleksiyonda saklanacak. Sorgu zamanında verileri bir SQL sorgusu kullanarak birleştirirdik.

İşte iki yaklaşım yan yana:

Elasticsearch'te Ebeveyn-Çocuk İlişkileri

 POST /blog/posts/1 { "title": "Elasticsearch Modeling", "content": "A post about data modeling in Elasticsearch" } POST /blog/comments/2?parent=1 { "text": "Great post!" } POST /blog/comments/3?parent=1 { "text": "I learned a lot from this." }

Bir gönderiyi başlığına ve tüm yorumlarına göre almak için aşağıdaki gibi bir sorgu oluşturmanız gerekir.

 GET /posts/_search { "query": { "bool": { "must": [ { "match": { "title": "Exploring Elasticsearch Models" } } ] } }, "inner_hits": { "_source": ["text"], "name": "comments", "path": "comments" } }

Rockset'te SQL

Daha sonra bu verileri sorgulamak için basit bir SQL sorgusu yazmanız yeterlidir.

 SELECT p.title, p.content, c.text FROM posts p JOIN comments c ON p.post_id = c.post_id WHERE p.post_id = 1;

Uygulamanız için birleştirilmesi gereken birden fazla veri kümeniz varsa Rockset, Elasticsearch'ten daha basit ve ölçeklenebilirdir. Ayrıca verilerinizi yeniden modellemenize, güncellemeleri yönetmenize veya işlemleri yeniden indekslemenize gerek olmadığından işlemleri basitleştirir.

Elasticsearch'te İlişkileri Yönetmek

Bu blog, iş yükünüz için en iyi veri modelleme yaklaşımını belirlemenize yardımcı olmak amacıyla Elasticsearch'teki iç içe alan türlerine, iç içe sorgulara ve üst-alt ilişkilere genel bir bakış sağladı.

İç içe alan türleri ve sorgular, ilişkinin tek bir belgede sürdürüldüğü bire bir veya bire çok ilişkiler için kullanışlıdır. Bunun ilişki yönetimine yönelik daha basit ve daha ölçeklenebilir bir yaklaşım olduğu düşünülmektedir.

Ebeveyn-çocuk ilişkisi modeli, birden çoğa ve çoktan çoğa ilişkiler için daha uygundur, ancak özellikle ilişkilerin belirli bir parçaya dahil edilmesi gerektiğinden artan karmaşıklıkla birlikte gelir.

Uygulamanızın temel gereksinimlerinden biri ilişkileri modellemekse Rockset'i düşünmek mantıklı olabilir. Rockset, veri modellemeyi basitleştirir ve SQL birleştirmelerini kullanarak ilişki yönetimine daha ölçeklenebilir bir yaklaşım sunar. Bugün 300$ krediyle ücretsiz deneme sürümünü başlatarak Elasticsearch ve Rockset'in performansını karşılaştırabilirsiniz.