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. gibi bir sistem için, mühendislerin 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ı. Elasticsearch akış verilerini verimli bir şekilde alabilmeleri Ö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 için de tasarlanmıştır; ekleme, güncelleme ve silme işlemleri için gereken CPU'yu azaltır. saha düzeyinde değiştirilebilirlik Bu blogda, 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 ve Rockset'in 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ş eklentisi, verileri PostgreSQL veya MySQL gibi ilişkisel bir veritabanından arama ve analiz için Elasticsearch'e aktarmak için kullanılabilir. Logstash JDBC giriş eklentisini kullanarak ilişkisel bir veritabanından verileri Elasticsearch'e aktarın. 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 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. JDBC giriş eklentisi 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. . 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. kullanarak Kafka'dan Elasticsearch'e veri alın Kafka Elasticsearch Havuz Bağlayıcısını Confluent ve Elastic, hem yönetilen Confluent Kafka hem de Elastic Elasticsearch tekliflerini kullanan şirketlerin kullanımına sunulan piyasaya sürülmesinde ortaklık kurdu. Bağlayıcı, Kafka Connect ek araçlarının kurulmasını ve yönetilmesini gerektirir. Kafka Elasticsearch Service Sink Connector'ın 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 kullanabilirsiniz. açık kaynaklı Kafka eklentisini 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 kullanma olanağı sunar. İstemci kitaplığı kullanmanın zorluklarından biri, Elasticsearch'ün alım yükünü kaldıramadığı durumlarda çalışacak şekilde yapılandırılmasının gerekmesidir. Sıralama sistemi mevcut olmadığında Elasticsearch'te veri kaybı potansiyeli vardır. REST API ve istemci kitaplıklarını kullanarak verileri doğrudan uygulamadan Elasticsearch'e alın desteklenen istemci kitaplıklarını sıraya alma ve karşı basınçla Elasticsearch'te Güncellemeler, Eklemeler ve Silmeler Elasticsearch, güncellemeleri ve silme işlemlerini işlemek için kullanılabilecek bir 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. Güncelleme API'sine 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 , 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ı. Bol.com Elasticsearch'te Silme ve Segment Birleştirme Zorlukları Elasticsearch'te ve alan kazanılmasıyla ilgili zorluklar yaşanabilir. eski belgelerin silinmesi 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 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. bölüm birleştirmeyi Bunun nedeni, Elasticsearch'ün tüm belgelerin 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. aynı boyutta Elasticsearch'te Kopyalama Zorlukları Elasticsearch, çoğaltma için 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 gereken veri miktarını arttırabilir. birincil yedekleme modelini yeniden indekslenmesi Elasticsearch'te Toplu API ve Sıra Zorlukları Elasticsearch'te Güncelleme API'sini kullanabilseniz de, genellikle 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. Toplu API'yi 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. 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. Yeniden indeksleme 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 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 Adlar API'sine 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: Rockset, OLTP veritabanınızdaki tablolarınızın ilk taramasını yapar ve ardından en son verilerle senkronize kalmak için kullanır; veriler, oluşturulduğu andan itibaren 2 saniye içinde sorgulama için kullanılabilir hale gelir. kaynak sistemi. OLTP Veritabanlarına Yerleşik Konektörler CDC akışlarını Rockset, 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 Akışlarına Yerleşik Bağlayıcılar Kafka 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. Veri Gölleri ve Depolara Yerleşik Konektörler 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, , 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. belge parçalı bir veritabanı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 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. Yakınsanmış Dizinde . RocksDB, farklı anahtarlar arasında atomik yazma ve silme işlemlerini destekler. Bir belgenin 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. Rockset, temel olarak mutasyonları önemsiz hale getiren yüksek performanslı bir anahtar-değer deposu olan RocksDB'yi kullanıyor name 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 . 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. uzaktan sıkıştırmadır 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, 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. şemasız alıma 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 ş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. bugün başlatın. Elasticsearch'ten Rockset'e geçiş yapan Ücretsiz denemenizi
