Elasticsearch Güncellemeleri, Eklemeler, Silmeler: Nasıl Çalıştıklarını ve Sınırlamalarını Anlamak

giriiş

Gerçek zamanlı arama ve analiz için PostgreSQL, MongoDB veya DynamoDB gibi bir kaynak sistemden gelen akış verilerini bir alt sisteme yönetmek birçok ekip için zorlu bir iştir. Veri akışı, güncellemeler ve silmeler de dahil olmak üzere yüksek hacimli yazma işlemlerinin CPU'yu yüklememesini veya son uygulamanın performansını etkilememesini sağlamak için genellikle karmaşık ETL araçlarının yanı sıra kendi kendini yöneten entegrasyonları da içerir.

Elasticsearch gibi bir sistem için, mühendislerin akış verilerini verimli bir şekilde alabilmeleri için temel mimari hakkında derinlemesine bilgiye sahip olmaları gerekir. Elasticsearch, verilerin sık sık değişmediği ve işlem verileriyle uğraşırken ek zorluklar ortaya çıkardığı günlük analitiği için tasarlandı.

Öte yandan Rockset, bulut tabanlı bir veritabanıdır ve sisteme veri almak için gereken birçok araç ve ek yükü ortadan kaldırır. Rockset, gerçek zamanlı arama ve analiz için özel olarak tasarlandığından, aynı zamanda saha düzeyinde değiştirilebilirlik için de tasarlanmıştır; ekleme, güncelleme ve silme işlemleri için gereken CPU'yu azaltır.

Bu blogda, Elasticsearch ve Rockset'in veri alımını nasıl ele aldığını karşılaştıracağız ve aynı zamanda bu sistemlerin gerçek zamanlı analiz için kullanılmasına yönelik pratik teknikler sunacağız.

Elasticsearch

Elasticsearch'te Veri Kullanımı

Elasticsearch'e veri aktarmanın birçok yolu olsa da, gerçek zamanlı arama ve analiz için üç yaygın yöntemi ele alıyoruz:

• Logstash JDBC giriş eklentisini kullanarak ilişkisel bir veritabanından verileri Elasticsearch'e aktarın

• Kafka Elasticsearch Hizmet Havuzu Bağlayıcısını kullanarak Kafka'dan Elasticsearch'e veri alma

• REST API ve istemci kitaplıklarını kullanarak verileri doğrudan uygulamadan Elasticsearch'e aktarın

  
  

Logstash JDBC giriş eklentisini kullanarak ilişkisel bir veritabanından verileri Elasticsearch'e aktarın. Logstash JDBC giriş eklentisi, verileri PostgreSQL veya MySQL gibi ilişkisel bir veritabanından arama ve analiz için Elasticsearch'e aktarmak için kullanılabilir.

Logstash, verileri Elasticsearch'e göndermeden önce alıp dönüştüren bir olay işleme hattıdır. Logstash, düzenli aralıklarla eklemeler ve güncellemeler için PostgreSQL veya MySQL gibi ilişkisel bir veritabanını yoklayan bir JDBC giriş eklentisi sunar. Bu hizmeti kullanmak için ilişkisel veritabanınızın, hangi değişikliklerin meydana geldiğini belirlemek amacıyla Logstash tarafından okunabilecek zaman damgalı kayıtlar sağlaması gerekir.

Bu alma yaklaşımı, eklemeler ve güncellemeler için iyi çalışır ancak silme işlemleri için ek hususlara ihtiyaç vardır. Bunun nedeni Logstash'ın OLTP veritabanınızda nelerin silindiğini belirlemesinin mümkün olmamasıdır. Kullanıcılar, silinen kayda bir işaretin uygulandığı ve sorgu zamanında verileri filtrelemek için kullanılan geçici silme işlemlerini uygulayarak bu sınırlamayı aşabilirler. Veya en güncel kayıtlara erişim sağlamak için ilişkisel veritabanlarını periyodik olarak tarayabilir ve verileri Elasticsearch'te yeniden indeksleyebilirler.

Kafka Elasticsearch Havuz Bağlayıcısını kullanarak Kafka'dan Elasticsearch'e veri alın . Gerçek zamanlı arama ve analiz için kaynak sistemlerden Elasticsearch'e veri göndermek amacıyla Kafka gibi bir olay akışı platformunun kullanılması da yaygındır.

Confluent ve Elastic, hem yönetilen Confluent Kafka hem de Elastic Elasticsearch tekliflerini kullanan şirketlerin kullanımına sunulan Kafka Elasticsearch Service Sink Connector'ın piyasaya sürülmesinde ortaklık kurdu. Bağlayıcı, Kafka Connect ek araçlarının kurulmasını ve yönetilmesini gerektirir.

Bağlayıcıyı kullanarak Kafka'daki her konuyu Elasticsearch'teki tek bir dizin türüyle eşleyebilirsiniz. Dizin türü olarak dinamik yazma kullanılıyorsa, Elasticsearch alan ekleme, kaldırma ve türleri değiştirme gibi bazı şema değişikliklerini destekler.

Kafka'yı kullanırken ortaya çıkan zorluklardan biri, analizörü, belirteci veya indekslenmiş alanları değiştirmek istediğinizde Elasticsearch'teki verileri yeniden indekslemenin gerekli olmasıdır. Bunun nedeni, eşlemenin zaten tanımlandıktan sonra değiştirilememesidir. Verilerin yeniden indekslenmesini gerçekleştirmek için orijinal indekse ve yeni indekse çift yazmanız, verileri orijinal indeksten yeni indekse taşımanız ve ardından orijinal bağlayıcı işini durdurmanız gerekecektir.

Confluent veya Elastic'in yönetilen hizmetlerini kullanmıyorsanız, verileri Elasticsearch'e göndermek üzere Logstash için açık kaynaklı Kafka eklentisini kullanabilirsiniz.

REST API ve istemci kitaplıklarını kullanarak verileri doğrudan uygulamadan Elasticsearch'e alın Elasticsearch, REST API aracılığıyla doğrudan uygulamanızdan veri almak için Java, Javascript, Ruby, Go, Python ve daha fazlasını içeren desteklenen istemci kitaplıklarını kullanma olanağı sunar. İstemci kitaplığı kullanmanın zorluklarından biri, Elasticsearch'ün alım yükünü kaldıramadığı durumlarda sıraya alma ve karşı basınçla çalışacak şekilde yapılandırılmasının gerekmesidir. Sıralama sistemi mevcut olmadığında Elasticsearch'te veri kaybı potansiyeli vardır.

Elasticsearch'te Güncellemeler, Eklemeler ve Silmeler

Elasticsearch, güncellemeleri ve silme işlemlerini işlemek için kullanılabilecek bir Güncelleme API'sine sahiptir. Güncelleme API'si, ağ gezilerinin sayısını ve sürüm çakışması olasılığını azaltır. Güncelleme API'si mevcut belgeyi dizinden alır, değişikliği işler ve ardından verileri yeniden dizine ekler. Bununla birlikte, Elasticsearch yerinde güncelleme veya silme hizmeti sunmuyor. Bu nedenle, tüm belgenin yine de yeniden indekslenmesi gerekiyor, bu da CPU yoğun bir işlemdir.

Temel olarak, Elasticsearch verileri bir Lucene indeksinde depolanır ve bu indeks daha küçük bölümlere ayrılır. Her bölüm değişmez olduğundan belgeler değiştirilemez. Bir güncelleme yapıldığında eski belge silinmek üzere işaretlenir ve yeni belge yeni bir bölüm oluşturacak şekilde birleştirilir. Güncellenen belgeyi kullanmak için tüm analizörlerin çalıştırılması gerekir, bu da CPU kullanımını artırabilir. Verileri sürekli değişen müşterilerin, dizin birleştirmelerinin genel Elasticsearch işlem faturalarının önemli bir kısmını tükettiğini görmesi yaygındır.

Gerekli kaynak miktarı göz önüne alındığında Elastic, Elasticsearch'teki güncelleme sayısının sınırlandırılmasını önerir. Elasticsearch'ün referans müşterisi Bol.com , e-ticaret platformunun bir parçası olarak site araması için Elasticsearch'ü kullandı. Bol.com'un içerik, fiyatlandırma ve kullanılabilirlik değişiklikleri dahil olmak üzere tekliflerinde günde yaklaşık 700 bin güncelleme yapıldı. Başlangıçta, meydana gelen değişikliklerle senkronize kalan bir çözüm istiyorlardı. Ancak güncellemelerin Elasticsearch sistem performansı üzerindeki etkisi göz önüne alındığında, 15-20 dakikalık gecikmelere izin vermeyi tercih ettiler. Belgelerin Elasticsearch'te gruplanması tutarlı sorgu performansı sağladı.

Elasticsearch'te Silme ve Segment Birleştirme Zorlukları

Elasticsearch'te eski belgelerin silinmesi ve alan kazanılmasıyla ilgili zorluklar yaşanabilir.

Elasticsearch, bir dizinde çok sayıda bölüm olduğunda veya bir bölümde silinmek üzere işaretlenmiş çok sayıda belge olduğunda, arka planda bölüm birleştirmeyi tamamlar. Segment birleştirme, belgelerin mevcut segmentlerden yeni oluşturulan bir segmente kopyalanması ve kalan segmentlerin silinmesidir. Ne yazık ki Lucene, birleştirilmesi gereken segmentleri boyutlandırma konusunda iyi değil ve potansiyel olarak performansı ve istikrarı etkileyen düzensiz segmentler yaratıyor.

Bunun nedeni, Elasticsearch'ün tüm belgelerin aynı boyutta olduğunu varsayması ve birleştirme kararlarını silinen belge sayısına göre vermesidir. Çok kiracılı uygulamalarda sıklıkla olduğu gibi, heterojen belge boyutlarıyla uğraşırken, bazı segmentlerin boyutu diğerlerinden daha hızlı büyüyecek ve uygulamadaki en büyük müşterilerin performansı yavaşlayacaktır. Bu durumlarda tek çözüm büyük miktarda veriyi yeniden indekslemektir.

Elasticsearch'te Kopyalama Zorlukları

Elasticsearch, çoğaltma için birincil yedekleme modelini kullanır. Birincil kopya, gelen bir yazma işlemini işler ve ardından işlemi kendi kopyalarına iletir. Her replika bu işlemi alır ve verileri yerel olarak yeniden indeksler. Bu, her kopyanın, aynı belgeyi tekrar tekrar yeniden indekslemek için bağımsız olarak maliyetli bilgi işlem kaynaklarını harcadığı anlamına gelir. N kopya varsa, Elastic aynı belgeyi dizine eklemek için işlemcinin n katını harcar. Bu, bir güncelleme veya ekleme meydana geldiğinde yeniden indekslenmesi gereken veri miktarını arttırabilir.

Elasticsearch'te Toplu API ve Sıra Zorlukları

Elasticsearch'te Güncelleme API'sini kullanabilseniz de, genellikle Toplu API'yi kullanarak sık yapılan değişiklikleri toplu olarak yapmanız önerilir. Toplu API'yi kullanırken mühendislik ekiplerinin sistemdeki güncellemeleri kolaylaştırmak için sıklıkla bir kuyruk oluşturması ve yönetmesi gerekecektir.

Kuyruk, Elasticsearch'ten bağımsızdır ve yapılandırılması ve yönetilmesi gerekir. Kuyruk, Elasticsearch üzerindeki etkiyi sınırlamak için belirli bir zaman aralığında (örneğin 15 dakika) sisteme ekleme, güncelleme ve silme işlemlerini birleştirecektir. Sıralama sistemi, uygulama stabilitesini sağlamak için ekleme hızı yüksek olduğunda da bir kısma uygulayacaktır. Kuyruklar güncellemeler için yararlı olsa da, verilerin tam olarak yeniden indekslenmesini gerektiren çok sayıda veri değişikliğinin ne zaman olduğunu belirlemede iyi değildir. Sistemde çok sayıda güncelleme olması durumunda bu durum herhangi bir zamanda meydana gelebilir. Elastic'i geniş ölçekte çalıştıran ekiplerin, kuyruklarını günlük olarak yöneten ve ayarlayan özel operasyon üyelerine sahip olması yaygın bir durumdur.

Elasticsearch'te yeniden indeksleme

Önceki bölümde bahsedildiği gibi, çok sayıda güncelleme olduğunda veya dizin eşlemelerini değiştirmeniz gerektiğinde, verilerin yeniden dizini oluşur. Yeniden indeksleme hataya açıktır ve bir kümeyi devre dışı bırakma potansiyeline sahiptir. Daha da korkutucu olanı, yeniden indekslemenin her an gerçekleşebilmesidir.

Eşlemelerinizi değiştirmek isterseniz, yeniden indekslemenin gerçekleşeceği süre üzerinde daha fazla kontrole sahip olursunuz. Elasticsearch, yeni bir dizin oluşturmak için bir yeniden dizin API'sine ve yeni bir dizin oluşturulurken kesinti yaşanmamasını sağlamak için bir Takma Adlar API'sine sahiptir. Bir takma ad API'si ile, yeni dizin oluşturulurken sorgular takma ada veya eski dizine yönlendirilir. Yeni dizin hazır olduğunda, takma adlar API'si yeni dizinden veri okumak üzere dönüştürülecektir.

Takma ad API'si ile yeni dizini en son verilerle senkronize tutmak hala zordur. Bunun nedeni, Elasticsearch'ün yalnızca bir dizine veri yazabilmesidir. Bu nedenle, veri hattını yukarı yönde yeni ve eski dizine çift yazacak şekilde yapılandırmanız gerekecektir.

Rockset

Rockset'te Veri Kullanımı

Rockset, verilerinizi kaynak sistemlerle senkronize tutmak için yerleşik konektörler kullanır. Rockset'in yönetilen konnektörleri, verilerin 2 saniye içinde alınabilmesi ve sorgulanabilir hale getirilebilmesi için her veri kaynağı türüne göre ayarlanmıştır. Bu, gecikmeye neden olan veya verileri yalnızca mikro gruplar halinde (örneğin her 15 dakikada bir) alabilen manuel işlem hatlarını ortadan kaldırır.

Rockset, yüksek düzeyde OLTP veritabanlarına, veri akışlarına, veri göllerine ve ambarlarına yerleşik konektörler sunar. İşte nasıl çalışıyorlar:

OLTP Veritabanlarına Yerleşik Konektörler Rockset, OLTP veritabanınızdaki tablolarınızın ilk taramasını yapar ve ardından en son verilerle senkronize kalmak için CDC akışlarını kullanır; veriler, oluşturulduğu andan itibaren 2 saniye içinde sorgulama için kullanılabilir hale gelir. kaynak sistemi.

Veri Akışlarına Yerleşik Bağlayıcılar Rockset, Kafka veya Kinesis gibi veri akışlarıyla, Kafka veya Kinesis'te ayarlama gerektirmeyen, çekme tabanlı bir entegrasyon kullanarak her türlü yeni konuyu sürekli olarak alır.

Veri Gölleri ve Depolara Yerleşik Konektörler Rockset, güncellemeleri sürekli olarak izler ve S3 klasörleri gibi veri göllerinden yeni nesneleri alır. Genellikle ekiplerin, gerçek zamanlı analizler için veri göllerinden gelen verilerle gerçek zamanlı akışlara katılmak istediklerini görüyoruz.

Rockset'teki Güncellemeler, Eklemeler ve Silmeler

Rockset, verileri birden fazla makinede paralel olarak verimli bir şekilde indekslemek için optimize edilmiş dağıtılmış bir mimariye sahiptir.

Rockset, belge parçalı bir veritabanıdır , dolayısıyla belgeleri bölmek ve farklı alanları farklı makinelere göndermek yerine, tüm belgeleri tek bir makineye yazar. Bu nedenle, güncellemeler ve silmeler için birincil anahtar _id'ye dayalı olarak eklemeler için yeni belgeler eklemek veya mevcut belgeleri bulmak hızlıdır.

Elasticsearch'e benzer şekilde Rockset, sorgulandığında verileri hızlı ve verimli bir şekilde almak için indeksleri kullanır. Diğer veritabanlarından veya arama motorlarından farklı olarak Rockset, verileri alım sırasında bir sütun deposunu, arama dizinini ve satır deposunu birleştiren bir dizin olan Yakınsanmış Dizinde dizine ekler. Yakınsanmış Dizin, alanlardaki tüm değerleri bir dizi anahtar/değer çifti olarak saklar. Aşağıdaki örnekte bir belgeyi ve ardından Rockset'te nasıl saklandığını görebilirsiniz.

Rockset, temel olarak mutasyonları önemsiz hale getiren yüksek performanslı bir anahtar-değer deposu olan RocksDB'yi kullanıyor . RocksDB, farklı anahtarlar arasında atomik yazma ve silme işlemlerini destekler. Bir belgenin name alanına güncelleme gelirse her indekste bir tane olmak üzere tam olarak 3 anahtarın güncellenmesi gerekir. Belgedeki diğer alanların dizinleri etkilenmez; bu, Rockset'in her seferinde tüm belgeler için dizinleri güncelleme döngülerini boşa harcamak yerine güncellemeleri verimli bir şekilde işleyebileceği anlamına gelir.

Yuvalanmış belgeler ve diziler de Rockset'te birinci sınıf veri türleridir; bu, aynı güncelleme işleminin onlar için de geçerli olduğu anlamına gelir; bu da Rockset'i JSON ve Avro gibi modern formatlarda depolanan verilerdeki güncellemeler için çok uygun hale getirir.

Rockset'teki ekip aynı zamanda gerçek zamanlı analitik iş yüklerinde yaygın bir model olan yüksek yazma ve ağır okuma işlemlerinin üstesinden gelmek için RocksDB için çeşitli özel uzantılar da geliştirdi. Bu uzantılardan biri, RocksDB Cloud'a sorgu hesaplaması ve indeksleme hesaplamasının temiz bir şekilde ayrılmasını sağlayan uzaktan sıkıştırmadır . Bu, Rockset'in okumalara müdahale eden yazma işlemlerini önlemesini sağlar. Bu geliştirmeler sayesinde Rockset, yazma işlemlerini müşterilerin ihtiyaçlarına göre ölçeklendirebiliyor ve arka planda mutasyonlar meydana gelse bile sorgulama için yeni veriler sunabiliyor.

Rockset API'yi Kullanarak Güncellemeler, Eklemeler ve Silmeler

Rockset kullanıcıları varsayılan _id alanını kullanabilir veya birincil anahtar olarak belirli bir alanı belirtebilir. Bu alan bir belgenin veya belgenin bir kısmının üzerine yazılmasını sağlar. Rockset ve Elasticsearch arasındaki fark, Rockset'in tüm belgenin yeniden indekslenmesine gerek kalmadan tek bir alanın değerini güncelleyebilmesidir.

Rockset API'yi kullanarak bir koleksiyondaki mevcut belgeleri güncellemek için Yama Belgeleri uç noktasına istekte bulunabilirsiniz. Güncellemek istediğiniz mevcut her belge için _id alanını ve belgeye uygulanacak yama işlemlerinin listesini belirtmeniz yeterlidir.

Rockset API ayrıca, uygulama kodunuzdan koleksiyonlarınıza doğrudan veri ekleyebilmeniz için bir Belge Ekle uç noktası da sunar. Mevcut belgeleri silmek için, kaldırmak istediğiniz belgelerin _id alanlarını belirtmeniz ve Rockset API'nin Belgeleri Sil uç noktasına bir istekte bulunmanız yeterlidir.

Rockset'te Kopyaları İşleme

Elasticsearch'ün aksine, Rockset'te yalnızca bir kopya, RocksDB uzaktan sıkıştırmalarını kullanarak indeksleme ve sıkıştırmayı gerçekleştirir. Bu, özellikle dayanıklılık için birden fazla kopya kullanıldığında, indeksleme için gereken CPU miktarını azaltır.

Rockset'te yeniden indeksleme

Rockset'teki alım sırasında, ham kaynak verilerinize uygulanması istenen veri dönüşümlerini belirtmek için bir alım dönüşümü kullanabilirsiniz. Daha sonraki bir tarihte alma dönüşümünü değiştirmek isterseniz verilerinizi yeniden indekslemeniz gerekecektir.

Bununla birlikte Rockset,şemasız alıma olanak tanır ve her veri alanının değerini dinamik olarak yazar. Verilerin veya sorguların boyutu ve şekli değişirse, Rockset performans göstermeye devam edecek ve verilerin yeniden indekslenmesini gerektirmeyecektir.

Rockset, yeniden indekslenmeye gerek kalmadan yüzlerce terabaytlık veriye ölçeklenebilir. Bu Rockset'in parçalama stratejisine kadar uzanıyor. Bir müşterinin Sanal Örneğine ayırdığı işlem arttığında, küme genelinde daha iyi bir dağıtım elde etmek için bir parça alt kümesi karıştırılır, böylece daha paralelleştirilmiş, daha hızlı dizin oluşturma ve sorgu yürütme olanağı sağlanır. Sonuç olarak, bu senaryolarda yeniden dizin oluşturmanın gerçekleşmesi gerekmez.

Çözüm

Elasticsearch, verilerin sık sık güncellenmediği, eklenmediği veya silinmediği durumlarda günlük analitiği için tasarlanmıştır. Zamanla ekipler, sürekli değişen işlem verileri üzerinde gerçek zamanlı analizler için genellikle Elasticsearch'ü ikincil bir veri deposu ve indeksleme motoru olarak kullanarak Elasticsearch'ün kullanımını genişletti. Bu, özellikle verilerin gerçek zamanlı alımını optimize eden ekipler için maliyetli bir çaba olabilir ve önemli miktarda yönetim yükü de içerebilir.

Öte yandan Rockset, gerçek zamanlı analizler yapmak ve yeni verileri oluşturulduğu andan itibaren 2 saniye içinde sorgulanmaya hazır hale getirmek için tasarlandı. Bu kullanım durumunu çözmek için Rockset, yerinde eklemeleri, güncellemeleri ve silmeleri destekler, bilgi işlemden tasarruf sağlar ve belgelerin yeniden indekslenmesinin kullanımını sınırlandırır. Rockset ayrıca konnektörlerin ve alımın yönetim yükünün de farkındadır ve gerçek zamanlı konnektörleri bulut teklifine dahil eden bir platform yaklaşımı benimser.

Genel olarak, gerçek zamanlı analiz için Elasticsearch'ten Rockset'e geçiş yapan şirketlerin yalnızca bilgi işlem faturalarında %44 tasarruf ettiğini gördük. Birkaç gün içinde Elasticsearch'ten Rockset'e geçiş yapan mühendislik ekipleri dalgasına katılın. Ücretsiz denemenizi bugün başlatın.