ClickHouse açık kaynağının 10 yılı
(clickhouse.com)- ClickHouse, 15 Haziran 2016 tarihinde yayımlandıktan sonra 10 yıl boyunca 2.000'den fazla kişinin katkı sunduğu, açık kaynak analitik veritabanlarının önde gelen projelerinden birine dönüştü
- Sadece kodu yayımlamakla kalmayıp katkı rehberi, kod incelemesi, yol haritası, CI, sürümler ve dokümantasyonu da açık tutan Seviye 3 açık kaynak anlayışını benimsiyor
- Çıkış noktası, MySQL tabanlı web analitiği sistemlerinin sınırlarıydı; OLAPServer ve Metrage deneyimi, sütun odaklı işleme ve MergeTree tasarımına uzandı
- ClickHouse, mevcut bir DBMS üzerine yapılmış bir genişletme değil; 2009'dan itibaren sütun temsili, toplulaştırma fonksiyonları, tablo motorları, sıkıştırma, SQL ayrıştırıcısı, sunucu·istemci ve ReplicatedMergeTree'nin adım adım geliştirildiği, sıfırdan uygulanmış bir DBMS
- 2014'te şirket içi prodüksiyonda her gün yüz milyarlarca kaydı işledikten sonra, 2015'te yayımlanan yazılar ve iç onay sürecinin ardından 2016'da dünya çapında açıklandı
Açık kaynak olarak yayımlanışının 10. yılı
- ClickHouse, 15 Haziran 2016'da açık kaynak olarak yayımlandı
- Sonrasında 2.000'den fazla kişi katkı sundu ve “en popüler açık kaynak analitik veritabanı” haline geldi
- Projenin temel hedefi, yalnızca kodu açmakla yetinmeyip geliştirme sürecini ve katkı sürecini mümkün olduğunca açık hale getirmek
ClickHouse'un hedeflediği açık kaynak seviyesi
- Açık kaynak dünyasında çeşitli seviyeler bulunuyor
- Level 0: Kod okunabilecek şekilde yayımlanır ama bunun ötesi yoktur. Doom ve MS-DOS gibi arşiv/müze tarzı yayımlar buna örnektir
- Level 1: Açık bir depoda commit'lerle güncellenir ama mutlaka dış katkı almaz. SQLite ve Ladybird buna örnektir
- Level 2: Katkı kabul edilir ama geliştirme süreci şeffaf ve kamusal değildir. Aktif açık kaynak projelerinin çoğu bu gruptadır
- Level 3: Katkı rehberi, iş takibi, kod incelemesi, geliştirme yol haritası, testler ve CI, sürüm döngüsü, kullanıcı desteği ve dokümantasyon vardır
- ClickHouse, Level 3 açık kaynağı hedefliyor
- Yeni bir veritabanı yapmak isteyen geliştiriciler için hem kod hem de geliştirme pratiği açısından bir referans olmak da amaçlanıyor
- Kodun modüler, ortogonal ve belgelenmiş olması hedefleniyor
- Karmaşık kavramlar gerektiğinde, okurun ders kitabı, Wikipedia veya yapay zekaya başvurmadan anlayabilmesi için yorumlarda en baştan açıklanıyor
C++ geliştirme ve performans deneyleri için bir alan
- ClickHouse, popüler C++ açık kaynak depolarından biri olarak; C++23 gibi modern dil özellikleri, build sistemi, sürekli entegrasyon/test ve kod inceleme pratiklerinin birlikte öğrenilebildiği bir yer olmayı hedefliyor
- Veri yapıları ve performans optimizasyonu deneyleri de önemli bir kullanım biçimi
- Birleştirilmesi hedeflenmeyen deneysel Pull Request'ler bile prodüksiyon sürümleriyle aynı seviyede test ediliyor
- Yeni bellek ayırıcılar, sıkıştırma kütüphaneleri, hash tabloları, veri formatları ve sıralama algoritmaları gibi deneyler ClickHouse üzerinde doğrulanabiliyor
- Yol haritasında deneysel, tuhaf, hatta komik maddeler bile yer alıyor
- Tüm katkı sağlayanlar, CHANGELOG ve veritabanı içindeki system.contributors tablosunda anılıyor
- İlk uygulaması eksik kalan özelliklerin sonradan birlikte tamamlanması sık görülüyor; tüm kodun yeniden yazılması gerekse bile, ilk yazanın niyeti ve kullanım senaryoları yine de takdir ediliyor
ClickHouse öncesindeki sorunlar ve prototipler
- ClickHouse'un ilk commit'i 29 Mayıs 2009'da yapıldı ve
localtime,mktime,gmtimegibi libc fonksiyonlarının çok yavaş olması nedeniyle profiler'da görünen sorunu azaltmaya yönelik bir performans optimizasyonuydu - Çıkış noktası, web analitiği sistemi için yapılan veri işleme deneyleriydi
- Sistem, Google Analytics'e benzer şekilde web sitelerinden gönderilen pageview log'larını alıyordu
- MySQL, C++ ile veri işleme ve MySQL'in yetmediği alanlar için özel C++ veri yapıları birlikte kullanılıyordu
- MySQL veritabanı, müşteri için önceden toplulaştırılmış raporları saklıyor; özel veri yapıları ise kullanıcı oturumları ve kullanıcı geçmişi hesaplamalarında kullanılıyordu
- Veri sürekli büyüyordu ve yeni log'lar gerçek zamanlı geliyordu; 5 dakikalık log'lar 5 dakika içinde işlenemezse gecikme birikmeye devam ediyordu
- Çeşitli veritabanları ve kütüphaneler de denendi
- TokuDB, LMDB, Judy Arrays, Hadoop, LZO, QuickLZ, HyperLogLog, veri sıkıştırma materyalleri ve event loop sunucu dokümantasyonları incelendi
- Kullanıcıların kendi raporlarını serbestçe oluşturabilmesini istemek, önceden toplulaştırılmış raporların sınırlarını ortaya çıkardı ve sütun odaklı veritabanı incelemelerine yol açtı
OLAPServer ve Metrage
- Sütun odaklı yaklaşım, toplulaştırılmamış yapısal log'ları saklayıp müşteriler sayfa yüklenmesini beklerken anlık olarak toplulaştırma yapmaktı
- MySQL eklentisi Infobright, InfiniDB ve bağımsız analitik veritabanları Vertica, MonetDB, LucidDB test edildi; ancak günde 100 milyar kayıt ve 500 sütunluk yükleme koşullarında çalışmadılar
- İlk özel prototip OLAPServer idi
- Aralık 2008'de geliştirildi ve Ocak 2009'da dağıtıldı
- Tüm sütunlar, gün ve web sitesi bazında tek bir ikili dosyada tutuluyordu
- String yerine hash kullanılıyor, yalnızca tamsayı tipleri destekleniyordu
- Hafif sıkıştırma kullanılıyor ve günde bir kez, birkaç saat gecikmeyle güncelleniyordu
- Gruplama sütunları, toplulaştırma fonksiyonları, filtreler ve sıralamayı belirleyen bir API sunuyordu; sorgular XML ile tanımlanıyordu
- Eski MySQL toplulaştırma verilerini “toplulaştırılmamış” hale getirerek aynı sonucu verecek biçimde doldurma işini Evgenii Gatov çözdü
- OLAPServer, tek bir web sitesi yerine tüm şirket internet verisini analiz eden uç noktada da çalıştı ve kurum içi analistlerin internal MapReduce yerine kullanabilecekleri kadar hızlı yanıt verdi
- İkinci prototip Metrage idi
- MySQL'de yaklaşık 50 TB veri 50 shard üzerinde birikmişti ve birçok özel veri yapısı BLOB olarak saklanıyordu
- Toplulaştırma sırasında programın BLOB'u okuyup özel kodu uygulaması, sonra yeniden eklemesi gerekiyordu
- MySQL verisi sıkıştırılmamıştı; ayrıca geliş sırası ile sorgu aralığı sırası uyuşmadığı için okuma da yavaştı
- Metrage, arka plan birleştirmeleri kullanan artımlı toplulaştırma için özel bir veri yapısıydı; her kayıt
add,update,merge,serializeText/Binary,deserializeText/Binarymetodlarına sahip bir C++ struct olarak tanımlanıyordu
- OLAPServer, toplulaştırılmamış sütun odaklı bir yapıydı; Metrage ise keyfi CRDT'lere sahip gerçek zamanlı satır odaklı bir yapıydı
- ClickHouse, sütun odaklı toplulaştırma hızını merge tree tabanlı gerçek zamanlı güncellemeler ve veri yerelliğiyle birleştirip, bunu gerçek bir sorgu dili ve veri tipleri desteğiyle genelleyerek doğdu
Sıfırdan yapılmış bir DBMS
- ClickHouse, mevcut bir veritabanı üzerine kurulmayan, sıfırdan uygulanmış nadir DBMS örneklerinden biri
- 2009'daki ilk commit'ler, aynı monorepo içindeki diğer veri yapısı optimizasyonlarıyla ilgiliydi; açık kaynak yayımlama sürecinde geçmiş korunarak depo ayrıldığı için bugün hâlâ görünüyorlar
- Yeni DBMS uygulamasının ilk adımı, bellek içi sütunların hayata geçirilmesiydi; bugün de tanıdık gelen
IColumnveFieldsınıfları burada ortaya çıktı- Apache Arrow'a benziyor görünebilir, ancak o dönemde Apache Arrow henüz yoktu
- RCFile, Trevni, ORC, Parquet gibi diğer sütun odaklı formatlar da o sırada mevcut değildi
- Sonrasında toplulaştırma fonksiyonları eklendi ve bunlar bugün de ClickHouse'un en önemli bölümlerinden biri
- Tablo motorları da eklendi
- Başlangıçta birkaç gün boyunca “primary key” adı kullanıldı
- Diskten sütun okuma ve yazmayı mümkün kıldı
- İlk tablo motoru, bugün hâlâ var olan TinyLog'a benziyordu
- Sıkıştırmada önce QuickLZ kullanıldı, ancak Yann Collet'nin blogu okunduktan sonra LZ4'e geçildi
Sorgu hattı ve SQL uygulaması
- block streams, sütun parçalarını akış biçiminde üreten, tüketen ve dönüştüren veri işleme hattı bileşenleriydi
- Günümüzde bunların yerini Processors aldı
- Sonuç biçimlendirme ve tablo sorgusu uygulamalarının temelini oluşturdular
- Aynı commit'te test amacıyla
StorageSystemNumberseklendi; bugün bu yapısystem.numberstablosu olarak yaşamını sürdürüyor - İlk sorgu hattı, sayıları TSV olarak yazdırıyordu; ilk ilişkisel işlemci
LIMITidi - SQL ayrıştırıcısında önce boost::spirit denendi ama başarısız olundu; daha sonra recursive descent parser geliştirildi
- Başta eklenip sonra çıkarılan ya da daha sonra geri gelen fikirler de vardı
- Değişken uzunluklu kodlanmış sayı sütunları yavaş oldukları için çıkarıldı; çok daha sonra sütunlardan bağımsız özel sıkıştırma codec'leri geldi
- Keyfi alan değerleri taşıyan
Variantsütun tipi de yavaş olduğu için kaldırıldı; daha iyi bir Variant 2025'te eklendi - Sabit boyutlu dizi tipi ihtiyaç azlığı nedeniyle kaldırıldı; bugün yeniden eklenmesi değerlendiriliyor
- Gereksiz kodu kaldırmanın, yeni kod eklemekten daha önemli olduğuna dair geliştirme ilkesi burada açıkça görülüyor
Prodüksiyon dağıtımı ve ReplicatedMergeTree
- ClickHouse'ta test edilen ilk gerçek tablo şeması
hitstablosuydu; bugün bunu ClickBench içinde de görmek mümkün - Bu tabloyu okuma ve yazma sürecinde C++ iostreams'in yavaş olduğu görüldü; bunun üzerine
WriteBufferveReadBuffergeliştirildi ve bugün hâlâ kullanılıyorlar - SQL'deki ilk fonksiyonlar aritmetik operatörlerdi; bunlarla ilk
SELECTsorgu yorumlayıcısı yazıldı - ClickHouse sunucusu 9 Mart 2012'de,
clickhouse-clientise 25 Mart 2012'de eklendi Log,TinyLog,Merge,Distributed,Memorytablo motorlarıyla birlikte prodüksiyon dağıtımı mümkün hale geldi- İlk prodüksiyon kullanımı, ek işlem için log parçalarını saklamak ve ham log'lar üzerinde global sorgular yapmaktı
- SQL sorgulanabilir kalıcı bir log kuyruğu gibi kullanıldı
- Sonrasında MergeTree eklendi
- Veri zamana göre gelse bile arka planda artımlı sıralama yapıyordu
- Tek bir web sitesi üzerindeki aralık sorgularını hızlı yürütmeyi sağladı
- OLAPServer ve Metrage'in yerini alabilecek prodüksiyon dağıtımlarını mümkün kıldı
- 2012'de Michael Kolupaev ekibin ikinci çalışanı olarak katıldı ve ReplicatedMergeTree'nin uygulanmasına katkı verdi
- Prodüksiyon, birden çok bölgedeki veri merkezlerine dağıtıldı; altyapı ekibi ayda bir kez veri merkezlerinden birini bir saatliğine kapatan “drill”ler yapıyordu
- Tüm prodüksiyon servislerinin çoklu veri merkezi replikasyonuna sahip olması gerekiyordu
- İlk aşamada basit double-write ve kesinti sonrası backfill kullanıldı
- %100 tutarlılık ve otomatik kurtarma için dağıtık uzlaşma gerekiyordu
- Metadata katmanı olarak ZooKeeper kullanan ReplicatedMergeTree geliştirildi
- ReplicatedMergeTree, 2014'te kullanıcıya dönük sorgular için ClickHouse'un prodüksiyonda kullanılmasını mümkün kıldı
Açık kaynak yayıma giden süreç
- 2014'te ClickHouse, prodüksiyonda her gün yüz milyarlarca kaydı saklıyor ve müşterilerin gerçek zamanlı sorgularına yanıt veriyordu
- Şirket içindeki veri bilimciler ClickHouse ile internet trendlerini hesapladı ve basit kullanım dokümanları da yayımlandı
- Reklam, e-ticaret, altyapı ve iş analitiği gibi diğer ekipler de ClickHouse'u denedi; bazı kullanım senaryoları internal MapReduce, MySQL ve Postgres'ten taşındı
- 2014 sonuna gelindiğinde ClickHouse tek bir şirket içinde yaygın biçimde kullanılıyordu; istisnai olarak CERN de LHCb experiment iş birliği kapsamında dağıtım yaptı
- Diğer şirketlerdeki mühendislerin de mevcut veritabanlarının kendi kullanım senaryolarını iyi karşılamaması nedeniyle OLAPServer veya Metrage benzeri sistemler geliştirdiği görüldü
- 2015'te ClickHouse hakkında yazılar ve çeviriler yayımlanınca ilgi daha da doğrulandı
- Açık kaynaktan önce, şirket yönetimini ikna etmek için olası fayda ve risklerin listesi hazırlandı
- Onay alındıktan sonra sürüm planı, ilk logo, ilk web sitesi, blog yazısı ve Debian deposu hazırlandı; ClickHouse 15 Haziran 2016'da dünya çapında yayımlandı
- Bugün ClickHouse, dünya genelindeki büyük şirketlerin kullandığı popüler bir analitik veritabanı haline geldi
1 yorum
Hacker News görüşleri
2017~2018 civarında ClickHouse'u keşfedip Elasticsearch'ün yerine geçebileceğini doğrulayan bir proof of concept hazırlamıştım; birkaç hafta içinde depolama alanı ve saniye başına sorgu sayısı 5 kat iyileşmişti
Ama yöneticiler, yeterince tanınmadığı ve “Rusların yaptığı bir veritabanı” gibi göründüğü gerekçesiyle bunu reddetti
Kişisel olarak, treni bu kadar erken görüp de binememiş olmama hâlâ epey üzülüyorum
Sıkıştırma oranı da akıl almaz düzeydeydi ve depolama maliyeti benchmark'ı S3 maliyeti seviyesine kadar indi
Aylık milyonlarca dolarlık bir depolama katmanı, aylık birkaç bin dolar seviyesine düşecekti
ClickHouse her derde deva değil ama veriye nasıl erişildiğini anlayıp buna göre yerleşim yapabiliyorsanız inanılmaz verim elde edebilirsiniz
Benim anladığım kadarıyla ClickHouse daha çok grep benzeri aramalarda işe yarıyor
Uzun süre TimescaleDB kullanan biri olarak ClickHouse gerçekten çok tazeleyici geldi. psql harika ve tek bir veritabanı sistemine tamamen güvenebilmek de güzel, ama migration bakımı ve dağıtım aşamalarında epey acı çektiriyordu
TimescaleDB'nin de her sürümde yapısı değişiyormuş gibi bir hissi var ve geliştirme yönü biraz sallantılı olduğundan bazen alfa kalitesinde bir ürün gibi geliyor
PeerDB ile büyük bir ClickHouse aynası mı kursam, yoksa ek bir kırılgan katman olmadan ayrı mı dağıtsam hâlâ kararsızım
TimescaleDB'yi hiç önermeyen biri misiniz, merak ediyorum. PostgreSQL şu an stack'teki en sağlam parça, bu yüzden alfa kalitesindeki yazılımın acısını kesinlikle çekmek istemem
DuckDB tarafında da pg_duckdb çalışmaları var, Xata gibi yerler de var
Bu arada ParadeDB'de çalışıyorum
Cloud 66'nın metrik ve otomatik ölçeklendirme motoru, ClickHouse'ta karar kılmadan önce 5 yinelemeden geçti: Redis, Cassandra, Ruby+RabbitMQ ile özel geliştirme, Go+RabbitMQ ile özel geliştirme ve son olarak ClickHouse
Her seferinde bir sınıra ya da taşınamaz optimizasyon yüküne çarpıyorduk; ClickHouse ise son 4 yıldır çok istikrarlı oldu
Loki'yi ClickHouse ile değiştirdikten sonra gözlemlenebilirlik stack'i nihayet “doğru” hissettirmeye başladı. Loglar ve genel analitik sorgular için gerçekten çok güçlü
İyi bir OLAP veritabanı olmasının yanında, uzak kaynaklardan veri çekebilen yerleşik bağlayıcıları oyunun kurallarını değiştirdi
İçinde Parquet/JSON dosyaları olan bir S3 klasörünü düzenli olarak otomatik içe alabiliyor, ayrıca Postgres'e de doğrudan bağlanabiliyor
Orta ölçekli bir gazetenin veri ambarında Druid+Postgres+Trino kombinasyonunu tek büyük bir ClickHouse düğümüyle değiştirdik ve bir daha arkamıza bakmadık
Çok daha hızlı, çok daha kullanışlı ve bakımı da çok daha az
ClickHouse'u gerçekten seviyorum ve performansı müthiş. Burada burada birkaç sorguyu performans için ayarlamam gerekti ama genel olarak beklentimin üstündeydi
İlk başta büyük artımlı yükleri işlemek için gerçek zamanlı bir pipeline ingestion kurmuştum; daha önce kullandığımız Redshift pahalı ve nispeten yavaştı
Şimdiye kadar ClickHouse çok miktarda veri ve büyük dönüşümleri rahatlıkla kaldırdığı için o pipeline'a ihtiyaç kalmadı
Tek sorun, varsayılan ayarlarda oldukça ağır bir tracing özelliğinin açık olması ve nispeten küçük makinelerde performansı ciddi biçimde düşürmesiydi
Sonrasında ölçeği büyüttük ve artık veri stack'inin merkezi haline geldi
Gerçekten devasa ölçekte olsaydım belki başka bir şey seçerdim ama birkaç düğüm seviyesinde kaldığınız sürece karmaşıklık yönetilebilir ve kullanması keyifli
“Merge edilmesi hedeflenmese bile deney amaçlı pull request açılabilir ve üretim sürümüyle aynı seviyede kontrolden geçer. Yeni bir bellek ayırıcısı, sıkıştırma kütüphanesi, hash tablosu, veri formatı ya da sıralama algoritması mı buldunuz? ClickHouse'a getirin, içini dışına çıkarır” denmesi etkileyici
Linux çekirdeği dahil neredeyse her yerde bug buluyor
Çok sıkı bir fuzzer altyapısı var; farklı seviyelerde birden çok fuzzer çalışıyor ve inanılmaz sayıda ayar kombinasyonuyla test yürütülüyor
Yaklaşık 1 yıl önce duyduğum son rakam, tam CI çalışmasının tek bir commit için yaklaşık 400 saat sürdüğü yönündeydi
Yani iyi anlamda epey çılgın bir seviye
Blog yazısının SQLite ve Ladybird'ü spektrumda gösterip, temel açık kaynak rakibi olan DuckDB'yi dışarıda bırakması ilginç
Güven veren şeyin 3. aşama olduğuna katılıyorum
Ama vibe coding ile üretilmiş veritabanları çağında sürdürülebilir olmak için yeni bir iş modeli icat etmek gerekecek
İndekslenmemiş sütunları sorgularken ClickHouse, Parquet sorgulayan DuckDB'den rahatlıkla 10 kat hızlı olabiliyor; primary key'e dokunduğunuzda ise neredeyse kıyas kabul etmeyecek kadar hızlı
İkisini karşılaştıran çok yazı var ama gerçekte ClickHouse ve DuckDB tamamen farklı alanlarda duruyor
DuckDB güçlü bir analiz motoru, ClickHouse ise replikasyon ve MergeTree motorları gibi özelliklere sahip tam teşekküllü bir veritabanı yönetim sistemi
Çoğu kişi için bu ölçek sorunu çıkmaz ama çıktığında fark büyük olur
Sayfada “Google Analytics benzeri web analitiği sistemi için veri işleme” ifadesinin aslında Yandex'te kullanılmış bir şey olduğunu söylemekten kaçınılması üzücü
Muhtemelen o şirketin reklamını yapmak istemiyorlar ama bunun neden üzücü olduğunu çok anlayamıyorum
ClickHouse, daha önce çalıştığım bazı şirketlerde tam bir oyun değiştirici olmuştu. Rust in Production podcast'inin Rust benimsemesiyle ilgili bölümünü hatırlattı
https://open.spotify.com/episode/0TBKDUhO0KihBxEzZqnQx1