ClickHouse özel bir sistem olduğundan, onu kullanırken mimarisinin özelliklerini dikkate almak önemlidir. Bu raporda Alexey, ClickHouse'u kullanırken etkisiz çalışmaya yol açabilecek yaygın hata örneklerinden bahsedecek. Pratik örnekler, bir veya başka bir veri işleme şemasının seçilmesinin performansı büyük ölçüde nasıl değiştirebileceğini gösterecektir.
Herkese selam! Adım Alexey, ClickHouse'u yapıyorum.
Öncelikle sizi hemen memnun etmek için acele ediyorum, bugün size ClickHouse'un ne olduğunu anlatmayacağım. Dürüst olmak gerekirse bundan yoruldum. Her seferinde sana ne olduğunu söylüyorum. Ve muhtemelen herkes zaten biliyor.
Bunun yerine size ne gibi olası hatalar olduğunu yani ClickHouse'u nasıl yanlış kullanabileceğinizi anlatacağım. Aslında korkmanıza gerek yok çünkü ClickHouse'u basit, kullanışlı ve kutudan çıktığı gibi çalışan bir sistem olarak geliştiriyoruz. Kurulumu yaptım, sorun yok.
Ancak yine de bu sistemin uzmanlaşmış olduğunu ve bu sistemi konfor alanının dışına çıkaracak alışılmadık bir kullanım durumuyla kolayca karşılaşabileceğinizi hesaba katmanız gerekir.
Peki ne tür bir tırmık var? Çoğunlukla bariz şeylerden bahsedeceğim. Herkes için her şey ortadadır, herkes her şeyi anlar ve bu kadar akıllı olduklarına sevinebilir, anlamayanlar ise yeni bir şeyler öğrenecektir.
Maalesef sıklıkla karşılaşılan ilk ve en basit örnek, küçük partilere sahip çok sayıda kesici uç, yani çok sayıda küçük kesici uçtur.
ClickHouse'un ekleme işlemini nasıl gerçekleştirdiğini düşünürsek, tek istekte en az bir terabayt veri gönderebilirsiniz. Problem değil.
Ve tipik performansın ne olacağını görelim. Örneğin Yandex.Metrica verilerinden bir tablomuz var. İsabetler. 105 bazı sütunlar. Sıkıştırılmamış 700 bayt. Ve bir milyon satırlık gruplar halinde iyi bir şekilde ekleyeceğiz.
MergeTree'yi tabloya yerleştiriyoruz, saniyede yarım milyon satır çıkıyor. Harika. Çoğaltılmış bir tabloda biraz daha küçük olacaktır; saniyede yaklaşık 400 satır olacaktır.
Çekirdek eklemeyi etkinleştirirseniz, biraz daha az ama yine de iyi bir performans elde edersiniz; saniyede 250 terim. Çekirdek ekleme, ClickHouse*'da belgelenmemiş bir özelliktir.
* 2020 yılı itibarıyla, .
Kötü bir şey yaparsan ne olur? MergeTree tablosuna bir satır ekliyoruz ve saniyede 59 satır elde ediyoruz. Bu 10 kat daha yavaştır. ReplicatedMergeTree'de – saniyede 000 satır. Ve yetersayı etkinleştirilirse, saniyede 6 satır ortaya çıkar. Bana göre bu tam bir saçmalık. Nasıl bu kadar yavaşlayabilirsin? Hatta tişörtüme ClickHouse'un yavaşlamaması gerektiğini yazdım. Ama yine de bazen oluyor.
Aslında bu bizim eksikliğimizdir. Her şeyin yolunda gitmesini kolaylıkla sağlayabilirdik ama yapmadık. Senaryomuz gerektirmediği için bunu yapmadık. Zaten kasaplarımız vardı. Az önce girişimizde partiler aldık ve hiçbir sorun yok. Takıyoruz ve her şey yolunda gidiyor. Ancak elbette her türlü senaryo mümkündür. Örneğin, verilerin oluşturulduğu bir grup sunucunuz olduğunda. Verileri o kadar sık eklemiyorlar ama yine de sık sık veri ekliyorlar. Ve bir şekilde bundan kaçınmamız gerekiyor.
Teknik açıdan bakıldığında önemli olan, ClickHouse'da bir ekleme yaptığınızda verilerin herhangi bir memtable'da bitmemesidir. Gerçek bir MergeTree günlük yapımız bile yok, yalnızca bir MergeTree'miz var çünkü ne bir günlük ne de bir memTable var. Verileri, zaten sütunlar halinde düzenlenmiş olan dosya sistemine hemen yazıyoruz. Ve 100 sütununuz varsa, 200'den fazla dosyanın ayrı bir dizine yazılması gerekecektir. Bütün bunlar çok zahmetlidir.
Ve şu soru ortaya çıkıyor: "Nasıl doğru yapılır?" Durum öyle ise, yine de bir şekilde ClickHouse'a veri kaydetmeniz gerekiyor.
Yöntem 1. Bu en kolay yoldur. Bir çeşit dağıtılmış kuyruk kullanın. Örneğin Kafka'yı. Sadece Kafka'dan veri çıkarıp saniyede bir topluyorsunuz. Ve her şey yoluna girecek, kaydediyorsunuz, her şey yolunda gidiyor.
Dezavantajları Kafka'nın başka bir hantal dağıtılmış sistem olmasıdır. Ayrıca şirketinizde Kafka'nın olup olmadığını da anlıyorum. İyidir, kullanışlıdır. Ancak mevcut değilse, başka bir dağıtılmış sistemi projenize sürüklemeden önce üç kez düşünmelisiniz. Bu yüzden alternatifleri düşünmeye değer.
Yöntem 2. Bu eski usul bir alternatiftir ve aynı zamanda çok basittir. Günlüklerinizi oluşturan bir tür sunucunuz var mı? Ve sadece günlüklerinizi bir dosyaya yazar. Ve örneğin saniyede bir kez bu dosyayı yeniden adlandırıp yenisini yırtıyoruz. Ve ayrı bir komut dosyası, cron veya bazı arka plan programları aracılığıyla en eski dosyayı alır ve onu ClickHouse'a yazar. Günlükleri saniyede bir kaydederseniz her şey yoluna girecek.
Ancak bu yöntemin dezavantajı, eğer logların oluşturulduğu sunucunuz bir yerde kaybolursa, veriler de kaybolacaktır.
Yöntem 3. Hiçbir şekilde geçici dosyalar gerektirmeyen ilginç bir yöntem daha var. Örneğin, veri üreten bir tür reklam döndürücünüz veya başka ilginç bir arka plan programınız var. Ve bir sürü veriyi doğrudan RAM'de, arabellekte biriktirebilirsiniz. Yeterli zaman geçtiğinde, bu arabelleği bir kenara koyarsınız, yeni bir tane oluşturursunuz ve ayrı bir iş parçacığına, halihazırda birikmiş olanı ClickHouse'a eklersiniz.
Öte yandan kill -9 ile veriler de kayboluyor. Sunucunuz çökerse bu verileri kaybedersiniz. Başka bir sorun da, eğer veritabanına yazamadıysanız verileriniz RAM'de birikecektir. Ya RAM tükenecek ya da sadece veri kaybedeceksiniz.
Yöntem 4. Başka bir ilginç yöntem. Bir tür sunucu işleminiz var mı? Ve ClickHouse'a hemen veri gönderebilir, ancak bunu tek bir bağlantıyla yapar. Örneğin, transfer-encoding: chunked ve insert ile bir http isteği gönderdim. Ve çok nadiren de olsa parçalar üretir, her satırı gönderebilirsiniz, ancak bu verileri çerçevelemek için ek yük olacaktır.
Ancak bu durumda veriler hemen ClickHouse'a gönderilecektir. Ve ClickHouse bunları kendisi tamponlayacaktır.
Ancak sorunlar da ortaya çıkıyor. Artık, işleminizin ne zaman sonlandırıldığı ve ClickHouse işleminin sonlandırılıp sonlandırılmadığı da dahil olmak üzere verileri kaybedeceksiniz çünkü bu, eksik bir ekleme olacaktır. Ve ClickHouse'da ekler, satır boyutunda belirli bir eşiğe kadar atomiktir. Prensip olarak bu ilginç bir yoldur. Ayrıca kullanılabilir.
Yöntem 5. İşte başka bir ilginç yöntem. Bu, veri toplulaştırma için topluluk tarafından geliştirilmiş bir tür sunucudur. Kendim bakmadım, dolayısıyla hiçbir şeyi garanti edemem. Ancak ClickHouse'un kendisi için herhangi bir garanti verilmemektedir. Bu da açık kaynaktır ancak öte yandan sağlamaya çalıştığımız bazı kalite standartlarına alışkın olabilirsiniz. Ama bunun için – bilmiyorum, GitHub'a gidin, koda bakın. Belki normal bir şey yazmışlardır.
*2020'den itibaren ayrıca dikkate alınmalıdır .
Yöntem 6. Diğer bir yöntem ise Tampon tablolarını kullanmaktır. Bu yöntemin avantajı kullanmaya başlamanın çok kolay olmasıdır. Bir Buffer tablosu oluşturun ve içine ekleyin.
Dezavantajı ise sorunun tamamen çözülmemesidir. MergeTree gibi bir hızda, verileri saniyede bir topluluğa göre gruplandırmanız gerekiyorsa, arabellek tablosundaki bir hızda, saniyede en az birkaç bine kadar gruplamanız gerekir. Saniyede 10'in üzerindeyse yine de kötü olacaktır. Ve bunu gruplar halinde eklerseniz, saniyede yüz bin satır olduğunu gördünüz. Ve bu zaten oldukça ağır veriler üzerinde.
Ayrıca arabellek tablolarının bir günlüğü yoktur. Sunucunuzda bir sorun varsa veriler kaybolur.
Bonus olarak yakın zamanda ClickHouse'da Kafka'dan veri alma fırsatı bulduk. Bir masa motoru var - Kafka. Siz sadece yaratın. Ve üzerine somutlaştırılmış temsilleri asabilirsiniz. Bu durumda kendisi Kafka'dan veri çıkaracak ve ihtiyacınız olan tablolara ekleyecektir.
Ve bu fırsatın özellikle sevindirici yanı, bunu yapanın biz olmamamızdır. Bu bir topluluk özelliğidir. Ve "topluluk özelliği" dediğimde bunu herhangi bir küçümseme olmadan söylüyorum. Kodu okuduk, inceleme yaptık, düzgün çalışması gerekiyor.
* 2020 yılı itibarıyla benzer destekler ortaya çıkmıştır. .
Verileri eklerken başka ne sakıncalı veya beklenmedik olabilir? Değer ekleme isteğinde bulunursanız ve değerlere hesaplanmış bazı ifadeler yazarsanız. Örneğin, now() aynı zamanda hesaplanmış bir ifadedir. Bu durumda ClickHouse her satırda bu ifadelerin yorumlayıcısını başlatmak zorunda kalır ve performans büyük ölçüde düşer. Bundan kaçınmak daha iyidir.
*şu anda sorun tamamen çözülmüştür, VALUES'daki ifadeleri kullanırken artık herhangi bir performans gerilemesi söz konusu değildir.
Başka bir örnek, bir grup bölüme ait olan bir toplu iş üzerinde verileriniz olduğunda bazı sorunların ortaya çıkabileceği durumdur. Varsayılan olarak ClickHouse bölümleri aya göredir. Ve bir milyon satırdan oluşan bir grup eklerseniz ve birkaç yıllık veriler varsa, o zaman orada birkaç düzine bölümünüz olacaktır. Ve bu, partilerin boyutlarının onlarca kat daha küçük olacağı gerçeğine eşdeğerdir, çünkü bunların içinde her zaman önce bölümlere ayrılırlar.
* Son zamanlarda, deneysel modda, ClickHouse, yazma öncesi günlük ile RAM'deki yığınların ve yığınların kompakt formatı için destek ekledi; bu, sorunu neredeyse tamamen çözüyor.
Şimdi ikinci tür soruna bakalım: veri yazmaya.
Veri yazma katı veya dize olabilir. String, onu yeni aldığınız ve tüm alanlarınızın string türünde olduğunu bildirdiğiniz zamandır. Bu berbat. Bunu yapmaya gerek yok.
Bir alanımız, bir dizemiz olduğunu söylemek istediğiniz durumlarda bunu nasıl doğru şekilde yapacağımızı bulalım ve bırakın ClickHouse bunu kendi başına çözsün, ben de uğraşmayacağım. Ama yine de biraz çaba harcamaya değer.
Örneğin bir IP adresimiz var. Bir durumda onu bir dize olarak kaydettik. Örneğin, 192.168.1.1. Başka bir durumda UInt32* türünde bir sayı olacaktır. IPv32 adresi için 4 bit yeterlidir.
İlk olarak, garip bir şekilde, veriler yaklaşık olarak eşit şekilde sıkıştırılacaktır. Elbette bir fark olacak ama o kadar da büyük değil. Dolayısıyla disk G/Ç'sinde özel bir sorun yoktur.
Ancak işlemci süresi ile sorgu yürütme süresi arasında ciddi bir fark var.
Sayı olarak saklanıyorsa benzersiz IP adreslerinin sayısını sayalım. Bu saniyede 137 milyon satıra denk geliyor. Aynısı dizeler biçimindeyse saniyede 37 milyon satır. Bu tesadüfün neden gerçekleştiğini bilmiyorum. Bu isteklerimi kendim yerine getirdim. Ama yine de yaklaşık 4 kat daha yavaş.
Ve eğer disk alanındaki farkı hesaplarsanız, o zaman bir fark da olur. Ve fark yaklaşık dörtte birdir çünkü oldukça fazla sayıda benzersiz IP adresi vardır. Ve az sayıda farklı anlamlara sahip satırlar olsaydı, bunlar sözlüğe göre kolayca yaklaşık olarak aynı cilde sıkıştırılırdı.
Ve dört kat zaman farkı yolda değil. Belki umursamıyorsunuz elbette ama böyle bir fark görmek beni üzüyor.
Farklı durumlara bakalım.
1. Birkaç farklı benzersiz değere sahip olduğunuz bir durum. Bu durumda, muhtemelen bildiğiniz ve herhangi bir DBMS için kullanabileceğiniz basit bir uygulama kullanacağız. Bunların hepsi yalnızca ClickHouse için anlamlı değil. Sadece sayısal tanımlayıcıları veritabanına yazın. Ayrıca uygulamanızın yan tarafında dizelere ve geri dönüşlere dönüştürebilirsiniz.
Mesela bir bölgeniz var. Ve onu bir dize olarak kaydetmeye çalışıyorsunuz. Ve orada yazılacak: Moskova ve Moskova Bölgesi. Ve üzerinde “Moskova” yazdığını gördüğümde hiçbir şey yok ama Moskova olunca bir şekilde tamamen üzücü oluyor. Bu kaç bayttır.
Bunun yerine Ulnt32 ve 250 sayısını yazıyoruz. Yandex'de 250 tane var ama sizinki farklı olabilir. Her ihtimale karşı, ClickHouse'un yerleşik bir coğrafi tabanla çalışma yeteneğine sahip olduğunu söyleyeceğim. Hiyerarşik bir dizin de dahil olmak üzere bölgelerin bulunduğu bir dizin yazmanız yeterlidir; Moskova, Moskova Bölgesi ve ihtiyacınız olan her şey olacak. Ve istek düzeyinde dönüştürebilirsiniz.
İkinci seçenek yaklaşık olarak aynıdır, ancak ClickHouse'un içinde destek vardır. Bu Enum veri türüdür. İhtiyacınız olan tüm değerleri Enum içerisine yazmanız yeterli. Örneğin, cihazın türünü yazın ve buraya yazın: masaüstü, mobil, tablet, TV. Toplamda 4 seçenek bulunmaktadır.
Dezavantajı ise periyodik olarak değiştirmeniz gerekmesidir. Yalnızca bir seçenek eklendi. Hadi masayı değiştirelim. Aslında ClickHouse'daki tabloyu değiştirme ücretsizdir. Özellikle Enum için ücretsizdir çünkü diskteki veriler değişmez. Ancak yine de alter, masada bir kilit* alır ve tüm seçimler yürütülene kadar beklemesi gerekir. Ve ancak bu değişiklik yapıldıktan sonra gerçekleştirilecek, yani. hala bazı rahatsızlıklar var.
* ClickHouse'un son sürümlerinde ALTER tamamen engelleyici olmayan bir hale getirildi.
ClickHouse için oldukça benzersiz olan bir diğer seçenek de harici sözlükleri bağlamaktır. ClickHouse'a sayıları yazabilir, dizinlerinizi size uygun herhangi bir sistemde tutabilirsiniz. Örneğin şunları kullanabilirsiniz: MySQL, Mongo, Postgres. Bu verileri http aracılığıyla gönderecek kendi mikro hizmetinizi bile oluşturabilirsiniz. Ve ClickHouse düzeyinde bu verileri sayılardan dizelere dönüştürecek bir fonksiyon yazarsınız.
Bu, harici bir tabloda birleştirme gerçekleştirmenin uzmanlaşmış ancak çok etkili bir yoludur. Ve iki seçenek var. Bir düzenlemede bu veriler tamamen önbelleğe alınacak, RAM'de tamamen mevcut olacak ve belirli bir sıklıkta güncellenecektir. Ve başka bir seçenekte, eğer bu veriler RAM'e sığmıyorsa, onu kısmen önbelleğe alabilirsiniz.
İşte bir örnek. Yandex.Direct var. Bir de reklam şirketi ve pankartlar var. Muhtemelen on milyonlarca reklam şirketi vardır. Ve kabaca RAM'e sığarlar. Ve milyarlarca pankart var, sığmıyorlar. Ve MySQL'den önbelleğe alınmış bir sözlük kullanıyoruz.
Tek sorun, önbelleğe alınan sözlüğün isabet oranı %100'e yakınsa düzgün çalışabilmesidir. Daha küçükse, her veri kümesi için sorguları işlerken aslında eksik anahtarları almanız ve MySQL'den veri almanız gerekir. ClickHouse konusunda yine de şunu garanti edebilirim - evet yavaşlamıyor, diğer sistemlerden bahsetmeyeceğim.
Bonus olarak sözlükler, ClickHouse'daki verileri geriye dönük olarak güncellemenin çok kolay bir yoludur. Yani reklam şirketleri hakkında bir raporunuz vardı, kullanıcı sadece reklam şirketini değiştirdi ve tüm eski verilerde, tüm raporlarda bu veriler de değişti. Satırları doğrudan tabloya yazarsanız güncellemeniz imkansız olacaktır.
Dizeleriniz için tanımlayıcıları nereden alacağınızı bilmediğiniz zaman başka bir yol. basitçe karma yapabilirsiniz. Üstelik en basit seçenek 64 bitlik bir karma almaktır.
Tek sorun, eğer karma 64 bit ise, o zaman neredeyse kesinlikle çarpışmalarla karşılaşacaksınız. Çünkü orada bir milyar çizgi varsa, o zaman olasılık zaten fark edilir hale gelir.
Ve reklam şirketlerinin isimlerini bu şekilde hash etmek pek de iyi olmaz. Farklı şirketlerin reklam kampanyaları karıştırılırsa anlaşılmaz bir şey olacaktır.
Ve basit bir numara var. Doğru, ciddi veriler için de pek uygun değil, ancak bir şey çok ciddi değilse, müşteri tanımlayıcısını sözlük anahtarına eklemeniz yeterlidir. Ve sonra çarpışmalar yaşayacaksınız, ancak yalnızca bir istemci içinde. Bu yöntemi Yandex.Metrica'daki bağlantı haritaları için de kullanıyoruz. Orada URL'lerimiz var, karmaları saklıyoruz. Ve elbette çarpışmaların olduğunu biliyoruz. Ancak sayfa görüntülendiğinde, bir kullanıcının bir sayfasında bazı URL'lerin birbirine yapışmış olması ve bunun fark edilmesi ihtimali ihmal edilebilir.
Bonus olarak, birçok işlem için karmalar tek başına yeterlidir ve dizelerin herhangi bir yerde saklanmasına gerek yoktur.
Başka bir örnek, dizelerin kısa olması, örneğin web sitesi alanlarıdır. Olduğu gibi saklanabilirler. Veya örneğin, tarayıcı dili ru 2 bayttır. Tabii ki baytlara gerçekten üzülüyorum ama merak etmeyin, 2 bayt yazık değil. Lütfen bu şekilde kalsın, endişelenmeyin.
Başka bir durum, aksine, çok sayıda çizginin olduğu ve içlerinde çok sayıda benzersiz çizginin olduğu ve hatta setin potansiyel olarak sınırsız olduğu durumdur. Tipik bir örnek, arama ifadeleri veya URL'lerdir. Yazım hataları da dahil olmak üzere arama ifadeleri. Günde kaç tane benzersiz arama ifadesinin bulunduğunu görelim. Ve bunların neredeyse tüm olayların yarısı olduğu ortaya çıktı. Ve bu durumda verileri normalleştirmeniz, tanımlayıcıları saymanız ve ayrı bir tabloya koymanız gerektiğini düşünebilirsiniz. Ama bunu yapmanıza gerek yok. Bu satırları olduğu gibi koruyun.
Hiçbir şey icat etmemek daha iyidir, çünkü ayrı olarak saklarsanız birleştirme yapmanız gerekir. Ve bu birleştirme, eğer hala belleğe uyuyorsa, en iyi ihtimalle belleğe rastgele bir erişimdir. Eğer uymuyorsa sorunlar yaşanacaktır.
Ve veriler yerinde saklanıyorsa, dosya sisteminden gerekli sırayla okunur ve her şey yolundadır.
URL'leriniz veya başka bir karmaşık uzun dizeniz varsa, o zaman bir tür özü önceden hesaplayabileceğinizi ve bunu ayrı bir sütuna yazabileceğinizi düşünmeye değer.
Örneğin URL'ler için alanı ayrı olarak depolayabilirsiniz. Ve gerçekten bir alan adına ihtiyacınız varsa, o zaman bu sütunu kullanın; URL'ler orada kalır ve onlara dokunmazsınız bile.
Bakalım fark ne? ClickHouse, etki alanını hesaplayan özel bir işleve sahiptir. Çok hızlı, optimize ettik. Ve dürüst olmak gerekirse, RFC'ye bile uymuyor, ancak yine de ihtiyacımız olan her şeyi düşünüyor.
Ve bir durumda, URL'leri alıp etki alanını hesaplayacağız. Bu 166 milisaniyeye denk geliyor. Ve eğer hazır bir alan adı alırsanız, o zaman sadece 67 milisaniye olduğu ortaya çıkıyor, yani. neredeyse üç kat daha hızlı. Ve bazı hesaplamalar yapmamız gerektiği için değil, daha az veri okuduğumuz için daha hızlıdır.
Bu nedenle daha yavaş olan bir isteğin saniyede gigabayt hızı daha yüksektir. Çünkü daha fazla gigabayt okuyor. Bu tamamen gereksiz bir veridir. İstek daha hızlı çalışıyor gibi görünüyor ancak tamamlanması daha uzun sürüyor.
Diskteki veri miktarına bakarsanız, URL'nin 126 megabayt ve etki alanının yalnızca 5 megabayt olduğu ortaya çıkıyor. 25 kat daha az çıkıyor. Ancak yine de istek yalnızca 4 kat daha hızlı gerçekleştirilir. Ancak bunun nedeni verilerin sıcak olmasıdır. Ve soğuk olsaydı, disk G/Ç'si nedeniyle muhtemelen 25 kat daha hızlı olurdu.
Bu arada, bir alan adının bir URL'den ne kadar küçük olduğunu tahmin ederseniz, yaklaşık 4 kat daha küçük olduğu ortaya çıkıyor, ancak bazı nedenlerden dolayı veriler diskte 25 kat daha az yer kaplıyor. Neden? Sıkıştırma nedeniyle. URL sıkıştırılır ve etki alanı sıkıştırılır. Ancak çoğu zaman URL bir sürü çöp içerir.
Ve tabii ki istenilen değerler için özel olarak tasarlanmış veya uygun olan doğru veri türlerini kullanmanın da faydası var. IPv4'teyseniz UInt32*'yi saklayın. IPv6 ise, FixString(16) olur çünkü IPv6 adresi 128 bittir, yani doğrudan ikili biçimde saklanır.
Peki ya bazen IPv4 adresleriniz, bazen de IPv6'nız varsa? Evet ikisini de saklayabilirsiniz. IPv4 için bir sütun, IPv6 için başka bir sütun. Elbette IPv4'da IPv6'ü görüntüleme seçeneği var. Bu da işe yarayacaktır, ancak isteklerde sıklıkla bir IPv4 adresine ihtiyacınız varsa, bunu ayrı bir sütuna koymak güzel olur.
* ClickHouse artık verileri sayılar kadar verimli bir şekilde depolayan, ancak bunları dizeler kadar rahat bir şekilde temsil eden ayrı IPv4, IPv6 veri türlerine sahiptir.
Verileri önceden işlemeye değer olduğunu unutmamak da önemlidir. Örneğin, bazı ham günlükler alıyorsunuz. Ve belki de onları hemen ClickHouse'a koymamalısınız, ancak hiçbir şey yapmamak çok cazip geliyor ve her şey işe yarayacak. Ancak yine de mümkün olan hesaplamaları yapmaya değer.
Örneğin, tarayıcı sürümü. Parmağımla işaret etmek istemediğim yakındaki bazı departmanlarda tarayıcı sürümü şu şekilde, yani bir dize olarak depolanıyor: 12.3. Daha sonra bir rapor oluşturmak için bu diziyi alıp bir diziye ve ardından dizinin ilk elemanına bölerler. Doğal olarak her şey yavaşlıyor. Bunu neden yaptıklarını sordum. Erken optimizasyondan hoşlanmadıklarını söylediler. Ve erken kötümserlikten hoşlanmam.
Yani bu durumda 4 sütuna bölmek daha doğru olacaktır. Burada korkmayın çünkü burası ClickHouse. ClickHouse sütunlu bir veritabanıdır. Ve küçük sütunlar ne kadar düzgün olursa o kadar iyidir. 5 Tarayıcı Sürümü olacak, 5 sütun oluşturulacak. Bu iyi.
Şimdi çok uzun dizeleriniz, çok uzun dizileriniz varsa ne yapacağınıza bakalım. ClickHouse'da saklanmalarına hiç gerek yok. Bunun yerine, yalnızca bir tanımlayıcıyı ClickHouse'da saklayabilirsiniz. Ve bu uzun hatları başka bir sisteme yerleştirin.
Örneğin, analiz hizmetlerimizden birinin bazı etkinlik parametreleri vardır. Ve olaylar için çok fazla parametre varsa, karşımıza çıkan ilk 512'yi kaydederiz çünkü 512 yazık değildir.
Veri türlerinize karar veremiyorsanız, verileri ClickHouse'a da kaydedebilirsiniz, ancak geçici verilere özel olan Günlük türünün geçici bir tablosuna da kaydedebilirsiniz. Bundan sonra orada hangi değer dağılımına sahip olduğunuzu, genel olarak orada ne olduğunu analiz edebilir ve doğru türleri oluşturabilirsiniz.
*ClickHouse artık bir veri türüne sahip bu da dizeleri daha az çabayla verimli bir şekilde saklamanıza olanak tanır.
Şimdi başka bir ilginç duruma bakalım. Bazen insanlar için işler garip yürür. İçeri girip şunu görüyorum. Ve bunun, MySQL 3.23 sürümünün kurulumunda geniş deneyime sahip, çok deneyimli, akıllı bir yönetici tarafından yapıldığı hemen anlaşılıyor.
Burada bin tane tablo görüyoruz, bunların her biri kim bilir kaça bölünerek geri kalan kısmı kaydediyor.
Prensip olarak, bu deneyim yoluyla kazanılabilecek acıların anlaşılması da dahil olmak üzere diğer insanların deneyimlerine saygı duyuyorum.
Ve nedenleri az çok açık. Bunlar, diğer sistemlerle çalışırken birikmiş olabilecek eski stereotiplerdir. Örneğin MyISAM tablolarının kümelenmiş bir birincil anahtarı yoktur. Ve verileri bu şekilde bölmek, aynı işlevselliği elde etmek için umutsuz bir girişim olabilir.
Bir diğer sebep ise büyük masalarda değişiklik işleminin yapılmasının zor olmasıdır. Her şey engellenecek. MySQL'in modern sürümlerinde bu sorun artık o kadar ciddi olmasa da.
Veya örneğin mikro parçalama, ancak bunun hakkında daha sonra daha fazla bilgi vereceğiz.
ClickHouse'da bunu yapmanıza gerek yoktur çünkü öncelikle birincil anahtar kümelenir, veriler birincil anahtara göre sıralanır.
Bazen insanlar bana şunu soruyor: "ClickHouse'daki aralık sorgularının performansı tablo boyutuna bağlı olarak nasıl değişiyor?" Hiç değişmiyor diyorum. Örneğin, bir milyar satırlık bir tablonuz var ve bir milyon satırlık bir aralığı okuyorsunuz. Herşey yolunda. Bir tabloda trilyonlarca satır varsa ve bir milyon satırı okursanız hemen hemen aynı olacaktır.
İkincisi, manuel bölümleme gibi her türlü şeye gerek yoktur. Eğer içeri girip dosya sisteminde ne olduğuna bakarsanız, tablonun oldukça önemli olduğunu göreceksiniz. Ve içeride bölmelere benzer bir şey var. Yani ClickHouse sizin için her şeyi yapar ve sizin acı çekmenize gerek kalmaz.
Ekle/bırak sütununu değiştirirseniz ClickHouse'daki değişiklik ücretsizdir.
Ve küçük tablolar yapmamalısınız çünkü bir tabloda 10 satırınız veya 10 satırınız varsa o zaman bunun hiç önemi yoktur. ClickHouse, gecikmeyi değil verimi optimize eden bir sistemdir, bu nedenle 000 satırı işlemenin bir anlamı yoktur.
Büyük bir masa kullanmak doğrudur. Eski stereotiplerden kurtulun, her şey yoluna girecek.
Ve bir bonus olarak, en son sürümde artık bireysel bölümler üzerinde her türlü bakım işlemini gerçekleştirmek için isteğe bağlı bir bölümleme anahtarı oluşturma yeteneğine sahibiz.
Örneğin çok sayıda küçük tabloya ihtiyacınız var, örneğin bazı ara verileri işlemeniz gerektiğinde, yığınlar alırsınız ve final tablosuna yazmadan önce bunlar üzerinde bir dönüşüm gerçekleştirmeniz gerekir. Bu durum için harika bir masa motoru var - StripeLog. Bir nevi TinyLog'a benziyor, sadece daha iyi.
* artık ClickHouse'da da var .
Başka bir antipattern mikro parçalamadır. Örneğin, verileri parçalamanız gerekiyor ve 5 sunucunuz var ve yarın 6 sunucunuz olacak. Ve bu verileri nasıl yeniden dengeleyeceğinizi düşünüyorsunuz. Ve bunun yerine 5 parçaya değil 1 parçaya bölünürsünüz. Daha sonra bu mikro parçaların her birini ayrı bir sunucuya eşlersiniz. Ve örneğin bir sunucuda 000 ClickHouse'a sahip olacaksınız. Ayrı bağlantı noktalarında veya ayrı veritabanlarında ayrı örnekler.
Ancak bu ClickHouse'da pek iyi değil. Çünkü bir ClickHouse örneği bile bir isteği işlemek için mevcut tüm sunucu kaynaklarını kullanmaya çalışır. Yani bir tür sunucunuz var ve örneğin 56 işlemci çekirdeği var. Bir saniye süren bir sorgu çalıştırıyorsunuz ve 56 çekirdek kullanacak. Ve eğer oraya bir sunucuya 200 ClickHouse yerleştirdiyseniz, 10 iş parçacığının başlayacağı ortaya çıkıyor. Genel olarak her şey çok kötü olacak.
Diğer bir neden ise bu örnekler arasında iş dağılımının eşit olmamasıdır. Bazıları daha erken bitirecek, bazıları daha geç bitirecek. Bütün bunlar tek bir durumda olsaydı, ClickHouse verilerin iş parçacıkları arasında nasıl doğru bir şekilde dağıtılacağını kendisi çözerdi.
Diğer bir neden ise TCP üzerinden işlemciler arası iletişim kuracak olmanızdır. Verilerin serileştirilmesi, seri durumdan çıkarılması gerekecek ve bu çok sayıda mikro parça anlamına geliyor. Etkili bir şekilde çalışmayacaktır.
Başka bir anti-örüntü, buna anti-örüntü denmesi pek mümkün olmasa da. Bu büyük miktarda bir ön toplamadır.
Genel olarak ön toplama iyidir. Bir milyar satırınız vardı, bunları topladınız ve 1 satır oldu ve artık sorgu anında yürütülüyor. Her şey harika. Bunu yapabilirsiniz. Ve bunun için ClickHouse'un bile veri eklendikçe artımlı toplama gerçekleştiren özel bir tablo türü olan AggregatingMergeTree vardır.
Ancak bazen bunun gibi verileri bir araya getireceğimizi ve bunun gibi verileri bir araya getireceğimizi düşündüğünüz zamanlar vardır. Ve bazı komşu departmanlarda hangisi olduğunu söylemek istemiyorum, birincil anahtara göre özetlemek için SummingMergeTree tablolarını kullanıyorlar ve birincil anahtar olarak yaklaşık 20 sütun kullanılıyor. Her ihtimale karşı, gizlilik adına bazı sütunların adlarını değiştirdim, ama hemen hemen bu kadar.
Ve bu tür sorunlar ortaya çıkıyor. Öncelikle veri hacminiz çok fazla azalmaz. Mesela üç kat azalır. Verilerinizin bir araya getirilmemesi durumunda ortaya çıkan sınırsız analiz yeteneklerinin karşılanması için bunun üç katı iyi bir fiyat olacaktır. Veriler toplanırsa, analiz yerine yalnızca acınası istatistikler elde edersiniz.
Peki bunda bu kadar özel olan ne? Gerçek şu ki, komşu departmandaki bu insanlar bazen gidip birincil anahtara bir sütun daha eklemek istiyorlar. Yani verileri bu şekilde topladık ama şimdi biraz daha fazlasını istiyoruz. Ancak ClickHouse'un alternatif bir birincil anahtarı yoktur. Bu nedenle C++ ile bazı scriptler yazmamız gerekiyor. Ve C++ dilinde olsalar bile komut dosyalarını sevmiyorum.
ClickHouse'un ne için oluşturulduğuna bakarsanız, birleştirilmemiş verilerin tam olarak doğduğu senaryo olduğunu görürsünüz. Toplanmamış veriler için ClickHouse kullanıyorsanız doğru yapıyorsunuz demektir. Eğer toplarsanız, bu bazen affedilebilir.
Bir başka ilginç durum ise sonsuz döngüdeki sorgulardır. Bazen bir üretim sunucusuna gidiyorum ve oradaki gösteri süreç listesine bakıyorum. Ve ne zaman korkunç bir şeyin olduğunu fark etsem.
Mesela bunun gibi. Her şeyin tek bir istekle yapılabileceği hemen anlaşılıyor. URL'yi ve listeyi oraya yazmanız yeterli.
Sonsuz bir döngüdeki bu tür sorguların çoğu neden kötü? Bir indeks kullanılmazsa, aynı veriler üzerinden birçok geçişiniz olacaktır. Ancak indeks kullanılıyorsa, örneğin, ru için bir birincil anahtarınız vardır ve oraya url = bir şey yazarsınız. Ve tablodan tek bir URL okunursa her şeyin yoluna gireceğini düşünüyorsunuz. Ama aslında hayır. Çünkü ClickHouse her şeyi gruplar halinde yapıyor.
Belirli bir veri aralığını okuması gerektiğinde biraz daha fazla okur çünkü ClickHouse'daki dizin seyrektir. Bu indeks tabloda tek bir satırı bulmanızı sağlamaz, yalnızca bir tür aralığı bulmanızı sağlar. Ve veriler bloklar halinde sıkıştırılır. Bir satırı okuyabilmek için tüm bloğu alıp açmanız gerekir. Ve eğer çok sayıda sorgu yapıyorsanız, çok fazla örtüşme olur ve tekrar tekrar yapacak çok işiniz olur.
Ve bir bonus olarak, ClickHouse'da megabaytları ve hatta yüzlerce megabaytı IN bölümüne aktarmaktan korkmamanız gerektiğini unutmayın. Uygulamamızdan hatırlıyorum ki, MySQL'de IN bölümüne bir grup değer aktarırsak, örneğin oraya 100 megabaytlık bazı sayılar aktarırsak, o zaman MySQL 10 gigabaytlık belleği tüketir ve ona başka hiçbir şey olmaz, her şey kötü çalışıyor.
İkincisi ise ClickHouse'da, eğer sorgularınız bir indeks kullanıyorsa, bu her zaman tam taramadan daha yavaş değildir, yani tablonun neredeyse tamamını okumanız gerekiyorsa, sırayla gidecek ve tablonun tamamını okuyacaktır. Genel olarak bunu kendi başına çözecektir.
Ancak yine de bazı zorluklar var. Örneğin, bir alt sorguya sahip IN'in dizini kullanmaması. Ama bu bizim sorunumuz ve bunu çözmemiz gerekiyor. Burada temel bir şey yok. Düzelteceğiz*.
Ve başka ilginç bir şey de, eğer çok uzun bir isteğiniz varsa ve dağıtılmış istek işleme devam ediyorsa, bu çok uzun istek her sunucuya sıkıştırılmadan gönderilecektir. Örneğin 100 megabayt ve 500 sunucu. Ve buna göre ağ üzerinden aktarılan 50 gigabayta sahip olacaksınız. İletilecek ve ardından her şey başarıyla tamamlanacak.
* zaten kullanıyorum; Her şey söz verildiği gibi düzeltildi.
Oldukça yaygın bir durum da isteklerin API'den gelmesidir. Örneğin, bir tür kendi hizmetinizi yarattınız. Birisinin hizmetinize ihtiyacı varsa, API'yi açarsınız ve kelimenin tam anlamıyla iki gün sonra anlaşılmaz bir şeyin olduğunu görürsünüz. Her şey aşırı yüklenmiş durumda ve asla gerçekleşmemesi gereken bazı korkunç istekler geliyor.
Ve tek bir çözüm var. API'yi açtıysanız kesmeniz gerekecektir. Örneğin, bir tür kota uygulayın. Başka normal seçenek yok. Aksi taktirde hemen senaryo yazacaklar ve sorunlar çıkacak.
Ve ClickHouse'un özel bir özelliği var - kota hesaplaması. Üstelik kota anahtarınızı da aktarabilirsiniz. Bu, örneğin dahili kullanıcı kimliğidir. Ve kotalar her biri için bağımsız olarak hesaplanacak.
Şimdi başka ilginç bir şey daha. Bu manuel çoğaltmadır.
ClickHouse'un yerleşik çoğaltma desteğine sahip olmasına rağmen insanların ClickHouse'u manuel olarak kopyaladığı birçok durum biliyorum.
Prensip nedir? Bir veri işleme hattınız var. Ve örneğin farklı veri merkezlerinde bağımsız olarak çalışır. ClickHouse'da aynı verileri aynı şekilde yazarsınız. Doğru, uygulama, kodunuzdaki bazı özellikler nedeniyle verilerin hala farklı olacağını gösteriyor. Umarım senin elindedir.
Ve zaman zaman yine de manuel olarak senkronizasyon yapmanız gerekecek. Örneğin, yöneticiler ayda bir kez rsync yapar.
Aslında ClickHouse'un yerleşik çoğaltmasını kullanmak çok daha kolaydır. Ancak bazı kontrendikasyonlar olabilir çünkü bunun için ZooKeeper'ı kullanmanız gerekir. ZooKeeper hakkında kötü bir şey söylemeyeceğim, prensipte sistem çalışıyor, ancak insanlar onu java fobisi nedeniyle kullanmıyorlar çünkü ClickHouse C++ ile yazılmış, kullanabileceğiniz çok iyi bir sistem. her şey yoluna girecek. Ve ZooKeeper Java'da. Ve bir şekilde bakmak bile istemiyorsunuz ama sonra manuel çoğaltmayı kullanabilirsiniz.
ClickHouse pratik bir sistemdir. İhtiyaçlarınızı dikkate alıyor. El ile çoğaltmanız varsa, el ile çoğaltmalarınıza bakan ve bunlar arasında yük devretme gerçekleştiren bir Dağıtılmış tablo oluşturabilirsiniz. Hatta hatlarınız sistematik olarak farklılaşsa bile floplardan kaçınmanıza olanak tanıyan özel bir seçenek bile var.
İlkel tablo motorları kullanırsanız daha fazla sorun ortaya çıkabilir. ClickHouse, birçok farklı tablo motoruna sahip bir kurucudur. Tüm ciddi durumlar için, belgelerde yazıldığı gibi MergeTree ailesindeki tabloları kullanın. Ve geri kalan her şey bireysel durumlar veya testler için böyledir.
MergeTree tablosunda herhangi bir tarih ve saate sahip olmanıza gerek yoktur. Hala kullanabilirsin. Tarih ve saat yoksa varsayılanın 2000 olduğunu yazın. Bu işe yarayacak ve kaynak gerektirmeyecek.
Ve sunucunun yeni sürümünde, bölümleme anahtarı olmadan özel bölümlemeye sahip olduğunuzu bile belirtebilirsiniz. Aynı olacak.
Öte yandan ilkel masa motorlarını da kullanabilirsiniz. Örneğin verileri bir kez doldurun ve bakın, çevirin ve silin. Günlüğü kullanabilirsiniz.
Veya küçük hacimleri ara işlemler için depolamak StripeLog veya TinyLog'dur.
Veri miktarı azsa bellek kullanılabilir ve RAM'deki bir şeyi basitçe çevirebilirsiniz.
ClickHouse yeniden normalleştirilmiş verilerden pek hoşlanmaz.
İşte tipik bir örnek. Bu çok sayıda URL'dir. Onları bir sonraki tabloya koy. Ve sonra onlarla JOIN yapmaya karar verdiler, ancak kural olarak bu işe yaramayacak çünkü ClickHouse yalnızca Hash JOIN'i destekliyor. Bağlanması gereken çok sayıda veri için yeterli RAM yoksa JOIN çalışmaz*.
Veriler yüksek kardinaliteye sahipse endişelenmeyin, normal olmayan bir biçimde saklayın; URL'ler doğrudan ana tabloda yer alır.
* ve artık ClickHouse'un bir birleştirme birleşimi de var ve ara verilerin RAM'e sığmadığı durumlarda çalışıyor. Ancak bu etkisizdir ve öneri yürürlükte kalmaya devam etmektedir.
Birkaç örnek daha var ama bunların anti-desen olup olmadığından zaten şüpheliyim.
ClickHouse'un bilinen bir kusuru var. Nasıl güncelleneceğini bilmiyor*. Hatta bazı açılardan bu iyi bir şey. Muhasebe gibi bazı önemli verileriniz varsa, güncelleme olmadığı için kimse bunları gönderemez.
* Toplu modda güncelleme ve silme desteği uzun zaman önce eklendi.
Ancak güncellemelerin arka plandaymış gibi yapılmasına izin veren bazı özel yollar vardır. Örneğin, ChangeMergeTree gibi tablolar. Arka plan birleştirmeleri sırasında güncellemeler yaparlar. Optimize tablosunu kullanarak bunu zorlayabilirsiniz. Ancak bunu çok sık yapmayın çünkü bu, bölümün tamamen üzerine yazılmasına neden olur.
ClickHouse'daki dağıtılmış JOIN'ler de sorgu planlayıcı tarafından kötü bir şekilde işleniyor.
Kötü ama bazen Tamam.
ClickHouse'u yalnızca select* kullanarak verileri geri okumak için kullanma.
Zahmetli hesaplamalar için ClickHouse'u kullanmanızı tavsiye etmem. Ancak bu tamamen doğru değil çünkü biz zaten bu öneriden uzaklaşıyoruz. Yakın zamanda ClickHouse - Catboost'a makine öğrenimi modellerini uygulama yeteneğini ekledik. Ve bu beni rahatsız ediyor çünkü şöyle düşünüyorum: “Ne dehşet. Bayt başına kaç döngü ortaya çıkıyor! Baytlarla saatleri boşa harcamaktan gerçekten nefret ediyorum.
Ama korkmayın, ClickHouse'u kurun, her şey yoluna girecek. Ne olursa olsun bizim bir topluluğumuz var. Bu arada, topluluk sensin. Herhangi bir sorun yaşarsanız en azından sohbetimize gidebilirsiniz, umarım size yardımcı olurlar.
sorular
Rapor için teşekkürler! ClickHouse'un çökmesi hakkında nereye şikayette bulunabilirim?
Şu anda kişisel olarak bana şikayette bulunabilirsiniz.
Yakın zamanda ClickHouse'u kullanmaya başladım. Hemen cli arayüzünü bıraktım.
Şanslısın
Biraz sonra sunucuyu küçük bir seçimle çökerttim.
Yeteneğin var.
GitHub hatasını açtım ancak göz ardı edildi.
Göreceğiz
Alexey beni rapora katılmam için kandırdı ve içerideki verilere nasıl erişeceğinizi bana söyleyeceğine söz verdi.
Çok basit.
Bunu dün farkettim. Daha fazla ayrıntı.
Orada korkunç numaralar yok. Sadece blok blok sıkıştırma var. Varsayılan LZ4'tür; ZSTD*'yi etkinleştirebilirsiniz. 64 kilobayttan 1 megabayta kadar bloklar.
* ayrıca diğer algoritmalarla zincir halinde kullanılabilecek özel sıkıştırma kodekleri için de destek vardır.
Bloklar sadece ham veriler mi?
Tamamen çiğ değil. Diziler var. Sayısal bir sütununuz varsa, sıradaki sayılar bir diziye yerleştirilir.
Temizleyin.
Alexey, IP'ler üzerinden uniqExact ile ilgili bir örnek, yani uniqExact'in hesaplamasının sayılardan ziyade satırlarla daha uzun sürmesi vb. Düzeltme sırasında kulaklarımızla bir yanılsama kullanıp alçı yaparsak ne olur? Yani, bizim diskimizde de durumun pek farklı olmadığını söylemişsiniz. Diskten ve yayından satırları okursak, toplamalarımız daha hızlı olur mu olmaz mı? Yoksa yine de burada biraz kazançlı çıkacak mıyız? Bana öyle geliyor ki bunu test ettiniz, ancak bir nedenden dolayı bunu kıyaslamada belirtmediniz.
Döküm yapmadan daha yavaş olacağını düşünüyorum. Bu durumda IP adresinin dizeden ayrıştırılması gerekir. Tabii ki ClickHouse'da IP adresi ayrıştırmamız da optimize edilmiştir. Çok uğraştık ama karşınızda onbininci formda yazılmış rakamlar var. Çok rahatsız. Öte yandan, uniqExact işlevi dizeler üzerinde daha yavaş çalışacaktır; bunun nedeni yalnızca bunların dize olması değil, aynı zamanda algoritmanın farklı bir uzmanlığının seçilmesidir. Dizeler basitçe farklı şekilde işlenir.
Daha ilkel bir veri türünü alırsak ne olur? Mesela elimizdeki kullanıcı kimliğini yazıp satır olarak yazdık ve sonra karıştırdık, daha eğlenceli olur mu olmaz mı?
Ben şüpheliyim. Daha da üzücü olacağını düşünüyorum çünkü sonuçta sayıları ayrıştırmak ciddi bir sorun. Bana öyle geliyor ki bu meslektaşım on bininci formdaki sayıları ayrıştırmanın ne kadar zor olduğuna dair bir rapor bile verdi, ama belki de değil.
Alexey, rapor için çok teşekkür ederim! Ve ClickHouse için çok teşekkür ederim! Planlarla ilgili bir sorum var. Sözlükleri eksik güncellemeye yönelik bir özellik için herhangi bir planınız var mı?
Yani kısmi bir yeniden başlatma mı?
Evet evet. Orada bir MySQL alanı ayarlama yeteneği gibi, yani daha sonra güncelleme yapın, böylece sözlük çok büyükse yalnızca bu veriler yüklenir.
Çok ilginç bir özellik. Ve sanırım sohbetimizde birisi bunu önerdi. Belki o sensin bile.
Öyle düşünmüyorum.
Harika, şimdi iki isteğin olduğu ortaya çıktı. Ve yavaş yavaş bunu yapmaya başlayabilirsiniz. Ancak bu özelliğin uygulanmasının oldukça basit olduğu konusunda sizi hemen uyarmak istiyorum. Yani, teorik olarak, tabloya sürüm numarasını yazmanız ve ardından şunu yazmanız yeterlidir: version less than falan. Bu da büyük ihtimalle bunu meraklılara sunacağımız anlamına geliyor. Bir meraklı mısınız?
Evet ama ne yazık ki C++'da değil.
Meslektaşlarınız C++'da nasıl yazılacağını biliyor mu?
Birini bulacağım.
Harika*.
* özellik rapordan iki ay sonra eklendi - sorunun yazarı onu geliştirdi ve .
Teşekkürler!
Merhaba! Rapor için teşekkürler! ClickHouse'un mevcut tüm kaynakları tüketme konusunda çok iyi olduğundan bahsettiniz. Luxoft'un yanındaki konuşmacı da Russian Post için sunduğu çözümden bahsetti. ClickHouse'u gerçekten sevdiklerini ancak tüm CPU'yu tükettiği için onu ana rakiplerinin yerine kullanmadıklarını söyledi. Ve bunu kendi mimarilerine, liman işçileri ile ZooKeeper'larına bağlayamadılar. ClickHouse'u, kendisine sunulan her şeyi tüketmeyecek şekilde bir şekilde sınırlamak mümkün müdür?
Evet mümkün ve çok kolay. Daha az çekirdek tüketmek istiyorsanız yazmanız yeterli set max_threads = 1. İşte bu kadar, isteği tek çekirdekte yürütecek. Üstelik farklı kullanıcılar için farklı ayarlar belirleyebilirsiniz. Öyleyse mesele yok. Ve Luxoft'taki meslektaşlarınıza bu ayarı belgelerde bulamamalarının iyi olmadığını söyleyin.
Alexey, merhaba! Bu soruyla ilgili şunu sormak istiyorum. Bu, birçok kişinin ClickHouse'u günlükler için depolama alanı olarak kullanmaya başladığını ilk kez duymuyorum. Raporda bunu yapmamanızı, yani uzun dizeleri saklamanıza gerek olmadığını söylemiştiniz. Bu konu hakkında ne düşünüyorsun?
İlk olarak, günlükler kural olarak uzun dizeler değildir. Elbette bazı istisnalar var. Örneğin, Java ile yazılmış bazı servisler bir istisna atar ve günlüğe kaydedilir. Ve bu sonsuz bir döngü halinde devam eder ve sabit sürücüdeki alan tükenir. Çözüm çok basit. Çizgiler çok uzunsa kesin. Uzun ne anlama geliyor? Onlarca kilobayt kötüdür*.
* ClickHouse'un en son sürümlerinde, uzun satırların depolanması sorununu büyük ölçüde ortadan kaldıran "uyarlanabilir dizin ayrıntı düzeyi" etkinleştirilmiştir.
Bir kilobayt normal mi?
Normalde.
Merhaba! Rapor için teşekkürler! Bunu zaten sohbette sordum, ancak bir yanıt alıp almadığımı hatırlamıyorum. İLE bölümünü bir şekilde CTE tarzında genişletme planlarınız var mı?
Henüz değil. İLE bölümümüz biraz anlamsız. Bizim için küçük bir özellik gibi.
Anladım. Teşekkür ederim!
Rapor için teşekkürler! Çok ilginç! Küresel soru. Veri silme işlemini bir tür taslak şeklinde değiştirmeye yönelik herhangi bir planınız var mı?
Mutlaka. Bu sıramızdaki ilk görevimiz. Artık her şeyi nasıl doğru yapacağımızı aktif olarak düşünüyoruz. Ve klavyeye basmaya başlamalısınız*.
* Klavyedeki tuşlara bastım ve her şeyi yaptım.
Bu bir şekilde sistem performansını etkileyecek mi, etkilemeyecek mi? Ekleme şimdiki kadar hızlı olacak mı?
Belki silme işlemlerinin kendisi ve güncellemelerin kendileri çok ağır olacaktır, ancak bu, seçimlerin performansını veya eklemelerin performansını etkilemeyecektir.
Ve bir küçük soru daha. Sunumda birincil anahtardan bahsettiniz. Buna göre varsayılan olarak aylık olan bölümlememiz var, değil mi? Ve bir aya sığacak şekilde bir tarih aralığı belirlediğimizde sadece bu bölüm okunuyor değil mi?
Evet.
Bir soru. Herhangi bir birincil anahtar seçemiyorsak, arka planda bu verilerin daha az yeniden düzenlenmesi ve daha düzenli bir şekilde sığması için bunu “Tarih” alanına göre özel olarak yapmak doğru mudur? Aralık sorgularınız yoksa ve herhangi bir birincil anahtar bile seçemiyorsanız, birincil anahtara tarih koymaya değer mi?
Evet.
Belki birincil anahtara, bu alana göre sıralanırsa verileri daha iyi sıkıştıracak bir alan koymak mantıklı olabilir. Örneğin kullanıcı kimliği. Örneğin kullanıcı aynı siteye gider. Bu durumda kullanıcı kimliğini ve saatini girin. Ve sonra verileriniz daha iyi sıkıştırılacaktır. Tarihe gelince, tarihlerle ilgili gerçekten aralık sorgularınız yoksa ve hiç sormadıysanız, tarihi birincil anahtara koymanız gerekmez.
Tamam çok teşekkür ederim!
Kaynak: habr.com