MongoDB 8.2'te şifreli substring arama, insert başına şifreli eşitlikten 20 kat pahalı

Substring sorguları şifreli alanlara ulaşıyor

MongoDB 8.2, Queryable Encryption alanlarına karşı prefix, suffix ve substring aramaları için genel önizleme desteğini sundu; bu, üç yeni aggregation operatörüyle sağlanıyor: $encStrStartsWith, $encStrEndsWith ve $encStrContains. Bu sürümden önce şifreli bir alan yalnızca eşitlik veya aralık ile sorgulanabiliyordu — SQL'deki LIKE '%foo%' ifadesinin şifreli bir karşılığı yoktu. dev.to'da yayınlanan bir benchmark, yeni yeteneğin gerçekte neye mal olduğunu ölçüyor ve öne çıkan rakam oldukça yüksek: substring aranabilir şifreli bir alana sahip bir koleksiyona belge eklemek, şifreli eşitlik için indekslenmiş aynı alana kıyasla belge başına yaklaşık 20 kat daha yavaştı.

Gönderide anlatıldığı şekilde test kurulumu, MongoDB 8.2.12 Community Edition'ı tek düğümlü bir replica set olarak (Queryable Encryption için bir gereklilik) PyMongo 4.18.1, crypt_shared sorgu analizi kütüphanesi ve yerel bir KMS anahtarıyla çalıştırdı. Yazar yaygın bir varsayımı da düzeltiyor: otomatik Queryable Encryption için Enterprise sürümü gerekmiyor. crypt_shared ücretsiz bir indirme ve tüm yapılandırma, herhangi bir sorun çıkarmadan standart Community Edition üzerinde çalıştı.

Yazma ve depolama maliyeti

200 belge eklemek, substring aranabilir şifreli bir e-posta alanına sahip bir koleksiyona 4,6 saniye sürdü; buna karşılık yalnızca eşitlik şifrelemesiyle 232 milisaniye, şifresiz durumda ise 7 milisaniye sürdü. Belge başına bu, substring için 22,9 ms, eşitlik için 1,16 ms ve düz metin için 0,03 ms anlamına geliyor; ortalama belge boyutları sırasıyla kabaca 24 KB, 489 bayt ve 133 bayt.

Depolama daha sert bir ceza. Şifreli indeksi destekleyen gizli ESC ve ECOC metadata koleksiyonları da sayıldığında, 500 düz metin belge 66,5 KB, eşitlik şifrelemesi 319,5 KB ve substring şifrelemesi 25,3 MB yer kaplıyor — düz metnin yaklaşık 380 katı, eşitliğin 79 katı. dev.to gönderisi nedenini açıklıyor: sorgu uzunluk aralığı 3–10 karakter olarak ayarlandığında, MongoDB bu aralıktaki her substring için eşleşebilir bir token önceden üretmek zorunda ve ECOC koleksiyonu e-posta adresi başına yaklaşık 173 token içeriyordu — 500 belge için 86.500 kayıt.

Yapılandırmadaki katı sınırlar

Sınırlar tavsiye niteliğinde değil, zorunlu. Gönderiye göre, azami uzunluğu 40 olarak belirlenmiş bir alana 47 karakterlik bir dize eklemek, sunucuya herhangi bir şey ulaşmadan önce istemci tarafında başarısız oluyor; üç olarak yapılandırılmış bir asgari değere karşı iki karakterlik bir substring ile sorgulamak da öyle. Şifreli bir alana düz bir $regex ise sessizce hiçbir sonuç döndürmek yerine doğrudan reddediliyor.

Daha büyük tasarım kısıtı ise bir alanın en fazla iki sorgu türü taşıyabilmesi ve tek geçerli ikilinin prefixPreview artı suffixPreview olması. SubstringPreview hiçbir şeyle birleştirilemiyor — eşitlikle bile — dolayısıyla aynı mantıksal değerde hem substring hem eşitlik eşleşmesi gerektiren bir şema, şu anda aynı düz metni tutan iki ayrı şifreli alan gerektiriyor. Birleşik bir prefix-ve-suffix alanı testte doğru çalıştı: insert başına 4,3 ms (hâlâ düz metin taban çizgisinin yaklaşık 130 katı) ve belge başına kabaca 2.500 bayt, yalnızca substring'in gerektirdiğinin onda biri.

Sorgu hızı ve bir benchmark tuzağı

500 belge üzerinde $encStrContains, bir test dizesi için 112 belgeyi en hızlı çalışmada 25,3 ms'de eşleştirdi; eşdeğer düz metin regex'i ise 1,0 ms sürdü — yaklaşık 25 kat daha yavaş, sonuç kümeleri aynıydı, dolayısıyla söz konusu olan yalnızca maliyetti, doğruluk değil.

Yazarın ilk eşzamanlılık testi on Python thread'i ile 17 katlık bir yavaşlama gösterdi, ancak bu, veritabanından çok interpreter kilosunu ölçüyormuş: bu operatörler için sorgu analizi crypt_shared içinde istemci tarafında gerçekleşiyor ve CPU'ya bağlı olduğundan, sunucu davranışından bağımsız olarak thread'ler seri hale geliyor. Her biri kendi istemcisine sahip on ayrı süreçle yeniden çalıştırıldığında yavaşlama 2 kata yakındı. Python'dan istemci tarafı şifrelemeyi benchmark yapacak herkes için faydalı bir uyarı.

İzleme için db.serverStatus().fle, bir dağıtımdaki şifreli alanlarda hangi sorgu türlerinin kullanımda olduğuna dair canlı sayıları gösteriyor — yazarın bulduğu tek bakışta benimseme kontrolü. Gönderide atıf yapılan MongoDB'nin kendi dokümantasyonu, özelliği önizleme olarak işaretliyor: üretime uygun değil ve nihai genel kullanılabilirlik sürümüyle uyumsuz.

Neden önemli

Bunlar, çoğu ekibin etkinleştirmesi kolay ama çalıştırması pahalı bir özellik için göreceği ilk somut rakamlar. Queryable Encryption'ın substring aramasını değerlendiren herkes artık modelleyebileceği somut yazma, depolama ve gecikme maliyetlerine sahip: eşitlik şifrelemesinin yaklaşık 20 katı insert maliyeti, düz metnin iki büyüklük mertebesi ötesinde depolama ve minik bir veri kümesinde bile yaklaşık 25 kat daha yavaş eşleşme. Benchmark bir lisanslama sorusunu da çözüyor — yığın ücretsiz Community Edition üzerinde çalışıyor — ve özellik yalnızca önizleme aşamasında olsa bile bugün tasarım kararlarını zorunlu kılan, substring'in eşitlikle bir alanı paylaşamaması gibi şema kısıtlarını belgeliyor.