Yandex tarafından oluşturulan çevrimiçi analitik sorgu işleme (OLAP) için açık kaynaklı bir sütunlu veritabanı yönetim sistemidir. Yandex, CloudFlare, VK.com, Badoo ve dünya çapındaki diğer hizmetler tarafından gerçekten büyük miktarlarda veri depolamak için kullanılır (saniyede binlerce satırın eklenmesi veya diskte depolanan petabaytlarca veri).
Örnekleri MySQL, Postgres, MS SQL Server olan normal bir "string" DBMS'de veriler şu sırayla saklanır:
Bu durumda bir satıra ilişkin değerler fiziksel olarak yan yana saklanır. Sütunlu DBMS'de, farklı sütunlardaki değerler ayrı ayrı depolanır ve bir sütunun verileri birlikte depolanır:
Sütunlu DBMS örnekleri Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+'dır.
Şirket bir posta ileticisidir Raporlama için Clickhouse'u 2018'de kullanmaya başladım ve basitliğinden, ölçeklenebilirliğinden, SQL desteğinden ve hızından çok etkilendim. Bu DBMS'nin hızı büyü sınırındaydı.
Kolaylaştırmak
Clickhouse tek komutla Ubuntu'ya kurulur. Eğer SQL biliyorsanız ihtiyaçlarınız için Clickhouse’u hemen kullanmaya başlayabilirsiniz. Ancak bu, MySQL'de "tablo oluşturmayı gösterebileceğiniz" ve Clickhouse'da SQL'i kopyalayıp yapıştırabileceğiniz anlamına gelmez.
MySQL ile karşılaştırıldığında, bu DBMS'deki tablo şeması tanımlarında önemli veri türü farklılıkları vardır, bu nedenle tablo şeması tanımlarını değiştirmek ve rahat olabilmek için tablo motorlarını öğrenmek için hala biraz zamana ihtiyacınız var.
Clickhouse herhangi bir ek yazılım gerektirmeden harika çalışır, ancak çoğaltmayı kullanmak istiyorsanız ZooKeeper'ı yüklemeniz gerekir. Sorgu performansı analizi mükemmel sonuçlar verir - sistem tabloları tüm bilgileri içerir ve tüm veriler eski ve sıkıcı SQL kullanılarak elde edilebilir.
Proizvoditelnost
- Yapılandırma sunucusunda Clickhouse ile Vertica ve MySQL karşılaştırmaları: iki soket Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz; 128 GiB RAM; 5 8 TB SATA HDD'de md RAID-6, ext4.
- Clickhouse'un Amazon RedShift bulut depolama alanıyla karşılaştırılması.
- Blogdan alıntılar :
ClickHouse veritabanı çok basit bir tasarıma sahiptir; kümedeki tüm düğümler aynı işlevselliğe sahiptir ve koordinasyon için yalnızca ZooKeeper'ı kullanır. Birkaç düğümden oluşan küçük bir küme oluşturduk ve testler gerçekleştirdik; bu sırada sistemin oldukça etkileyici bir performansa sahip olduğunu gördük; bu, analitik DBMS kıyaslamalarında iddia edilen avantajlara karşılık geliyor. ClickHouse'un arkasındaki konsepte daha yakından bakmaya karar verdik. Araştırmanın önündeki ilk engel, araçların eksikliği ve ClickHouse'un küçük topluluğuydu, bu yüzden nasıl çalıştığını anlamak için bu DBMS'nin tasarımını derinlemesine inceledik.
ClickHouse sadece bir veritabanı olduğu için doğrudan Kafka'dan veri almayı desteklemiyor, bu yüzden Go'da kendi adaptör hizmetimizi yazdık. Kafka'dan Cap'n Proto kodlu mesajları okudu, bunları TSV'ye dönüştürdü ve HTTP arayüzü aracılığıyla toplu olarak ClickHouse'a ekledi. Daha sonra performansı artırmak için Go kitaplığını kendi ClickHouse arayüzümüzle birlikte kullanacak şekilde bu hizmeti yeniden yazdık. Paket alma performansını değerlendirirken önemli bir şey keşfettik - ClickHouse için bu performansın büyük ölçüde paketin boyutuna, yani aynı anda eklenen satır sayısına bağlı olduğu ortaya çıktı. Bunun neden olduğunu anlamak için ClickHouse'un verileri nasıl sakladığını inceledik.
Ana motor veya daha doğrusu ClickHouse tarafından veri depolamak için kullanılan tablo motorları ailesi MergeTree'dir. Bu motor kavramsal olarak Google BigTable veya Apache Cassandra'da kullanılan LSM algoritmasına benzer, ancak bir ara bellek tablosu oluşturmaktan kaçınır ve verileri doğrudan diske yazar. Bu, eklenen her paketin yalnızca "birincil anahtar" birincil anahtarına göre sıralanması, sıkıştırılması ve bir bölüm oluşturmak üzere diske yazılması nedeniyle mükemmel yazma verimi sağlar.
Bellek tablosunun veya verilerin "tazeliği" kavramının bulunmaması, bunların yalnızca eklenebileceği anlamına gelir, sistem değiştirmeyi veya silmeyi desteklemez. Bugün itibarıyla verileri silmenin tek yolu, segmentlerin hiçbir zaman ay sınırını aşmaması nedeniyle verileri takvim ayına göre silmektir. ClickHouse ekibi bu özelliği özelleştirilebilir hale getirmek için aktif olarak çalışıyor. Öte yandan, bölümlerin yazılmasını ve birleştirilmesini sorunsuz hale getirir, böylece G/Ç veya çekirdekler dolana kadar aktarım hızı paralel eklerin sayısıyla doğrusal olarak ölçeklenir.
Ancak bu durum aynı zamanda sistemin küçük paketler için uygun olmadığı anlamına da gelir ve ara belleğe alma için Kafka servisleri ve yerleştiriciler kullanılır. Dahası, ClickHouse arka planda bölümleri sürekli olarak birleştirmeye devam ediyor, böylece birçok küçük bilgi parçası daha fazla kez birleştirilip kaydedilecek, böylece kayıt yoğunluğu artacak. Bununla birlikte, çok fazla ilgisiz parça, birleştirme devam ettiği sürece kesici uçların agresif bir şekilde daraltılmasına neden olacaktır. Gerçek zamanlı veri alımı ile alım performansı arasındaki en iyi uzlaşmanın, tabloya saniyede sınırlı sayıda ekleme kabul edilmesi olduğunu bulduk.
Tablo okuma performansının anahtarı, verilerin diskteki dizine eklenmesi ve konumudur. İşleme ne kadar hızlı olursa olsun, motorun terabaytlarca veriyi diskten taraması ve bunun yalnızca bir kısmını kullanması gerektiğinde, bu zaman alacaktır. ClickHouse bir sütun deposudur, dolayısıyla her segment, her sütun (sütun) için, her satır için sıralanmış değerleri içeren bir dosya içerir. Böylece, sorguda bulunmayan tüm sütunlar önce atlanabilir, ardından vektörize yürütme ile birden fazla hücre paralel olarak işlenebilir. Tam taramayı önlemek için her bölümün küçük bir dizin dosyası vardır.
Tüm sütunların "birincil anahtara" göre sıralandığı göz önüne alındığında, dizin dosyası yalnızca her N'inci satırın etiketlerini (yakalanan satırları) içerir, böylece çok büyük tablolar için bile bunları bellekte tutabilirsiniz. Örneğin, varsayılan ayarları "her 8192'inci satırı işaretlemek" ve ardından 1 trilyonluk bir tablonun "yetersiz" indekslenmesi olarak ayarlayabilirsiniz. belleğe kolayca sığan satırlar yalnızca 122 karakter alır.
Sistem Geliştirme
Clickhouse'un gelişimi ve iyileştirilmesi şu adreste takip edilebilir: ve “büyüme” sürecinin etkileyici bir hızla ilerlediğinden emin olun.
Popülerlik
Görünüşe göre Clickhouse'un popülaritesi özellikle Rusça konuşan toplulukta katlanarak artıyor. Geçen yılki High load 2018 konferansı (Moskova, 8-9 Kasım 2018), vk.com ve Badoo gibi canavarların on binlerce sunucudan aynı anda veri (örneğin günlükler) ekleyen Clickhouse'u kullandığını gösterdi. 40 dakikalık bir videoda . Yakında materyalle çalışmanın rahatlığı için transkripti Habr'da yayınlayacağız.
uygulamaları
Araştırmaya biraz zaman ayırdıktan sonra, ClickHouse'un yararlı olabileceği veya MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot ve gibi diğer daha geleneksel ve popüler çözümlerin tamamen yerini alabileceği alanlar olduğunu düşünüyorum. Druid. Yukarıdaki DBMS'yi yükseltmek veya tamamen değiştirmek için ClickHouse'u kullanmanın ayrıntıları aşağıdadır.
MySQL ve PostgreSQL'i genişletme
Son zamanlarda haber bülteni platformu için MySQL'i kısmen ClickHouse ile değiştirdik . Sorun, MySQL'in kötü tasarlanmış tasarımı nedeniyle gönderilen her e-postayı ve bu e-postadaki her bağlantıyı bir base64 karma değeriyle kaydetmesi ve devasa bir MySQL tablosu (email_stats) oluşturmasıydı. Hizmetin abonelerine yalnızca 10 milyon e-posta gönderdikten sonra bu tablo 150 GB dosya alanı kapladı ve MySQL basit sorgularda "aptal" olmaya başladı. Dosya alanı sorununu düzeltmek için InnoDB tablo sıkıştırmasını başarıyla kullandık ve bu da sorunu 4 kat azalttı. Ancak, sırf geçmişi okumak adına MySQL'de 20-30 milyondan fazla e-postayı depolamak yine de mantıklı değil, çünkü herhangi bir nedenle tam tarama yapmak zorunda kalan herhangi bir basit sorgu, takas ve ağır G/Ç ile sonuçlanır. Zabbix uyarılarını düzenli olarak aldığımız genel gider.
Clickhouse, veri miktarını yaklaşık olarak azaltan iki sıkıştırma algoritması kullanır ancak bu özel durumda veriler özellikle "sıkıştırılabilirdi".
ELK'nin Değiştirilmesi
Kendi deneyimlerime dayanarak, ELK yığınının (ElasticSearch, Logstash ve Kibana, bu özel durumda ElasticSearch) çalıştırılması, günlüklerin saklanması için gerekenden çok daha fazla kaynağa ihtiyaç duyuyor. İyi bir tam metin günlük araması istiyorsanız ElasticSearch harika bir motordur (ki buna gerçekten ihtiyacınız olduğunu düşünmüyorum), ancak bunun neden fiili standart günlük kaydı motoru haline geldiğini merak ediyorum. Logstash ile birleşen alım performansı, oldukça hafif iş yüklerinde bile bize sorun yaşattı ve giderek daha fazla RAM ve disk alanı eklenmesini gerektirdi. Bir veritabanı olarak Clickhouse, aşağıdaki nedenlerden dolayı ElasticSearch'ten daha iyidir:
- SQL lehçesi desteği;
- Saklanan verilerin en iyi sıkıştırma derecesi;
- Tam metin araması yerine Regex araması desteği;
- Geliştirilmiş sorgu zamanlaması ve daha iyi genel performans.
Şu anda ClickHouse'u ELK ile karşılaştırırken ortaya çıkan en büyük sorun, günlüklerin yüklenmesine yönelik çözümlerin eksikliği ve bu konuyla ilgili belge ve eğitimlerin eksikliğidir. Aynı zamanda her kullanıcı Digital Ocean kılavuzunu kullanarak ELK kurulumunu gerçekleştirebilir ki bu da bu tür teknolojilerin hızlı bir şekilde hayata geçirilmesi açısından oldukça önemlidir. Burada bir veritabanı motoru var ancak ClickHouse için henüz Filebeat yok. Evet var ve günlüklerle çalışmak için bir sistem , bir araç var Günlük dosyası verilerini ClickHouse'a girmek için, ancak tüm bunlar daha fazla zaman alır. Ancak ClickHouse basitliği nedeniyle hala öncülük ediyor, böylece yeni başlayanlar bile kolayca kurabilir ve yalnızca 10 dakika içinde tam işlevsel kullanıma başlayabilir.
Minimalist çözümleri tercih ederek, Kafka kullanmaktan kaçınmaya çalışırken, hafızası oldukça düşük bir log yükleme aracı olan FluentBit'i ClickHouse ile kullanmaya çalıştım. Bununla birlikte, aşağıdaki gibi küçük uyumsuzlukların giderilmesi gerekir: verileri FluentBit'ten ClickHouse'a dönüştüren proxy katmanı olmadan yapılabilir.
Kibana'ya alternatif olarak ClickHouse'u arka uç olarak kullanabilirsiniz. . Anladığım kadarıyla bu, özellikle Grafana'nın eski sürümlerinde çok sayıda veri noktasının işlenmesi sırasında performans sorunlarına neden olabiliyor. Qwintry'de bunu henüz denemedik ancak Telegram'daki ClickHouse destek kanalında zaman zaman bununla ilgili şikayetler ortaya çıkıyor.
Google Big Query ve Amazon RedShift'in değiştirilmesi (büyük şirketler için çözüm)
BigQuery için ideal kullanım örneği, 1 TB JSON verisi yüklemek ve üzerinde analitik sorgular çalıştırmaktır. Big Query, ölçeklenebilirliği abartılması zor olan harika bir üründür. Bu, dahili bir kümede çalışan ClickHouse'dan çok daha karmaşık bir yazılımdır, ancak müşterinin bakış açısından ClickHouse ile pek çok ortak noktası vardır. BigQuery, her bir SELECT için ödeme yapmaya başladığınızda hızla "fiyatlandırabilir"; dolayısıyla tüm artıları ve eksileriyle birlikte gerçek bir SaaS çözümüdür.
Hesaplama açısından pahalı birçok sorgu çalıştırdığınızda ClickHouse en iyi seçimdir. Her gün ne kadar çok SELECT sorgusu çalıştırırsanız, Big Query'yi ClickHouse ile değiştirmek o kadar mantıklı olur, çünkü böyle bir değiştirme, işlenen terabaytlarca veri söz konusu olduğunda size binlerce dolar tasarruf sağlayacaktır. Bu, Big Query'de işlenmesi oldukça ucuz olan depolanan veriler için geçerli değildir.
Altinity'nin kurucu ortağı Alexander Zaitsev'in bir makalesinde böyle bir DBMS geçişinin faydalarını açıklamaktadır.
Zaman ÖlçeğiDB Değişimi
TimescaleDB, normal bir veritabanındaki zaman serileriyle çalışmayı optimize eden bir PostgreSQL uzantısıdır (, ).
ClickHouse, zaman serisi alanında ciddi bir rakip olmasa da sütunlu yapı ve vektör sorgu yürütme açısından analitik sorguların işlenmesinde çoğu durumda TimescaleDB'den çok daha hızlıdır. Aynı zamanda ClickHouse paket verilerini alma performansı yaklaşık 3 kat daha yüksektir, ayrıca 20 kat daha az disk alanı kullanır, bu da büyük hacimli geçmiş verileri işlemek için gerçekten önemlidir: .
ClickHouse'un aksine TimescaleDB'de disk alanından tasarruf etmenin tek yolu ZFS veya benzeri dosya sistemlerini kullanmaktır.
ClickHouse'a gelecek güncellemeler muhtemelen delta sıkıştırmayı tanıtacak ve bu da onu zaman serisi verilerinin işlenmesi ve depolanması için daha da uygun hale getirecek. TimescaleDB aşağıdaki durumlarda çıplak ClickHouse'dan daha iyi bir seçim olabilir:
- çok az RAM'e (<3 GB) sahip küçük kurulumlar;
- büyük parçalara tamponlamak istemediğiniz çok sayıda küçük INSERT;
- daha iyi tutarlılık, tekdüzelik ve ASİT gereksinimleri;
- PostGIS desteği;
- Timescale DB aslında PostgreSQL olduğundan mevcut PostgreSQL tablolarıyla birleşir.
Hadoop ve MapReduce sistemleriyle rekabet
Hadoop ve diğer MapReduce ürünleri çok sayıda karmaşık hesaplama gerçekleştirebilir, ancak büyük gecikmelerle çalışma eğilimindedirler. ClickHouse, terabaytlarca veriyi işleyerek ve neredeyse anında sonuç üreterek bu sorunu çözer. Böylece ClickHouse, veri bilimcilerin ilgisini çekmesi gereken hızlı, etkileşimli analitik araştırmaları gerçekleştirmek için çok daha verimlidir.
Pinot ve Druid ile rekabet
ClickHouse'un en yakın rakipleri sütunlu, doğrusal olarak ölçeklenebilir açık kaynaklı ürünler Pinot ve Druid'dir. Makalede bu sistemleri karşılaştıran mükemmel bir çalışma yayınlandı 1 Şubat 2018
Bu makalenin güncellenmesi gerekiyor - ClickHouse'un UPDATE ve DELETE işlemlerini desteklemediğini söylüyor ve bu, en son sürümlerle ilgili olarak tamamen doğru değil.
Bu DBMS'lerle ilgili pek deneyimimiz yok, ancak Druid ve Pinot'u çalıştırmak için gereken temel altyapının karmaşıklığından hoşlanmıyorum - bu, her tarafı Java ile çevrelenmiş bir sürü "hareketli parçadan" oluşuyor.
Druid ve Pinot, Apache'nin GitHub proje sayfalarında ayrıntılı olarak ele alınan Apache kuluçka projeleridir. Pinot Ekim 2018'de kuluçka makinesinde ortaya çıktı ve Druid 8 ay önce Şubat ayında doğdu.
AFS'nin nasıl çalıştığına dair bilgi eksikliği benim için bazı ve belki de aptalca soruları gündeme getiriyor. Pinot'un yazarlarının Apache Vakfı'nın Druid'e daha yatkın olduğunu fark edip etmediklerini merak ediyorum ve bir rakibe karşı böyle bir tutum kıskançlık duygusuna neden oldu mu? Druid'in gelişimi yavaşlayıp Pinot'un gelişimi hızlanır mı? Druid'i destekleyen sponsorlar aniden ikincisine ilgi duymaya başlarsa, Pinot'un gelişimi hızlanır mı?
ClickHouse'un dezavantajları
Olgunlaşmamışlık: Açıkçası bu hala sıkıcı bir teknoloji, ancak her halükarda diğer sütunlu DBMS'lerde buna benzer bir şey görülmüyor.
Küçük kesici uçlar yüksek hızda iyi performans göstermez: küçük kesici uçların performansı her satırdaki sütun sayısıyla orantılı olarak düştüğü için kesici uçların büyük parçalara bölünmesi gerekir. ClickHouse verileri diskte bu şekilde depolar - her sütun 1 dosya veya daha fazlası anlamına gelir, bu nedenle 1 sütun içeren 100 satır eklemek için en az 100 dosya açıp yazmanız gerekir. Bu nedenle ekleme arabelleğe almanın bir aracıya (istemcinin kendisi arabelleğe alma sağlamadığı sürece) ihtiyaç duymasının nedeni budur - genellikle Kafka veya bir tür kuyruklama sistemi. Daha sonra büyük veri yığınlarını MergeTree tablolarına kopyalamak için Buffer tablo motorunu da kullanabilirsiniz.
Tablo birleştirmeleri sunucu RAM'i ile sınırlıdır, ancak en azından oradalar! Örneğin, Druid ve Pinot'un bu tür bağlantıları yoktur, çünkü büyük veri yığınlarının düğümler arasında taşınmasını desteklemeyen dağıtılmış sistemlerde doğrudan uygulanmaları zordur.
Bulgular
Gelecek yıllarda Qwintry'de ClickHouse'dan kapsamlı bir şekilde yararlanmayı planlıyoruz çünkü bu DBMS performans, düşük yük, ölçeklenebilirlik ve basitlik arasında mükemmel bir denge sağlıyor. ClickHouse topluluğu bunu küçük ve orta ölçekli kurulumlarda kullanmanın daha fazla yolunu bulduktan sonra hızla yayılacağına eminim.
Bazı reklamlar 🙂
Bizimle kaldığın için teşekkürler. Yazılarımızı beğeniyor musunuz? Daha ilginç içerik görmek ister misiniz? Sipariş vererek veya arkadaşlarınıza tavsiye ederek bize destek olun, , sizin için bizim tarafımızdan icat edilen benzersiz bir giriş seviyesi sunucu analoğu: (RAID1 ve RAID10, 24 adede kadar çekirdek ve 40 GB'a kadar DDR4 ile mevcuttur).
Amsterdam'daki Equinix Tier IV veri merkezinde Dell R730xd 2 kat daha mı ucuz? Sadece burada Hollanda'da! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 99$'dan! Hakkında oku
Kaynak: habr.com