Let’s look at the performance-related complexities that teams commonly face with write-heavy workloads and discuss your options for tackling them Yazılı ağır veritabanı iş yükü, okuma ağır olanlardan farklı bir dizi zorluk getirir. örneğin: Yazıların ölçeklenmesi pahalı olabilir, özellikle işlem başına ödeme yaparsanız ve yazılar okurlardan 5 kat daha pahalıdır. Kilitleme gecikmeleri ekleyebilir ve geçişini azaltabilir I/O şişe sıkışmaları yazma amplifikasyonuna ve çarpışma kurtarmasını zorlaştırabilir Database Backpressure Gelen Yükü Düştürebilir Maliyetler önemli olsa da – çoğu durumda – burada ele almak istediğimiz bir konu değildir. Bunun yerine, takımların genellikle karşılaştığı performansla ilgili karmaşıklıklara odaklanalım ve bunları ele almak için seçeneklerinizi tartışalım. “Real-Time Write Heavy Workload” kelimesinin anlamı nedir? İlk olarak, “gerçek zamanlı yazma ağırlığı” olarak ne anlama geldiğini açıklayalım. Büyük miktarda veri (örneğin, 50K OPS'den fazla) Okumadan daha çok yazıyor Sıkı latensiyel SLA'lar (örneğin, tek rakamlı milisekunde P99 latensiyeli) Vahşi ortamda, çevrimiçi oyunlardan gerçek zamanlı borsalara kadar her şeyde meydana gelirler. Şeylerin İnterneti (IoT) iş yükü, zaman serisi verilerinin küçük ama sıklıkla eklenmiş yazılar içerme eğilimindedir. Burada, alım oranı öncelikle verileri toplayan son noktaların sayısına göre belirlenir. akıllı ev sensörleri veya endüstriyel izleme ekipmanları, sürekli olarak işlenmesi ve depolanması için veri akışlarını gönderir. Kayıt ve izleme sistemleri de sık sık veri alımı ile ilgilenir, ancak sabit bir alım oranı yoktur.Onlar yalnızca eklemeye gerek yoktur, ayrıca bir son nokta yanlış davranışta olduğu gibi sıcak noktalara eğilim gösterebilirler. Online oyun platformları, oyun durumlarında değişiklikler, oyuncuların eylemleri ve mesajlaşma dahil olmak üzere gerçek zamanlı kullanıcı etkileşimlerini işlemeye ihtiyaç duyarlar. iş yükü aktiflikte aniden artışlar ile pürüzsüz kalır. E-ticaret ve perakende iş yükü genellikle güncelleme ağırdır ve genellikle seri işleme içerir.Bu sistemler, doğru stok seviyelerini korumak, müşteri incelemelerini işlemek, sipariş durumunu izlemek ve genellikle güncelleştirmeler yapmadan önce mevcut verileri okumak gerektiren alışveriş sepetleri operasyonlarını yönetmek zorundadır. Reklam Teknolojisi ve Gerçek Zamanlı Teklif Sistemleri, bölünmüş saniyelik kararlar gerektirir.Bu sistemler, görüntüleme izleme ve ihracat sonuçları da dahil olmak üzere karmaşık teklif işlemlerini ele alırken, aynı zamanda tıklamalar ve dönüşümler gibi kullanıcı etkileşimlerini de izler. Gerçek zamanlı Borsa sistemleri, yüksek frekanslı ticaret işlemlerini, sürekli stok fiyatları güncellemelerini ve karmaşık sipariş eşleştirme süreçlerini desteklemeli - hepsi mutlak veri tutarlılığını ve minimum gecikmeyi korurken. Ardından, yazma performansını etkileyen ana mimari ve yapılandırma düşüncelerine bir göz atalım. Depolama Makinesi Mimarisi Depolama motoru mimarisinin seçimi temel olarak veri tabanlarında yazma performansını etkiler. iki ana yaklaşım vardır: LSM ağaçları ve B-Ağaçlar. ScyllaDB, Apache Cassandra, HBase ve Google BigTable gibi veritabanları, Log-Structured Merge Trees (LSM) kullanır. Bu mimari, büyük miktarlarda yazılar işlemek için idealdir. Yazılar anında belleğe bağlı olduğundan, bu çok hızlı bir başlangıç depolama sağlar. Hafızadaki “memtable” dolduğunda, son yazılar diske sıralı bir şekilde yıkanır. Bu da rastgele I/O ihtiyacını azaltır. Örneğin, ScyllaDB yazma yolu nasıl görünüyor: B-ağaç yapıları ile, her yazma işlemi, ağaçta bir düğmeyi konumlandırmak ve değiştirmek gerektirir - ve bu hem sıralı hem de rastgele I/O içerir. veri kümesi büyüdükçe, ağaç ek düğmelere ve yeniden dengelenmeye ihtiyaç duyabilir, daha fazla disk I/O'ya yol açabilir, bu da performansını etkileyebilir. Payload Boyutları Payload büyüklüğü de performansı etkiler. Küçük payloads ile, geçiş iyi ama CPU işleme ana şişliktir. payload büyüklüğü arttıkça, genel geçiş daha düşüktür ve disk kullanımı da artar. Sonuçta, küçük bir yazma genellikle tüm tamponlara uyum sağlar ve her şey oldukça hızlı bir şekilde işlenebilir. Bu yüzden yüksek geçiş elde etmek kolaydır. Daha büyük payloads için, daha büyük tamponlar veya daha fazla tamponlar atamanız gerekir. Daha büyük payloads, o payloads hizmet etmek için daha fazla kaynak (ağı ve disk) gereklidir. Kompresyon Disk kullanımı, yazma ağır bir iş yükü ile yakından izlenmesi gereken bir şeydir. depolama sürekli daha ucuz olmasına rağmen, hala ücretsiz değildir. Sıkıştırma işleri kontrol altında tutmaya yardımcı olabilir – bu yüzden sıkıştırma stratejinizi akıllıca seçin.Hızlı sıkıştırma hızı yazma ağır iş yükleri için önemlidir, ancak mevcut CPU ve bellek kaynaklarınızı da dikkate alın. bakın bakalım bakalım Kompresyon temel olarak verilerinizi daha küçük bloklara (veya parçalara) bölünür ve daha sonra her bir blokı ayrı ayrı sıkıştırır.Bu ayarı ayarlarken, daha büyük parçaların okuma için daha iyi olduğunu ve daha küçük parçaların yazılar için daha iyi olduğunu fark edin ve kullanışlı yükünüzün boyutunu dikkate alın. Kompresyon Parametreleri Parametreleri Şefkat LSM tabanlı veritabanları için seçtiğiniz sıkıştırma stratejisi yazma performansını da etkiler. sıkıştırma, okuma performansını optimize etmek, disk alanını geri kazanmak, veri parçalanmasını azaltmak ve genel sistem verimliliğini korumak için daha az, daha düzenli dosyalara birleştirmeyi içerir. Kompresyon stratejilerini seçerken, okuyucuları olabildiğince verimli hale getiren düşük okuma amplifikasyonunu hedefleyebilirsiniz. Ya da, kompresyonun çok agresif olmasını önleyerek düşük yazma amplifikasyonunu hedefleyebilirsiniz. Ya da, düşük alan amplifikasyonunu önceliklendirebilir ve kompresyon temizleme verilerini olabildiğince verimli hale getirebilirsiniz. Örneğin, ScyllaDB sunar. (Cassandra da benzer teklifler sunuyor): Çeşitli Kompozisyon Stratejileri Boyut düzeyinde sıkıştırma stratejisi (STCS): Sistemde yeterli (varsayılan olarak dört) benzer boyutlu SSTables olduğunda tetiklenir. Seviyeli sıkıştırma stratejisi (LCS): Sistem, farklı düzeylerde dağıtılan küçük, sabit boyutlu (varsayılan olarak 160 MB) SSTables kullanır. Incremental Compaction Strateji (ICS): STCS ile aynı okuma ve yazma amplifikasyon faktörlerini paylaşıyor, ancak 2x geçici uzay amplifikasyon sorununu, daha küçük (1 GB varsayılan olarak), üstesinden gelmeyen SSTables'lerin bir gruptan oluşan SSTable sürümlerine büyük sstables'leri kırarak düzeltiyor. Zaman penceresi sıkıştırma stratejisi (TWCS): Zaman serisi verileri için tasarlanmıştır. Yazma ağır iş yükleri için, kullanıcıları her ne pahasına olursa olsun seviyeli sıkıştırmayı önlemeye uyarırız.Bu strateji okuma ağır kullanım durumları için tasarlanmıştır. Kullanımı üzücü 40x yazma amplifikasyonuna neden olabilir. bataklık ScyllaDB ve Cassandra gibi veritabanlarında, gruplandırma aslında biraz tuzak olabilir - özellikle yazma ağır iş yükleri için. Eğer ilişki veritabanlarına alışkınsanız, gruplandırma, büyük bir yazma hacmini yönetmek için iyi bir seçenek gibi görünebilir. Ama aslında dikkatli yapılmazsa işleri yavaşlatabilir. Bu, esas olarak, büyük veya yapılandırılmamış gruplar, düğümler arasında çok fazla koordinasyon ve ağ üstü yaratmaya başlar. Ancak, ScyllaDB gibi dağıtılmış bir veritabanında gerçekten istediğiniz şey bu değildir. İşte ağır yazılar ile uğraştığınızda gruplandırma hakkında nasıl düşünürsünüz: Bölüm anahtarına göre gruplandırma: Yazılarınızı bölme anahtarına göre gruplandırın, böylece grup aynı zamanda verileri de sahip olan bir koordinatör düğmesine gider. Böylece, koordinatör ekstra veriler için diğer düğmelere erişmek zorunda kalmaz. Parçaları Küçük ve Hedefli tutun: Büyük parçaları bölünerek daha küçük parçalara bölünerek işleri verimli hale getirir. Ağın aşırı yüklenmesini önler ve her düğmeye yalnızca sahip olduğu veriler üzerinde çalışmasına izin verir. Kayıt dışı gruplara tutun: Önceki noktaları takip ettiğinizi düşünürsek, kayıt dışı grupları kullanmak en iyisidir.Kayıt dışı gruplar, yazmayı gerçekten yavaşlatabilecek ek tutarlılık kontrollerini ekler. Yani, yazmak zor bir durumda iseniz, büyük, çapraz düğümlü grupların getirebileceği gecikmelerden kaçınmak için gruplarınızı dikkatlice yapılandırın. Çekiliş Up Birkaç uyarı sunmuştuk, ama endişelenmeyin. Öğrenilen derslerin bir listesini oluşturmak kolaydı, çünkü çok sayıda ekip gerçek zamanlı yazma ağır iş yükleriyle çok başarılı. Daha fazlasını öğrenmek istiyorsanız, oldukça ilginç yazma zorlu zorluklarla uğraşan ekiplerden ilk el bakış açıları şunlardır: Zillow: Birden fazla veri üreticisinin kayıtlarını tüketen, bu da yanlış güncelleştirmelere yol açabilecek sorunsuz yazılar getirdi Tractian: IoT cihazlarından yüksek frekanslı verilerde 10 kat artışa hazırlanmak Fanatikler: Siparişlerin işlenmesi, alışveriş sepetleri ve bu çevrimiçi spor perakendecileri için ürün güncellemeleri gibi ağır yazma işlemleri Zeynep Trakya fanatikler Ayrıca, bu yazma zorlu zorlukları daha da derinleştirdiğimiz ve aynı zamanda bu çalışma yüklerinin ScyllaDB'de nasıl göründüğünü izleyebileceğimiz aşağıdaki videoda bir göz atın.
