- rqlite, Go ile yazılmış hafif, açık kaynaklı, dağıtık ilişkisel bir veritabanıdır
- Raft uzlaşma protokolü üzerine kuruludur ve depolama motoru olarak SQLite kullanır
- 9.0 geliştirmesi başladı ve hedef, disk kullanımını yaklaşık %50 azaltmak
- Bu hedefe, rqlite’ın disk tüketiminin başlıca nedenlerini ortadan kaldıracak yüksek seviyeli bir tasarım değişikliğiyle ulaşılması planlanıyor
Mevcut disk kullanımının ana kaynağı nedir?
- Raft günlüğü:
- Sistemdeki değişikliklerin günlüğü
- Bu günlük, Raft uzlaşma sisteminin çekirdeğidir
- Çalışan SQLite veritabanı:
- rqlite’ın okuma ve yazma sağlamak için kullandığı canlı veritabanı
- SQLite ifadeleri Raft günlüğüne başarıyla commit edildikten sonra bu ifadeler çalışan SQLite veritabanına uygulanır
- Çalışan SQLite veritabanının snapshot’ı:
- Raft günlüğünün sınırsız büyümesini önlemek için rqlite içindeki Raft alt sistemi, belirli aralıklarla çalışan SQLite veritabanının belirli bir andaki kopyasını oluşturur ve saklar
- Bu kopyaya snapshot denir
- Snapshot oluşturulduğunda rqlite, Raft günlüğünü budayabilir
- Snapshot alınmış bu kopya, düğüm yeniden başlatıldığında rqlite’ın düğümü geri yüklemesi için kullanılır veya başka bir düğümün mevcut rqlite kümesinin durumunu "yakalamak" zorunda kaldığında o düğüme gönderilir
- Snapshot oluşturma ve günlük budama, Raft tabanlı sistemlerin temel kavramlarıdır
rqlite 9.0 için yüksek seviyeli tasarım
- Disk kullanımını azaltmanın ana stratejisi, Raft sisteminde çalışan SQLite veritabanının snapshot kopyasını saklama gereğini ortadan kaldırmaktır
- Raft günlüğü, snapshot oluşturma nedeniyle düzenli olarak budanır ve belli bir noktadan sonra büyümeyi durdurur, ancak çalışan SQLite veritabanı daha fazla veri yazıldıkça büyümeye devam eder
- SQLite veritabanının snapshot kopyası da çalışan SQLite veritabanıyla neredeyse aynı boyutta olduğu için o da büyür
- Bu nedenle, eğer snapshot kopyası kaldırılabilirse rqlite %50 daha az disk kullanacaktır
- Ancak rqlite düğümünün bazı anlarda snapshot alınmış bir kopyaya ihtiyacı vardır. Bundan kaçınılamaz.
- Peki kopyayı atlayıp yine de snapshot oluşturma ve geri yükleme gereksinimleri nasıl karşılanabilir?
- Snapshot sürecinde ek bir kopya saklamadan bunun nasıl önlenebileceğini anlamak için, rqlite’ın alttaki SQLite veritabanını Write-Ahead Log (WAL) modunda çalıştırdığını bilmek önemlidir
- Önerilen 9.0 tasarımında, çalışan SQLite veritabanı dosyası (ilgili WAL dosyası hariç) ile Raft sisteminin snapshot kopyası mantıksal olarak aynıdır
- Bu gerçekten yararlanılarak Raft sisteminde ayrı bir snapshot kopyası saklama gereği ortadan kaldırılabilir
Snapshot oluşturmaya yeni yaklaşım
- Snapshot oluşturma ve WAL checkpointing:
- Snapshot oluşturma anında rqlite, çalışan SQLite veritabanının Write-Ahead Log (WAL) dosyasına checkpoint uygular
- Bundan sonraki tüm yazmalar yeni bir WAL dosyasına yönlendirilir, böylece ana SQLite dosyası snapshot’ın oluşturulduğu andan itibaren değişmeden kalır
- Sonuç olarak bir sonraki snapshot oluşana kadar ana SQLite dosyası, Raft snapshot deposu için gereken zaman noktasındaki durumu temsil eder
- Bu yaklaşım sayesinde normal okuma ve yazma işlemleri birleştirilmiş SQLite dosyası ve WAL dosyasıyla yapılırken, değişmeyen ana SQLite dosyası Raft snapshot deposunun veri kümesi işlevini görür
- Artık ek bir kopyaya gerek yok!
- Snapshot deposuna referans yazma:
- Tüm SQLite dosyasını kopyalamak yerine rqlite, checksum gibi bir referansı snapshot deposuna yazar
- Bu referans, snapshot verisine ihtiyaç duyulduğunda ana SQLite dosyasının snapshot deposunun işaret ettiği veriyle eşleşip eşleşmediğini doğrulamak için kullanılabilir
- (Bu doğrulama hata, operasyonel yanlışlık veya disk bozulmasına karşı koruma sağlar, ancak kesin olarak gerekli değildir)
- Snapshot’tan geri yükleme:
- Daha önce belirtildiği gibi, snapshot sürecinden sonraki tüm yazmalar WAL dosyasına yönlendirildiği için ana SQLite dosyası, düğüm yeniden başlatıldığında veya snapshot başka bir düğüme gönderildiğinde olduğu gibi snapshot’tan geri yükleme sürecinde kullanılmaya hazırdır
- Yani ana SQLite dosyası (ilgili WAL dosyası yok sayıldığında), eğer rqlite gerçekten fazladan bir kopya oluştursaydı Raft snapshot deposuna yazılmış olacak olanla mantıksal olarak aynı kalır
- Bu yeni tasarıma "referans snapshot" adı veriliyor
Bonus iyileştirmeler
- Referans snapshot, birkaç önemli iyileştirme daha getirecek
- Daha hızlı snapshot oluşturma: Raft snapshot deposuna minimum veri yazıldığı için snapshot süreci çok daha hızlı olacak
- Bu süre, SQLite WAL checkpoint süresiyle (genelde çok kısadır) checksum hesaplama süresinden oluşacaktır
- Her snapshot oluşturulduğunda büyük miktarda SQLite verisini snapshot deposuna kopyalamak gerekmeyecek
- Snapshot süreci boyunca rqlite’a yazmaların engellendiği düşünüldüğünde, daha hızlı snapshot’ın avantajı açıktır
- Daha hızlı yeniden başlatma: Birkaç GB’lık SQLite verisi olan düğümler bile çok daha hızlı yeniden başlatılacak
- Şu anda yeniden başlatma sırasında rqlite, çalışan SQLite veritabanı dosyasını Raft snapshot deposundaki kopyadan geri yüklemek zorundadır
- Ancak bu yeni tasarımda başlangıçta çalışan SQLite veritabanı dosyası zaten doğru konumda olacaktır
- En fazla rqlite, snapshot deposundaki checksum ile çalışan SQLite veritabanının checksum değerini karşılaştırmak zorunda kalacaktır
- Birden fazla GB büyüklüğündeki sistemler birkaç saniye içinde yeniden başlatılabilmelidir
Sonraki adımlar
- rqlite 9.0’a geçiş, rqlite’ın verimliliğini optimize etmede önemli bir adım olacak
- Referans snapshot uygulanarak disk kullanımının önemli ölçüde azaltılması, snapshot oluşturma hızının artırılması ve düğüm yeniden başlatma sürelerinin iyileştirilmesi bekleniyor
- SQLite WAL yönetimi, önceki sürümlerden sorunsuz yükseltme ve checksum seçimi gibi doğru ele alınması gereken birçok ayrıntı var
- Bu nedenle, bu büyük sürüme doğru ilerlenirken ek güncellemeleri takip etmekte fayda var
1 yorum
rqlite - SQLite tabanlı hafif dağıtık veritabanı