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 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ı : Bir belgenin iç içe nesneler içeren herhangi bir bölümündeki , 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. Güncelleme verimsizliği güncellemeler, eklemeler ve silme işlemleri : Ö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. İç içe geçmiş büyük alanlarla sorgu performansı : 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. Birden çok düzeyde iç içe yerleştirme karmaşık hale gelebilir 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: : Ü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. İlişkisel veri modeline benzer : 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. Güncelleme verimliliği : 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. Heterojen çocuklar için daha uygundur Ebeveyn-Çocuk İlişkilerinin Dezavantajları Ebeveyn-çocuk ilişkilerinin dezavantajları şunlardır: : Belgeleri ayrı dizinlerde birleştirmek, sorgu yürütme sırasında hesaplama işini artırır ve yine performansı etkiler. , ebeveyn-çocuk sorgularının, iç içe geçmiş nesnelerin sorgulanmasından 5-10 kat daha yavaş olabileceğini belirtiyor. Pahalı, yavaş sorgular Elasticsearch : 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. Eşleme yükü : 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, zorluklara yol açabilir. Parça boyutu yönetimi Elasticsearch kümesinin yönetilmesinde ve ölçeklendirilmesinde : 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. Yeniden dizin oluşturma ve küme bakımı Verileri yeniden dizine eklemeniz veya parçalama stratejisini değiştirmeniz Elasticsearch'ün arkasındaki şirket olan , 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. Elastic İç İç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. İç içe alan türleri ve iç içe geçmiş sorgular Ebeveyn-çocuk ilişkileri Tanım Bir nesneyi başka bir nesnenin içine yerleştirir Ebeveyn ve alt belgeleri birbirine bağlar İlişkiler Bire bir, bire çok Bire çok, çoktan çoğa Sorgu hızı Veriler aynı blok ve segmentte depolandığından genellikle ebeveyn-çocuk ilişkilerinden daha hızlıdır Ana ve alt belgeler sorgu zamanında birleştirildiğinden genellikle iç içe geçmiş nesnelerden 5-10 kat daha yavaştır. Sorgu esnekliği Sorgulamanın kapsamını iç içe geçmiş her nesnenin sınırlarıyla sınırladığından, ebeveyn-çocuk sorgularından daha az esnektir Ana veya alt belgeler birlikte veya ayrı ayrı sorgulanabildiğinden sorgulamada daha fazla esneklik sunar Veri güncellemeleri İç içe geçmiş nesnelerin güncellenmesi tüm belgenin yeniden indekslenmesini gerektiriyordu Tüm belgelerin yeniden indekslenmesini gerektirmediği için alt belgeleri güncellemek daha kolaydır Yönetmek Her şey tek bir belgede yer aldığından daha basit yönetim Ana ve alt belgeler arasındaki ilişkilerin ayrı indekslenmesi ve sürdürülmesi nedeniyle yönetimi daha karmaşık Kullanım örnekleri Karmaşık verileri birden fazla hiyerarşi düzeyiyle depolayın ve sorgulayın Ürünler ve ürün incelemeleri gibi az sayıda ebeveynin ve çok sayıda çocuğun olduğu ilişkiler İlişki Modelleme için Elasticsearch'e Alternatifler Elasticsearch, iç içe geçmiş sorgular ve üst-alt ilişkiler de dahil olmak üzere 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 ile alternatif bir yaklaşımı düşünmek mantıklı olabilir. SQL tarzı birleştirmeler Rockset 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 ile karşılaştıralım. SQL sorgusu 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 Elasticsearch ve Rockset'in performansını karşılaştırabilirsiniz. ücretsiz deneme sürümünü başlatarak
