Nisan ayında Avito mühendisleri, ClickHouse'un ana geliştiricisi Alexey Milovidov ve Integros'tan Golang geliştiricisi Kirill Shvakov ile çevrimiçi toplantılar için bir araya geldi. Veritabanı yönetim sistemini nasıl kullandığımızı ve ne gibi zorluklarla karşılaştığımızı tartıştık.
Toplantıya dayanarak, yedeklemeler, veri yeniden paylaşım, harici sözlükler, Golang sürücüsü ve ClickHouse sürümlerinin güncellenmesiyle ilgili bizim ve izleyicilerimizin sorularına uzmanların yanıtlarını içeren bir makale derledik. Zaten Yandex DBMS ile aktif olarak çalışan ve onun bugünü ve geleceği ile ilgilenen geliştiriciler için faydalı olabilir. Aksi yazılmadığı sürece varsayılan olarak cevaplar Alexey Milovidov'a aittir.
Dikkatli olun, kesimin altında çok fazla metin var. Soru içeren içeriğin gezinmenize yardımcı olacağını umuyoruz.
Içerik
Metni okumak istemiyorsanız toplantıların kayıtlarını izleyebilirsiniz. . Zaman kodları videonun altındaki ilk yorumdadır.
ClickHouse sürekli olarak güncellenmektedir ancak verilerimiz güncellenmemektedir. Bu konuda ne yapmalı?
ClickHouse sürekli güncellenmekte olup, optimize edilerek son işleme tabi tutulan verilerimiz güncellenmemekte ve yedek kopya halinde bulunmaktadır.
Diyelim ki bir sorun yaşadık ve veriler kayboldu. Geri yüklemeye karar verdik ve yedekleme sunucularında depolanan eski bölümlerin ClickHouse'un şu anda kullanılan sürümünden çok farklı olduğu ortaya çıktı. Böyle bir durumda ne yapmalı ve bu mümkün mü?
Verileri eski formattaki bir yedekten geri yüklediğiniz ancak yeni sürüme bağlanmadığı bir durum imkansızdır. ClickHouse'daki veri formatının her zaman geriye dönük uyumlu kalmasını sağlıyoruz. Nadiren kullanılan bazı işlevlerin davranışı değiştiyse, bu işlevsellik açısından geriye dönük uyumluluktan çok daha önemlidir. ClickHouse'un yeni sürümü her zaman diskte depolanan verileri okuyabilmelidir. Kanun budur.
ClickHouse'dan veri yedeklemeye yönelik mevcut en iyi uygulamalar nelerdir?
Nihai işlemleri optimize ettiğimizi, terabaytlık devasa bir veritabanını ve örneğin son üç gün boyunca güncellenen verileri ve ardından hiçbir prosedür gerçekleşmediğini hesaba katarak yedekleme nasıl yapılır?
Kendi çözümümüzü yapıp bash'a yazabiliriz: Bu yedek kopyaları şu şekilde toplayabiliriz. Belki koltuk değneğine gerek yoktur ve bisiklet uzun zaman önce icat edilmiştir?
En iyi uygulamalarla başlayalım. Yedeklemelerle ilgili sorulara yanıt olarak meslektaşlarım her zaman onlara bu sorunun zaten çözülmüş olduğu Yandex.Cloud hizmetini hatırlatmalarını tavsiye ediyor. Bu yüzden mümkünse kullanın.
Yedeklemeler için yüzde yüz ClickHouse'a yerleşik eksiksiz bir çözüm yoktur. Kullanılabilecek bazı boşluklar var. Eksiksiz bir çözüm elde etmek için, ya elle biraz uğraşmanız ya da komut dosyaları biçiminde sarmalayıcılar oluşturmanız gerekecektir.
Veri hacmine ve kümenin boyutuna bağlı olarak en basit çözümlerle başlayacağım ve en karmaşık çözümlerle bitireceğim. Küme büyüdükçe çözüm daha karmaşık hale gelir.
Veri içeren tablo yalnızca birkaç gigabayt yer kaplıyorsa yedekleme şu şekilde yapılabilir:
- Tablo tanımını, yani meta verileri kaydedin – tablo oluştur göster.
- ClickHouse istemcisini kullanarak bir döküm yapın - seçmek * masadan dosyalamak. Varsayılan olarak TabSeparated formatında bir dosya alacaksınız. Daha verimli olmak istiyorsanız bunu Native formatta yapabilirsiniz.
Veri miktarı daha büyükse, yedekleme daha fazla zaman alacak ve daha fazla yer kaplayacaktır. Buna mantıksal yedekleme denir; ClickHouse veri formatına bağlı değildir. Öyleyse, son çare olarak yedeklemeyi alıp kurtarma için MySQL'e yükleyebilirsiniz.
Daha gelişmiş durumlar için ClickHouse, yerel dosya sistemindeki bölümlerin anlık görüntüsünü oluşturma konusunda yerleşik bir yeteneğe sahiptir. Bu özellik istek üzerine mevcuttur tablo dondurma bölümünü değiştir. Ya da sadece tablo dondurmayı değiştir - bu tüm tablonun anlık görüntüsü.
Anlık görüntü, tek bir parçadaki bir tablo için tutarlı bir şekilde oluşturulacaktır, yani bu şekilde tüm kümenin tutarlı bir anlık görüntüsünü oluşturmak imkansızdır. Ancak çoğu görev için böyle bir ihtiyaç yoktur ve her bir parça için bir istek yürütmek ve tutarlı bir anlık görüntü elde etmek yeterlidir. Sabit bağlantılar biçiminde oluşturulur ve bu nedenle ek yer kaplamaz. Daha sonra bu anlık görüntüyü yedekleme sunucusuna veya yedekleme için kullandığınız depolama alanına kopyalarsınız.
Böyle bir yedeği geri yüklemek oldukça kolaydır. Öncelikle mevcut tablo tanımlarını kullanarak tablolar oluşturun. Daha sonra, bu tablolar için bölümlerin kayıtlı anlık görüntülerini Directory-Detached'a kopyalayın ve sorguyu çalıştırın. bölüm ekle. Bu çözüm, en ciddi veri hacimleri için oldukça uygundur.
Bazen daha da havalı bir şeye ihtiyaç duyarsınız; her sunucuda ve yüzlerce sunucuda onlarca, hatta yüzlerce terabaytın olduğu durumlarda. Burada Yandex.Metrica'daki meslektaşlarımdan aldığım bir çözüm var. Herkese tavsiye etmem, okuyun ve uygun olup olmadığına kendiniz karar verin.
Öncelikle büyük disk raflarına sahip birkaç sunucu oluşturmanız gerekir. Daha sonra, bu sunucularda birkaç ClickHouse sunucusu oluşturun ve bunları aynı parçalar için başka bir kopya olarak çalışacak şekilde yapılandırın. Daha sonra bu sunucularda anlık görüntüler oluşturmanıza olanak tanıyan bir dosya sistemi veya bazı araçlar kullanın. Burada iki seçenek var. İlk seçenek LVM anlık görüntüleri, ikinci seçenek ise Linux'ta ZFS'dir.
Bundan sonra her gün bir anlık görüntü oluşturmanız gerekir, yalan söyleyecek ve biraz yer kaplayacaktır. Doğal olarak veriler değişirse alan miktarı da zamanla artacaktır. Bu anlık görüntü herhangi bir zamanda çıkarılabilir ve veriler geri yüklenebilir, bu çok garip bir çözüm. Ayrıca, lider olmaya çalışmamaları için yapılandırmadaki bu kopyaları da sınırlamamız gerekiyor.
Şaftlarda kontrollü bir kopya gecikmesi düzenlemek mümkün olacak mı?
Bu yıl ClickHouse'da şaft yapmayı planlıyorsunuz. İçlerinde kontrollü bir kopya gecikmesi düzenlemek mümkün olacak mı? Değişiklikler ve diğer değişikliklerle olumsuz senaryolardan kendimizi korumak için kullanmak istiyoruz.
Değişiklikler için bir çeşit geri alma işlemi yapmak mümkün mü? Mesela mevcut bir kuyuda, bu ana kadar değişiklikleri uyguladığınızı ve bu andan itibaren değişiklikleri uygulamayı bıraktığınızı mı söylüyorsunuz?
Kümemize bir komut gelip onu bozduysa, o zaman bir saatlik gecikmeli koşullu bir kopyamız var, onu şu anda kullanalım diyebiliriz ama son on dakika boyunca ona değişiklik uygulamayacağız?
İlk olarak, kopyaların kontrollü gecikmesi hakkında. Kullanıcılardan böyle bir istek geldi ve biz de Github'da şu istekle bir konu oluşturduk: "Birinin buna ihtiyacı varsa beğenin, kalp koyun." Kimse cevap vermedi ve konu kapandı. Ancak ClickHouse kurarak bu fırsatı zaten yakalayabilirsiniz. Doğru, yalnızca 20.3 sürümünden itibaren.
ClickHouse arka planda sürekli olarak veri birleştirme işlemini gerçekleştirir. Birleştirme tamamlandığında, belirli bir veri kümesi daha büyük bir parçayla değiştirilir. Aynı zamanda daha önce orada olan veri parçaları bir süre daha diskte kalmaya devam eder.
Öncelikle, bloke edilmeyen bir çalışma sağlamak amacıyla, onları kullanan seçilmiş sorgular olduğu sürece saklanmaya devam ederler. Seçme sorguları eski parçalardan kolayca okunur.
İkincisi, ayrıca bir zaman eşiği de vardır - eski veri parçaları diskte sekiz dakika boyunca kalır. Bu sekiz dakika özelleştirilebilir ve hatta bir güne dönüştürülebilir. Bu, disk alanına mal olacaktır: Veri akışına bağlı olarak, son günde verilerin yalnızca iki katına çıkmayacağı, beş katına çıkabileceği ortaya çıktı. Ancak ciddi bir sorun varsa ClickHouse sunucusunu durdurup her şeyi halledebilirsiniz.
Şimdi bunun değişikliklere karşı nasıl koruduğu sorusu ortaya çıkıyor. Buraya daha derinlemesine bakmaya değer çünkü ClickHouse'un eski sürümlerinde değişiklik, parçaları doğrudan değiştirecek şekilde çalışıyordu. Bazı dosyalarda bir parça veri var ve bunu yapıyoruz, örneğin: bırakma sütununu değiştir. Daha sonra bu sütun tüm parçalardan fiziksel olarak kaldırılır.
Ancak sürüm 20.3'ten itibaren değiştirme mekanizması tamamen değiştirildi ve artık veri parçaları her zaman değiştirilemez. Hiç değişmiyorlar; değişiklikler artık birleştirmelerle hemen hemen aynı şekilde çalışıyor. Bir parçayı yerinde değiştirmek yerine yenisini yaratıyoruz. Yeni yığında, değişmeyen dosyalar sabit bağlantılara dönüşür ve eğer bir sütunu silersek, yeni yığında eksik olacaktır. Eski parça varsayılan olarak sekiz dakika sonra silinecektir ve burada yukarıda belirtilen ayarları yapabilirsiniz.
Aynı şey mutasyonlar gibi değişiklikler için de geçerlidir. Bunu yaptığında değiştir sil veya güncellemeyi değiştirparçayı değiştirmez, yenisini yaratır. Daha sonra eskisini siler.
Peki ya tablo yapısı değişirse?
Eski şemayla oluşturulmuş bir yedekleme nasıl geri yüklenir? İkinci soru ise anlık görüntüler ve dosya sistemi araçlarıyla ilgili durumla ilgili. Linux LVM'de ZFS yerine Btrfs iyi mi?
Yaparsan bölüm ekle Farklı bir yapıya sahip bölümleri seçerseniz ClickHouse size bunun mümkün olmadığını söyleyecektir. Çözüm bu. Bunlardan ilki, eski yapıya sahip MergeTree türünde geçici bir tablo oluşturmak, verileri buraya iliştirmeyi kullanarak eklemek ve alter sorgusu yapmaktır. Daha sonra bu verileri kopyalayabilir veya aktarabilir ve tekrar ekleyebilir veya bir istek kullanabilirsiniz. tablo taşıma bölümünü değiştir.
Şimdi ikinci soru Btrfs'in kullanılıp kullanılamayacağıdır. Başlangıç olarak, LVM'niz varsa, LVM anlık görüntüleri yeterlidir ve dosya sistemi ext4 olabilir, önemli değil. Btrts'te her şey sizin kullanım deneyiminize bağlıdır. Bu olgun bir dosya sistemidir, ancak belirli bir senaryoda pratikte her şeyin nasıl çalışacağına dair hala bazı şüpheler vardır. Üretimde Btrfs'niz olmadığı sürece bunu kullanmanızı tavsiye etmem.
Verilerin yeniden paylaşılmasında mevcut en iyi uygulamalar nelerdir?
Yeniden parçalama konusu karmaşık ve çok yönlüdür. Burada birkaç olası cevap var. Bir taraftan gidip şunu söyleyebilirsiniz - ClickHouse'un yerleşik bir yeniden parçalama özelliği yoktur. Ama korkarım bu cevap kimseye uymayacak. Dolayısıyla diğer taraftan gidip ClickHouse'un verileri yeniden düzenlemek için birçok yolu olduğunu söyleyebilirsiniz.
Kümenin alanı biterse veya yükü kaldıramazsa yeni sunucular eklersiniz. Ancak bu sunucular varsayılan olarak boştur, üzerlerinde veri yoktur, yük yoktur. Verileri yeni, daha büyük kümeye eşit şekilde yayılacak şekilde yeniden düzenlemeniz gerekir.
Bunu yapmanın ilk yolu, bölümlerin bir kısmını bir istek kullanarak yeni sunuculara kopyalamaktır. tablo getirme bölümünü değiştir. Örneğin, aya göre bölümleriniz vardı ve 2017'nin ilk ayını alıp yeni bir sunucuya kopyalıyorsunuz, ardından üçüncü ayı başka bir yeni sunucuya kopyalıyorsunuz. Ve bunu aşağı yukarı eşit hale gelinceye kadar yaparsınız.
Aktarım yalnızca kayıt sırasında değişmeyen bölümler için gerçekleştirilebilir. Yeni bölümler için, aktarımları atomik olmadığından kaydın devre dışı bırakılması gerekecektir. Aksi takdirde verilerde kopyalar veya boşluklar ortaya çıkar. Ancak bu yöntem pratiktir ve oldukça etkili çalışır. Hazır sıkıştırılmış bölümler ağ üzerinden iletilir, yani veriler sıkıştırılmaz veya yeniden kodlanmaz.
Bu yöntemin bir dezavantajı vardır ve bu, parçalama planına, bu parçalama planına taahhütte bulunup bulunmadığınıza, hangi parçalama anahtarına sahip olduğunuza bağlıdır. Metriklerle ilgili örneğinizde, parçalama anahtarı yolun karmasıdır. Dağıtılmış bir tablo seçtiğinizde kümedeki tüm parçalara aynı anda gider ve oradan veri alır.
Bu, hangi verinin hangi parçada bulunduğunun aslında sizin için önemli olmadığı anlamına gelir. Önemli olan, bir yol boyunca bulunan verilerin tek bir parçaya ulaşmasıdır ancak hangisinin önemli olmadığıdır. Bu durumda, hazır bölümlerin aktarılması mükemmeldir, çünkü seçili sorgularla aynı zamanda eksiksiz veriler alırsınız - ister yeniden parçalamadan önce ister sonra olsun, şema gerçekten önemli değildir.
Ancak daha karmaşık vakalar da var. Uygulama mantığı düzeyinde özel bir parçalama şemasına güveniyorsanız, bu istemci şu veya bu parçada bulunur ve istek Dağıtılmış tabloya değil doğrudan oraya gönderilebilir. Veya ClickHouse'un oldukça yeni bir sürümünü kullanıyorsunuz ve ayarı etkinleştirdiniz optimize edilmeyen parçaları atla. Bu durumda seçim sorgusu sırasında nerede kısmındaki ifade analiz edilecek ve sharding şemasına göre hangi shardların kullanılması gerektiği hesaplanacaktır. Bu, verilerin tam olarak bu parçalama şemasına göre bölümlendirilmesi koşuluyla çalışır. Bunları manuel olarak yeniden düzenlediyseniz yazışmalar değişebilir.
Yani bu bir numaralı yöntemdir. Ben de yöntemin uygun olup olmadığı konusunda cevabınızı bekliyorum, yoksa devam edelim.
Vladimir Kolobaev, Avito'nun lider sistem yöneticisi: Alexey, bahsettiğin yöntem, okuma dahil yükü dağıtman gerektiğinde pek işe yaramıyor. Aylık olan ve bir önceki ayı başka bir node'a götürebilen bir partition alabiliriz ancak bu veri için bir istek geldiğinde sadece onu yükleyeceğiz. Ancak kümenin tamamını yüklemek istiyoruz, çünkü aksi takdirde bir süre boyunca okuma yükünün tamamı iki parça tarafından işlenecektir.
Alexey Milovidov: Buradaki cevap tuhaf; evet, kötü ama işe yarayabilir. Tam olarak nasıl olduğunu açıklayacağım. Verilerinizin arkasında gelen yükleme senaryosuna bakmaya değer. Eğer bu veri izleme ise, o zaman isteklerin büyük çoğunluğunun yeni veriler için olduğunu neredeyse kesin olarak söyleyebiliriz.
Yeni sunucular kurdunuz, eski bölümleri taşıdınız ama aynı zamanda yeni verilerin kaydedilme biçimini de değiştirdiniz. Ve yeni veriler kümenin geneline yayılacak. Böylece, yalnızca beş dakika sonra, son beş dakikaya ait istekler kümeyi eşit şekilde yükleyecektir; bir gün sonra, 24 saatlik istekler kümeyi eşit şekilde yükleyecektir. Ve ne yazık ki önceki aya ait istekler küme sunucularının yalnızca bir kısmına gidecek.
Ancak çoğu zaman Şubat 2019'a özel istekleriniz olmayacak. Büyük olasılıkla, eğer talepler 2019'a girerse, o zaman 2019'un tamamı için geçerli olacaklar - küçük bir aralık için değil, büyük bir süre için. Ve bu tür istekler aynı zamanda kümeyi eşit şekilde yükleyebilecektir. Ancak genel olarak, bunun verileri tamamen eşit şekilde yaymayan geçici bir çözüm olduğu yönündeki yorumunuz kesinlikle doğrudur.
Soruya cevap vermem gereken birkaç nokta daha var. Bunlardan biri, yeniden parçalamanın daha az acıya neden olması için başlangıçta bir parçalama şemasının nasıl tasarlanacağıyla ilgilidir. Bu her zaman mümkün değil.
Örneğin, izleme verileriniz var. İzleme verileri üç nedenden dolayı artıyor. Birincisi tarihsel verilerin birikmesidir. İkincisi trafik artışıdır. Üçüncüsü ise izlemeye tabi olan şeylerin sayısının artması. Kaydedilmesi gereken yeni mikro hizmetler ve ölçümler var.
Bunlardan en büyük artışın üçüncü nedenden, izleme kullanımındaki artıştan kaynaklanması muhtemeldir. Ve bu durumda, yükün niteliğine, ana seçim sorgularının neler olduğuna bakmaya değer. Temel seçme sorguları büyük olasılıkla bazı metrik alt kümelerine dayalı olacaktır.
Örneğin, bazı sunucularda bazı servislerin CPU kullanımı. Bu verileri aldığınız belirli bir anahtar alt kümesinin olduğu ortaya çıktı. Ve bu verilere yönelik talebin kendisi büyük olasılıkla oldukça basittir ve onlarca milisaniye içinde tamamlanır. Hizmetleri ve kontrol panellerini izlemek için kullanılır. Umarım bunu doğru anlamışımdır.
Vladimir Kolobaev: Gerçek şu ki, mevcut durumu gerçek zamanlı olarak tarihsel durumla karşılaştırdığımız için sıklıkla tarihsel verilere başvuruyoruz. Büyük miktarda veriye hızlı erişime sahip olmak bizim için önemli ve ClickHouse bu konuda mükemmel bir iş çıkarıyor.
Kesinlikle haklısınız, okuma isteklerinin çoğunu her izleme sistemi gibi biz de son gün yaşıyoruz. Ancak aynı zamanda tarihsel verilerin üzerindeki yük de oldukça büyük. Temelde her otuz saniyede bir dolaşan ve ClickHouse'a şunu söyleyen bir uyarı sisteminden geliyor: “Bana son altı haftanın verilerini ver. Şimdi bana bunlardan bir tür hareketli ortalama oluştur ve mevcut değeri geçmiş değerle karşılaştıralım."
Bu tür çok yeni talepler için, yalnızca iki günlük veriyi sakladığımız başka bir küçük tablomuz olduğunu ve ana isteklerin bu tabloya uçtuğunu söylemek isterim. Yalnızca büyük geçmiş sorguları büyük parçalı tabloya göndeririz.
Alexey Milovidov: Ne yazık ki senaryonuz için pek uygulanabilir olmadığı ortaya çıktı, ancak size kullanılması gerekmeyen ancak arkadaşlarımın hizmetinde kullanılan iki kötü ve karmaşık parçalama şemasının açıklamasını anlatacağım.
Yandex.Metrica etkinliklerinin yer aldığı bir ana küme bulunmaktadır. Etkinlikler; sayfa görüntülemeleri, tıklamalar ve dönüşümlerdir. Çoğu istek belirli bir web sitesine gider. Yandex.Metrica hizmetini açıyorsunuz, bir web siteniz var - avito.ru, rapora gidin ve web siteniz için bir talepte bulunuldu.
Ancak şirket içi analistler tarafından yapılan analitik ve küresel başka talepler de var. Her ihtimale karşı, dahili analistlerin yalnızca Yandex hizmetleri için talepte bulunduğunu not ediyorum. Ancak yine de Yandex hizmetleri bile tüm verilerde önemli bir paya sahip. Bunlar belirli sayaçlara yönelik talepler değil, daha geniş filtrelemeye yönelik taleplerdir.
Veriler, her şeyin tek bir sayaç ve küresel sorgular için verimli şekilde çalışacağı şekilde nasıl organize edilir? Diğer bir zorluk ise Metrics kümesi için ClickHouse'daki istek sayısının saniyede birkaç bin olmasıdır. Aynı zamanda, bir ClickHouse sunucusu önemsiz olmayan istekleri, örneğin saniyede birkaç bin isteği işleyemez.
Küme boyutu altı yüz civarında sunucudur. Bu kümenin üzerine Dağıtılmış bir tablo çekerseniz ve oraya birkaç bin istek gönderirseniz, bu, bunları tek bir sunucuya göndermekten daha da kötü olacaktır. Öte yandan verilerin eşit şekilde dağıtılması ve tüm sunuculardan talepte bulunulması seçeneği de anında reddediliyor.
Tamamen zıt bir seçenek var. Verileri siteler arasında parçaladığımızı ve bir siteye yönelik isteğin tek bir parçaya gittiğini düşünün. Artık küme saniyede on bin isteği işleyebilecek, ancak bir parçada herhangi bir istek çok yavaş çalışacak. Artık aktarım hızı açısından ölçeklenmeyecek. Özellikle bu avito.ru sitesi ise. Avito'nun RuNet'te en çok ziyaret edilen sitelerden biri olduğunu söylersem sırrı açıklamayacağım. Ve onu tek bir parça üzerinde işlemek delilik olur.
Bu nedenle parçalama şeması daha kurnaz bir şekilde tasarlanmıştır. Kümenin tamamı katman dediğimiz birkaç kümeye bölünmüştür. Her küme bir düzineden birkaç düzineye kadar parça içerir. Toplamda bu tür otuz dokuz küme vardır.
Bütün bunlar nasıl ölçekleniyor? Kümelerin sayısı değişmiyor; birkaç yıl önce otuz dokuz iken hâlâ öyle. Ancak her birinde veri biriktirdikçe parça sayısını yavaş yavaş artırıyoruz. Ve parçalama şeması bir bütün olarak şu şekildedir: Bu kümeler web sitelerine bölünmüştür ve hangi web sitesinin hangi kümede olduğunu anlamak için MySQL'de ayrı bir metataban kullanılır. Tek site - tek kümede. İçerisinde ise ziyaretçi ID’lerine göre parçalama yapılıyor.
Kayıt yaparken bunları ziyaretçi kimliğinin kalan kısmına bölüyoruz. Ancak yeni bir parça eklerken parçalama şeması değişir; bölmeye devam ederiz, ancak kalan kısmı başka bir sayıya böleriz. Bu, bir ziyaretçinin zaten birden fazla sunucuda bulunduğu ve buna güvenemeyeceğiniz anlamına gelir. Bu yalnızca verilerin daha iyi sıkıştırılmasını sağlamak için yapılır. Ve istekte bulunurken kümeye bakan ve onlarca sunucuya erişen Dağıtılmış tabloya gidiyoruz. Bu çok aptalca bir plan.
Ama bu plandan vazgeçtiğimizi söylemezsem hikayem eksik kalacak. Yeni şemada her şeyi değiştirdik ve tüm verileri clickhouse-copier kullanarak kopyaladık.
Yeni şemada, tüm siteler büyük ve küçük olmak üzere iki kategoriye ayrılıyor. Eşiğin nasıl seçildiğini bilmiyorum, ancak sonuç, büyük sitelerin her biri üç kopyaya sahip 120 parçanın (yani 360 sunucunun) bulunduğu tek bir kümeye kaydedilmesiydi. Ve parçalama şeması, herhangi bir isteğin aynı anda tüm parçalara gitmesini sağlayacak şekildedir. Artık Yandex.Metrica'da avito.ru için herhangi bir rapor sayfası açarsanız istek 120 sunucuya gidecektir. RuNet'te birkaç büyük site var. Ve istekler saniyede bin değil, yüzden bile az. Tüm bunlar, her biri 120 sunucuyla işlenen Dağıtılmış tablo tarafından sessizce çiğneniyor.
İkinci küme ise küçük siteler içindir. Burada site kimliğini temel alan bir parçalama şeması verilmiştir ve her istek tam olarak bir parçaya gider.
ClickHouse'un bir clickhouse fotokopi yardımcı programı vardır. Bize ondan bahseder misiniz?
Hemen bu çözümün daha hantal ve biraz daha az üretken olduğunu söyleyeceğim. Avantajı, verileri tamamen belirttiğiniz desene göre yaymasıdır. Ancak yardımcı programın dezavantajı, hiç yeniden sertleştirilmemesidir. Verileri bir küme şemasından başka bir küme şemasına kopyalar.
Bu, çalışması için iki kümeye sahip olmanız gerektiği anlamına gelir. Aynı sunucularda bulunabilirler, ancak yine de veriler aşamalı olarak taşınmayacak, kopyalanacaktır.
Mesela dört sunucu vardı, şimdi sekiz tane var. Tüm sunucularda yeni bir Dağıtılmış tablo, yeni yerel tablolar oluşturursunuz ve clickhouse-copier'ı başlatırsınız, oradan okuması gereken çalışma düzenini belirtir, yeni parçalama düzenini kabul eder ve verileri oraya aktarırsınız. Ve eski sunucularda şu anda olduğundan bir buçuk kat daha fazla alana ihtiyacınız olacak, çünkü eski verilerin onlarda kalması gerekiyor ve aynı eski verilerin yarısı onların üzerine ulaşacak. Verilerin yeniden parçalanması gerektiğini ve alan olduğunu önceden düşündüyseniz, bu yöntem uygundur.
Clickhouse fotokopi makinesi içeride nasıl çalışır? Bir tablonun bir bölümünü tek bir parçada işlemek için tüm işi bir dizi göreve böler. Tüm bu görevler paralel olarak yürütülebilir ve clickhouse-copier farklı makinelerde birden fazla durumda çalıştırılabilir, ancak bir bölüm için yaptığı şey bir ekleme seçiminden başka bir şey değildir. Veriler okunur, sıkıştırılmış hali açılır, yeniden bölümlendirilir, sonra tekrar sıkıştırılır, bir yere yazılır ve yeniden sıralanır. Bu daha zor bir karar.
Yeniden parçalama denen bir pilot şeyiniz vardı. Peki ya onunla?
2017'de yeniden parçalama adı verilen pilot bir uygulamanız vardı. ClickHouse'da bir seçenek bile var. Anladığım kadarıyla kalkmadı. Bunun neden olduğunu bana söyleyebilir misin? Çok alakalı görünüyor.
Sorun şu ki, eğer veriyi yerinde yeniden parçalamak gerekirse, bunu atomik olarak yapmak için çok karmaşık bir senkronizasyona ihtiyaç vardır. Bu senkronizasyonun nasıl çalıştığına baktığımızda temel sorunların olduğu ortaya çıktı. Ve bu temel problemler sadece teorik değil, aynı zamanda pratikte de çok basit bir şekilde açıklanabilecek bir şey şeklinde kendini göstermeye başladı - hiçbir şey işe yaramıyor.
Yavaş disklere taşımadan önce tüm veri parçalarını birleştirmek mümkün müdür?
Birleştirmeler bağlamında yavaş diske geçiş seçeneğiyle TTL hakkında soru. Tüm parçaları yavaş disklere taşımadan önce birleştirmenin cron dışında bir yolu var mı?
Sorunun cevabı, aktarmadan önce tüm parçaları bir şekilde otomatik olarak tek bir parçaya yapıştırmanın mümkün olduğudur - hayır. Bunun gerekli olduğunu düşünmüyorum. Tüm parçaları tek bir parçada birleştirmeniz gerekmez; bunların yavaş disklere otomatik olarak aktarılacağına güvenmeniz yeterlidir.
Transfer kuralları için iki kriterimiz var. İlki dolu haliyle. Geçerli depolama katmanında belirli bir yüzdeden daha az boş alan varsa, bir parça seçip onu daha yavaş depolamaya taşıyoruz. Daha doğrusu, daha yavaş değil, bir sonraki - yapılandırırken.
İkinci kriter boyuttur. Büyük parçaları hareket ettirmekle ilgili. Eşiği hızlı diskteki boş alana göre ayarlayabilirsiniz; veriler otomatik olarak aktarılacaktır.
Uyumluluğu önceden kontrol etmenin bir yolu yoksa ClickHouse'un yeni sürümlerine nasıl geçilir?
Bu konu düzenli olarak tartışılıyor farklı versiyonları dikkate alarak ve hala. 19.11 sürümünden 19.16 sürümüne ve örneğin 19.16 sürümünden 20.3 sürümüne yükseltme ne kadar güvenlidir? Korumalı alanda uyumluluğu önceden kontrol etmeden yeni sürümlere geçmenin en iyi yolu nedir?
Burada birkaç “altın” kural var. Birinci - . Büyük, ancak geriye dönük olarak uyumsuz değişikliklerle ilgili ayrı paragraflar var. Bu noktalara tehlike işareti olarak bakmayın. Bunlar genellikle büyük olasılıkla kullanmadığınız bazı uç işlevleri içeren küçük uyumsuzluklardır.
İkinci olarak, korumalı alanda uyumluluğu kontrol etmenin bir yolu yoksa ve üretimde hemen güncelleme yapmak istiyorsanız, önerimiz bunu yapmanıza gerek olmamasıdır. İlk önce bir sanal alan oluşturun ve test edin. Test ortamı yoksa, büyük olasılıkla çok büyük bir şirketiniz yoktur, bu da verilerin bir kısmını dizüstü bilgisayarınıza kopyalayabileceğiniz ve üzerinde her şeyin doğru çalıştığından emin olabileceğiniz anlamına gelir. Hatta makinenizde yerel olarak birkaç kopya bile oluşturabilirsiniz. Veya yakın bir yerden yeni bir sürüm alıp verilerin bir kısmını oraya yükleyebilirsiniz - yani doğaçlama bir test ortamı oluşturabilirsiniz.
Diğer bir kural ise, üretimdeki hataların yakalanması ve ardından hızlı düzeltmeler yapılması nedeniyle sürüm yayınlandıktan sonra bir hafta boyunca güncelleme yapılmamasıdır. Kafanızın karışmaması için ClickHouse sürümlerinin numaralandırmasını bulalım.
20.3.4 sürümü var. 20 sayısı üretim yılını - 2020 - gösterir. İçeride ne olduğu açısından bunun bir önemi yok, bu yüzden buna dikkat etmeyeceğiz. Sonraki - 20.3. Her yeni işlevsellik içeren bir sürüm yayınladığımızda ikinci sayıyı - bu durumda 3 - artırıyoruz. ClickHouse'a bir özellik eklemek istiyorsak bu sayıyı arttırmamız gerekiyor. Yani 20.4 sürümünde ClickHouse daha da iyi çalışacak. Üçüncü rakam 20.3.4'tür. Burada 4, yeni özellikler eklemediğimiz ancak bazı hataları düzelttiğimiz yama sürümlerinin sayısıdır. Ve 4, bunu dört kez yaptığımız anlamına geliyor.
Bunun korkunç bir şey olduğunu düşünmeyin. Genellikle kullanıcı en son sürümü yükleyebilir ve yıllık çalışma süresinde herhangi bir sorun olmadan çalışacaktır. Ancak Çinli yoldaşlarımız tarafından eklenen bitmap işlemeye yönelik bazı işlevlerde, yanlış argümanlar iletildiğinde sunucunun çöktüğünü hayal edin. Bunu düzeltme sorumluluğumuz var. Yeni bir yama sürümü yayınlayacağız ve ClickHouse daha kararlı hale gelecektir.
Üretimde çalışan ClickHouse'unuz varsa ve ClickHouse'un ek özelliklerle yeni bir sürümü yayınlandıysa - örneğin, 20.4.1 ilk sürümse, onu ilk gün üretime geçirmek için acele etmeyin. Neden buna ihtiyaç var? Zaten ClickHouse'u kullanmıyorsanız, onu yükleyebilirsiniz ve büyük olasılıkla her şey yoluna girecek. Ancak ClickHouse zaten istikrarlı bir şekilde çalışıyorsa hangi sorunları çözdüğümüzü görmek için yamaları ve güncellemeleri takip edin.
Kirill Shvakov: Test ortamları hakkında biraz eklemek istiyorum. Herkes test ortamlarından çok korkuyor ve bazı nedenlerden dolayı eğer çok büyük bir ClickHouse kümeniz varsa test ortamının daha az olmaması veya en az on kat daha küçük olması gerektiğine inanıyorlar. Hiç de öyle değil.
Kendi örneğimden yola çıkarak söyleyebilirim. Bir projem var ve ClickHouse var. Test ortamımız tam da onun için - bu, Hetzner'de kesinlikle her şeyin konuşlandırıldığı yirmi avroluk küçük bir sanal makine. Bunu yapmak için Ansible'da tam otomasyona sahibiz ve bu nedenle prensip olarak nereye gidileceği, donanım sunucularına mı yoksa sadece sanal makinelere konuşlandırılacağı mı önemli değil.
Ne yapılabilir? ClickHouse belgelerinde kendi evinizde küçük bir kümeyi nasıl dağıtacağınıza dair bir örnek vermek güzel olurdu - Docker'da, LXC'de, belki bir Ansible oyun kitabı oluşturabilirsiniz çünkü farklı kişiler farklı dağıtımlara sahiptir. Bu çok şeyi basitleştirecektir. Bir kümeyi beş dakika içinde alıp dağıttığınızda, bir şeyi çözmeye çalışmak çok daha kolaydır. Bu çok daha kullanışlıdır çünkü test etmediğiniz bir üretim versiyonuna geçmek hiçbir yere varmayan bir yoldur. Bazen işe yarıyor, bazen çalışmıyor. Bu nedenle başarıyı ummak kötüdür.
Maxim Kotyakov, kıdemli arka uç mühendisi Avito: Büyük şirketlerin karşılaştığı bir dizi sorundan test ortamları hakkında biraz ekleyeceğim. Tam teşekküllü bir ClickHouse kabul kümesine sahibiz; veri şemaları ve ayarlar açısından üretimdekinin tam bir kopyasıdır. Bu küme, minimum kaynakla oldukça yıkık kapsayıcılarda dağıtılır. Üretim verilerinin belli bir yüzdesini oraya yazıyoruz, ne mutlu ki Kafka'daki akışın aynısını yapmak mümkün. Buradaki her şey hem kapasite hem de akış açısından senkronize ve ölçeklendirilmiş. Teorik olarak diğer her şey eşit olduğunda, metrik açısından üretim gibi davranması gerekiyor. Potansiyel olarak patlayıcı olan her şey ilk önce bu standa yuvarlanıyor ve hazır olana kadar birkaç gün orada bırakılıyor. Ancak doğal olarak bu çözüm pahalıdır, zordur ve destek maliyeti sıfır değildir.
Alexey Milovidov: Size Yandex.Metrica'daki arkadaşlarımızın test ortamının nasıl olduğunu anlatacağım. Bir kümede 600 küsur sunucu vardı, diğerinde 360 sunucu vardı ve üçüncü ve birkaç küme daha vardı. Bunlardan birinin test ortamı, her birinde iki kopya bulunan iki parçadan oluşuyor. Neden iki parça? Böylece yalnız değilsin. Ayrıca kopyaları da olmalı. Sadece karşılayabileceğiniz belirli bir minimum miktar.
Bu test ortamı, sorgularınızın çalışıp çalışmadığını ve önemli bir şeyin bozuk olup olmadığını kontrol etmenize olanak tanır. Ancak çoğu zaman her şey çalıştığında tamamen farklı nitelikte sorunlar ortaya çıkar, ancak yükte bazı küçük değişiklikler olur.
Sana bir örnek vereyim. ClickHouse'un yeni bir sürümünü kurmaya karar verdik. Bir test ortamında yayınlandı, Yandex.Metrica'nın kendisinde eski sürüm ile yeni sürümdeki verileri karşılaştıran ve tüm hattı çalıştıran otomatik testler tamamlandı. Ve tabii ki CI'mızın yeşil testleri. Aksi takdirde bu versiyonu önermezdik bile.
Herşey yolunda. Üretime geçmeye başlıyoruz. Grafiklerdeki yükün birkaç kat arttığına dair bir mesaj alıyorum. Sürümü geri alıyoruz. Grafiğe bakıyorum ve şunu görüyorum: yük, kullanıma sunma sırasında birkaç kez arttı ve kullanıma sunulduklarında tekrar azaldı. Daha sonra sürümü geri almaya başladık. Ve yük aynı şekilde arttı ve aynı şekilde geri düştü. Sonuç şu: Yerleşim düzeni nedeniyle yük arttı, şaşırtıcı bir şey yok.
O zaman iş arkadaşlarını yeni sürümü yüklemeye ikna etmek zordu. Ben de şöyle diyorum: “Sorun değil, dışarı çıkın. Parmaklarınızı çapraz tutun, her şey işe yarayacaktır. Artık grafiklerin yükü arttı ama her şey yolunda. Pes etme." Genel olarak bunu yaptık ve hepsi bu - sürüm üretim için yayınlandı. Ancak neredeyse her düzende benzer sorunlar ortaya çıkıyor.
Öldürme sorgusunun sorguları öldürmesi gerekir, ancak öldürmez. Neden?
Bir tür analist olan bir kullanıcı bana geldi ve ClickHouse kümemi koyan bir istek oluşturdu. İsteğin hangi kopyaya veya parçaya gittiğine bağlı olarak bir düğüm veya kümenin tamamı. Bu sunucudaki tüm CPU kaynaklarının bir rafta olduğunu görüyorum, her şey kırmızı. Aynı zamanda ClickHouse isteklere kendisi yanıt verir. Ben de şunu yazıyorum: “Lütfen bana bu çılgınlığı hangi isteğin yarattığını gösterin, süreç listesi.”
Bu isteği bulup ona kill yazıyorum. Ve hiçbir şeyin olmadığını görüyorum. Sunucum bir rafta, ClickHouse bana bazı komutlar veriyor, sunucunun canlı olduğunu ve her şeyin harika olduğunu gösteriyor. Ancak tüm kullanıcı isteklerimde bozulma var, bozulma ClickHouse'daki kayıtlarla başlıyor ve kill sorgum çalışmıyor. Neden? Sorguyu öldürmenin sorguları öldürmesi gerektiğini düşündüm, ama öyle değil.
Şimdi oldukça tuhaf bir cevap olacak. Önemli olan, öldürme sorgusunun sorguları öldürmemesidir.
Kill query, "Bu sorgunun öldürülmesini istiyorum" adlı küçük bir kutuyu işaretler. Ve isteğin kendisi, her bloğu işlerken bu bayrağa bakar. Ayarlanırsa istek çalışmayı durdurur. Hiç kimsenin isteği öldürmediği ortaya çıktı, kendisinin her şeyi kontrol etmesi ve durması gerekiyor. Ve bu, isteğin veri bloklarını işliyor durumda olduğu tüm durumlarda işe yaramalıdır. Bir sonraki veri bloğunu işleyecek, bayrağı kontrol edecek ve duracaktır.
Bu, isteğin bazı işlemlerde engellendiği durumlarda işe yaramaz. Doğru, büyük olasılıkla bu sizin durumunuz değil, çünkü size göre bir ton sunucu kaynağı kullanıyor. Bunun harici sıralama durumunda ve diğer bazı detaylarda işe yaramaması mümkündür. Ancak genel olarak bunun olmaması gerekir, bu bir hatadır. Ve önerebileceğim tek şey ClickHouse'u güncellemek.
Okuma yükü altında tepki süresi nasıl hesaplanır?
Öğe toplamlarını (çeşitli sayaçlar) saklayan bir tablo vardır. Hat sayısı yaklaşık yüz milyondur. 1K öğeler için 1K RPS dökerseniz öngörülebilir bir yanıt süresine güvenmek mümkün müdür?
Bağlama bakılırsa okuma yükünden bahsediyoruz çünkü yazmada herhangi bir sorun yok - hatta bin, hatta yüz bin ve bazen birkaç milyon satır eklenebilir.
Okuma istekleri çok farklıdır. Seçim 1'de ClickHouse saniyede yaklaşık on binlerce istek gerçekleştirebilir, dolayısıyla bir anahtara yönelik istekler bile zaten bazı kaynaklar gerektirecektir. Ve bu tür nokta sorguları bazı anahtar-değer veritabanlarına göre daha zor olacaktır çünkü her okuma için bir veri bloğunu dizine göre okumak gerekir. Dizinimiz her kaydı değil, her aralığı ele alır. Yani, aralığın tamamını okumanız gerekecek - bu, varsayılan olarak 8192 satırdır. Sıkıştırılmış veri bloğunun sıkıştırmasını 64 KB'tan 1 MB'a çıkarmanız gerekecektir. Genellikle bu tür hedeflenen sorguların tamamlanması birkaç milisaniye sürer. Ancak bu en basit seçenektir.
Basit bir aritmetik deneyelim. Birkaç milisaniyeyi binle çarparsanız birkaç saniye elde edersiniz. Saniyede bin isteğe yetişmek imkansız gibi ama aslında mümkün çünkü birden fazla işlemci çekirdeğimiz var. Dolayısıyla, prensip olarak ClickHouse bazen 1000 RPS tutabilir, ancak kısa talepler, özellikle hedeflenen talepler için.
Bir ClickHouse kümesini basit isteklerin sayısına göre ölçeklendirmeniz gerekiyorsa, o zaman en basit şeyi öneririm: kopya sayısını artırın ve istekleri rastgele bir kopyaya gönderin. Bir kopya saniyede beş yüz istek tutuyorsa ki bu tamamen gerçekçidir, o zaman üç kopya bir buçuk bin isteği işleyecektir.
Elbette bazen ClickHouse'u maksimum nokta okuma sayısı için yapılandırabilirsiniz. Bunun için ne gerekiyor? Birincisi endeksin ayrıntı düzeyini azaltmaktır. Bu durumda, bire indirilmemeli, indeksteki giriş sayısının sunucu başına birkaç milyon veya on milyonlarca olacağı esas alınarak yapılmalıdır. Tabloda yüz milyon satır varsa ayrıntı düzeyi 64 olarak ayarlanabilir.
Sıkıştırılmış bloğun boyutunu azaltabilirsiniz. Bunun için ayarlar var minimum sıkıştırma bloğu boyutu, maksimum sıkıştırma bloğu boyutu. Bunlar azaltılabilir, verilerle yeniden doldurulabilir ve ardından hedeflenen sorgular daha hızlı olacaktır. Ancak yine de ClickHouse bir anahtar-değer veritabanı değildir. Çok sayıda küçük istek bir yük antimodelidir.
Kirill Shvakov: Orada sıradan hesapların olması durumunda tavsiyelerde bulunacağım. ClickHouse'un bir tür sayacı sakladığı durumlarda bu oldukça standart bir durumdur. Bir kullanıcım var, filanca ülkeden ve üçüncü bir alandan, bir şeyleri adım adım artırmam gerekiyor. MySQL'i alın, benzersiz bir anahtar yapın - MySQL'de bu yinelenen bir anahtardır ve PostgreSQL'de bu bir çakışmadır - ve bir artı işareti ekleyin. Bu çok daha iyi çalışacaktır.
Çok fazla veriniz olmadığında ClickHouse'u kullanmanın pek bir anlamı yoktur. Düzenli veritabanları var ve bunu iyi yapıyorlar.
Önbellekte daha fazla veri olması için ClickHouse'da neyi ayarlayabilirim?
Bir durum hayal edelim - sunucularda 256 GB RAM var, günlük rutinde ClickHouse yaklaşık 60-80 GB alıyor, en yüksekte - 130'a kadar. Önbellekte daha fazla veri olması için neler etkinleştirilebilir ve ayarlanabilir ve buna göre, diske daha az gezi mi yapılıyor?
Genellikle işletim sisteminin sayfa önbelleği bu işi iyi yapar. Sadece üst kısmı açarsanız, oraya önbelleğe alınmış veya boş olarak bakarsanız - aynı zamanda ne kadar önbelleğe alındığını da gösterir - o zaman tüm boş belleğin önbellek için kullanıldığını fark edeceksiniz. Ve bu veriler okunurken diskten değil RAM'den okunacaktır. Aynı zamanda önbelleğe alınan sıkıştırılmış veriler olduğu için önbelleğin etkili bir şekilde kullanıldığını söyleyebilirim.
Ancak bazı basit sorguları daha da hızlandırmak istiyorsanız ClickHouse içindeki sıkıştırılmış verilerde bir önbellek etkinleştirmek mümkündür. denir sıkıştırılmamış önbellek. Config.xml yapılandırma dosyasında, sıkıştırılmamış önbellek boyutunu ihtiyacınız olan değere ayarlayın - geri kalanı sayfa önbelleğinin altına gireceğinden, boş RAM'in yarısından fazlasını önermem.
Ayrıca iki istek düzeyi ayarı vardır. İlk ayar - sıkıştırılmamış önbellek kullan - kullanımını içerir. Tüm verileri okuyabilen ve önbelleği temizleyebilen ağır istekler hariç tüm istekler için etkinleştirilmesi önerilir. İkinci ayar ise önbelleği kullanacak maksimum satır sayısı gibi bir şeydir. Büyük sorguları önbelleği atlayacak şekilde otomatik olarak sınırlandırır.
RAM'de depolama için depolama_yapılandırmasını nasıl yapılandırabilirim?
Yeni ClickHouse belgelerinde ilgili bölümü okudum . Açıklamada hızlı SSD'ye sahip bir örnek yer almaktadır.
Aynı şeyin birim sıcak bellekle nasıl yapılandırılabileceğini merak ediyorum. Ve bir soru daha. Select bu veri organizasyonuyla nasıl çalışıyor, setin tamamını mı yoksa sadece disktekini mi okuyacak ve bu veriler hafızada mı sıkıştırılıyor? Ve bu tür bir veri organizasyonunda ön yer bölümü nasıl çalışır?
Bu ayar, veri parçalarının depolanmasını etkiler ve formatları hiçbir şekilde değişmez.
Hadi daha yakından bakalım.
RAM'de veri depolamayı yapılandırabilirsiniz. Disk için yapılandırılan tek şey onun yoludur. Dosya sistemindeki bir yola bağlanan bir tmpfs bölümü oluşturursunuz. Bu yolu en sıcak bölüm için veri depolama yolu olarak belirtirsiniz, veri parçaları gelmeye ve oraya yazılmaya başlar, her şey yolunda.
Ancak düşük güvenilirlik nedeniyle bunu yapmanızı önermiyorum, ancak farklı veri merkezlerinde en az üç kopyanız varsa o zaman bu mümkündür. Herhangi bir şey olursa veriler geri yüklenecektir. Sunucunun aniden kapatılıp tekrar açıldığını düşünelim. Bölme tekrar monte edildi, ancak orada hiçbir şey yoktu. ClickHouse sunucusu başlatıldığında bu parçaların olmadığını görüyor, ancak ZooKeeper meta verilerine göre bunların orada olması gerekiyor. Hangi replikaların olduğuna bakar, ister ve indirir. Bu şekilde veriler geri yüklenecektir.
Bu anlamda veriyi RAM'de depolamak, diskte depolamaktan temelde farklı değildir, çünkü veri diske yazıldığında önce sayfa önbelleğine gider ve daha sonra fiziksel olarak yazılır. Bu, dosya sistemi montaj seçeneğine bağlıdır. Ancak her ihtimale karşı, ClickHouse'un ekleme sırasında fsync yapmadığını söyleyeceğim.
Bu durumda RAM'deki veriler disktekiyle tamamen aynı formatta saklanır. Seçme sorgusu da aynı şekilde okunması gereken parçaları seçer, parçalardaki gerekli veri aralıklarını seçer ve okur. Ve prewhere, verinin RAM'de mi yoksa diskte mi olduğuna bakılmaksızın tamamen aynı şekilde çalışır.
Düşük Kardinalite kaç benzersiz değere kadar etkilidir?
Düşük Kardinalite akıllıca tasarlanmıştır. Veri sözlükleri derler ama bunlar yereldir. Birincisi, her parça için farklı sözlükler vardır ve ikincisi, tek parça içinde bile her aralık için farklı sözlükler bulunabilir. Benzersiz değerlerin sayısı bir eşik rakamına (sanırım bir milyon) ulaştığında, sözlük rafa kaldırılır ve yeni bir sözlük oluşturulur.
Cevap genel olarak şudur: her yerel aralık için - örneğin her gün için - bir milyona kadar benzersiz değer Düşük Kardinallik etkilidir. Daha sonra sadece bir tane değil, birçok farklı sözlüğün kullanılacağı bir geri dönüş olacak. Yaklaşık olarak normal bir dize sütunu ile aynı şekilde çalışacak, belki biraz daha az verimli olacak, ancak ciddi bir performans düşüşü olmayacak.
Beş milyar satırlık bir tabloda tam metin araması yapmak için en iyi uygulamalar nelerdir?
Farklı cevaplar var. Birincisi, ClickHouse'un tam metinli bir arama motoru olmadığını söylemektir. Bunun için özel sistemler var örneğin; и . Ancak giderek daha fazla insanın Elasticsearch'ten ClickHouse'a geçiş yaptığını söylediğini görüyorum.
Bu neden oluyor? Bunu, Elasticsearch'ün indekslerin oluşturulmasından başlayarak bazı hacimlerde yükle başa çıkmayı bırakmasıyla açıklıyorlar. Dizinler çok hantal hale geliyor ve verileri yalnızca ClickHouse'a aktarırsanız, bunların hacim açısından birkaç kat daha verimli bir şekilde depolandığı ortaya çıkıyor. Aynı zamanda, arama sorguları çoğu zaman, tüm veri hacminde morfolojiyi dikkate alarak bir kelime öbeği bulmayı gerektirecek şekilde değildi, ancak tamamen farklıydı. Örneğin, son birkaç saatteki günlüklerde bazı bayt dizilerini bulun.
Bu durumda ClickHouse'da ilk alanı tarih ve saat olacak bir dizin oluşturursunuz. Ve en büyük veri kesintisi tarih aralığına bağlı olacaktır. Seçilen tarih aralığında, kural olarak, kaba kuvvet yöntemi kullanılarak beğeni kullanılarak bile tam metin araması yapmak zaten mümkündür. ClickHouse'daki like operatörü bulabileceğiniz en etkili like operatörüdür. Daha iyi bir şey bulursan bana söyle.
Ama yine de tam tarama gibi. Ve tam tarama yalnızca CPU'da değil, diskte de yavaş olabilir. Aniden günde bir terabayt veriniz varsa ve gün içinde bir kelime ararsanız terabaytı taramanız gerekir. Ve muhtemelen normal sabit disklerdedir ve sonunda bu sunucuya SSH aracılığıyla erişemeyeceğiniz şekilde yükleneceklerdir.
Bu durumda küçük bir numara daha sunmaya hazırım. Bu deneysel; işe yarayabilir, yaramayabilir. ClickHouse, trigram Bloom filtreleri biçiminde tam metin dizinlerine sahiptir. Arenadata'daki meslektaşlarımız bu indeksleri zaten denediler ve genellikle tam olarak amaçlandığı gibi çalışıyorlar.
Bunları doğru kullanmak için tam olarak nasıl çalıştıklarını iyi anlamalısınız: trigram Bloom filtresinin ne olduğu ve boyutunun nasıl seçileceği. Verilerde nadir bulunan bazı ifadeler, alt diziler üzerindeki sorgulamalarda yardımcı olacaklarını söyleyebilirim. Bu durumda alt aralıklar indekslere göre seçilecek ve daha az veri okunacaktır.
Yakın zamanda ClickHouse, tam metin araması için daha da gelişmiş işlevler ekledi. Bu, ilk olarak, büyük/küçük harfe duyarlı, büyük/küçük harfe duyarlı olmayan, UTF-8 desteği veya yalnızca ASCII desteği içeren seçenekler de dahil olmak üzere, tek geçişte bir grup alt dizenin aranmasıdır. İhtiyacınız olan en etkili olanı seçin.
Tek geçişte birden fazla normal ifadenin aranması da ortaya çıktı. X'i bir alt dize gibi veya X'i başka bir alt dize gibi yazmanıza gerek yoktur. Hemen yazarsınız ve her şey mümkün olduğunca verimli bir şekilde yapılır.
Üçüncüsü, artık normal ifadeler için yaklaşık bir arama ve alt dizeler için yaklaşık bir arama var. Birisi bir kelimeyi yanlış yazmışsa, maksimum eşleşme aranacaktır.
Çok sayıda kullanıcı için ClickHouse'a erişimi organize etmenin en iyi yolu nedir?
Çok sayıda tüketici ve analist için erişimi en iyi nasıl organize edebileceğimizi bize anlatın. Bir kuyruk nasıl oluşturulur, maksimum eşzamanlı sorgulara öncelik nasıl verilir ve hangi araçlarla?
Küme yeterince büyükse, analistler için bir giriş noktası haline gelecek iki sunucuyu daha yükseltmek iyi bir çözüm olacaktır. Yani analistlerin kümedeki belirli parçalara erişmesine izin vermeyin, bunun yerine veri içermeyen iki boş sunucu oluşturun ve bunlar üzerinde erişim haklarını yapılandırın. Bu durumda dağıtılmış isteklere ilişkin kullanıcı ayarları uzak sunuculara aktarılır. Yani bu iki sunucudaki her şeyi yapılandırıyorsunuz ve ayarların tüm küme üzerinde etkisi oluyor.
Prensip olarak bu sunucularda veri yoktur ancak isteklerin yürütülmesi için üzerlerindeki RAM miktarı çok önemlidir. Harici toplama veya harici sıralama etkinleştirilmişse disk, geçici veriler için de kullanılabilir.
Olası tüm sınırlarla ilişkili ayarlara bakmak önemlidir. Şimdi analist olarak Yandex.Metrica kümesine gidip bir istek sorsam isabetlerden sayıyı seç, o zaman bana hemen isteği yerine getiremeyeceğime dair bir istisna verilecek. Taramama izin verilen maksimum satır sayısı yüz milyardır ve kümedeki bir tabloda toplamda elli trilyon satır vardır. Bu ilk sınırlamadır.
Diyelim ki satır sınırını kaldırdım ve sorguyu tekrar çalıştırdım. Sonra aşağıdaki istisnayı göreceğim - ayar etkin tarihe göre kuvvet endeksi. Tarih aralığı belirtmediğim takdirde sorguyu tamamlayamam. Bunu manuel olarak belirlemek için analistlere güvenmeniz gerekmez. Tipik bir durum, olay tarihinin hafta arasında olduğu bir tarih aralığının yazılmasıdır. Ve sonra yanlış yerde bir parantez belirttiler ve bunun yerine veya - veya URL eşleşmesi olduğu ortaya çıktı. Herhangi bir sınır yoksa, URL sütununu tarayacak ve yalnızca bir ton kaynak israfına neden olacaktır.
Ayrıca ClickHouse'un iki öncelik ayarı vardır. Ne yazık ki çok ilkeldirler. Birine basitçe denir öncelik. Öncelik ≠ 0 ve önceliği olan istekler yürütülüyorsa, ancak öncelik değeri daha düşük olan, yani daha yüksek öncelik anlamına gelen bir istek yürütülüyorsa, öncelik değeri daha büyük olan, yani daha düşük önceliğe sahip bir istek yürütülür. , yalnızca askıya alınır ve bu süre zarfında hiç çalışmaz.
Bu çok kaba bir ayardır ve kümenin sabit bir yüke sahip olduğu durumlar için uygun değildir. Ancak önemli olan kısa, hızlı istekleriniz varsa ve küme çoğunlukla boştaysa bu kurulum uygundur.
Bir sonraki öncelik ayarı çağrılır İşletim sistemi iş parçacığı önceliği. Basitçe Linux zamanlayıcı için tüm istek yürütme iş parçacıklarının güzel değerini ayarlar. Öyle çalışıyor ama yine de çalışıyor. Minimum güzel değeri ayarlarsanız - bu, değer olarak en büyüğüdür ve dolayısıyla en düşük önceliktir - ve yüksek öncelikli istekler için -19'u ayarlarsanız, CPU düşük öncelikli istekleri yüksek öncelikli olanlardan yaklaşık dört kat daha az tüketecektir.
Ayrıca maksimum istek yürütme süresini de (örneğin beş dakika) yapılandırmanız gerekir. Minimum sorgu yürütme hızı en harika şeydir. Bu ayar uzun süredir var ve yalnızca ClickHouse'un yavaşlamadığını iddia etmek için değil, aynı zamanda onu zorlamak için de gerekli.
Düşünün, yapılandırıyorsunuz: eğer bir sorgu saniyede bir milyondan az satır işliyorsa, bunu yapamazsınız. Bu bizim iyi ismimizi, iyi veri tabanımızı utandırıyor. Bunu yasaklayalım. Aslında iki ayar var. Biri denir minimum yürütme hızı - saniye başına satır cinsinden ve ikincisine, minimum yürütme hızını kontrol etmeden önce zaman aşımı adı verilir - varsayılan olarak on beş saniye. Yani, on beş saniye mümkündür ve eğer yavaşsa, bir istisna atın ve isteği iptal edin.
Ayrıca kotaları da ayarlamanız gerekir. ClickHouse, kaynak tüketimini sayan yerleşik bir kota özelliğine sahiptir. Ancak maalesef CPU, diskler gibi donanım kaynakları değil, mantıksal kaynaklar - işlenen isteklerin, okunan satırların ve baytların sayısı. Ve örneğin beş dakika içinde en fazla yüz, saatte ise bin istek yapılandırabilirsiniz.
Neden önemlidir? Çünkü bazı analitik sorguları doğrudan ClickHouse istemcisinden manuel olarak gerçekleştirilecektir. Ve her şey iyi olacak. Ama şirketinizde ileri düzey analistler varsa senaryo yazarlar ve senaryoda hata olabilir. Ve bu hata isteğin sonsuz döngüde yürütülmesine neden olacaktır. Kendimizi korumamız gereken şey budur.
Bir sorgunun sonuçlarını on müşteriye vermek mümkün müdür?
Aynı anda çok büyük taleplerle gelmeyi seven birçok kullanıcımız var. Talep büyüktür ve prensip olarak hızlı bir şekilde yerine getirilir, ancak aynı anda bu tür çok sayıda talep olması nedeniyle çok acı verici hale gelir. Art arda on kez gelen aynı isteği bir kez gerçekleştirip sonucu on müşteriye vermek mümkün müdür?
Sorun, ara verilerin önbelleğinin veya önbelleğinin sonuçlarına sahip olmamamızdır. İşletim sisteminin, diskteki verileri tekrar okumanızı engelleyecek bir sayfa önbelleği vardır, ancak ne yazık ki veriler yine de sıkıştırılmamış, seri durumdan çıkarılacak ve yeniden işlenecektir.
Ara verileri önbelleğe alarak veya benzer sorguları bir tür sıraya dizerek ve bir sonuç önbelleği ekleyerek bundan bir şekilde kaçınmak istiyorum. Şu anda geliştirme aşamasında olan ve istek önbelleği ekleyen bir çekme isteğimiz var, ancak yalnızca giriş ve birleştirme bölümlerindeki alt sorgular için - yani çözüm eksik.
Ancak böyle bir durumla da karşı karşıyayız. Özellikle kanonik bir örnek, sayfalandırılmış sorgulardır. Bir rapor var, birkaç sayfası var ve limit 10 için talep var. O zaman aynı şey ama limit 10,10. Sonra bir sonraki sayfa daha. Ve soru şu; neden tüm bunları her seferinde sayıyoruz? Ama artık bir çözüm yok ve bundan kaçınmanın da bir yolu yok.
ClickHouse'un yanına sepet olarak yerleştirilen alternatif bir çözüm var - .
Kirill Shvakov: ClickHouse Proxy'de yerleşik bir hız sınırlayıcı ve yerleşik bir sonuç önbelleği bulunur. Benzer bir sorun çözüldüğü için orada birçok ayar yapıldı. Proxy, istekleri kuyruğa alarak sınırlamanıza ve istek önbelleğinin ne kadar süre dayanacağını yapılandırmanıza olanak tanır. İstekler gerçekten aynıysa, Proxy bunları birçok kez gönderecektir ancak ClickHouse'a yalnızca bir kez gidecektir.
Nginx'in ücretsiz sürümünde de bir önbellek var ve bu da işe yarayacak. Nginx'in, istekler aynı anda gelirse, biri tamamlanana kadar diğerlerini yavaşlatacak ayarları bile vardır. Ancak kurulumun çok daha iyi yapıldığı yer ClickHouse Proxy'dir. ClickHouse'a özel olarak bu isteklere özel olarak yapıldığı için daha uygundur. Kurulumu kolaydır.
Eşzamansız işlemler ve gerçekleştirilmiş görünümler ne olacak?
Tekrar oynatma motoruyla yapılan işlemlerin eşzamansız olması gibi bir sorun var; veriler önce yazılır, sonra çöker. Bazı agregalara sahip somutlaştırılmış bir tablet işaretin altında yaşıyorsa, ona kopyalar yazılacaktır. Ve eğer karmaşık bir mantık yoksa, veriler kopyalanacaktır. Bu konuda ne yapabilirsiniz?
Eşzamansız bir daraltma işlemi sırasında belirli bir matview sınıfına bir tetikleyici uygulamak için açık bir çözüm var. Benzer işlevleri uygulamaya yönelik herhangi bir sihirli çözüm veya plan var mı?
Tekilleştirmenin nasıl çalıştığını anlamaya değer. Şimdi anlatacaklarım soruyla alakalı değil ama yine de hatırlamakta fayda var.
Çoğaltılmış bir tabloya ekleme yaparken, eklenen tüm blokların tekilleştirilmesi söz konusudur. Aynı sayıda aynı satırı içeren aynı bloğu aynı sırayla yeniden yerleştirirseniz, veriler tekilleştirilir. Eklemeye yanıt olarak "Tamam" mesajı alacaksınız, ancak aslında bir veri paketi yazılacak ve kopyalanmayacak.
Kesinlik için bu gereklidir. Ekleme sırasında "Tamam" mesajını alırsanız verileriniz eklenmiş demektir. ClickHouse'dan bir hata alırsanız bu, bunların eklenmediği ve eklemeyi tekrarlamanız gerektiği anlamına gelir. Ancak ekleme sırasında bağlantı kesilirse verinin eklenip eklenmediğini bilemezsiniz. Tek seçenek ekleme işlemini tekrarlamaktır. Veriler gerçekten eklenmişse ve siz yeniden eklediyseniz blok tekilleştirme söz konusudur. Yinelemeleri önlemek için bu gereklidir.
Ayrıca somutlaştırılmış görüşler için nasıl çalıştığı da önemlidir. Veriler ana tabloya eklendiğinde tekilleştirilmişse, bu durumda materyalleştirilmiş görünüme de gitmeyecektir.
Şimdi soru hakkında. Durumunuz daha karmaşık çünkü tek tek satırların kopyalarını kaydediyorsunuz. Yani, kopyalanan paketin tamamı değil, belirli çizgilerdir ve arka planda çökerler. Aslında veriler ana tabloda çökecek, ancak daraltılmamış veriler materyalleştirilmiş görünüme gidecek ve birleştirme sırasında materyalize edilmiş görünümlere hiçbir şey olmayacak. Çünkü somutlaştırılmış bir görünüm, bir ekleme tetikleyicisinden başka bir şey değildir. Diğer işlemler sırasında ona ek bir şey olmuyor.
Ve seni burada mutlu edemem. Bu durum için özel bir çözüm aramanız yeterli. Örneğin, materyalleştirilmiş bir görünümde yeniden oynatmak mümkün mü ve veri tekilleştirme yöntemi aynı şekilde çalışabilir. Ama ne yazık ki her zaman değil. Eğer toplama yapılıyorsa işe yaramaz.
Kirill Shvakov: Eskiden koltuk değneği yapımımız da vardı. Reklam gösterimlerinin olmasıyla ilgili bir sorun vardı ve gerçek zamanlı olarak gösterebileceğimiz bazı veriler vardı; bunlar yalnızca gösterimlerdi. Nadiren kopyalanırlar, ancak bu durumda onları daha sonra çökerteceğiz. Ve kopyalanamayan şeyler vardı; tıklamalar ve tüm bu hikaye. Ama aynı zamanda onlara hemen göstermek istedim.
Gerçekleşen görüşler nasıl yapıldı? Doğrudan yazıldığı görünümler vardı - ham verilere yazıldı ve görünümlere yazıldı. Orada, bir noktada veriler pek doğru olmuyor, kopyalanıyor vb. Ve tablonun, somutlaştırılmış görüşlerle tamamen aynı göründükleri, yani yapı olarak kesinlikle aynı oldukları ikinci bir kısmı var. Arada bir verileri yeniden hesaplıyoruz, verileri kopya olmadan sayıyoruz, o tablolara yazıyoruz.
API'yi inceledik - bu, ClickHouse'da manuel olarak çalışmayacaktır. Ve API şöyle görünüyor: tabloya son ekleme tarihini aldığımda, burada doğru verilerin zaten hesaplandığı garanti ediliyor ve bir tabloya ve başka bir tabloya istekte bulunuyor. İstek, birinden belirli bir süreye kadar seçim yapar ve diğerinden henüz hesaplanmamış olanı alır. Ve işe yarıyor ama yalnızca ClickHouse aracılığıyla değil.
Analistler için, kullanıcılar için bir tür API'niz varsa, o zaman prensipte bu bir seçenektir. Her zaman sayıyorsun, her zaman sayıyorsun. Bu, günde bir kez veya başka bir zamanda yapılabilir. İhtiyacınız olmayan ve kritik olmayan bir aralığı kendiniz seçersiniz.
ClickHouse'un çok sayıda günlüğü var. Sunucuda olup biten her şeyi bir bakışta nasıl görebilirim?
ClickHouse'un çok sayıda farklı log'u var ve bu sayı giderek artıyor. Yeni sürümlerde bunlardan bazıları varsayılan olarak etkindir; eski sürümlerde ise güncelleme sırasında etkinleştirilmeleri gerekir. Ancak sayıları giderek artıyor. Son olarak, şu anda sunucumda neler olup bittiğini, belki bir tür özet kontrol panelinde görmek isterim.
Bu günlükleri bitmiş ürün olarak görüntüleyecek hazır kontrol panellerinin bazı işlevlerini destekleyen bir ClickHouse ekibiniz veya arkadaşlarınızın ekipleri var mı? Sonuçta, ClickHouse'daki günlüklere bakmak bile harika. Ancak zaten bir gösterge paneli şeklinde hazırlanmış olsaydı çok güzel olurdu. Bundan büyük keyif alırdım.
Standartlaştırılmamış olsalar da gösterge tabloları vardır. Şirketimizde yaklaşık 60 ekip ClickHouse kullanıyor ve en tuhafı da çoğunun kendileri için yaptıkları ve biraz farklı gösterge tablolarına sahip olmaları. Bazı ekipler dahili bir Yandex.Cloud kurulumu kullanır. Gerekli olanların hepsi olmasa da bazı hazır raporlar var. Diğerlerinin kendilerine ait.
Metrica'daki meslektaşlarımın Grafana'da kendi kontrol panelleri var ve benim de onların kümeleri için kendi kontrol panelim var. Serif önbelleği için önbellek isabeti gibi şeylere bakıyorum. Daha da zoru farklı araçlar kullanmamızdır. Kontrol panelimi Graphite-web adlı çok eski bir aracı kullanarak oluşturdum. O tamamen çirkin. Ve hala bu şekilde kullanıyorum, ancak Grafana muhtemelen daha kullanışlı ve güzel olurdu.
Gösterge tablolarındaki temel şey aynıdır. Bunlar kümeye ilişkin sistem ölçümleridir: CPU, bellek, disk, ağ. Diğerleri - eşzamanlı istek sayısı, eşzamanlı birleştirme sayısı, saniye başına istek sayısı, MergeTree tablo bölümleri için maksimum parça sayısı, çoğaltma gecikmesi, çoğaltma sırası boyutu, saniye başına eklenen satır sayısı, saniye başına eklenen blok sayısı. Günlüklerden değil, metriklerden elde edilenlerin hepsi budur.
Vladimir Kolobaev: Alexey, biraz düzeltmek istiyorum. Grafana var. Grafana'nın ClickHouse adında bir veri kaynağı var. Yani Grafana'dan direkt olarak ClickHouse'a talepte bulunabiliyorum. ClickHouse'un logları olan bir tablosu var, herkes için aynı. Sonuç olarak Grafana'daki bu log tablosuna erişip sunucumun yaptığı istekleri görmek istiyorum. Böyle bir kontrol paneline sahip olmak harika olurdu.
Kendim bisiklete bindim. Ancak bir sorum var: Eğer her şey standartsa ve Grafana herkes tarafından kullanılıyorsa, neden Yandex'in böyle resmi bir kontrol paneli yok?
Kirill Shvakov: Aslında ClickHouse'a giden veri kaynağı artık Altinity'yi destekliyor. Ve ben sadece nereyi kazacağımı ve kimi iteceğimi gösteren bir vektör vermek istiyorum. Onlara sorabilirsiniz, çünkü Yandex hâlâ ClickHouse'u yapıyor, etrafındaki hikayeyi değil. Altinity, şu anda ClickHouse'u destekleyen ana şirkettir. Onu bırakmayacaklar ama destekleyecekler. Çünkü prensip olarak Grafana web sitesine bir kontrol paneli yüklemek için yalnızca kaydolmanız ve yüklemeniz yeterlidir - özel bir sorun yoktur.
Alexey Milovidov: Geçen yıl ClickHouse birçok sorgu profili oluşturma özelliği ekledi. Kaynak kullanımına ilişkin her istek için ölçümler vardır. Ve kısa bir süre önce, bir sorgunun her milisaniyede nerede harcadığını görmek için daha da düşük düzeyde bir sorgu profili oluşturucu ekledik. Ancak bu işlevi kullanmak için konsol istemcisini açmam ve bir istek yazmam gerekiyor ki bunu her zaman unutuyorum. Onu bir yere kaydettim ve tam olarak nerede olduğunu unutup duruyorum.
Keşke şunu söyleyen bir araç olsaydı: İşte ağır sorgularınız, sorgu sınıfına göre gruplandırılmış. Birine bastım ve bana bu yüzden ağır olduğunu söylediler. Şimdilik böyle bir çözüm yok. Ve insanlar bana "Söyle bana, Grafana için hazır kontrol panelleri var mı?" diye sorduklarında şunu söylemem gerçekten çok garip: "Grafana web sitesine gidin, bir "Kontrol Panelleri" topluluğu var ve bir kontrol paneli var Dimka'dan Kostyan'dan bir gösterge paneli var. Ne olduğunu bilmiyorum, kendim kullanmadım.”
Sunucunun OOM'a çarpmaması için birleştirmeler nasıl etkilenebilir?
Bir masam var, tabloda yalnızca bir bölüm var, o da ReplacingMergeTree. Dört yıldır ona veri yazıyorum. Üzerinde bir değişiklik yapmam ve bazı verileri silmem gerekiyordu.
Bunu yaptım ve bu isteğin işlenmesi sırasında kümedeki tüm sunuculardaki tüm bellekler tükendi ve kümedeki tüm sunucular OOM'a girdi. Sonra hep birlikte ayağa kalktılar, aynı işlemi, bu veri bloğunu birleştirmeye başladılar ve tekrar OOM'a düştüler. Sonra tekrar kalktılar ve tekrar düştüler. Ve bu şey durmadı.
Sonra bunun aslında adamların düzelttiği bir hata olduğu ortaya çıktı. Bu çok hoş, çok teşekkür ederim. Ama bir kalıntı kaldı. Ve şimdi, tabloda bir tür birleştirme yapmayı düşündüğümde bir sorum var: neden bu birleştirmeleri bir şekilde etkileyemiyorum? Örneğin, bunları gerekli RAM miktarına veya prensip olarak bu özel tabloyu işleyecek miktara göre sınırlayın.
"Metrics" adında bir tablom var, lütfen bunu benim için iki başlıkta işleyin. Paralel olarak on veya beş birleştirme oluşturmaya gerek yok, bunu ikiye yapın. İkiye yetecek kadar hafızam olduğunu düşünüyorum ama on tanesini işlemeye yetmeyebilir. Neden korku devam ediyor? Çünkü tablo büyüyor ve bir gün, prensipte artık bir hatadan kaynaklanmayan, veriler o kadar büyük miktarda değişeceğinden ve üzerinde yeterli hafızamın olmayacağı bir durumla karşı karşıya kalacağım. sunucu. Ve sonra sunucu, birleştirme sırasında OOM'a çarpacaktır. Üstelik mutasyonu iptal edebilirim ama Merji artık orada değil.
Biliyorsunuz, birleştirme sırasında sunucu OOM'a düşmeyecektir, çünkü birleştirme sırasında RAM miktarı yalnızca küçük bir veri aralığı için kullanılır. Yani veri miktarı ne olursa olsun her şey yoluna girecek.
Vladimir Kolobaev: İyi. İşte o an öyle ki, hata giderildikten sonra kendim için yeni bir sürüm indirdim ve çok sayıda bölümün olduğu daha küçük bir başka masada benzer bir işlem gerçekleştirdim. Ve birleştirme sırasında sunucuya yaklaşık 100 GB RAM yakıldı. 150'si işgal edildi, 100'ü yenildi ve 50 GB'lık bir pencere kaldı, bu yüzden OOM'a düşmedim.
Gerçekten 100 GB RAM tüketiyorsa beni OOM'a düşmekten koruyan şey şu anda nedir? Birleştirmelerdeki RAM aniden biterse ne yapmalı?
Alexey Milovidov: Öyle bir sorun var ki, özellikle birleştirmeye yönelik RAM tüketimi sınırlı değil. İkinci sorun ise, eğer bir tür birleştirme atanmışsa, çoğaltma günlüğüne kaydedildiği için bunun yürütülmesi gerekir. Çoğaltma günlüğü, çoğaltmayı tutarlı bir duruma getirmek için gereken eylemlerdir. Bu çoğaltma günlüğünü geri alacak manuel manipülasyonlar yapmazsanız, birleştirmenin öyle ya da böyle gerçekleştirilmesi gerekecektir.
Elbette “her ihtimale karşı” OOM'a karşı koruma sağlayan bir RAM sınırlamasına sahip olmak gereksiz olmayacaktır. Birleşmenin tamamlanmasına yardımcı olmayacak, yeniden başlayacak, bir eşiğe ulaşacak, bir istisna atacak ve sonra yeniden başlayacak - bundan iyi bir şey çıkmayacak. Ancak prensip olarak bu kısıtlamanın getirilmesi faydalı olacaktır.
ClickHouse için Golang sürücüsü nasıl geliştirilecek?
Kirill Shvakov tarafından yazılan Golang sürücüsü artık resmi olarak ClickHouse ekibi tarafından destekleniyor. O O artık büyük ve gerçek.
Küçük bir not. Sonsuz düzenin normal formlarının harika ve sevilen bir deposu var - bu Vertica. Ayrıca Vertica geliştiricileri tarafından desteklenen kendi resmi python sürücülerine de sahiptirler. Ve birkaç kez, depolama sürümleri ile sürücü sürümlerinin oldukça farklılaştığı ve sürücünün bir noktada çalışmayı bıraktığı durumlar yaşandı. Ve ikinci nokta. Bana öyle geliyor ki, bu resmi sürücünün desteği "meme ucu" sistemi tarafından gerçekleştiriliyor - onlara bir sorun yazıyorsunuz ve bu sonsuza kadar askıda kalıyor.
İki sorum var. Artık Kirill'in Golang sürücüsü Golang'dan ClickHouse ile iletişim kurmanın neredeyse varsayılan yoludur. Birisi hala http arayüzü üzerinden iletişim kurmuyorsa çünkü bu şekilde seviyor. Bu sürücünün gelişimi nasıl ilerleyecek? Deponun kendisinde meydana gelen herhangi bir değişiklikle senkronize edilecek mi? Peki bir konuyu değerlendirme prosedürü nedir?
Kirill Shvakov: Birincisi her şeyin bürokratik olarak organize edilmesi. Bu konu tartışılmadı, dolayısıyla cevaplayacak hiçbir şeyim yok.
Sorunla ilgili soruyu cevaplamak için sürücünün küçük bir geçmişine ihtiyacımız var. Çok fazla veriye sahip bir şirkette çalıştım. Bir yerde saklanması gereken çok sayıda etkinliğe sahip bir reklam döndürücüydü. Ve bir noktada ClickHouse ortaya çıktı. Onu verilerle doldurduk ve ilk başta her şey yolundaydı ama sonra ClickHouse çöktü. O anda buna ihtiyacımız olmadığına karar verdik.
Bir yıl sonra ClickHouse kullanma fikrine geri döndük ve oraya bir şekilde veri yazmamız gerekiyordu. Giriş mesajı şuydu: Donanım çok zayıf, kaynak çok az. Ama biz her zaman bu şekilde çalıştık ve bu nedenle yerel protokole yöneldik.
Go'da çalıştığımızdan beri bir Go sürücüsüne ihtiyacımız olduğu açıktı. Bunu neredeyse tam zamanlı olarak yaptım; bu benim iş görevimdi. Bunu belli bir noktaya getirdik ve prensipte kimse bunu bizden başkasının kullanacağını varsaymıyordu. Sonra CloudFlare tamamen aynı problemle geldi ve bir süre onlarla çok sorunsuz çalıştık çünkü aynı görevleri vardı. Üstelik bunu hem ClickHouse'da hem de sürücüde yaptık.
Bir noktada bunu yapmayı bıraktım çünkü ClickHouse ve iş açısından faaliyetlerim biraz değişti. Bu nedenle konular kapanmıyor. Periyodik olarak, kendileri de bir şeye ihtiyaç duyan insanlar depoya taahhütte bulunurlar. Sonra çekme isteğine bakıyorum ve bazen bir şeyi kendim bile düzenliyorum, ancak bu nadiren oluyor.
Şoföre dönmek istiyorum. Birkaç yıl önce, tüm bunlar başladığında ClickHouse da farklıydı ve farklı yeteneklere sahipti. Artık sürücünün iyi çalışması için nasıl yeniden oluşturulacağına dair bir anlayışa sahibiz. Böyle bir durumda, biriken koltuk değneği nedeniyle sürüm 2 her durumda uyumsuz olacaktır.
Bu konuyu nasıl organize edeceğimi bilmiyorum. Benim de fazla zamanım yok. Eğer bazı insanlar sürücünün işini bitirirse onlara yardım edip ne yapmaları gerektiğini söyleyebilirim. Ancak Yandex'in projenin geliştirilmesine aktif katılımı henüz tartışılmadı.
Alexey Milovidov: Aslında bu sürücülerle ilgili henüz bir bürokrasi yok. Tek şey resmi bir kuruluşa teslim edilmeleridir, yani bu sürücü Go için resmi varsayılan çözüm olarak kabul edilmektedir. Başka sürücüler de var ama ayrı ayrı geliyorlar.
Bu sürücülere yönelik dahili bir geliştirmemiz yok. Soru şu: Bu özel sürücü için değil, tüm topluluk sürücülerinin gelişimi için bireysel bir kişiyi işe alabilir miyiz, yoksa dışarıdan birini bulabilir miyiz?
Lazy_load ayarı etkinken yeniden başlatmanın ardından harici sözlük yüklenmiyor. Ne yapalım?
Lazy_load ayarını etkinleştirdik ve sunucu yeniden başlatıldıktan sonra sözlük kendi kendine yüklenmiyor. Yalnızca kullanıcı bu sözlüğe eriştikten sonra oluşturulur. Ve ilk girdiğimde hata veriyor. ClickHouse'u kullanarak sözlükleri bir şekilde otomatik olarak yüklemek mümkün mü, yoksa kullanıcıların hata almaması için sözlüklerin hazır olup olmadığını her zaman kendiniz kontrol etmeniz mi gerekiyor?
Belki de ClickHouse'un eski bir sürümüne sahibiz, dolayısıyla sözlük otomatik olarak yüklenmedi. Durum böyle olabilir mi?
İlk olarak, sözlükler bir sorgu kullanılarak zorlanabilir sistem sözlüklerini yeniden yükle. İkincisi, hatayla ilgili olarak - sözlük zaten yüklüyse, sorgular yüklenen verilere göre çalışacaktır. Sözlük henüz yüklenmemişse istek sırasında doğrudan yüklenecektir.
Bu, ağır sözlükler için pek uygun değildir. Örneğin MySQL'den bir milyon satır çekmeniz gerekiyor. Birisi basit bir seçim yapıyor ama bu seçim aynı milyon satırı bekleyecek. Burada iki çözüm var. Birincisi lazy_load'ı kapatmaktır. İkinci olarak, sunucu açıkken, yükü ona yüklemeden önce şunları yapın: sistem sözlüğünü yeniden yükle veya yalnızca sözlük kullanan bir sorgu yapın. Daha sonra sözlük yüklenecektir. ClickHouse sözlükleri otomatik olarak yüklemediğinden, lazy_load ayarı etkinken sözlüklerin kullanılabilirliğini kontrol etmeniz gerekir.
Son sorunun cevabı ya sürüm eski ya da hata ayıklanması gerekiyor.
En az biri bir hatayla çökerse, sistem yeniden yükleme sözlüklerinin birçok sözlükten hiçbirini yüklememesi gerçeğiyle ne yapmalı?
Sistem yeniden yükleme sözlükleriyle ilgili başka bir soru daha var. İki sözlüğümüz var - biri yüklü değil, ikincisi yüklü. Bu durumda, Sistem yeniden yükleme sözlükleri herhangi bir sözlük yüklemez ve sistem yeniden yükleme sözlüğünü kullanarak belirli bir sözlüğü adına göre nokta nokta yüklemeniz gerekir. Bu aynı zamanda ClickHouse sürümüyle de alakalı mı?
Seni mutlu etmek istiyorum. Bu davranışı değişiyordu. Bu, ClickHouse'u güncellerseniz onun da değişeceği anlamına gelir. Şu andaki davranışınızdan memnun değilseniz sistem sözlüklerini yeniden yükle, güncelleyin ve daha iyiye doğru değişeceğini umalım.
ClickHouse yapılandırmasında ayrıntıları yapılandırmanın, ancak hata durumunda bunları görüntülememenin bir yolu var mı?
Bir sonraki soru sözlükle ilgili hatalar yani detaylarla ilgili. Sözlük için ClickHouse config'de bağlantı detaylarını belirttik ve hata olması durumunda bu detayları ve şifreyi yanıt olarak alıyoruz.
Bu hatayı ODBC sürücüsü yapılandırmasına ayrıntılar ekleyerek çözdük. ClickHouse yapılandırmasındaki ayrıntıları yapılandırmanın ancak hata durumunda bu ayrıntıları göstermemenin bir yolu var mı?
Buradaki gerçek çözüm, bu kimlik bilgilerini odbc.ini'de belirtmek ve ClickHouse'un kendisinde yalnızca ODBC Veri Kaynağı Adını belirtmektir. Bu, diğer sözlük kaynakları için gerçekleşmeyecek - ne MySQL'li sözlük için ne de diğerleri için, bir hata mesajı aldığınızda şifreyi görmemelisiniz. ODBC için de bakacağım - eğer varsa, onu kaldırmanız yeterli.
Bonus: Toplantılardan Zoom için arka planlar
Resme tıkladığınızda, en ısrarcı okuyucular için toplantılardan bonus arka planlar açılacaktır. Avito teknoloji maskotlarıyla birlikte yangını söndürüyoruz, sistem yöneticisi odasındaki veya eski tarz bilgisayar kulübündeki meslektaşlarımızla konuşuyoruz ve grafiti fonunda köprünün altında günlük toplantılar gerçekleştiriyoruz.
Kaynak: habr.com