Yalnızca performans yeterli değil
(motherduck.com)- Veritabanı seçiminde yalnızca ham sorgu hızına ve genel benchmark’lara bakmak, kullanıcının sorudan cevaba ulaşmasına kadar geçen toplam süreyi gözden kaçırmayı kolaylaştırır
- 2019 GigaOm benchmark’ı Azure Data Warehouse ve Redshift’i öne çıkarsa da, gerçek pazarda Snowflake ve BigQuery daha iyi satıldı; bu da performans dışı etkenlerin gücünü gösteriyor
- Sunucu çalışma süresini kısaltsanız bile JDBC sürücüsü, sonuç indirme, CSV ayrıştırma ve SQL yazma zorluğu gibi çevresel yollar daha büyük darboğaz olabilir
- ClickBench, TPC-H ve TPC-DS faydalıdır, ancak sonuçlar JOIN olup olmaması, tek tablo taraması, şema ayarı ve doğruluk·ACID garantisi koşullarına göre değişebilir
- Veritabanı motoru performansı zamanla birbirine yakınsadığı için, uzun vadeli seçim ölçütü mevcut sıralamadan çok fikirden cevaba giden hız ve iş akışı entegrasyonu olmalıdır
Benchmark’ların kaçırdığı gerçek bekleme süresi
- Seattle’daki evden San Francisco’daki ofise 4,5 saat süren bir yolculukta uçağın seyir hızını 10 kat artırmak bile, havalimanına gidiş, güvenlik kontrolü, biniş, pistte bekleme, bagaj ve varış noktasına ulaşım yüzünden toplam süreyi yalnızca yaklaşık %20 azaltabilir
- Veritabanlarında da durum benzerdir
- Motor hızlansa bile kullanıcılar garip CSV dosyaları, soruyu SQL ile ifade etmenin zor olduğu problemler ve araç bağlantı sorunlarıyla birlikte uğraşır
- Benchmark savaşını kazanan ürünü pazarlamak kolaydır, ancak bu onun kullanıcıların sorun çözme süresini doğrudan kısalttığı anlamına gelmez
- Veritabanı seçiminde kullanım kolaylığı, ekosistem, güncelleme hızı ve iş akışı entegrasyonu daha iyi değerlendirme ölçütleri olabilir
- Performans yalnızca belirli bir andaki belirli bir işin süresini gösterir ve yanlış darboğazı büyük çabayla optimize etmeye yol açabilir
2019 GigaOm sonuçları ile pazarın ters düşmesi
- GigaOm, 2019’da bulut veri ambarları için TPC-H ve TPC-DS benchmark’larını çalıştırdı
- Kapsamda üç büyük bulut sağlayıcısı ve Snowflake vardı
- Sonuçlarda Azure Data Warehouse en hızlıydı, onu Redshift izliyordu; Snowflake ve BigQuery ise belirgin biçimde geride kalmıştı
- O dönem BigQuery kullanıcı değerlendirmelerinde, Azure ile doğrudan karşılaştırma yapan müşteriler çoğu zaman BigQuery’yi seçiyordu
- Pazar sonuçları benchmark sıralamasının neredeyse tersiydi
- Snowflake ve BigQuery, Redshift’ten daha fazla sattı
- Redshift, Azure’dan daha iyi sattı
- TPC-H ve TPC-DS sektör standardıydı ve iç performans değerlendirmelerinde de kullanılıyordu; buna rağmen iyi performans benchmark’larında düşük sırada yer alan sistemler müşteriler tarafından daha çok satın alındıysa, performanstan daha önemli etkenler olduğu söylenebilir
Kullanıcının hissettiği hız sunucu süresi değildir
- Veritabanı yapanlar, kullanıcının “run” düğmesine bastıktan sonra sonuç hazır olana kadar geçen sunucu çalışma süresine odaklanma eğilimindedir
- Kullanıcı için önemli olan süre, işi tamamlamaya kadar geçen toplam zamandır; bu da veritabanı sunucusunun sorguyu çalıştırma süresinden farklıdır
- BigQuery’nin JDBC sürücüsü örneği bu farkı iyi gösterir
- JDBC sürücüsü, programcıların ve BI araçlarının veritabanına bağlanırken kullandığı genel amaçlı bir arayüzdü
- BigQuery sorguları 1-2 saniyede çalışsa da, sürücünün tamamlanma yoklaması ve sonuç indirme yöntemi yüzünden kullanıcıya birkaç saniye ya da birkaç dakika daha yavaş görünebiliyordu
- Sonuç çok olduğunda sürücü, kullanıcının ihtiyaç duymadığı verileri de sayfalar halinde tamamen çekiyor, gecikmeyi artırıyor ve bazen bellek yetersizliği nedeniyle çöküyordu
- Mühendisler sorgu süresinden saniyenin küçük kesirlerini düşürmek için çok zaman harcadı, ancak kullanıcıların sık kullandığı bağlayıcılar daha büyük gecikme yaratıyordu
- İç benchmark’lar her gün çalışıyordu, ancak uçtan uca performans ve kullanıcının hissettiği süre görünmüyordu
Performans tek bir sayıya sabitlenmez
- Performans, veritabanı bakış açısından değil kullanıcı bakış açısından ölçülmelidir ve UX gibi tek bir sayıyla bütünüyle açıklanması zordur
- Hangi veritabanının daha hızlı olduğu gerçek iş yüküne göre değişir
- Lamborghini Prius’tan daha hızlı olsa da, trafik sıkışıklığında işe gidiş süresi değişmeyebilir
- ClickHouse ile Redshift arasındaki performans farkı da kullanım biçimine göre değişir
- ClickHouse’un ClickBench’i, ClickHouse’un birçok veritabanından daha hızlı olduğunu gösterdi
- Benchmark, JOIN olmadan tek tablo üzerinde çalışıyordu ve distinct count’a yoğun biçimde dayanıyordu
- Log analizi ya da web sitesi tekil kullanıcı hesabı için iyi bir vekil gösterge olabilir
- Geleneksel veri ambarlarının yıldız şeması iş yüklerinde yanıltıcı olabilir
- Tedarikçi benchmark’ları genellikle tedarikçinin güçlü olduğu noktalara odaklanır
- BigQuery benchmark’larda zayıf görünebilir, ancak neredeyse hiç ayar düğmesi olmaması ve büyük ölçüde kendi kendini ayarlaması nedeniyle gerçek kullanıcı deneyiminde iyi hissedilebilir
- Yüksek düzeyde ayarlanmış bir SingleStore örneği birçok işte BigQuery’yi açık ara geçebilir, ancak şema ayarı için zaman ve yeni iş yükleri eklendiğinde ek müdahale gerekir
- Performansı artırmak için güvenlik önlemleri veya doğruluk azaltılabilir
- overflow check kaldırma
- write flush atlama
- bazı işlemlerde yaklaşık sonuç verme
- ACID garantileri sağlamama
- Bu tür kısayollar, kontrollü ortamlar dışında tercih etmek istemeyeceğiniz seçenekler olabilir
Bugünkü sıralamadan çok iyileşme hızı daha kalıcıdır
- DuckDB tabanlı bir şirket kurulurken DuckDB’nin h2o.ai benchmark’ında belirgin biçimde geride kaldığı eleştirileri vardı
- Bunun dert edilmemesinin iki nedeni vardı
- Performans ikincil bir unsurdu
- DuckDB çok hızlı bir gelişim gösteriyordu
- DuckDB’nin hızlı gelişiminde bazı mimari kararlar, nispeten yeni ve temiz bir kod tabanı ve çok iyi mühendisler etkili oldu
- Aynı benchmark’ın en yeni DuckDB sürümü için açık sonuçlarında, DuckDB orta sıralardan büyük farkla lider gruba çıktı
- Veritabanı seçimi yıllarca süren bir karar olduğundan, yalnızca bugünkü performans ve özellikler değil, bir yıl sonra mümkün olacak yetenekler de önemlidir
- İki veritabanı farklı hızlarda gelişiyorsa, daha hızlı ilerleyeni seçmek daha doğru olabilir
Performans farkı zamanla daralır
- Aktif biçimde bakımı yapılan çeşitli veritabanları birkaç yıl boyunca tekrar tekrar geliştirildiğinde performansları birbirine yaklaşma eğilimindedir
- Bir ürünün performans tekniği zamanla diğer ürünlerde de uygulanabilir
- ClickHouse tarama hızında avantaj sağlayan bir teknik kullanıyorsa, Snowflake de 1-2 yıl içinde benzer bir özelliğe sahip olabilir
- Snowflake artımlı materialized view eklerse, BigQuery de kısa süre sonra onu takip edebilir
- Her veritabanının performans üretme yöntemi farklıdır
- sorguları makine koduna derlemek
- veriyi yerel SSD’de önbelleğe almak
- shuffle işlemini özel ağ donanımıyla yürütmek
- Etkili teknikler, zaman verildiğinde herkes tarafından uygulanabilir ve iyi çalıştığında birçok sisteme yayılma olasılığı yüksektir
- Fivetran CEO’su George Fraser’ın veri ambarı performans karşılaştırmasında, 2020’de en hızlı süre 8 saniye, en yavaş süre 18 saniyeydi; 2022’de ise üç tedarikçi yaklaşık 7 saniyeye gelirken en yavaş tedarikçi 9 saniyeye indi
- Ancak mimari farklar aşılması zor olabilir
- shared nothing veritabanları, shared disk’e göre dezavantajlı olabilir
- Redshift’in büyük ölçüde shared disk mimarisine geçmesi yıllar aldı
- metadata’yı object store’da tutan lakehouse yapıları hızlı güncellemelerde zorlanabilir
- Bu farklar çoğunlukla sınır koşullarında ortaya çıkar ve uzun vadede Redshift’in Snowflake’ten özünde daha hızlı ya da daha yavaş olmak zorunda olmasının bir nedeni yoktur
Sorudan cevaba giden süreyi azaltan özellikler
- Kullanıcı için önemli olan performans, sorunun doğduğu andan cevabın alındığı ana kadar geçen süredir
- Bu süreyi azaltmanın yolu yalnızca sorgu planını iyileştirmek değildir
- soruyu daha kolay ifade etmeyi sağlayabilir
- sorgu sonucunu anlamayı kolaylaştırabilir
- yanlış soru sorulduğunda geri bildirim verebilir
- veri sorunlarının anlaşılmasına yardımcı olabilir
- gerekli verinin doğru yerde ve doğru biçimde hazırlanmasını sağlayabilir
- Snowflake, kullanıcı SQL yazdığında “sadece çalışmasını” sağlama konusunda güçlüydü
- tarih farkı hesaplarken hem DATEDIFF hem TIMEDIFF kullanılabiliyordu
- makul türlerde ikisi de çalışıyordu
- granularity belirtilebilir ya da atlanabilirdi
- granularity tırnaklı ya da tırnaksız yazılabiliyordu
- DuckDB de Friendlier SQL ile sorgu yazmayı ve bakımını kolaylaştıran özellikler ekledi
GROUP BY ALL, toplulaştırma sorgularında GROUP BY alanlarının eksik yazılmasını azaltır- yalnızca SELECT listesini değiştirmek yeterli olduğundan, sorgu evrilirken birden çok yeri değiştirme ihtiyacı azalır
- bu özellik yararlı olunca birçok veritabanı tedarikçisi benzer işlevler ekledi
- CSV dosyaları dünyadaki verilerin büyük bölümünü taşıyan bir biçimdir, ancak birçok dosya hatalı yapılandırılmıştır ve ayrıştırma gerçekte zordur
- BigQuery’nin ilk CSV splitter’ı inference yapamıyordu ve dosyalar arasında şema biraz bile farklıysa zorlanıyordu
- CSV ayrıştırma düşünüldüğünden daha zorlu bir problemdir
- İki mühendis CSV verisini okuyup aynı sonucu hesaplamak zorundaysa, CSV’yi daha kolay ve doğru ingest eden taraf, sorgu motoru hızından bağımsız olarak cevaba önce ulaşabilir
- Sonuçların işlenme biçimi de kullanıcı deneyimini büyük ölçüde etkiler
SELECT *, MySQL’de olduğu gibi ilk sayfayı ve cursor’ı döndürüyorsa hemen görüntülenebilir- BigQuery’de olduğu gibi sunucu tarafında tablonun bir kopyasını oluşturmak gerekiyorsa, büyük tablolarda bu saatler sürebilir
- istemci tüm veriyi indirmeye çalışırsa bellek yetersizliği oluşabilir
- uzun bağlantılar ağ sorunlarına daha açıktır ve yoklama yöntemi, sorgu yoklama aralıklarının arasında biterse daha yavaş görünmesine yol açabilir
DuckDB benchmark’larına bakarken ipuçları
- DuckDB hızlıdır ve bazı machine size’larda ClickBench’te en üst sıralardadır
- örnek olarak c6a.4xlarge sonucu verilir
- DuckDB, çoğu h2o.ai benchmark’ında da iyi performans gösterir; TPC-H ve TPC-DS’de de kötü değildir
- Hangi veritabanının hızlı olduğunu varsaymadan önce, bunu kendi iş yükünüz üzerinde doğrudan test etmelisiniz
Hızlı sorgudan çok hızlı problem çözümü
- En başarılı veritabanı şirketleri, rakiplerinden daha hızlı oldukları için başarılı olmadı
- Redshift bir süre güçlüydü, ancak Snowflake’in pazara girebilmesinin nedeni benchmark performansı değil bakım kolaylığıydı
- Performansı ana satış noktası yapan veritabanları pazarda iyi sonuç almadı; işleri kolay tamamlatan veritabanları daha kalıcı oldu
- Veritabanı seçiminde bakılması gereken eksen daha geniştir
- sihirli gizli teknikler yoktur; mimari farklar dışında performans zamanla yakınsar
- veritabanı motorlarının gelişim hızı büyük ölçüde farklıdır ve hızlı ilerleyen taraf uzun vadede avantajlıdır
- performansa en takıntılı veritabanı tedarikçisi uzun vadede yavaşlayabilir
- veritabanı performansı için tek bir gösterge yoktur ve hızlı veritabanı bile bazı iş yüklerinde kötü olabilir
- önemli olan, sorgudan sonuca değil fikirden cevaba ne kadar hızlı gidilebildiğidir
- Yavaş sorgudan hızlı sorgu iyidir, ancak veritabanı seçimi ham hız dışındaki etkenlere göre yapılmalıdır
1 yorum
Hacker News yorumları
Yıllardır çok sayıda müşteri şikâyeti olmasına rağmen JDBC sürücüsü sorununun performansı mahvettiğini “hiç bilmedikleri” kısmı insanı hayal kırıklığına uğratıyor.
Google içinde kendi ürünlerini gerçek müşteriler gibi kullanmamışlar; kullanıcıların gördüğü sorgu süreleri içeride görünmediği için de bunu başkasının sorunu gibi ele almışlar.
Sorun optimizasyona fazla emek harcanması değil, müşterinin acısından başlayıp kök nedene kadar iz sürülmemesiydi. Gerçek neden de nihayetinde bir performans sorunuydu.
JDBC hikâyesi gerçekten iyiydi. Google içeride iyi çalışan bir veritabanı yapmış, dış dünya için adaptör katmanını taşerona yaptırmış; o katman düzgün çalışmayınca dış kullanıcılar berbat bir veritabanı kullanmak zorunda kalmış.
Google’ın kullandığı sofistike çekirdeğin üstüne bozuk bir ambalaj geçirilmiş ve bütün ürün gereksiz yere berbat hale gelmiş; içeride kimse fark etmemiş, dış kullanıcıların da nedeni anlaması zor olmuş. Google’ın açık kaynak stratejisini çok isabetli gösteren bir örnek gibi görünüyor.
Sorun şu: Temel olmayan alanları yeterince bozarsanız, temel yetkinliğinizin mükemmel olması da işe yaramaz. Dış kaynak kullanımı bedava öğle yemeği değildir.
Yazıda “performans özneldir” ve basit ölçümler yetmez deniyor, ama verilen örnekler performansın gerçekten önemli ve nesnel olduğu durumlar. Sadece yanlış şey ölçülmüş.
Bu, şirketin organizasyon sorunu gibi geliyor. Nihai hedef insanların bulutu kullanmasını sağlamak ve değer sunmaksa, müşterilerin önem verdiği şeylerle uyuşmayan metriklerin neden kullanıldığını anlamıyorum.
Google içinde müşterilerle doğrudan konuşup sorunun ne olduğunu anlayan, sonra bunu mühendislere aktararak neyin iyileştirileceğini bilmelerini sağlayan birileri olmalı. Organizasyon, mühendislerin ihtiyaç duyduğu metrikleri alacağı ya da o metrikleri üretmenin bizzat iş tanımına dahil olacağı şekilde tasarlanmalı.
Ürün ve organizasyon liderliğinin hangi metriklere baktığını ve böyle bir müşteri geri bildirimini nasıl kaçırdığını daha çok merak ediyorum.
“Seattle’daki evden San Francisco’daki ofise kapıdan kapıya 4,5 saat” kısmını görünce, günümüz kurucuları artık saatte 179 mil hızla hareket etmiyor gibi geldi. Fed faizleri artırınca böyle oluyor galiba.
Kesinlikle iyi noktalar var ama sonuç biraz hedefi ıskalamış gibi. Performans burada anlatıldığı gibi ikincil olmaktan ziyade yeterli olup olmadığı meselesi.
Yeterince hızlı mı eşiğini geçmeniz gerekir ki ondan sonra diğer unsurlar değerlendirilebilsin. Ondan önce rekabet masasına bile oturamazsınız. Yazar da “DuckDB hızlı” diyor; hızlı olmasaydı, en azından o kutucuğu işaretleyene kadar performansla rekabet etmek zorunda kalırdı.
Ayrıca “en hızlı hareket eden veritabanı motoru eninde sonunda kazanır” sözü bir ölçüde doğru olabilir ama pek pratik değil. Yeni bir oyuncuyken ilerleme hızlıdır; Snowflake gibi bir konuma gelince hız kaçınılmaz olarak düşer. Bugün sistem seçen biri olarak mevcut ivmeyi geleceğe aynen ekstrapole edemezsiniz.
Yine de “sorgudan sonuca” değil, fikirden yanıta ne kadar hızlı gidildiği bakış açısı ayrıca derinlemesine incelenmeye değer görünüyor.
Performans “öznel” olmaktan çok görelidir. Anlamı, eldeki işle bağlantılıdır.
Ancak kullanıcının daha hızlıymış gibi hissetmesini sağlayan, hızlı ilerleyen bir ilerleme göstergesi gibi arayüzlerden söz ediliyorsa o ayrı mesele. Bu bir arayüz sorunudur, veritabanı sorunu değil.
“Göreli” demek için, sistemler arası karşılaştırma dışında performansa sayı atamanın mümkün olmaması gerekir; bu doğru değil.
İlk popüler olan web uygulaması tüm durumu bir Python dict içinde tutup birkaç dakikada bir diske dump ediyordu. Hayatımda gördüğüm en hızlı API’ydi.
Mongo’ya taşındıktan sonra performans bir daha hiç toparlanmadı. Yine de bugün bir web sitesi yaparken “pickledb”ye uzanmıyorum.
fopenyerine kullanılacak orta yol SQLite.İstek/yanıt tarzı kullanıcı etkileşimlerine daha az uygun, ama büyük statik verileri ya da yeniden oynatılabilir streaming verilerini artımlı veya toplu işleyen durumlarda bence bugünkünden daha yaygın olmalı.
“Shared nothing veritabanları shared disk’e göre dezavantajlıdır; Redshift’in ağırlıklı olarak shared disk mimarisine geçmesi yıllar aldı. Metadata’yı nesne depolamada tutan Lakehouse’larda hızlı güncelleme yapmak zordur” konularında iyi kaynaklar arıyorum.
Güzel yazı. Son 10 yılda pandas’ın güçlü olmasının nedenlerinden birinin de bu olduğunu düşünüyorum.
Tek makine performansı yeterince iyiydi ve insanlığın bildiği CSV’lerin %99’unu okuyabiliyordu.