Uzun ömürlü sistemler için PostgreSQL mi MySQL mi

Bu iki veritabanı arasındaki seçim kadar sık kamplar arası bir kavgaya dönüşen pek az teknik tercih vardır — ve çoğu sistem için tartışmanın düşündürdüğü kadar az belirleyici olan da pek azdır. İkisi de uzun zamandır olgundur, ikisi de sağlam temellere sahip ilişkisel veritabanlarıdır, ikisinin de on yıl sonra hâlâ bakımı yapılıyor ve uzman bulunabiliyor olacaktır. İkisinden birini seçen neredeyse hiçbir zaman yanlış seçmez — hata başka yerdedir: verilerin nasıl modellendiğinde ve veritabanının nasıl işletildiğinde.

Bu yüzden bu doküman seçimi soğukkanlılıkla ele alıyor: İkisinin ortak yanlarını, gerçekte nerede ayrıştıklarını ve kararın anlamlı olarak hangi az sayıdaki özelliğe bağlı olduğunu adlandırıyor. Bir kazanan ilan etmiyor, çünkü kazanan yok — her birinin neye daha uygun olduğunu anlatıyor. İlkeler sürümden bağımsız olarak geçerlidir; hiçbir rakam ve hiçbir karşılaştırmalı ölçüm verilmiyor.

1. Yanlış soru

“Hangisi daha iyi?” yanlış bir sorudur, çünkü yalnızca duruma bağlı yanıtların olduğu yerde genel bir yanıt bekler. İşletme sistemlerinin büyük çoğunluğu için her iki veritabanı da fazlasıyla yeterlidir; farkları ancak kenarlarda, veri tipleri, eşzamanlılık veya işletim konusundaki özel gereksinimlerde hissedilir hâle gelir. Ortalama bir sistem için — tablolar, ilişkiler, transaction'lar, makul bir yük — ikisi de aynı şeyi sunar: yıllar boyunca güvenilirlik.

Tartışmanın sürmesinin bir nedeni de araç seçiminin kolayca bir kimliğe dönüşmesidir — bildiğinizi, kendinizin bir parçasıymış gibi savunursunuz. Bu insanidir, ama bir argüman değildir. Soğukkanlı bir karar tercihi uyumdan ayırır ve neyle daha rahat hissettiğinizi değil, sistemin neye ihtiyaç duyduğunu sorar.

Daha iyi soru şudur: Hangisi verilerimin biçimine ve onları işletecek ekibe uyuyor? Bu sorunun bir yanıtı vardır ve bu yanıt işe yarar. Bunun yerine bir sıralama arayan, sonucu sistemi için pek bir önem taşımayan bir tartışma yürütür — ve bu arada gerçekten önemli olan kararları gözden kaçırır: veri modelini, indekslemeyi, migrasyon disiplinini.

Ödünleşim. Soruyu soğukkanlılıkla sormak, genel bir tavsiyenin rahatlığından vazgeçip kendi sisteminiz için hüküm vermek demektir.

Maliyet. Bu hüküm, kendi veri biçiminizi ve kendi ekibinizin güçlü yanlarını dürüstçe değerlendirmeyi gerektirir — bir sıralamaya göz atmaktan daha fazla iş.

Ne zaman farklı karar veririz. Bir ekip ikisinden birine çoktan derinlemesine hâkimse ve onu işletiyorsa soru çoğu zaman zaten yanıtlanmıştır: Tanıdık, iyi işletilen veritabanı, teoride biraz daha uygun olan ama kimsenin güvenle kullanamadığı veritabanını yener.

2. İkisinin ortak yanları

Bu iki veritabanı hakkındaki gerçeğin en büyük kısmı, paylaştıkları şeylerdir. İkisi de tablolar, ilişkiler ve SQL sorgu diline sahip ilişkisel veritabanlarıdır. İkisi de para ve durum söz konusu olduğunda güvenmek zorunda olduğunuz garantilerle transaction'lar sunar. İkisi de uzun yıllar boyunca olgunlaşmış, büyük sistemleri taşıyan, derin dokümantasyona, geniş bir uzman çevresine ve güvenceli bir geleceğe sahiptir. İkisinin de on yıl sonra hâlâ bakımını yapabilecek ve uzman bulabileceksiniz.

Bu ortaklıktan rahatlatıcı bir kavrayış çıkar: Çoğu sistem için seçim yeterince geri alınabilir ve yetenekler yeterince benzerdir; çıkmaza girmeniz mümkün değildir. İkisinden birinde kalıp temiz modelleme yapan, hangisi olursa olsun sağlam bir zemin üzerine inşa eder. Asıl kazanç ikisinin de olgunluğudur; seçimin göründüğünden daha nadiren kritik olmasının nedeni budur.

Bu ortak temeli takdir etmeye değer, çünkü bir sistemin veritabanından beklediği şeylerin açık ara en büyük kısmı odur. Verileri güvenle saklamak ve yeniden bulmak; ilişkileri ifade etmek; yarım durumlar bırakmadan transaction'lar içinde değiştirmek; yük altında güvenilir yanıt vermek; yıllar boyunca bakımı yapılmak ve anlaşılmak. Bunların hepsini ikisi de sağlar ve bunların hepsi çekirdektir. Üzerinde tartışılan farklar, bunun ötesindeki dar kenarla ilgilidir. Temeli düzgün kullanan bir ekip, ikisinden hangisiyle olursa olsun iyi bir sisteme sahip olur; onu kötü kullanan bir ekibi teoride üstün olan veritabanı da kurtarmaz.

Ödünleşim. Ortaklığı kabul etmek, seçimi pazarın sahnelediğinden daha az dramatik ele almak demektir — bu, ondaki yanlış ağırlığı ortadan kaldırır.

Maliyet. Benzerliği hafife alan, çok şeyi değiştiren veri modeli yerine az şeyi değiştiren bir karara enerji harcar.

Ne zaman farklı karar veririz. Ancak özel bir gereksinim tam olarak farklardan birine bağlıysa (bkz. sonraki bölümler) ortaklık ikinci planda kalır ve fark belirleyici olur.

3. Gerçekte nerede ayrışırlar

Farklar gerçektir, ama çekirdekte değil, kenarlarda yer alırlar. Kabaca söylemek gerekirse biri — PostgreSQL — zenginliğe ve katılığa eğilimlidir: daha fazla veri tipi, daha fazla genişletilebilirlik, doğruluk ve karmaşık sorgular konusunda belirgin bir titizlik. Diğeri — MySQL — sadeliğe ve yaygınlığa eğilimlidir: standart durum için işletimde daha dolaysız, son derece yaygın, yaygın örüntüler için büyük bir deneyim birikimiyle. Bunlar sınırlar değil, eğilimlerdir; birinin yapabildiği pek çok şeyi diğeri de yapabilir, yalnızca farklı bir eforla.

Taraf tutmadan somut bir örnek: yarı yapılandırılmış verilerin ve geçersiz girdilerin ele alınışı. Bir sistemin sütunlara düzgünce oturmayan çok sayıda veri taşıdığı yerde daha zengin eğilim ifade gücünü ortaya koyar; bir veritabanının izin verilmeyen her girdiyi sessizce eğip bükmek yerine katı biçimde reddettiği yerde doğruluk kazanırsınız, ama bunun bedelini gündelik işte daha az hoşgörüyle ödersiniz. İki davranış da savunulabilir ve ikisinin de bir bedeli vardır — biri sessiz hatalardan, diğeri sürtünmeden kurtarır. Hangisini istediğiniz, kendi sisteminizde doğruluğun mu yoksa esnekliğin mi daha ağır bastığına bağlıdır. Bu iyi ya da kötü meselesi değil, uyum meselesidir.

Önemli olan bu eğilimleri dogmaya dönüştürmemektir. İkisinden hiçbiri “ciddi sistemlerin veritabanı” ve hiçbiri “basit sistemlerin veritabanı” değildir — ikisi de her ikisini taşır. Eğilimler yalnızca nereye daha az dirençle ulaşacağınızı söyler: Karmaşık, katı veri mantığıyla dolu bir sistem birinde biraz daha fazla arka rüzgâr bulur, basit ve geniş ölçekte işletilecek bir sistem ise diğerinde.

Ödünleşim. Farkları ciddiye almak, genel bir tercihi izlemek yerine kendi veri biçiminize yakından bakmak demektir.

Maliyet. Yakından bakmak zaman ve sistemin veritabanından gerçekte ne beklediğinin dürüst bir analizini gerektirir.

Ne zaman farklı karar veririz. Özel gereksinimlerin hiçbiri geçerli değilse — en sık rastlanan durum —, farklar seçimi taşıyamayacak kadar küçüktür ve başka ölçütler (ekip, işletim) belirleyici olur.

4. PostgreSQL ne zaman uygundur

PostgreSQL, verilerin zengin ve doğruluğun katı olması gereken yerde daha uygun seçimdir. Bir sistem çok sayıda, alışılmadık veya bileşik veri tipine ihtiyaç duyuyorsa, karmaşık sorgular ve analizler çekirdeğin bir parçasıysa, az sayıda örtük varsayımda bulunan ve hataları erken ve açıkça bildiren bir veritabanına önem veriyorsanız — PostgreSQL zenginlik ve katılık eğilimini o zaman ortaya koyar. Veritabanını eklentilerle (extension) özel gereksinimlere uyarlamak istediğiniz yerde de genişletilebilir karakteri gerçek bir avantajdır.

Bu gücün bedeli, belirli bir özen gerektirmesi ve bazı standart ortamlarda daha yaygın olan alternatife göre biraz daha az kendiliğinden hazır bulunmasıdır. Zenginliğe ihtiyacı olmayan, onun karşılığını almadan yalnızca biraz daha yüksek bir talep ile bedelini öder.

Ödünleşim. PostgreSQL'in zenginliği, ifade gücünü ve katılığı özen ve işletim konusunda biraz daha yüksek bir talep karşılığında satın alır.

Maliyet. Olanakların bolluğuna hâkim olmak gerekir; onları kullanmayan bir ekip, ihtiyaç duymadığı bir karmaşıklığı taşır.

Ne zaman farklı karar veririz. Verilerin basit ve sorguların yaygın olduğu yerde zenginlik bir karşılık getirmez — o zaman daha basit ve daha yaygın seçim daha uygundur.

5. MySQL ne zaman uygundur

MySQL, sadeliğin ve yaygınlığın önemli olduğu yerde daha uygun seçimdir. Veri biçimi dolaysızsa, sorgular yaygınsa, alışılmadık veri tiplerine yönelik gereksinimler düşükse — ve ekip veya işletim ortamı MySQL'e aşinaysa —, sadelik ve her yerde bulunma eğilimi gerçek bir avantajdır. Pek çok yaygın uygulama için en az direncin yoludur: iyi anlaşılmış, her yerde mevcut, olağan örüntüler için devasa bir deneyim birikimiyle.

Bedeli, PostgreSQL'in gücünün ayna görüntüsüdür: Zenginliğe ve katılığa yine de ihtiyaç duyduğunuz yerde onları daha fazla eforla taklit etmeniz gerekir ve tarihsel olarak daha pragmatik tutum, veritabanının zorlamadığı yerde doğruluğa sizin daha dikkatle bakmanızı gerektirir.

Ödünleşim. MySQL'in sadeliği, düşük direnci ve geniş aşinalığı daha az yerleşik zenginlik ve katılık karşılığında satın alır.

Maliyet. Katı doğruluk veya alışılmadık tipler yine de gerektiğinde, bunları veritabanının dışında güvence altına alma eforunu siz taşırsınız.

Ne zaman farklı karar veririz. Zengin tipler, karmaşık analizler veya katı doğruluk çekirdeğin bir parçası olduğu anda, taklit etme eforu sadeliğin avantajından ağır basar — o zaman daha zengin seçim daha uygundur.

6. Ölçüt: veri biçimi ve ekip

İkisi de olgunsa ve farklar kenarlarda yatıyorsa, karar neye dayandırılır? İki şeye: verinin biçimine ve veritabanını işleten ekibe. Veri biçimi, hangi eğilimin daha fazla arka rüzgâr sağladığını söyler — zengin ve katı mı, yoksa basit ve yaygın mı. Ekip, hangi veritabanının güvenilir biçimde işletileceğini söyler, çünkü bir veritabanı ancak onu taşıyan işletim kadar iyidir. Teoride biraz daha uygun olan ama kimsenin güvenle kullanamadığı bir veritabanı, ekibin uykusunda bile hâkim olduğu tanıdık veritabanına kıyasla daha kötü seçimdir.

Şema: Açık ara en büyük kısım ortak temeldir. Farklar üstte, kenarlarda durur — yalnızca sistem onlara gerçekten dokunduğunda belirleyici olurlar.

Şema: Daha iyi veya daha kötü değil, arka rüzgâr. Eğilim ancak bandın uçlarında belirleyici olur; geniş ortada ikisi de taşır.

Burada işletim, gündelik aşinalıktan daha fazlasıdır. Bir veritabanı yıllar boyunca acil bir durumda geri de yüklenebilecek yedekler, yük altındaki davranışının anlaşılmasını, kesintiler ve değişikliklerin kesinti olmadan uygulanması için bir plan gerektirir. Bu işlemlere ikisinden biri için hâkim olan bir ekip — test edilmiş yedekler, anlaşılmış sınırlar, prova edilmiş müdahaleler — onu on yıl boyunca taşır; teoride daha uygun olan için bunları önce öğrenmesi gereken bir ekip ise hiçbir veritabanı özelliğinin dengeleyemeyeceği bir risk taşır. Bu yüzden işletim olgunluğu çoğu zaman tüm argümanların en güçlüsüdür: Hangi veritabanının daha iyi olduğuna değil, tam da bu ellerde hangisinin daha güvenilir olacağına karar verir.

Uzun ömürlülük ölçütü sertleştirmez, aksine rahatlatır: İkisi de on yıl taşıdığı için seçimi bir kader kararı gibi yürütmeniz gerekmez. Veri biçimine uyan ve ekibin işletebileceği olanı seçersiniz — ve serbest kalan enerjiyi, yıllar içinde veritabanının adından kıyaslanamayacak kadar fazlasını belirleyen veri modeline, indekslemeye ve migrasyon disiplinine yöneltirsiniz.

Ödünleşim. Veri biçimine ve ekibe göre karar vermek, genel bir tavsiyenin arkasına saklanmak yerine kendi durumunuzu dürüstçe adlandırmak demektir.

Maliyet. Ölçüt, kolayca güzelleştirilebilecek iki dürüst değerlendirme gerektirir — verilerin ve ekibin.

Ne zaman farklı karar veririz. Katı bir dış zorunluluk bulunduğunda — mevcut bir işletim ortamı, istenen bir uyumluluk — ölçüt geri planda kalır ve zorunluluğa uyulur.

7. Bağımlılık ve geri alınabilirlik

Seçim ilke olarak ne kadar geri alınabilir olursa olsun — ikisi de SQL konuşur —, pratikte kendinizi gerektiğinden daha sıkı bağlamanız o kadar kolaydır. Kullandığınız her veritabanına özgü özellik, sonraki bir geçişi daha pahalı hâle getirir. Bu, özel özelliklerden kaçınmak için bir neden değildir — çoğu zaman veritabanını tam da onlar için seçmişsinizdir —, ama bilinçli karar vermek için bir nedendir: Burada bir özel özelliği gerçek bir kazanç sağladığı için mi kullanıyorum, yoksa standart SQL'in yeterli olacağı yerde alışkanlıktan mı?

Tutum, sonuçları ağır her seçimdekiyle aynıdır: Geri alınabilir olanı kolay olduğu yerde ucuz tutmak ve yalnızca kazancın bedele değdiği yerde bağlanmak. Veri erişiminin çekirdeğini standart SQL'de tutan ve özel özellikleri bilinçli ve yerel olarak kullanan, önemli oldukları yerde avantajlardan vazgeçmeden, sistemin yarısına dokunmak zorunda kalmadan bir gün veritabanını değiştirme özgürlüğünü korur.

Pratikte geçiş nadirdir ve bu bir çelişki değildir: Tam da seçimi geri alınabilir tuttuğunuz için onu neredeyse hiçbir zaman geri almanız gerekmez. Geri alınabilirlik sürekli geçiş yapılsın diye değil, gereksinimler köklü biçimde kayarsa tutsak kalmamak için vardır. Onu koruyan, veritabanı sorusunu sonsuza dek bağlanma korkusu olmadan karara bağlar — ve bu sükûnet kendi başına bir değerdir, çünkü kararı yanlış ağırlığından kurtarır.

Ödünleşim. Özel özelliklere bağlanmak, onların avantajını daha pahalı bir sonraki geçiş karşılığında satın alır — bilinçli yapıldığında bu iyi bir takastır.

Maliyet. Geri alınabilirliği korumak disiplin gerektirir: Erişimi, özel özelliklerin yerel kalacağı ve bütün sisteme yayılmayacağı şekilde tasarlamak.

Ne zaman farklı karar veririz. Bir geçişin pratikte söz konusu olmadığı ve bir özel özelliğin büyük kazanç sağladığı yerde onu çekinmeden kullanırsınız; temkin, geçişin düşünülebilir kaldığı yerde geçerlidir.

8. Tipik hatalar

Veritabanı seçiminin başarısız olduğu tekrarlayan örüntüler — neredeyse hepsi yanlış soruyu sormanın varyasyonlarıdır:

• Seçimi kendi verilerinizin biçimine göre karara bağlamak yerine kamplar arası bir kavga olarak yürütmek.
• Veri modelinden ve indekslemeden esirgenen enerjiyi veritabanlarının sıralamasına harcamak.
• Ekibin güvenle işletemediği, teoride daha uygun bir veritabanını seçmek.
• Birinin zenginliğini, kullanmadan satın almak — karşılığı olmayan bir karmaşıklığı taşımak.
• Diğerinin sadeliğini seçip ardından sizin güvence altına almanız gereken katı doğruluğu beklemek.
• Standart SQL'in yeterli olacağı yerde gereksiz yere özel özelliklere bağlanmak ve sonraki bir geçişi pahalı hâle getirmek.
• İkisinin de olgunluğunu gözden kaçırmak ve seçimi, nadiren olduğu bir kader kararına yüceltmek.

9. Karar kontrol listesi

İkisi arasında seçim yapmadan önce sırasıyla netleştirilmesi gerekenler:

• Veri biçimi? Veriler zengin ve katı mı (daha çok PostgreSQL), yoksa basit ve yaygın mı (daha çok MySQL)?
• Özel gereksinim? Temel bir şey tam olarak farklardan birine mi bağlı — yoksa her şey ortak temelde mi yatıyor?
• Ekip ve işletim? Ekip hangi veritabanını güvenilir biçimde işletiyor ve hangisi ortamda zaten yerleşik?
• Zenginlik kullanılıyor mu? Daha zengin seçim yapılırsa: Güçlü yanlarını gerçekten kullanıyor muyum — yoksa yalnızca karmaşıklığını mı taşıyorum?
• Doğruluk güvence altında mı? Daha basit seçim yapılırsa: Veritabanının zorlamadığı yerde katı doğruluğu sağlıyor muyum?
• Bağımlılık bilinçli mi? Özel özellikleri gerçek bir kazanç için mi kullanıyorum — yoksa standart SQL'in yeterli olduğu yerde alışkanlıktan mı?
• Enerji doğru yerde mi? Dikkat isim kavgasına değil, veri modeline ve migrasyon disiplinine mi akıyor?

Bu sorulara yanıt verebilen, konunun özüne göre karar vermiş — ve seçimin nadiren gerçekten önemli olan şey olduğunu fark etmiştir.

Sıkça Sorulan Sorular

Hangisi daha iyi veritabanı? Genel olarak hiçbiri. İkisi de olgun, ilişkisel ve bir sistemi yıllarca taşır. İşe yarayan soru “hangisi daha iyi” değil, “hangisi verilerimin biçimine ve ekibime uyuyor” sorusudur. Çoğu sistem için ikisinden her biri iyi bir seçim olurdu.

PostgreSQL “daha ciddi” veritabanı değil mi? Zenginliğe ve katılığa eğilimlidir, ama ikisi de “ciddidir”. MySQL de büyük, ciddi sistemleri taşır. Eğilim, nereye daha az dirençle ulaşacağınızı söyler; hangisinin ciddi yazılım için uygun olduğunu değil — ikisi de uygundur.

Seçim gerçekten büyük bir rol oynuyor mu? Tartışmanın düşündürdüğünden daha nadiren. Yıllar içinde veri modeli, indeksleme ve migrasyon disiplini, veritabanının adından kıyaslanamayacak kadar fazlasını belirler. İki olgun seçenek arasındaki seçim bilinçli yapılacak kadar önemlidir, ama nadiren bir sistemi taşıyan veya başarısız kılan şeydir.

Sonradan fikrimizi değiştirmek istersek ne olur? İlke olarak mümkündür, çünkü ikisi de SQL konuşur; pratikte bedeli, veritabanına özgü kaç özellik kullandığınıza bağlıdır. Çekirdeği standart SQL'de tutan ve özel özellikleri bilinçli ve yerel olarak kullanan, önemli oldukları yerde avantajlardan vazgeçmeden geçiş özgürlüğünü korur.

Ekibin bildiğine göre mi karar vermeliyiz? Çoğu zaman evet. Bir veritabanı ancak işletimi kadar iyidir ve tanıdık, güvenle işletilen veritabanı, teoride biraz daha uygun olan ama kimsenin hâkim olmadığı veritabanını yener — özel bir gereksinim tam olarak bir farka bağlı değilse.

Bu seçimdeki en pahalı hata nedir? Yanlış veritabanı değil, boşa harcanan dikkat. Haftalarını isim kavgasına harcayıp ardından veri modelini özensizce tasarlayan, sonuçları olan tek yerde tasarruf etmiş olur. Neredeyse aynı derecede pahalı olan kararsızlıktır: Projenin ortasında geçiş yapmak veya iki seçeneği de açık tutmak, iki veritabanından herhangi birinin şimdiye kadar mal olacağından daha pahalıdır. Karar vermek, temiz modellemek, devam etmek — yol budur.

İleri okuma

• Kesintisiz veritabanı migrasyonları — yıllar içinde veritabanı seçiminden daha fazlasını belirleyen şey: şemasını değiştirme disiplini.
• Şema ile model birbirinden uzaklaştığında — veri modeline gösterilen özenin neden veritabanının adından daha önemli olduğu.
• PostgreSQL: JSONB ve tablolar — veritabanı içinde somut bir modelleme kararı.
• Yenilikten önce olgun teknoloji — ikisinin de olgunluğunun neden asıl kazanç olduğu.

Temeli Batunet Engineering Method'tur: verinin biçimine ve ekibe göre karar vermek, seçimi geri alınabilir tutmak, enerjiyi veri modeline yöneltmek.

Son mühendislik ilkesi

“PostgreSQL mi MySQL mi” sorusuna verilebilecek en olgun yanıt, soruyu doğru boyutuna oturtmaktır. Bilinçli olarak karara bağlanacak kadar önemli, bir inanç savaşına dönüştürülmeyecek kadar önemsizdir. İki veritabanı da taşıdığını kanıtlamıştır; hiçbiri iyi modellenmiş bir sistemi başarısız kılmaz, hiçbiri de kötü modellenmiş bir sistemi kurtarmaz. Bunu kavrayan, başkalarının haftalarca tartıştığını dakikalar içinde seçer — verinin biçimine, ekibe, varsa özel gereksinime göre — ve ardından gerçekten önemli olana yönelir: modele, indekslere, şemayı yıllar içinde değiştirirken gösterilen disipline. Uzun ömürlülük veritabanının adında değil, orada belirlenir.

İki olgun veritabanı arasındaki seçim, bir sistemin neden taşıdığının ya da başarısız olduğunun nadiren nedenidir. Bunu veri modeli belirler — ve veri modeli ikisinden hiçbirine değil, onu tasarlayana aittir.