Sadece Perf Yeterli Değil

Veritabanlarında performans takıntısı kültürü

• Veritabanı sektörü performans artışına odaklanıyor, ancak gerçek kullanıcı deneyimi çoğu zaman başka unsurlardan etkileniyor.
• Kullanıcının veriyi işlerken gerçekten önem verdiği şey, sorgu optimizasyonundan ziyade verinin biçimi ya da SQL ile soruyu kurabilme becerisi olabilir.
• Veritabanı performansı önemlidir, ancak veritabanını seçerken kullanım kolaylığı, ekosistem, güncelleme hızı ve iş akışıyla entegrasyon gibi başka unsurları temel almak daha iyi olabilir.

Benchmark savaşlarının sonu

• 2019'da GigaOm, bulut veri ambarlarını karşılaştıran bir benchmark yayımladı, ancak gerçek pazar sonuçları bununla farklı bir tablo ortaya koydu.
• Benchmark sonuçları kullanıcı deneyimiyle örtüşmüyorsa, bu ya benchmark'ın yanlış olduğu, ya yanlış şeyi test ettiği ya da performansın o kadar önemli olmadığı anlamına gelebilir.

Hızlı olmanın anlamı

• Bulut veritabanı alanında kullanıcılar, genellikle "çalıştır" düğmesine bastıktan sonra sonucun hazır olmasına kadar geçen süreye odaklanır.
• Kullanıcıyı gerçekten etkileyen şey, işi tamamlamak için geçen süredir ve bu süre veritabanı sunucusunun harcadığı süreyle aynı değildir.

Performans özneldir

• Performans, kullanıcının bakış açısından ölçülmelidir ve bir UX sorunu olarak tek bir sayıyla açıklanamaz.
• Performansın öznel olması, hangi veritabanının daha hızlı olduğunun onun nasıl kullanıldığına bağlı olduğu anlamına gelir.

Değişimin hızı

• DuckDB çok hızlı bir tempoda gelişiyor ve bu da bugünün benchmark'larını anlamsızlaştırıyor.
• Bir veritabanı seçerken yalnızca bugünkü performans değil, gelecekteki performans ve özellik değişimleri de önemli değişkenlerdir.

Sihirli fasulye yok

• Eğer tüm veritabanları aktif biçimde bakım görüyorsa, performans zaman içinde yakınsayacaktır.
• Önemli performans farklarının zamanla kalıcı olmama ihtimali yüksektir.

Sorun sandalye ile klavye arasında, klavye ile veritabanı arasında

• Kullanıcı için önemli performans ölçütü, bir soruyla başlayıp cevaba ulaşmak için geçen süredir.
• Önemli olan, veritabanının sorguyu ne kadar sürede çalıştırdığı değil, fikirden yanıta ulaşma hızıdır.

Ekşi üzümler üzerine

• DuckDB şu anda ClickBench ve h20.ai benchmark'larında üst sıralarda yer alıyor ve TPC-H ile TPC-DS'de de kötü sayılmayacak performans gösteriyor.
• Bir veritabanının hızlı olduğunu varsaymadan önce, onu gerçek iş yükünüz üzerinde denemek önemlidir.

Sonuç

• En başarılı veritabanı şirketleri, rakiplerinden daha hızlı oldukları için başarıya ulaşmadı.
• Performansı ana satış vaadi olarak öne çıkaran veritabanları pazarda başarılı olamadı.
• Veritabanı seçerken ham hızın dışındaki unsurları temel alarak karar vermek daha iyi bir yaklaşımdır.

GN⁺ görüşü

• Bu yazı, yalnızca veritabanı performansına odaklanmak yerine kullanıcı deneyimi ve iş akışını optimize etmenin önemli olduğunu vurguluyor. Bu, giriş seviyesindeki yazılım mühendisleri için de veritabanı seçerken basit performans metrikleri yerine kullanıcı merkezli bir yaklaşımı dikkate almaları gerektiğine dair önemli bir ders sunuyor.
• Veritabanı performansı zaman içinde yakınsama eğilimindedir; çünkü teknolojik ilerleme tüm platformlara yayılır. Bu da teknoloji seçerken kısa vadeli performanstan çok uzun vadeli destek ve iyileştirme potansiyelinin dikkate alınması gerektiğini gösterir.
• DuckDB gibi açık kaynak projeler, hızlı gelişim temposu ve topluluk desteği sayesinde hızlı biçimde ilerleyebilir. Bu, yeni bir teknolojiyi benimserken topluluğun canlılığını ve projenin gelişim hızını da değerlendirmek gerektiği anlamına gelir.
• Veritabanı seçerken yalnızca performans benchmark sonuçlarına güvenmemek, bunun yerine gerçek iş yükü üzerindeki performansı test etmek önemlidir. Bu, gerçek kullanım senaryolarına daha uygun bir veritabanı seçmeye yardımcı olabilir.
• Veritabanı teknolojisi seçiminin yalnızca teknik yönlere değil, iş gereksinimlerine, bakım kolaylığına ve veri işlemenin verimliliğine kadar uzanan çeşitli unsurları dikkate alması gerektiği vurgulanıyor.

[GN⁺]

Hacker News görüşleri

• Müşterilerden yıllarca çok sayıda şikayet geldikten sonra, JDBC sürücüsündeki bir bug'ın performansı düşürdüğünü fark ettik. Birçok mühendisin zamanını sorgu hızını artırmaya harcadık, ancak çoğu kullanıcının kullandığı bağlayıcı, kazandırdığımız süreden çok daha fazla gecikme ekliyordu. Üstelik bunun farkında bile değildik. Google içinde hiç kimse JDBC sürücüsünü kullanmadığı için kullanıcıların deneyimlediği sorgu sürelerini göremiyor ve bunu başkasının sorunu olarak görüyorduk.

  • Bu yorum, Google'ın müşteri şikayetlerine karşı "tamamen kör" olmasından ve kendi ürününü kullanmamasından duyulan hayal kırıklığını ifade ediyor. Özellikle JDBC kısmı çok çarpıcı.
• Google, içeride iyi çalışan bir veritabanı kurdu ama dış dünya için adaptör katmanını taşerona verdi; o da düzgün çalışmayınca dış dünya kötü bir veritabanı kullanmak zorunda kaldı. Google'ın kullandığı sofistike çekirdek, kusurlu adaptörlerle çevriliydi ve ortaya genel olarak gereksiz yere dağınık bir ürün çıktı. İçeridekiler bunun farkında değildi, dışarıdakilerin ise bunu anlaması zordu.
  • Bu yorum, Google'ın açık kaynak stratejisini çok isabetli biçimde değerlendirdiğini söylüyor.
• Blogun "performans özneldir" demesi garip geliyor. Performansı sadece ölçmek yeterli değil, ama verilen tek örnekte performans önemli ve nesnel. Sadece yanlış şey ölçülmüş.
  • Bu yorum, blogun performans ölçümüne dair iddiasını sorguluyor.
• Bu, şirket organizasyonuyla ilgili bir sorun gibi görünüyor. Nihai hedef müşterilerin bulutu kullanmasını sağlamak ve değer sunmaksa, müşterilerin önem verdiğinden farklı metriklere sahip olunmamalı. Google içinde, müşteri sorunlarını aktif biçimde dinleyip bunları mühendislere ileterek neyin iyileştirilmesi gerektiğini söyleyen birileri olmalı.
  • Bu yorum, Google'ın müşteri ihtiyaçlarını anlaması ve iyileştirmesi için uygun bir organizasyon yapısına ihtiyaç olduğunu vurguluyor.
• Seattle'daki evimden San Francisco ofisine kapıdan kapıya yaklaşık 4,5 saatte gidiyorum.
  • Bu yorum, kurucuların artık eskisi kadar hızlı hareket etmediğini söylüyor ve şakayla karışık bunun nedeninin Fed'in faiz artırımları olabileceğini ekliyor.
• Burada anlatıldığı anlamda performansın ikincil olduğunu düşünmüyorum. Önce performansın yeterince iyi olduğundan emin olmak, ardından diğer her şeyi değerlendirmek gerekir. Yazar da zaten kendisi "DuckDB hızlı" diyor. Öyle olmasaydı performans yarışı vermesi gerekirdi.
  • Bu yorum, performansın ikincil olduğu iddiasına katılmıyor ve önce performansın yeterince iyi olup olmadığının doğrulanması gerektiğini savunuyor.
• Performans "öznel" değil, "bağlamsaldır". Anlamı, yapılan işle bağlantılıdır.
  • Bu yorum, performansın bağlama göre değiştiğini açıklıyor ve bunu kullanıcı arayüzü tasarımında hissedilen performanstan ayırıyor.
• İlk popüler web uygulamam tüm durumu bir Python dict içinde tutuyor ve birkaç dakikada bir diske dump ediyordu. API çok hızlıydı, ama MongoDB'ye geçince performans asla toparlanmadı. Yine de bugün bir web sitesi yaparken "pickledb" seçmezdim.
  • Bu yorum, ilk dönem web uygulamasının performansını ve veritabanı geçişinden sonra yaşanan performans kaybını paylaşıyor.
• Kendi veritabanı sistemimi kurarken, bunu diğer popüler veritabanlarıyla (Postgres, Sqlite, MySQL, SQL Server) kıyaslamak istedim.
  • Bu yorum, kullanıcının "çalıştır" düğmesine basmasından sonucun ekranda görünmesine kadar geçen süreyi ölçtüğünü ve çeşitli sorgularda kendi veritabanı daha hızlı olana kadar tatmin olmadığını anlatıyor.
• "Elbette bu kuralın istisnaları var; bunlardan biri, mimari farkları aşmanın zor olması. Shared nothing veritabanları, shared disk'e kıyasla dezavantajlıdır ve Redshift'in büyük ölçüde shared disk mimarisine geçmesi yıllar aldı. Meta veriyi object store üzerinde kalıcılaştıran lakehouse sistemleri hızlı güncellemelerde zorlanacaktır; bu, modelin doğasında var."
  • Bu yorum, veritabanı mimarisi farklarıyla ilgili sorunlara dikkat çekiyor ve bu konuda iyi kaynaklar aradığını belirtiyor.