Dolt: Veritabanına git gibi dal, fark ve birleştirme

İki kötü seçenek

Değişen bir veriyi saklamak için genelde iki yol var.

Birincisi veriyi gerçek bir veritabanına koymak. SQL, indeksler, kısıtlar, hepsi elinde. Ama biri bir satırı değiştirdiğinde bunu inceleyecek bir süreç yok. “Bu kaydı kim değiştirdi?” sorusunun cevabı çoğu zaman “veritabanına erişimi olan biri”.

İkincisi veriyi CSV, JSON ya da YAML dosyası olarak git’e koymak. Artık commit’ler ve pull request’ler var. Ama SQL yok, şema kontrolü zayıf, satır bazında fark okumak ve birleştirmek zor.

Dolt bu ikisini birleştiriyor.

Dolt nedir?

Dolt, Go ile yazılmış, Apache-2.0 lisanslı bir SQL veritabanı. MySQL ile uyumlu: Bir sunucu olarak çalıştırınca uygulaman, ORM’in ya da raporlama aracın onu sıradan bir MySQL gibi görüyor. Postgres uyumlu kardeşi Doltgres ise henüz beta aşamasında.

Farkı, git’i bilen birine hemen tanıdık gelen komutlarda:

• dolt branch ve dolt checkout -b ile veritabanının bir dalını açıyorsun.
• Tablolarda değişiklik yapıyorsun.
• dolt diff hangi satırın, hangi sütunun eskiden ne olduğunu ve şimdi ne olduğunu gösteriyor. “Bir dosya değişti” demiyor, değişen hücreyi gösteriyor.
• dolt commit ile kaydediyorsun, dolt merge ile ana dala birleştiriyorsun, dolt log ile geçmişi görüyorsun.

Aynı işlemler SQL içinden de yapılabiliyor. Sürüm komutları saklı yordamlar olarak, geçmiş ve farklar da sistem tabloları olarak sunuluyor. AS OF ile bir tabloyu geçmişteki bir anda nasıl göründüğüyle sorgulayabiliyorsun.

Her commit’te bütün veritabanı kopyalanmıyor mu?

Hayır. Dolt, verisini prolly tree denen bir yapıda saklıyor. Bu, veritabanlarının hızlı okuma ve yazma için kullandığı ağaç yapısının, sürümlemeye uygun bir türü.

Fikir şu: Veri parçalara bölünüyor ve her parçanın adresi, içeriğinin özetinden (hash) üretiliyor. İki sürümde aynı kalan parçalar aynı adrese sahip, bu yüzden sadece bir kez saklanıyor. Tek bir satır değiştiğinde sadece o satırdan köke giden kısa yol yeniden yazılıyor. Yeni bir dal açmak neredeyse bedava. İki sürüm arasındaki farkı bulmak da bütün tabloyu taramayı değil, sadece adresleri farklı olan parçaları karşılaştırmayı gerektiriyor. Yani fark hesaplamanın maliyeti, verinin boyutuna değil, değişikliğin boyutuna bağlı.

Ajanlar için neden ilginç?

Bir yapay zekâ ajanına üretim veritabanına yazma izni vermek korkutucu. Dolt’ta ajan kendi dalında çalışabiliyor. Sen farkı inceleyip beğenirsen birleştiriyorsun, beğenmezsen dalı silip geçiyorsun. Bu, kodda zaten alıştığımız “PR aç, incele, birleştir” akışının veriye taşınmış hâli.

DoltHub’ın Ocak’taki yazısında da bu tartışılıyor: Carnegie Mellon’dan veritabanı profesörü Andy Pavlo’nun, ajanların değişiklikleri hızlıca denemek için veritabanı dallarına ihtiyaç duyduğu tespitinden yola çıkılıyor. Dolt’un cevabı, sadece dal değil, fark ve birleştirme de sunmak.

Ne zaman kullanmalı?

Videonun önerisi ölçülü: Her üretim sistemine körü körüne koyma. Ama zamanla değişen ve yanlış bir değişikliğin bir şeyleri bozabileceği yapılandırılmış verin varsa denemeye değer. Örneğin makine öğrenmesi için etiketlenmiş veriler, oyun ayarları, test verileri ya da iç araçların kullandığı yapılandırma tabloları.

Düşün

• Projende “keşke kimin, neyi, ne zaman değiştirdiğini görebilsem” dediğin bir tablo var mı?
• Bir ajanın veritabanında yaptığı değişikliği, kod incelemesi gibi incelemek nasıl bir süreç olurdu?

Kendi cümlelerimizle yazılmış bir özettir, çeviri değildir. Tüm kaynaklar yukarıda.