47 puan yazan xguru 2021-07-05 | 16 yorum | WhatsApp'ta paylaş
  • SQLite geliştiricisi Richard Hipp ile yapılan röportaj podcast’inin özeti (38 dakika, transkript mevcut)
  • Asıl işi, ABD Donanması’nın destroyerlerinde kullanılan yazılımları geliştirmekti
    → Gemi içinde kullanılan Informix sık sık hata veriyor, sunucu çöküyor ve bağlantı kopuyordu
    → Bu bir savaş gemisi olduğu için, çatışma sırasında hasar alsa bile “Veritabanına bağlanılamıyor” açılır penceresi göstermeden sağlam şekilde çalışması gerekiyordu.
    → Transaction’a da ihtiyaç yoktu; her durumda verinin RAM’e okunabilmesi gerekiyordu
    → Sunucusuz çalışan bir SQL DB motoru aradı ama bulamayınca kendisi yapmaya karar verdi

SQLite V1 (2000)

  • SQL ifadelerini bir program gibi düşünerek sorguları derleyip çalıştıran bir bytecode motoru yazdı
  • Aslında projede kullanılmadı (müşteri Informix kullanmak istiyordu)
  • Geliştirme amaçlı kullanırken internette yayımladı ve insanlar kullanmaya başladı
  • “Palm Pilot’ta SQL DB çalıştırdım” gibi yorumlar görmeye başladı ve bu insanların dikkatini çekti. Bu da onu çalışmayı sürdürmesi için teşvik etti.

Motorola

  • 2001~2002 arasında Motorola arayıp yeni telefon işletim sistemlerine SQLite koymak istediklerini söyledi
  • Gerekli özellikleri desteklerse ücret ödeyeceklerini belirttiler
  • Açık kaynakla para kazanılabildiğini ilk kez o zaman fark etti
  • Yaklaşık $80,000 idi; bugüne kıyasla çok büyük görünmeyebilir ama onun için inanılmaz bir miktardı
  • Birlikte çalıştığı üç kişiyle projeyi yürüttü ve başlangıç böyle oldu

America Online Phones

  • Sonraki arayan AOL oldu
  • O zamanlar CD’lerin postayla gönderildiği dönemdi ve o CD’nin içinde bir veritabanı gerekiyordu
  • Yani CD’ye SQLite eklemek istiyorlardı ve bunun için yeni özelliklere ihtiyaçları vardı

Symbian OS ve Nokia

  • Şükran Günü’nde Londra’ya gidip toplantı yaptı (İngiltere’de Şükran Günü olmadığı için)
  • Symbian OS için bir veritabanı istiyorlardı ve başka veritabanlarıyla rekabet etti (2 açık kaynak, 7 ticari)
  • Diğer 9 veritabanına da ayar yapma fırsatı verildi ama sonunda kazanan SQLite oldu

Bus Factor [1] ve konsorsiyum

  • Bus factor, birkaç kişinin başına bir şey gelirse geliştirmenin durma riskini ifade eden bir ölçü
  • Kendisi tam zamanlı olarak birkaç kişiyle çalışıyordu ama Symbian tarafı bus factor’ün artırılması gerektiğini söyledi
  • Bunun üzerine SQLite Consortium başlatılsın, projeye fon sağlansın ve daha fazla insan uzun vadeli olarak katılsın fikri ortaya çıktı
  • Başta, tüm konsorsiyum üyelerine oy hakkı vermek gibi çılgın bir fikir öne sürüldü
  • Mozilla Foundation’dan Mitchell Backer bunu bir yerden duyup aradı
    → “Richard, bunu tamamen yanlış yapıyorsun. Sana konsorsiyumun nasıl kurulacağını söyleyeyim.”
    → Kuralları oluşturmaya başladı
    → “Kontrol geliştiricilerde olmalı. Son karar onların olmalı. Sırf katıldıkları için oy hakkı almamalılar.”
    → “Bunu kullanan şirketler para vererek destek olma onurunu kazanır ama son kararı sen vermelisin.”
    → Çok kararlıydı ve her şeyi toparladı. Kendisi bir avukat
  • Richard “Peki insanları nasıl katacağız? Teşvik ne olacak?” diye sorunca
    → “Merak etme. Katılacaklar. Hatta bunu böyle yaparsan Mozilla kurucu üyelerden biri olur.”
  • Mozilla, Symbian ve Adobe’nin desteğiyle bu üç şirketle konsorsiyum başlatıldı
    → Başta Symbian konsorsiyuma ihtiyaç olduğunu söylediğinde ne yapacağını bilmiyordu. Mitchell Baker’ın bunu nasıl duyup aradığını bilmiyor ama tüm bunlar inanılmaz bir yolculuktu
Reklam

Enter Android : Android’in başlangıcı

  • Tüm akıllı telefonlar SQLite kullandığı için Richard erken dönem akıllı telefon gelişimini her açıdan görebildi
  • 2005’te Android ile toplantı yaptı. O zaman ne Android ne de iPhone piyasaya çıkmıştı
  • Üstte küçük ekranı ve tam QWERTY klavyesi olan BlackBerry benzeri bir telefona bağlanıp SQLite debug etti
  • Gerçek çalışan telefon şebekesine bağlı bir cihazda GDB ile debug yapmak inanılmaz bir deneyimdi
  • O sırada Motorola, Symbian ve Nokia’dan hiç kimse böyle bir şey yapmıyordu; o anda Android’in çok büyüyeceğini anladı

Guy, This Is Important : Arkadaşlar, bu gerçekten önemli

  • O dönemde diğer şirketlerde donanım ve yazılım güncelleme döngüsü yaklaşık 30 gün gibi çok uzundu; Android ise gerçek şebekeye bağlı telefonlara günde birkaç kez yeni OS yüklüyordu
  • NDA kapsamında aldığı prototip Android telefonun kasası 3D yazıcıdan çıkmış gibiydi ama taşınabilecek durumdaydı
    → Diğer şirketlerin cihazları büyük breadboard ve prototiplerden ibaretti; şebekeye bile bağlı değildi, telefon olarak kullanılamıyordu
  • Motorola ve Symbian’daki insanlara “Bu önemli, bunu çözmeniz gerekiyor” demek istedi ama NDA yüzünden söyleyemedi; farkı yaratan da bu oldu

Testing and Aviation Standards : Test ve havacılık standartları

  • Adam (röportajcı): “Richard’ın DB’si şu anda gerçekten canlı bir durumda. Yetenekli bir ekip var ama tüm Android telefonlarda kullanılan veritabanını destekleyen 1~4 kişilik bir yazılım danışmanlık şirketi bu. Geliştiriciler veritabanı konusunda çok titizdir ve veride sorun çıkmasından hoşlanmaz.”
  • Herkese biraz safça SQLite’ın bugsız olduğunu anlatıyorlardı ama Android bunun kesin olarak yanlış olduğunu kanıtladı
  • Hatasız yazılım yapılabileceğini düşünüyordu ama yazılım milyonlarca cihaza kurulduğunda ne kadar çok bug çıkabileceği gerçekten şaşırtıcıydı
  • O sıralarda bir aviyonik şirketi olan Rockwell Collins ile çalışıyordu; onlar DO-178B [2] kavramını tanıttı
    → DO-178B, güvenlik kritik havacılık ürünleri için kalite standardı ile ilgili ve diğer kalite standartlarının aksine “okunabilir”
    → Birkaç yüz dolar civarında ama ince bir doküman olduğu için mutlaka okunmasını tavsiye ediyor
  • Gerçekten DO-178B süreçlerini izlemeye başladılar; bunlardan biri de %100 MCDC test kapsamıydı
  • MCDC (Modified Condition / Decision Coverage) [3], testlerin tek tek dalların her birinden en az bir kez geçmesini gerektirir
  • SQLite’ın %100 MCDC’ye ulaşması haftada 60 saat çalışmayla 1 yıl sürdü. Gerçekten çok zordu. Her gün 12 saat çalışması gerekti ve çok yorucuydu
  • %90~95 test kapsamına ulaşmak kolay ama kalan %5 gerçekten çok zor. Ancak bunu 1 yıl boyunca yapıp sonunda %100’e ulaştıklarında Android’den bug raporu gelmemeye başladı
  • O andan itibaren işler yoluna girdi ve büyük fark yarattı. Sonrasında 8~-9 yıl boyunca bug gelmedi

Milyarlarca test

  • İlk testler TCL(Tool Command Language) ile yazıldı ve tipik geliştirici testleriydi
  • İlk TCL testleri hâlâ bakımı yapılıyor ve açık durumda. %100 değil ama SQLite’ın tüm özelliklerini ayrıntılı biçimde test ediyor
  • %100 MCDC kapsamına TH3 deniyor ve yayımlanmıyor (proprietary)
  • Bunu havacılık şirketlerine satarak para kazanmayı denediler ama bir tane bile satamadılar; yani o anlamda işe yaramadı
  • Ama ürünlerini gerçekten sağlam tutmalarını, yeni özellikleri ve bug düzeltmelerini hızlı denemelerini sağladı
  • Test sayısını saymak zor ama 100 bin ayrı test parametreleştirilerek milyarlarca test çalıştırılıyor
  • Bir kontrol listesi var ve sürümden önce en az 3 gün test yapılıyor
  • Kasıtlı olarak birden fazla OS üzerinde test yapıyorlar
    → Bugün neredeyse tüm cihazlar little-endian ama eskiden big-endian çoktu. Bu yüzden PowerPC iBook üzerinde big-endian testleri yapıyorlardı
    → 32 bit platformlar, ARM ve Intel, 64 Bit platformlar, Windows, Linux, Mac, OpenBSD gibi erişebildikleri tüm platform ve OS’lerde test yapıyorlar
    → Birden fazla farklı test suite’i var; orijinal TCL de var, TH3 de var. Sürekli çalışan fuzzer (fuzz testing) da var
  • SQL Logic testleri de var
    → 10 yıl önce Shane Harrelson’ın hazırladığı devasa bir SQL ifade yığını
    → Dokunabildikleri tüm veritabanlarında test ettiler ve Postgres hariç tüm DB motorları ya cevap veremedi ya da segmentation fault verdi. SQLite da dahil
    → Sadece Postgres her zaman sonuç verdi ve kusur bulamadılar. Postgres geliştiricileri yeterince uğraşmadıklarını söyledi ama... Postgres’i hata vermeye zorlamak belki mümkündü; yine de çok etkilendiler
    → Ticari Oracle sürümü de çöktü, DB2 de çöktü
    → Buradaki önemli nokta, SQLite’ın tüm bu sorgular için aynı cevabı verir hale getirilmiş olması

Building From First Principles

  • İlk yazmaya başladığında SQL DB motorunun nasıl yapılacağına dair bir referans aradı ama bulamadı. Bu yüzden kendisi yapmak zorundaydı; tamamen bağımsız bir görevdi
  • MIT, Harvard ve Berkeley’de pek çok teori geliştiriliyordu ama o okullara gitmediğiniz sürece böyle teorilerin varlığından bile haberdar olmuyordunuz, nasıl bulunacağını da bilmiyordunuz
  • Postgres’in kullandığı Volcano modeli ile SQLite’ın kullandığı bytecode modeli incelendiğinde, aslında herkesin aynı fikirlere yakınsadığı görülüyor
  • Yukarıdan bakınca çok farklı yerlerden başlıyor gibi görünse de, “bunu nasıl daha hızlı yaparız” sorusunda aynı noktaya varılıyor
  • Bunu teorik bir doğrulama gibi görüyor: birbirinden bağımsız iki geliştirme hattının aynı cevaba ulaşması
  • Örneğin covering index hakkında hiçbir şey bilmiyordu; Almanya’daki bir PHP konferansına katıldığında MySQL’den David Axmark da oradaydı ve bir konuşma yaptı
    → O sunumda MySQL’in covering index’i nasıl yaptığını anlattı
    → Veritabanı indeksinde birden fazla sütun varken, sorgu indeksin ön tarafındaki sütunları kullanıyor ve cevap kalan sütunlardaysa, DB özgün tabloya bakmadan sadece indeks üzerinden çalışabilir; bu da işi hızlandırır
    → Sonra eve dönerken uçakta çok az insan vardı; dizüstünü açıp Atlantik üzerinde SQLite için covering index’i implemente etti

B-Trees and The Art of Computer Programming

  • Pek çok şeyi kendisi inşa etmek zorunda kaldı. Ona hiç kimse B-Tree öğretmemişti; sadece adını duymuştu
  • Kendi B-Tree’sini geliştirmeye çalışırken rafta Don Knuth’un TAOCP kitabı vardı; oradan B-Tree’ye baktı ve Knuth algoritmayı açıkladı
  • Komik olan şu ki kitap B-Tree arama ve ekleme algoritmalarını ayrıntılı anlatıyor ama silme algoritmasını vermiyor. O bölüm sonu alıştırması olarak bırakılmıştı; yani kendi B-Tree’sini yapmadan önce soruyu çözmek zorundaydı. “Teşekkürler Don, gerçekten teşekkürler.”
  • Günümüz insanları en azından TAOCP’yi okumalı ya da en azından göz gezdirmeli
Reklam

Freedom to Build It Yourself : Kendin yapabilme özgürlüğü

  • SQLite, Richard’ın kendisinin yazdıkları dışında hiçbir şeye bağımlı değil (C derleyicisi ve libc hariç). Hatta kendi sürüm kontrol sistemini ve bug tracker’ını bile yaptı. Bu ona özgürlük sağlıyor
  • Özgürlük (Freedom), kendi kendine bakabilmek demek
  • Sırt çantalı gezen insanların ihtiyaç duydukları her şeyi yanlarında taşıyarak kendilerini özgür hissetmeleri, kendi ihtiyaçlarını kendilerinin karşılamasından kaynaklanır
  • Her şeyi kendiniz yaparsanız kimseye bağlı olmazsınız; özgürlük de tam burada
  • Diyelim ki SQLite 2’nin storage engine’i olarak Berkeley DB’yi seçmiş olsalardı
    → O zamanlar Berkeley DB açık kaynaktı ama sonra Oracle’a satıldı ve çift lisanslı kapalı bir modele dönüştü; lisans ücreti ödemeden en güncel kaynak koduna erişmek mümkün olmadı
  • Şu anda SQLite’ın parser generator’ı Yak ya da Bison değil, Lemon adını verdiği kendi yazdığı araç. Bu sayede yeni dil özellikleri gerektiğinde onlara bağımlı kalmadan değiştirebildi
  • 2000’lerin başında tüm projeler CVS kullanıyordu, o yüzden onu kullandı; ama 2000’lerin ortasında dağıtık sürüm kontrol fikri ortaya çıkmaya başladı

Fossil’i kurmak

  • Git ve Mercurial’a bakıp gereksinimleri çıkardıktan sonra kendi sürüm kontrol sistemini geliştirmeye karar verdi
  • Artık Fossil iyi çalışıyor ve kendi başına bir proje haline geldi
  • Torvalds, Linux Kernel geliştirmesini desteklemek için Git’i yaptı; dolayısıyla Linux Kernel ile ilgili iş yapıyorsanız Git mükemmel bir sürüm kontrol sistemi
  • Fossil ise SQLite üzerinde çalışmak için biçilmiş kaftan. Çünkü onu kendisi yaptığı için gereksinimlerini tam olarak karşılıyor
  • Bir şeyi kendin geliştirince kaderini kontrol ediyorsun, daha fazla özgürlüğün oluyor ve üçüncü taraflara bağımlı kalmıyorsun

Kendi kendine yetmek

  • Şehirden uzaklaşıp kendi yiyeceğini yetiştirerek yaşayan insana ne denir? Survivalist mi? Ya da prepper mı?
    “Seninle iletişim kurarken de gördüğün gibi Gmail’im biraz tuhaf davranıyor. Mailler geri dönüp duruyor. O yüzden kendi mail sunucumu kurmayı düşünüyorum. Bu toplantıyı ayarlarken bile bununla ilgili notlar alıyordum. Muhtemelen bir DB motoru yazmaktan daha zor değildir ama Gmail’e bağlı kalmak istemiyorum. Onların benim kaderimi kontrol etmesini istemiyorum. Tüm konuşmalarımın kayıtlarını onların yönetmesini istemiyorum. Kontrol bende olsun istiyorum; bu yüzden zahmetli ve yapılacak işi çok olsa da, kontrolü kendi elimde tutacak bir çözüm aramaya çalışıyorum. Bunu bulutta sanal makine kiralayıp çalıştırarak da üçüncü taraflara bağımlı olmadan yapabilirim.”
  • Eğer birisi gelip “Sorununu ben çözerim” diyorsa, bunun özgürlüğünü elinden alabileceğini bilmelisin. “Özgür olmak istiyorsan kendin yapmalısın.”

Başkaları için tavsiye

  • Ben, sunucuya ihtiyaç duymadan diskte doğrudan okuyup yazan bir DB motoru yapacağım gibi çılgın bir fikirle başladım
  • Uzmanlara sorarsanız “Bu imkânsız. Asla çalışmaz. Aptalca bir fikir.” diyeceklerdir
  • Neyse ki böyle uzmanları tanımıyordum, ben de sadece yaptım; sonra bunlar oldu
  • Uzmanların sözünü fazla dinlemeyin; mantıklı gelen şeyi yapın. Kendi probleminizi çözün

--

Reklam

[1] Bus Factor : Bir ekip üyesinin başına bir şey gelmesi halinde ekibin krize girme riski.

  • Ekip üyeleri arasında bilgi ve işlevler paylaşılmadığında ortaya çıkabilecek riski anlatan bir ölçü.
  • Bu değerin yüksek olması, bilginin paylaşılması ve işin belirli kişilere yığılmaması anlamına gelir.

[2] DO-178B : Havacılık sistemleri ve ekipman sertifikasyonunda yazılım değerlendirmeleri (Software Considerations in Airborne Systems and Equipment Certification)

  • FAA tarafından havacılık yazılımı sertifikasyonunda uygunluğun gösterilmesi yöntemi olarak benimsenmiştir

[3] MCDC : Modified Condition / Decision Coverage

  • Birden fazla koşul ifadesi olduğunda, her bir koşulun diğerlerinden bağımsız şekilde toplam koşul sonucunu etkilediğini gösterecek test vakaları tasarlama yöntemi

16 yorum

 
enowy 2025-08-07

Böyle güzel bir yazı varmış. Çeviri olarak okuyabildiğimize sevindim.

 
mkeasy 2021-07-08

İnsanı defalarca yeniden okumaya iten bir yazı. Teşekkürler.

Özgür olmak istiyorsanız, kendiniz yapın.

Anlamlı işler yapın.

Kendi probleminizi çözün.

 
edunga1 2021-07-05

Gerçekten çok ilginç bir yazı!

"%90~95 test kapsamına ulaşmak kolay ama kalan %5 gerçekten çok zor. Ama bunu 1 yıl boyunca yapıp sonunda %100'e ulaştığımızda, Android'den artık hata raporu gelmemeye başladı"

Demek böyle bir şey mümkünmüş.

 
panarch 2021-07-05

Keyifle okudum. Teşekkür ederim!

 
jsryu 2021-07-05

Bunu büyük bir keyifle okudum. Teşekkür ederim.

 
falconer 2021-07-05

Keyifle okudum.

 
gmlwo530 2021-07-05

Keyifle okudum!

 
kwangyeol 2021-07-05

Büyük bir keyifle okudum. Teşekkür ederim.

 
baeba 2021-07-05

Keyifle okudum.

Özetleyip derlemek daha zor gibi görünüyor.

 
shaichoi 2021-07-05

Keyifle okudum. Düşündürdü. Teşekkürler :)

 
fureweb 2021-07-05

Keyifle okudum. Teşekkürler!

 
kalihman 2021-07-05

Keyifle okudum.

 
jongpak 2021-07-05

Zamanın nasıl geçtiğini fark etmeden okudum haha

Basit bir gömülü veritabanı diye küçümsediğim için utanır oldum^^;

 
sixmen 2021-07-05

Bunu sadece basit bir yerel geliştirme DBMS’i sanıp kullanmıştım ama hiç de basit değilmiş!!

 
nicewook 2021-07-05

Bunu çok keyifle okudum.

 
xguru 2021-07-05

Şu anda dünya genelinde kullanımda olan SQLite sayısı 1 trilyonu aşmıştır.

  • 4 milyardan fazla tüm akıllı telefonlarda (Android, iOS)

  • Mac/Windows

  • FF/Chrome/Safari tarayıcıları

  • PHP/Python

  • Skype/iTunes/Dropbox/Turbotax

  • Çoğu set üstü kutu ve TV’de

  • Çoğu otomobilin multimedya sisteminde

https://www.sqlite.org/mostdeployed.html