How Coralogix cut processing times from 30 seconds to 86 milliseconds with a PostgreSQL to ScyllaDB migration. Hız önemlidir Coralogix, olayları sorunlara dönüşmeden önce tespit etmek için geliştiricilerin güvenebileceği bir gözlemlenebilirlik platformu. Coralogix, gerçek zamanlı bir akış analitik boru hattını kullanır ve indeksleme gerektirmeden izleme, görselleştirme ve uyarı yeteneğini sağlar. Coralogix için Coralogix'in ana ayırtçılarından biri, uzaktan depolanan bir müşteri arşivinden haritalanan verileri hızlı bir şekilde sorgulamak için dağıtılmış bir sorgu motoru.Bu motor, nesne depolama alanında saklanan yarı yapılandırılmış verileri (örneğin, GCS, S3) özel bir Başlangıçta temel nesne depolama üstünde statüsüz bir sorgu motoru olarak tasarlanmıştır, ancak sorgu yürütme sırasında Parquet metadata okumak kabul edilemez bir gecikme hitini tanıttı. parkı PostgreSQL üzerine kurulan orijinal metastor uygulaması, ihtiyaçlarını karşılamak için yeterince hızlı değildi. Bu yüzden ekibi yeni bir uygulama denedi – bu sefer PostgreSQL yerine ScyllaDB ile. Spoiler: İşe yaradı. İnanılmaz performans artışları elde ettiler – 30 saniyeden 86 miliseküne sorgu işleme süresini düşürdük. Ve mühendisleri Dan Harris (Önemli Yazılım Mühendisi) ve Sebastian Vercruysse (Önemli Yazılım Mühendisi) ScyllaDB Zirvesi'nde sahneye çıktı ve bunu nasıl yaptıklarını açıklamışlar. ScyllaDB Summit 24'te ekibin en zor veri tabanı zorluklarını nasıl ele aldığını daha fazla ilk elden öğrenmek için bize katılın. Disney, Discord, Expedia, Supercell, Paramount ve daha fazlası gündemde. ScyllaDB Summit 2024 Artık Çıkıyor! Update: Metastor Motivasyonu ve Gereksinimleri Metastor uygulamasının ayrıntılarına girmeden önce, bir adım geriye gidelim ve ilk olarak bir metastor oluşturma nedenini inceleyelim. “Başlangıçta bu platformu temel nesne depolamasının üstünde statüsüz bir sorgu motoru olarak tasarladık – ancak sorgu yürütme sırasında Parquet metadata okumanın maliyeti sorgu süresinin büyük bir yüzdesini oluşturduğunu anladık,” diyor Dan Harris. Bir çözüm önermişlerdi ki: Yüksek ölçeklenebilirlik ve geçiş için Parquet metadata parçalanmış bir biçimde depolayın Her soru için taramak için dosyaları etkin bir şekilde tanımlamak için bloom filtreleri kullanın Transaksyon komisyon loglarını kullanarak varolan verileri işlemsel olarak ekler, güncelleştirir ve altındaki nesne depolamasındaki verileri değiştirir Anahtar gereksinimler düşük gecikme, hem okuma / yazma kapasitesinde ölçeklenebilirlik hem de temel depolama ölçeklenebilirliği içeriyordu. ve gerekli aşırı ölçeklenebilirliği anlamak için şunları düşünün: saatte 2.000 Parquet dosyası (50.000 günde) oluşturur, günde toplam 15 TB, Parquet metadata yalnızca 20 GB sonuçlanır . a single customer tek bir gün için Tek Müşteri tek bir gün için PostgreSQL Uygulaması “Postgres’te ilk uygulama başlattık, o zaman dağıtılmamış bir motorun uzun vadede yeterli olmayacağını anladık” dedi Dan. Orijinal uygulama, bir satır grubunu ve bir Parquet dosyasını temsil eden “bloklar” gibi anahtar bilgileri depoladı. Block url: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Row group: 0, 1, 2 … Min timestamp Max timestamp Number of rows Total size … Okumayı optimize etmek için verileri verimli bir şekilde kesmek için bloom filtreleri kullandılar. Dan ayrıntılı olarak, “Sonunda, tam metin arama gibi bir şey desteklemek istiyoruz. Temel olarak, bu dosyaları sistemimize enjekte ettiğimizde, dosyada bulduğumuz tüm farklı tokenler için bir bloom filtresi oluşturabiliriz. Sonra, belirli bir sorguya dayanarak, taramak zorunda olduğumuz verileri kesmek için bu bloom filtrelerini kullanabiliriz.” Ek olarak, her Parquet dosyası için sütun metadata depoladılar. örneğin: Block URL Row Group Column Name Column metadata (blob) Dan, “Yazdığımız dosyalar oldukça geniş, bazen 20.000 sütun kadar. Yani, sadece ihtiyacımız olan metadata okumakla, belirli bir soru için gerekli IO miktarını gerçekten azaltabiliriz.” ScyllaDB Uygulaması Ardından, Dan'ın takım arkadaşı Sebastian Vercruysse tarafından özetlenen ScyllaDB uygulamasını inceleyelim. Blok Veri Modeli Yeni uygulama için blok modellerinin yeniden gözden geçirilmesi gerekiyordu. İşte bir blok URL örneği: s3://cgx-production-c4c-archive-data/cx/parquet/v1/team_id=555585/… …dt=2022-12-02/hr=10/0246f9e9-f0da-4723-9b64-a12346095d25.parquet Cesur kısmı, müşterinin üst düzey kutusu; kutunun içinde, öğeler saat başına bölünür. Ancak bazı müşterilerin diğer müşterilerden çok daha fazla Parquet dosyası var ve her şeyi dengeli tutmak istiyorlardı. ((Block url, row group))? Bu, belirli bir bloğu benzersiz bir şekilde tanımlar, ancak belirli bir gün için tüm blokları listelemek zordur çünkü zaman etiketleri anahtarda bulunmamaktadır ((Tabel url, time))? Bu işe yarıyor çünkü sorgu için 24 saatiniz varsa oldukça kolayca sorabilirsiniz ((Tablo url, saat), blok url, satır grubu)? Bu seçtikleri şeydir. blok url ve satır grubu toplama anahtarları olarak ekleyerek, blok ve satır grubu güncelleme veya silme işlemini de basitleştiren bir saat içinde belirli bir bloğu kolayca alabilirler. Bloom Filter Chunking ve Veri Modelleme Bir sonraki zorluk: belirli bitlerin ayarlandığından emin olmak için, ScyllaDB'nin bunun için kutunun dışındaki işlevleri sunmadığından. Ekip, çiçek filtresini okumaya ve bunları uygulamada işlemeye karar verdi. Ancak, her müşteri başına günde 50.000 blokla ilgili olduğunu unutmayın, her blok çiçek filtresinin parçası için 262 KB içeriyor. Bu toplam 12 GB'dır - tek bir soru için uygulamaya geri çekmek için çok fazla. Ama her seferinde tüm çiçek filtresini okumak zorunda değildiler; soru yürütme sırasında yer alan tokenlere bağlı olarak sadece bir kısmına ihtiyaç duydular. Data modeling için, bir seçenek kullanmak Birincil anahtar olarak. Bu, bloom filtresinde 8192 adet 32 bayt üretir, bu da bölümü başına yaklaşık 262 KB ile eşit bir dağılım sağlar. Aynı bölüme her bir bloom filtresiyle, tek bir batch sorgusu ile verileri eklemek ve silmek kolay olurdu. Ama okuma verimliliğini etkileyen bir yakalama var: bloom filtresini okumadan önce blokun kimliğini bilmeniz gerekir. Buna ek olarak, yaklaşım önemli bir sayıda bölüme erişmek içerir; 50K bloklar 50K bölüme işaret eder. ve Sebastian’ın belirttiği gibi, “ScyllaDB gibi hızlı bir şeyle bile 50K bölümler için alt-second işlem elde etmek zor.” ((block_url, row_group), çerçeve endeksi) Diğer bir seçenek (sonunda seçtikleri): Bu, Blocks'ta olduğu gibi aynı bölme anahtarı olduğunu unutmayın, bölme anahtarına, sorgu motoru tarafından gerekli olan nth token'i temsil eden bir indekse eklendi.Bu yaklaşımla, 24 saatlik bir pencereyi kapsayan 5 token tarama, 120 bölmeye sonuç verir - önceki veri modelleme seçeneğiyle karşılaştırıldığında etkileyici bir iyileştirme. ((table url, time, chunk index), blok url, row group) Ayrıca, bu yaklaşım bloom filtresini okumadan önce bloom ID'yi gerektirmez - daha hızlı okuma sağlar. Tabii ki, her zaman kompromisler vardır. Burada, engellenmiş bloom filtresinin yaklaşımı nedeniyle, tek bir bloom filtresini 8192 benzersiz bölüme bölmek zorunda kalırlar. Bu, tüm bloom filtresini bir kerede yutma imkanı sağlayan önceki bölünme yaklaşımına kıyasla alım hızı etkiler. Ancak, bir saat içinde belirli bir bloğu hızlı okuma yeteneği hızlı yazılardan daha önemlidir - bu yüzden bu kompromisin buna değer olduğunu karar verdiler. Data Modeling Çözümleri Örneğin, Sebastian, “Bir gün, min ve max zaman etiketlerini karıştırdığımızı fark ettim – ve bunu nasıl düzelteceğimi merak ettim. belki sütunları yeniden adlandırıp sonra bir şekilde yeniden çalıştırabileceğimi düşündüm. Ama burada bir sütunu yeniden adlandıramazsınız, eğer bir gruplandırma anahtarının bir parçası ise. kesinlikle yeni sütunlar ekleyebileceğimi ve tüm satırları güncellemek için bir UPDATE sorgusunu çalıştırabileceğimi düşündüm. Ne yazık ki, bu da NoSQL’de çalışmıyor.” Sonuçta, masayı kesmeye ve yeniden başlatmaya karar verdiler vs. Göç kodu yazma. Bu cephede en iyi tavsiyesi ilk kez doğru almak. 🙂 Performans kazançları Gerekli veri modelleme çalışmalarına rağmen, göç iyi ödüllendirildi. metastor blok listesi için: Her bir düğme şu anda 4-5 TB'yi işleyebilir. Şu anda saniyede yaklaşık 10K yazım işlemektedirler ve P99 gecikmesi sürekli olarak bir milisekunden daha azdır. Blok listeleme, bir saatte yaklaşık 2000 parket dosyası elde eder; çiçek filtreleri ile, 20 milisekunduktan daha az sürede işlenir. 50K dosyaları için, 500 milisekunden daha azdır. Ancak, 50K Parquet dosyaları için, 500 millisecond onların ihtiyaçları için iyi. Sütun metadata işleminde, P50 oldukça iyi, ancak yüksek bir sırt gecikmesi vardır. Sebastian açıklıyor: “Problem 50K Parquet dosyaları varsa, yürütücülerimiz bunların hepsini paralel olarak alır. ScyllaDB İnceleme Önemli olan, Coralogix, ScyllaDB'yi ilk keşfetmekten sadece 2 ay içinde terabyte verilerle üretime girmeye gitti (ve bu, çok daha basit bir Cassandra veya DynamoDB geçişi değil, veri modelleme çalışması gerektiren bir SQL'e NoSQL geçişi). Yürütme, Rust üzerinde yazılmıştır Ve onlar buldular ve ve Tüm bunlar hızlı bir geçiş için oldukça yararlıdır. kendi müşterilerine düşük maliyetli bir gözlemsel alternatif sunmak Coralogix için önemlidir, Coralogix ekibi ScyllaDB altyapısının uygun fiyat performansından memnun kaldı: 3 düğümlü bir kümes: ScyllaDB Rust Sürücü Kubernetes için ScyllaDB Operatörü ScyllaDB İzleme ScyllaDB Yöneticisi 8 VCPU 32 GB hafıza Silahlı Kuvvet / Graviton 500 MBps bant genişliği ve 12k IOPS ile EBS hacimleri (gp3) ARM kullanımı maliyetleri azaltır ve EBS (gp3) hacimleri kullanma kararı nihayetinde kullanılabilirlik, esneklik ve fiyat performansı ile sonuçlandı. “Bu tartışmalı bir karar – ama bunu çalıştırmaya çalışıyoruz ve ne kadar süreceğini göreceğiz.” Öğrenilen Dersler Burada öğrendiğimiz en önemli dersler... ScyllaDB ile çalışmanın en büyük farkı Postgres ile çalışmanın, bölünme ve bölünme boyutları hakkında oldukça dikkatli düşünmeniz gerektiğidir. Keep an eye on partition sizes: Ayrıca okuma/yazma şekilleri hakkında da dikkatli düşünmelisiniz. iş yükünüz okuma ağır mı? Okuma ve yazma iyi bir karışım içeriyor mu? Ya da, çoğunlukla yazma ağır mı? Coralogix'in çalışma yükü oldukça yazma ağırdır çünkü sürekli olarak verileri tüketiyorlar, ancak okuma gecikmesinin işleri için en kritik olduğu için okuma önceliklerine sahip olmaları gerekir. Think about read/write patterns: Ekibi, EBS'yi kullanmamaları konusunda uyarılar aldıklarını itiraf ediyor: " Dinlemedik, ama muhtemelen yapmalıyız. Eğer ScyllaDB'yi kullanmayı düşünüyorsanız, muhtemelen EBS hacimleri kullanmaya çalışmak yerine yerel SSD'lere sahip olan örnekleri incelemek iyi bir fikir olacaktır." Avoid EBS: Gelecek planları: WebAssembly UDFs with Rust Gelecekte, yeterince büyük parçalar yazmak ve gereksiz verileri okumak arasında orta nokta bulmak istiyorlar. parçaları 8.000 satırlara bölüyorlar ve bunları 1000 satırya daha da bölebileceğine inanıyorlar, bu da eklemelerini hızlandırabilir. Onların nihai amacı, ScyllaDB'ye daha fazla iş yükleyerek yararlanmaktır. Mevcut Rust kodlarıyla, UDF'lerin entegre edilmesi, verilerin uygulamaya geri gönderilmesinin gerekliliğini ortadan kaldırır ve ayarları ve potansiyel iyileştirmeler için esneklik sağlar. WebAssembly ile Kullanıcı Tanımlı Fonksiyonlar (UDFs) Sebastian, “Şimdi Rust’ta yazılmış her şeyimiz var. UDF’leri kullanmaya başlayabilirsek çok güzel olurdu, böylece herhangi bir şeyi uygulamaya geri göndermemiz gerekmez. Tüm Teknoloji Konuşmalarını İzle Tech Talk kütüphanemizde tüm teknik konuşmaları izleyebilirsiniz ve tekerleğinizde skim yapabilirsiniz. Cynthia Dunlop Hakkında Cynthia, ScyllaDB'de içerik stratejisi üst düzey direktörüdür ve 20 yıldan fazla bir süredir yazılım geliştirme ve kalite mühendisliği hakkında yazıyor.
