Redis 8.10 compact hashes: gerçek bellek tasarrufu için HIMPORT veya yeniden başlatma gerekiyor

Redis 8.10'un compact hashes özelliğine yönelik bağımsız benchmark'lar, öne çıkarılan bellek tasarrufunun şema yapısına göre büyük ölçüde değiştiğini — testlerde kabaca yüzde 20'den neredeyse yüzde 68'e kadar savrulduğunu — ve sıradan HSET komutlarıyla yazılan hash'lerin, operatör yeni HIMPORT komutuna geçmedikçe ya da yeni RDB yükleme ayarlarını etkinleştirip sunucuyu yeniden başlatmadıkça asla dönüştirilmediğini gösteriyor. Testler dev.to'da yayımlandı ve Redis 8.10.1 bir Docker container içinde çalıştırıldı.

Compact hashes Temmuz'da Redis 8.10 ile birlikte geldi: birçok hash aynı alan adlarını paylaşıyorsa, Redis bu adların her anahtar için tekrarlanması yerine tek bir kopyasını tutabiliyor. dev.to yazısına göre sürüm blogu yüzde 50'ye kadar daha düşük bellek ve 2 kat daha yüksek yükleme throughput'u iddia ediyor.

Tasarruf yüzde 20 ile yüzde 68 arasında değişti

Yazar 100.000 hash'i dört alanlı bir kullanıcı profili şemasıyla (name, email, country, last_login) iki şekilde yükledi: anahtar başına düz HSET ve HIMPORT — HIMPORT PREPARE ile bağlantı başına bir kez alan listesi bildirip ardından değerleri ona karşı yükleyen yeni bir komut çifti. Düz HSET hash başına 159,9 bayt kullanırken HIMPORT 127,6 bayt kullandı; bu, yüzde 20,2'lik bir azalma ve duyurulan üst sınırın oldukça altında. Özelliği kayıracak şekilde tasarlanmış ikinci bir şema — account_status_code ve two_factor_enabled_flag gibi uzun adlara sahip, kısa değerler tutan sekiz alan — hash başına 271,3 bayttan 87,3 bayta geriledi; yüzde 67,8'lik bir azalma. Tasarruf alan adlarının kendisinden geliyor; dolayısıyla bir şemanın bellek kullanımında değerlerden çok alan adlarının payı ne kadar büyükse kazanç da o kadar büyük.

Throughput iki kat değil, yüzde 35 arttı

Yöntem başına 500.000 hash üç kez yüklendi; en hızlı düz HSET çalışması 2,698 saniye (saniyede 185.323 hash), en hızlı HIMPORT çalışması ise 1,992 saniye (saniyede 251.004 hash) sürdü: yüzde 35'lik bir iyileşme, iddia edilenin iki katı değil. Yazar, blogdaki rakamın daha geniş şemaları ya da tekrarlanan alan adlarının ağ üzerinden atlanmasının yerel bir container pipe'ından daha çok fark yarattığı ağa bağlı istemcileri yansıtıyor olabileceğini tahmin ediyor.

Mevcut HSET verisi yalnızca HIMPORT veya yeniden başlatmayla dönüşür

Asıl operasyonel sorun burada. Aynı şemaya sahip 100.000 hash HSET ile yüklendikten sonra INFO stats, hash_templates değerini sıfır gösterdi: Redis, canlı hash'leri aynı alan kümesini paylaştıklarını tespit edip birleştirmek yerine oldukları gibi bırakıyor. Dönüşüm yalnızca HIMPORT üzerinden ya da üç yeni yapılandırma parametresi — hash-rdb-load-min-template-entries, hash-rdb-load-max-template-entries ve hash-rdb-load-template-disassembly-threshold — ayarlanmışken bir RDB dosyasının yeniden yüklenmesiyle gerçekleşiyor; hepsi varsayılan olarak sıfır, yani kapalı. Ayarlar etkinleştirildiğinde, bir BGSAVE ve ardından container yeniden başlatması 100.000 hash'in tamamını tek bir paylaşılan şablona dönüştürdü ve used_memory 17.459.464 bayttan 14.182.656 bayta düştü; doğrudan karşılandırla tutarlı yüzde 18,8'lik bir kesinti. Yazara göre pratik sonuç şu: süresiz ayakta kalan ve hiç HIMPORT yazımı almayan bir primary, bu özellikten hiçbir kazanç elde etmiyor.

Küçük gruplar ve şema dışı alanlar belleğe mal olabilir

Şablonlar sabit yük taşıyor. MEMORY USAGE, iki anahtarlı bir şablondaki bir anahtarı 156 bayt, üç anahtarlı bir şablondaki bir anahtarı 129 bayt olarak rapor etti; ikisi de 112 baytlık düz hash taban çizgisinden kötü. Kesişim noktası dört ile beş anahtar civarında ve tasarruf 100 anahtar yakınında, 76 baytta düzleşiyor.

Şablonlu bir hash'i değiştirmek de beklenmedik biçimde davranıyor. Şema dışı bir alanı HSET ile eklemek anahtarı düz kodlamaya geri döndürmedi — Redis onun için yeni bir tek anahtarlı şabolun çatalladı ve anahtar 76 bayttan 265 bayta çıktı; başka bir anahtardaki HDEL ise 208 bayt üretti. İkisi de düz taban çizgisini aşıyor; dokunulmayan anahtarlar etkilenmedi.

HIMPORT alan kümeleri bağlantı başına kapsamlıdır

HIMPORT PREPARE ile hazırlanan alan kümeleri sunucuda değil bağlantıda yaşar. Yanlış değer sayıları ve bilinmeyen alan kümesi adları hata döndürür; bir redis-cli oturumunda hazırlanan bir alan kümesi başka bir oturumdan kullanılamaz — bu, bağlantı havuzlu istemcilerin her havuzlanmış bağlantıda PREPARE çalıştırması ya da bir import'u tek bir bağlantıya sabitlemesi gerektiği anlamına geliyor. RESET alan kümelerini anında düşürür. Eşzamanlılık自身ü kendini tuttu: her biri kendi şemasını hazırlayıp 2.000 ayrık anahtar yazan on paralel redis-cli --pipe süreci, toplamda üçte bir saniyenin altında sıfır hatayla tamamlandı.

Neden önemli

Yükseltme planlayan operatörler için bu benchmark'lar compact hashes'i otomatik bir iyileştirme değil, koşullu kazançları olan opt-in bir kodlama olarak çerçeveliyor. Mevcut HSET iş yükleri ya yeniden yazılmış bir yazma yolu ya da yeni yapılandırma artı veriyi tutan her düğümde yeniden başlatma veya failover gerektiriyor. Uzun alan adları ve kısa değerlerden oluşan şemalar en çok kazanıyor; tek bir alan kümesi altındaki küçük hash grupları ya da şema dışı alan ekleyen uygulamalar daha önce olduğundan fazla bellek kullanabilir. Taahhütte bulunmadan önce kendi anahtarlarınızı MEMORY USAGE ile ölçmek, hangi tarafta olduğunuzu anlamanın güvenilir yoludur.