LSM-tree tabanlı veritabanları geleneksel olarak yazma işlemleri için optimize edilmiştir, ancak belirli bir anahtarı arama (seek) performansı genellikle bir zorluktur. Bir anahtar arandığında, birden fazla SSTable'da bloom filtreleri kontrol etmek, diskten blok dizinlerini yüklemek, dizin içinde ikili arama yapmak, bloğu okumak ve sıkıştırmayı açmak gibi adımlar disk G/Ç'ye yol açarak gecikmeleri artırır. RocksDB gibi popüler veritabanları bu sorunu blok ve tablo önbellekleme ile ele alsa da, TidesDB bu alanda önemli bir iyileştirme sunuyor.
TidesDB'nin mimarisi, SSTable meta verilerini agresif bir şekilde bellekte tutma kararına dayanıyor. Bu, blok dizinleri, bloom filtreleri, minimum/maksimum anahtarlar ve dosya tanıtıcıları gibi kritik bilgilerin bellek baskısı gerektirmedikçe serbest bırakılmamasını içerir. Bu yaklaşım, disk G/Ç'yi ortadan kaldırmak için daha fazla bellek kullanma ödünleşimini açıkça kabul eder. Yapılan karşılaştırmalı testlerde, TidesDB'nin rastgele aramalarda RocksDB'ye göre 4.17 kat, sıralı aramalarda ise 4.74 kat daha hızlı olduğu gözlemlendi.
Bu performans farkının temel nedenleri arasında TidesDB'nin "önbellek-öncelikli" arama yolu ve blok dizinlerinin sürekli bellekte tutulması yer alıyor. Bir anahtar arandığında, TidesDB önce önbelleğe bakar. Eğer blok önbellekteyse, sıfır disk G/Ç, sıfır sıkıştırma açma yükü ve doğrudan belleğe erişim sağlanır. Bu, arama işlemini tamamen bellek içi operasyonlara dönüştürerek syscall'ları, sıkıştırmayı ve serileştirmeyi ortadan kaldırır. Bu tasarım kararları, TidesDB'yi özellikle arama performansı kritik olan iş yükleri için cazip bir seçenek haline getiriyor.
TidesDB'nin agresif bellek içi önbellekleme stratejisi, geleneksel LSM-tree veritabanlarının arama performansı sınırlamalarını aşarak önemli hız avantajları sağlıyor.