ParticleDB'nin ACID Sertifikasyonu: Jepsen Testleriyle Ortaya Çıkan Gerçekler

0:00

/0

1×

ParticleDB'nin ACID Sertifikasyonu: Jepsen Testleriyle Ortaya Çıkan Gerçekler

Modern uygulamalar, veri depolama süreçlerini birden fazla sisteme dağıtmak zorundadır: veritabanları, önbellekler, kuyruklar, veri ambarları, arama dizinleri ve benzeri. Bu sistemler arasında koordinasyon sağlamak oldukça zordur. Önbellekler genellikle eski olur, analitik platformlar ana veritabanından günlerce geride kalır, arama dizinleri veri kaybına uğrayabilir ve farklı sistemler arasında işlem güncellemeleri hâlâ açık bir araştırma konusudur.

ParticleDB, bu karmaşıklıkları tek bir motorla birleştirmeyi hedefleyen bir veritabanı çözümüdür. Özellikle AI agent ve uygulamalarına odaklanan bu sistem, işlemeli SQL, anahtar-değer depolama, vektör arama, canlı analitik süreçler ve kullanıcı tanımlı fonksiyonlar olan "Particles" sunar. PostgreSQL ve Redis protokolleri gibi çeşitli arabirimlerle entegre olabilmektedir. Rust dilinde geliştirilmiş olan ParticleDB, Postgres'e göre "onlarca kat daha hızlı" olmasıyla öne çıkmaktadır. Bu proje, Orkes tarafından Conductor adlı iş akışı düzenleme platformu için geliştirilmiştir. Conductor, başlangıçta Redis ve Postgres kullanıyordu ancak performansı artırmak için kendine özel bir veritabanı yazmaya karar vermiştir.

ParticleDB 1.0.0, ilk olarak Conductor için özel olarak geliştirilmiş ve sınırlı bir özellik setiyle sunulmuştur. Daha sonra, daha geniş bir piyasaya açılması için büyük bir yeniden yapılandırmaya tabi tutulmuştur. Bu yeniden yapılandırma, özel bir ağ protokolü, daha fazla veri türü, ek OLAP sorguları ve diğer özelliklerle birlikte gelmiştir. Orkes, bu yeni versiyonları particledb.ai üzerinde yumuşak bir şekilde tanıtmıştır. Bu süreçte, ParticleDB'nin güvenilirliğini doğrulamak amacıyla Jepsen testleri gerçekleştirilmiştir.

Jepsen, 1.1.4'ten 1.1.18.11.rc-22'ye kadar olan ParticleDB sürümlerini test etmiştir. Testlerde, ParticleDB'nin "Tam ACID" iddiasının bazı yönlerinin erken yapıldığı ortaya çıkmıştır. Özellikle, ParticleDB'nin tek düğümlü davranışına odaklanan bu testler, çoğulama özelliği yalnızca enterprise bulut dağıtımlarında mevcut olduğu için, bu raporda bu özelliği ele almamıştır.

Güvenlik ve Tutulum Özellikleri

ParticleDB'nin ev sayfasında, "formal olarak kanıtlanmış" olduğu belirtilmiştir. Ancak iş birliği süreci sırasında hiçbir TLA+ belgesi sunulmamıştır. Bu durum, hangi özelliklerin kanıtlandığı ve bu kanıtların ParticleDB'nin gerçek haliyle uyumlu olup olmadığı konusunda belirsizlik yaratmaktadır.

ParticleDB, yazı logunun (WAL) senkronizasyonu için üç farklı mod sunar: fsync, groupsync ve nosync. fsync modu her işlemde bir fsync çağrısı yaparken, groupsync çoklu işlemi tek bir fsync ile gruplar. nosync ise fsync çağrılarını tamamen atlar. Dokümantasyon, sync modunun groupsync'dan daha güçlü bir tutulum sağladığını belirtirken, particledb start --help komutu, groupsync modunun "COMMIT, flush için bekler" anlamına geldiğini söyler. Orkes'in iç operatör kılavuzu da bu durumu destekler. Bu durum, ParticleDB'nin tutulum politikaları konusunda tutarsızlık olduğu anlamına gelir.

Yalnızca Bir Kısımlı İzolasyon: "Tam ACID" Gerçekleri

ParticleDB'nin ev sayfasında "Tam ACID. 159K TPS." ifadesi yer alır. Ancak bu ifadenin hemen altında "snapshot isolation" (snapshot izolasyon) belirtilmiştir. Bu, tam izolasyon anlamına gelmez. Çoğu SQL veritabanı, SET TRANSACTION ISOLATION LEVEL komutuyla işlem izolasyon seviyesini kontrol eder. Ancak ParticleDB, bu komutları ya reddeder ya da yok sayar. Bazı durumlarda kullanıcıları READ COMMITTED seçmeye yönlendirirken, diğer durumlarda farklı izolasyon seviyeleri istenmesine rağmen bunları sessizce yoksayar.

İzolasyon düzeyi, --txn-mode ayarına göre belirlenir. Dokümantasyon, dört farklı mod tanımlar:

• fast: Kilit almadan çalışır; commit-on-write kullanır. Toplu yükleme ve tek yazıcı benchmark'ları için uygundur.
• occ: Tablo kilidi ve commit zamanı OCC doğrulaması. Genel OLTP için uygundur ve aynı zamanda "konsantrasyon altında güvenli" olarak tanımlanır.
• zero-copy-occ: Partition-pinned OCC; tek bir partition içinde işlem yaparken çapraz partition koordinasyonu atlanır. Yüksek throughput'lu OLTP için uygundur.
• table-2pl: Tüm tablo kilidini ilk dokunuşta alır. En katı serileştirme düzeyini sağlar.

Bu modlar, kullanıcıların dikkatli seçim yapması gerektiğini belirtir. Ancak, bu modların ne kadar korumalı olduğunu açıkça belirtmez. Örneğin, fast modu açıkça daha zayıf izolasyonu hedeflerken, occ modu da ne kadar güvenli olduğu belirsizdir. "Commit-time OCC validation", Read Uncommitted'dan Strong Serializable'ye kadar geniş bir spektrumda tanımlanabilen bir modeli ifade edebilir. Ancak "konsantrasyon altında güvenli" ifadesi, bu modun Serializable olabileceğini ima eder.

zero-copy-occ modu, occ modu kadar güvenli olabilir, ancak "konsantrasyon altında güvenli" olarak tanımlanmamıştır. Bu durum, bu modun hangi yönlerde zayıf olduğunu sorgulamaya neden olur. Ayrıca, table-2pl modunun "en katı serileştirme" olduğunu söylerken, occ modunun daha zayıf bir izolasyon düzeyi olduğunu düşündürür.

CLI referans sayfasında, occ ve table-2pl modlarının "Jepsen güvenli" olduğu belirtilirken, fast modu güvenli değildir. Ancak bu terimlerin ne anlama geldiği açıklanmamıştır. Jepsen, güvenlik açısından belgeler ve pazarlama iddialarına göre değerlendirme yapar. Bu durumda, bu terimlerin yorumlanması zordur.

Yalnızca Bir Kısımlı İzolasyon: "Tam ACID" Gerçekleri

particledb start --help komutu, aşağıdaki tabloyu sunar:

Optimistic Concurrency Control (OCC) modelinin amacı genellikle kilit almayı engellemektir. Bu nedenle, "tablo kilidi" ve "row-2pl" alias'ının yer alması şaşırtıcıdır. Ayrıca, "çoğu OLTP için güvenli" ifadesi, occ modunun "konsantrasyon altında güvenli" olmayabileceğini düşündürür.

Sonuç: Gerçekler Ortaya Çıktı

Jepsen testleri, ParticleDB'nin "tam ACID" iddiasının bazı yönlerinde aşırı derecede iddialı olduğunu göstermiştir. Özellikle tutulum politikaları, izolasyon düzeyleri ve belgelerdeki tutarsızlıklar, sistemdeki güvenlik sınırlamalarını ortaya koymuştur. Bu testler, kullanıcıların sistemdeki bu durumları dikkate alarak karar vermesi gerektiğini vurgulamaktadır. ParticleDB, özellikle AI uygulamaları ve yüksek performanslı sistemler için potansiyel bir çözüm sunsa da, bu durumda doğrulanmış bir güvenilirlik düzeyi elde edilene kadar, "tam ACID" iddiası dikkatle ele alınmalıdır.