είναι ένα σύστημα διαχείρισης βάσης δεδομένων ανοικτού κώδικα στηλών για ηλεκτρονική επεξεργασία αναλυτικών ερωτημάτων (OLAP) που δημιουργήθηκε από την Yandex. Χρησιμοποιείται από το Yandex, το CloudFlare, το VK.com, το Badoo και άλλες υπηρεσίες σε όλο τον κόσμο για την αποθήκευση πραγματικά μεγάλων ποσοτήτων δεδομένων (εισαγωγή χιλιάδων σειρών ανά δευτερόλεπτο ή petabyte δεδομένων αποθηκευμένων στο δίσκο).
Σε ένα κανονικό, "string" DBMS, παραδείγματα του οποίου είναι MySQL, Postgres, MS SQL Server, τα δεδομένα αποθηκεύονται με αυτή τη σειρά:
Σε αυτήν την περίπτωση, οι τιμές που σχετίζονται με μια σειρά αποθηκεύονται φυσικά δίπλα-δίπλα. Σε στήλη DBMS, οι τιμές από διαφορετικές στήλες αποθηκεύονται χωριστά και τα δεδομένα μιας στήλης αποθηκεύονται μαζί:
Παραδείγματα στήλης DBMS είναι τα Vertica, Paraccel (Actian Matrix, Amazon Redshift), Sybase IQ, Exasol, Infobright, InfiniDB, MonetDB (VectorWise, Actian Vector), LucidDB, SAP HANA, Google Dremel, Google PowerDrill, Druid, kdb+.
Η εταιρεία είναι μεταφορέας αλληλογραφίας Άρχισα να χρησιμοποιώ το Clickhouse το 2018 για αναφορές και εντυπωσιάστηκα πολύ με την απλότητα, την επεκτασιμότητα, την υποστήριξη SQL και την ταχύτητά του. Η ταχύτητα αυτού του DBMS συνόρευε με τη μαγεία.
Απλότητα
Το Clickhouse εγκαθιστά στο Ubuntu με μία μόνο εντολή. Εάν γνωρίζετε SQL, μπορείτε να αρχίσετε αμέσως να χρησιμοποιείτε το Clickhouse για τις ανάγκες σας. Ωστόσο, αυτό δεν σημαίνει ότι μπορείτε να "εμφανίσετε τη δημιουργία πίνακα" στη MySQL και να κάνετε αντιγραφή-επικόλληση SQL στο Clickhouse.
Σε σύγκριση με τη MySQL, υπάρχουν σημαντικές διαφορές τύπων δεδομένων στους ορισμούς των σχημάτων πινάκων σε αυτό το DBMS, επομένως χρειάζεστε ακόμα λίγο χρόνο για να αλλάξετε τους ορισμούς των σχημάτων πίνακα και να μάθετε τις μηχανές πινάκων για να νιώσετε άνετα.
Το Clickhouse λειτουργεί άψογα χωρίς πρόσθετο λογισμικό, αλλά αν θέλετε να χρησιμοποιήσετε την αναπαραγωγή, θα πρέπει να εγκαταστήσετε το ZooKeeper. Η ανάλυση απόδοσης ερωτήματος δείχνει εξαιρετικά αποτελέσματα - οι πίνακες συστήματος περιέχουν όλες τις πληροφορίες και όλα τα δεδομένα μπορούν να ληφθούν χρησιμοποιώντας παλιά και βαρετή SQL.
Παραγωγικότητα
- Συγκρίσεις Clickhouse έναντι Vertica και MySQL στον διακομιστή διαμόρφωσης: δύο υποδοχές Intel® Xeon® CPU E5-2650 v2 @ 2.60 GHz. 128 GiB RAM; md RAID-5 σε 8 6TB SATA HDD, ext4.
- σύγκριση του Clickhouse με την αποθήκευση cloud του Amazon RedShift.
- Αποσπάσματα ιστολογίου :
Η βάση δεδομένων ClickHouse έχει πολύ απλό σχεδιασμό - όλοι οι κόμβοι στο σύμπλεγμα έχουν την ίδια λειτουργικότητα και χρησιμοποιούν μόνο το ZooKeeper για συντονισμό. Δημιουργήσαμε ένα μικρό σύμπλεγμα αρκετών κόμβων και πραγματοποιήσαμε δοκιμές, κατά τις οποίες διαπιστώσαμε ότι το σύστημα έχει αρκετά εντυπωσιακή απόδοση, η οποία αντιστοιχεί στα ισχυριζόμενα πλεονεκτήματα στα αναλυτικά σημεία αναφοράς DBMS. Αποφασίσαμε να ρίξουμε μια πιο προσεκτική ματιά στην ιδέα πίσω από το ClickHouse. Το πρώτο εμπόδιο για την έρευνα ήταν η έλλειψη εργαλείων και η μικρή κοινότητα του ClickHouse, έτσι εμβαθύναμε στη σχεδίαση αυτού του DBMS για να καταλάβουμε πώς λειτουργεί.
Το ClickHouse δεν υποστηρίζει τη λήψη δεδομένων απευθείας από τον Kafka, καθώς είναι απλώς μια βάση δεδομένων, επομένως γράψαμε τη δική μας υπηρεσία προσαρμογέα στο Go. Διάβαζε μηνύματα κωδικοποιημένα από το Cap'n Proto από τον Kafka, τα μετέτρεψε σε TSV και τα εισήγαγε στο ClickHouse σε παρτίδες μέσω της διεπαφής HTTP. Αργότερα ξαναγράψαμε αυτήν την υπηρεσία για να χρησιμοποιήσουμε τη βιβλιοθήκη Go σε συνδυασμό με τη δική μας διεπαφή ClickHouse για να βελτιώσουμε την απόδοση. Κατά την αξιολόγηση της απόδοσης των πακέτων λήψης, ανακαλύψαμε ένα σημαντικό πράγμα - αποδείχθηκε ότι για το ClickHouse αυτή η απόδοση εξαρτάται σε μεγάλο βαθμό από το μέγεθος του πακέτου, δηλαδή από τον αριθμό των σειρών που εισάγονται ταυτόχρονα. Για να κατανοήσουμε γιατί συμβαίνει αυτό, μελετήσαμε πώς το ClickHouse αποθηκεύει δεδομένα.
Η κύρια μηχανή, ή μάλλον, μια οικογένεια μηχανών πίνακα που χρησιμοποιείται από το ClickHouse για την αποθήκευση δεδομένων, είναι το MergeTree. Αυτή η μηχανή είναι εννοιολογικά παρόμοια με τον αλγόριθμο LSM που χρησιμοποιείται στο Google BigTable ή στο Apache Cassandra, αλλά αποφεύγει τη δημιουργία ενός ενδιάμεσου πίνακα μνήμης και εγγράφει δεδομένα απευθείας στο δίσκο. Αυτό του δίνει εξαιρετική απόδοση εγγραφής, καθώς κάθε εισαγόμενο πακέτο ταξινομείται μόνο από το πρωτεύον κλειδί "πρωτεύον κλειδί", συμπιέζεται και γράφεται στο δίσκο για να σχηματίσει ένα τμήμα.
Η απουσία πίνακα μνήμης ή οποιασδήποτε έννοιας «φρεσκάδας» δεδομένων σημαίνει επίσης ότι μπορούν μόνο να προστεθούν, το σύστημα δεν υποστηρίζει αλλαγή ή διαγραφή. Από σήμερα, ο μόνος τρόπος για να διαγράψετε δεδομένα είναι να τα διαγράψετε ανά ημερολογιακό μήνα, καθώς τα τμήματα δεν ξεπερνούν ποτέ τα όρια ενός μήνα. Η ομάδα του ClickHouse εργάζεται ενεργά για να κάνει αυτό το χαρακτηριστικό προσαρμόσιμο. Από την άλλη πλευρά, καθιστά το γράψιμο και τη συγχώνευση τμημάτων χωρίς διαμάχη, επομένως λαμβάνετε κλίμακες διεκπεραίωσης γραμμικά με τον αριθμό των παράλληλων εισαγωγών έως ότου κορεστούν οι I/O ή οι πυρήνες.
Ωστόσο, αυτή η περίσταση σημαίνει επίσης ότι το σύστημα δεν είναι κατάλληλο για μικρά πακέτα, επομένως οι υπηρεσίες Kafka και οι εισαγωγείς χρησιμοποιούνται για αποθήκευση στην προσωρινή μνήμη. Επιπλέον, το ClickHouse στο παρασκήνιο συνεχίζει να συγχωνεύει συνεχώς τμήματα, έτσι ώστε πολλά μικρά κομμάτια πληροφοριών να συνδυάζονται και να καταγράφονται περισσότερες φορές, αυξάνοντας έτσι την ένταση της εγγραφής. Ωστόσο, πάρα πολλά άσχετα μέρη θα προκαλέσουν επιθετικό στραγγαλισμό των ενθέτων όσο συνεχίζεται η συγχώνευση. Βρήκαμε ότι ο καλύτερος συμβιβασμός μεταξύ της απορρόφησης δεδομένων σε πραγματικό χρόνο και της απόδοσης απορρόφησης είναι η αποδοχή ενός περιορισμένου αριθμού εισαγωγών ανά δευτερόλεπτο στον πίνακα.
Το κλειδί για την απόδοση ανάγνωσης πίνακα είναι η ευρετηρίαση και η θέση των δεδομένων στο δίσκο. Ανεξάρτητα από το πόσο γρήγορη είναι η επεξεργασία, όταν ο κινητήρας χρειάζεται να σαρώσει terabytes δεδομένων από το δίσκο και να χρησιμοποιήσει μόνο ένα κλάσμα από αυτά, θα χρειαστεί χρόνος. Το ClickHouse είναι ένα κατάστημα στηλών, επομένως κάθε τμήμα περιέχει ένα αρχείο για κάθε στήλη (στήλη) με ταξινομημένες τιμές για κάθε σειρά. Έτσι, ολόκληρες στήλες που δεν υπάρχουν στο ερώτημα μπορούν πρώτα να παραβλεφθούν και, στη συνέχεια, πολλά κελιά μπορούν να υποβληθούν σε επεξεργασία παράλληλα με τη διανυσματική εκτέλεση. Για να αποφευχθεί η πλήρης σάρωση, κάθε τμήμα έχει ένα μικρό αρχείο ευρετηρίου.
Δεδομένου ότι όλες οι στήλες ταξινομούνται με βάση το "πρωτεύον κλειδί", το αρχείο ευρετηρίου περιέχει μόνο τις ετικέτες (αποτυπωμένες σειρές) κάθε Νης σειράς, ώστε να μπορεί να τις διατηρεί στη μνήμη ακόμη και για πολύ μεγάλους πίνακες. Για παράδειγμα, μπορείτε να ορίσετε τις προεπιλεγμένες ρυθμίσεις σε "επισήμανση κάθε 8192ης σειράς", στη συνέχεια σε "πενιχρή" ευρετηρίαση ενός πίνακα με 1 τρισ. Οι γραμμές που χωράνε εύκολα στη μνήμη χρειάζονται μόνο 122 χαρακτήρες.
Ανάπτυξη συστήματος
Η ανάπτυξη και η βελτίωση του Clickhouse μπορούν να εντοπιστούν και βεβαιωθείτε ότι η διαδικασία του «μεγαλώματος» γίνεται με εντυπωσιακούς ρυθμούς.
Δημοτικότητα
Φαίνεται ότι η δημοτικότητα του Clickhouse αυξάνεται εκθετικά, ειδικά στη ρωσόφωνη κοινότητα. Το περσινό συνέδριο High load 2018 (Μόσχα, 8-9 Νοεμβρίου 2018) έδειξε ότι τέρατα όπως το vk.com και το Badoo χρησιμοποιούν το Clickhouse, το οποίο εισάγει δεδομένα (για παράδειγμα, αρχεία καταγραφής) από δεκάδες χιλιάδες διακομιστές ταυτόχρονα. Σε ένα βίντεο 40 λεπτών . Σύντομα θα δημοσιεύσουμε τη μεταγραφή στο Habr για την ευκολία της εργασίας με το υλικό.
Εφαρμογές
Αφού αφιέρωσα λίγο χρόνο στην έρευνα, νομίζω ότι υπάρχουν τομείς όπου το ClickHouse μπορεί να είναι χρήσιμο ή ικανό να αντικαταστήσει πλήρως άλλες πιο παραδοσιακές και δημοφιλείς λύσεις όπως MySQL, PostgreSQL, ELK, Google Big Query, Amazon RedShift, TimescaleDB, Hadoop, MapReduce, Pinot και Ιερέας των κελτών. Ακολουθούν οι λεπτομέρειες σχετικά με τη χρήση του ClickHouse για την αναβάθμιση ή την πλήρη αντικατάσταση του παραπάνω DBMS.
Επέκταση MySQL και PostgreSQL
Πιο πρόσφατα, αντικαταστήσαμε εν μέρει τη MySQL με το ClickHouse για την πλατφόρμα ενημερωτικών δελτίων . Το πρόβλημα ήταν ότι η MySQL λόγω λανθασμένης σχεδίασης καταγράφει κάθε email που αποστέλλεται και κάθε σύνδεσμο σε αυτό το email με ένα hash base64, δημιουργώντας έναν τεράστιο πίνακα MySQL (email_stats). Αφού έστειλε μόνο 10 εκατομμύρια email στους συνδρομητές της υπηρεσίας, αυτός ο πίνακας καταλάμβανε 150 GB χώρου αρχείων και η MySQL άρχισε να «χαζεύει» σε απλά ερωτήματα. Για να διορθώσουμε το πρόβλημα του χώρου αρχείων, χρησιμοποιήσαμε με επιτυχία τη συμπίεση πίνακα InnoDB, η οποία μείωσε κατά 4. Ωστόσο, εξακολουθεί να μην έχει νόημα να αποθηκεύονται περισσότερα από 20-30 εκατομμύρια μηνύματα ηλεκτρονικού ταχυδρομείου στη MySQL μόνο και μόνο για λόγους ανάγνωσης του ιστορικού, καθώς κάθε απλό ερώτημα που για κάποιο λόγο πρέπει να κάνει πλήρη σάρωση έχει ως αποτέλεσμα swap και βαριά I/O γενικά έξοδα, για τα οποία λαμβάναμε τακτικά προειδοποιήσεις Zabbix.
Το Clickhouse χρησιμοποιεί δύο αλγόριθμους συμπίεσης που μειώνουν την ποσότητα των δεδομένων κατά περίπου , αλλά στη συγκεκριμένη περίπτωση τα δεδομένα ήταν ιδιαίτερα «συμπιέσιμα».
Αντικατάσταση ΕΛΚ
Με βάση τη δική μου εμπειρία, η στοίβα ELK (ElasticSearch, Logstash και Kibana, στη συγκεκριμένη περίπτωση ElasticSearch) απαιτεί πολύ περισσότερους πόρους για την εκτέλεση από ό,τι χρειάζεται για την αποθήκευση αρχείων καταγραφής. Το ElasticSearch είναι μια εξαιρετική μηχανή αν θέλετε καλή αναζήτηση αρχείων καταγραφής πλήρους κειμένου (που δεν νομίζω ότι χρειάζεστε πραγματικά), αλλά αναρωτιέμαι γιατί έχει γίνει η de facto τυπική μηχανή καταγραφής. Η απόδοση απορρόφησής του, σε συνδυασμό με το Logstash, μας δημιουργούσε προβλήματα ακόμα και σε αρκετά μικρό φόρτο εργασίας και απαιτούσε την προσθήκη ολοένα και περισσότερης μνήμης RAM και χώρου στο δίσκο. Ως βάση δεδομένων, το Clickhouse είναι καλύτερο από το ElasticSearch για τους ακόλουθους λόγους:
- Υποστήριξη διαλέκτου SQL.
- Ο καλύτερος βαθμός συμπίεσης των αποθηκευμένων δεδομένων.
- Υποστήριξη για αναζήτηση Regex αντί για αναζήτηση πλήρους κειμένου.
- Βελτιωμένος προγραμματισμός ερωτημάτων και καλύτερη συνολική απόδοση.
Επί του παρόντος, το μεγαλύτερο πρόβλημα που προκύπτει κατά τη σύγκριση του ClickHouse με το ELK είναι η έλλειψη λύσεων για τη μεταφόρτωση αρχείων καταγραφής, καθώς και η έλλειψη τεκμηρίωσης και οδηγιών για αυτό το θέμα. Ταυτόχρονα, κάθε χρήστης μπορεί να ρυθμίσει το ELK χρησιμοποιώντας το εγχειρίδιο Digital Ocean, το οποίο είναι πολύ σημαντικό για την ταχεία εφαρμογή τέτοιων τεχνολογιών. Υπάρχει μια μηχανή βάσης δεδομένων εδώ, αλλά δεν υπάρχει ακόμα Filebeat για το ClickHouse. Ναι υπάρχει και ένα σύστημα για εργασία με κορμούς , υπάρχει ένα εργαλείο για να εισαγάγετε δεδομένα αρχείου καταγραφής στο ClickHouse, αλλά όλα αυτά χρειάζονται περισσότερο χρόνο. Ωστόσο, το ClickHouse εξακολουθεί να προηγείται λόγω της απλότητάς του, επομένως ακόμη και οι αρχάριοι μπορούν εύκολα να το εγκαταστήσουν και να ξεκινήσουν την πλήρως λειτουργική χρήση σε μόλις 10 λεπτά.
Προτιμώντας μινιμαλιστικές λύσεις, προσπάθησα να χρησιμοποιήσω το FluentBit, ένα εργαλείο μεταφόρτωσης αρχείων καταγραφής πολύ χαμηλής μνήμης, με το ClickHouse προσπαθώντας να αποφύγω τη χρήση του Kafka. Ωστόσο, πρέπει να αντιμετωπιστούν μικρές ασυμβατότητες, όπως π.χ προτού μπορεί να γίνει χωρίς το επίπεδο διακομιστή μεσολάβησης που μετατρέπει δεδομένα από το FluentBit σε ClickHouse.
Ως εναλλακτική λύση στο Kibana, μπορείτε να χρησιμοποιήσετε το ClickHouse ως backend . Από όσο καταλαβαίνω, αυτό μπορεί να προκαλέσει προβλήματα απόδοσης κατά την απόδοση ενός τεράστιου αριθμού σημείων δεδομένων, ειδικά με παλαιότερες εκδόσεις του Grafana. Στο Qwintry, δεν το έχουμε δοκιμάσει ακόμα, αλλά παράπονα σχετικά με αυτό εμφανίζονται κατά καιρούς στο κανάλι υποστήριξης ClickHouse στο Telegram.
Αντικατάσταση Google Big Query και Amazon RedShift (λύση για μεγάλες εταιρείες)
Η ιδανική περίπτωση χρήσης για το BigQuery είναι η φόρτωση 1 TB δεδομένων JSON και η εκτέλεση αναλυτικών ερωτημάτων σε αυτά. Το Big Query είναι ένα εξαιρετικό προϊόν του οποίου η επεκτασιμότητα είναι δύσκολο να υπερεκτιμηθεί. Αυτό είναι πολύ πιο περίπλοκο λογισμικό από το ClickHouse που εκτελείται σε ένα εσωτερικό σύμπλεγμα, αλλά από την άποψη του πελάτη, έχει πολλά κοινά με το ClickHouse. Το BigQuery μπορεί γρήγορα να «τιμολογήσει» μόλις αρχίσετε να πληρώνετε για κάθε SELECT, επομένως είναι μια πραγματική λύση SaaS με όλα τα πλεονεκτήματα και τα μειονεκτήματά του.
Το ClickHouse είναι η καλύτερη επιλογή όταν εκτελείτε πολλά υπολογιστικά ακριβά ερωτήματα. Όσο περισσότερα ερωτήματα SELECT εκτελείτε καθημερινά, τόσο πιο νόημα έχει να αντικαταστήσετε το Big Query με το ClickHouse, επειδή μια τέτοια αντικατάσταση θα σας εξοικονομήσει χιλιάδες δολάρια όταν πρόκειται για πολλά terabyte δεδομένων που υποβάλλονται σε επεξεργασία. Αυτό δεν ισχύει για αποθηκευμένα δεδομένα, η επεξεργασία των οποίων είναι αρκετά φθηνή στο Big Query.
Σε άρθρο του Alexander Zaitsev, συνιδρυτή του Altinity περιγράφει τα οφέλη μιας τέτοιας μετεγκατάστασης DBMS.
Αντικατάσταση TimescaleDB
Το TimescaleDB είναι μια επέκταση PostgreSQL που βελτιστοποιεί την εργασία με χρονοσειρές σε μια κανονική βάση δεδομένων (, ).
Αν και το ClickHouse δεν είναι σοβαρός ανταγωνιστής στη θέση της χρονοσειράς, αλλά όσον αφορά τη δομή στηλών και την εκτέλεση διανυσματικών ερωτημάτων, είναι πολύ ταχύτερο από το TimescaleDB στις περισσότερες περιπτώσεις επεξεργασίας αναλυτικών ερωτημάτων. Ταυτόχρονα, η απόδοση λήψης δεδομένων πακέτων ClickHouse είναι περίπου 3 φορές υψηλότερη, επιπλέον, χρησιμοποιεί 20 φορές λιγότερο χώρο στο δίσκο, κάτι που είναι πραγματικά σημαντικό για την επεξεργασία μεγάλου όγκου ιστορικών δεδομένων: .
Σε αντίθεση με το ClickHouse, ο μόνος τρόπος για να εξοικονομήσετε χώρο στο δίσκο TimescaleDB είναι να χρησιμοποιήσετε ZFS ή παρόμοια συστήματα αρχείων.
Οι επερχόμενες ενημερώσεις στο ClickHouse πιθανότατα θα εισαγάγουν συμπίεση δέλτα, γεγονός που θα το καταστήσει ακόμη πιο κατάλληλο για την επεξεργασία και την αποθήκευση δεδομένων χρονοσειρών. Το TimescaleDB μπορεί να είναι καλύτερη επιλογή από το γυμνό ClickHouse στις ακόλουθες περιπτώσεις:
- μικρές εγκαταστάσεις με πολύ μικρή μνήμη RAM (<3 GB).
- ένας μεγάλος αριθμός μικρών INSERT που δεν θέλετε να αποθηκεύσετε σε μεγάλα τμήματα.
- καλύτερες απαιτήσεις συνοχής, ομοιομορφίας και οξέων·
- Υποστήριξη PostGIS.
- συγχώνευση με υπάρχοντες πίνακες PostgreSQL, αφού το Timescale DB είναι ουσιαστικά PostgreSQL.
Ανταγωνισμός με συστήματα Hadoop και MapReduce
Το Hadoop και άλλα προϊόντα MapReduce μπορούν να εκτελέσουν πολλούς σύνθετους υπολογισμούς, αλλά τείνουν να εκτελούνται με τεράστιο λανθάνοντα χρόνο. Το ClickHouse διορθώνει αυτό το πρόβλημα επεξεργάζοντας terabyte δεδομένων και παράγοντας αποτελέσματα σχεδόν αμέσως. Έτσι, το ClickHouse είναι πολύ πιο αποτελεσματικό για την εκτέλεση γρήγορης, διαδραστικής αναλυτικής έρευνας, η οποία θα πρέπει να ενδιαφέρει τους επιστήμονες δεδομένων.
Ανταγωνισμός με τον Pinot και τον Druid
Οι πιο κοντινοί ανταγωνιστές του ClickHouse είναι τα στηλοειδή, γραμμικά κλιμακούμενα προϊόντα ανοιχτού κώδικα Pinot και Druid. Μια εξαιρετική δουλειά συγκρίνοντας αυτά τα συστήματα δημοσιεύεται στο άρθρο 1 Φεβρουαρίου 2018
Αυτό το άρθρο πρέπει να ενημερωθεί - λέει ότι το ClickHouse δεν υποστηρίζει λειτουργίες ΕΝΗΜΕΡΩΣΗΣ και ΔΙΑΓΡΑΦΗΣ, κάτι που δεν είναι απολύτως αληθές σε σχέση με τις πιο πρόσφατες εκδόσεις.
Δεν έχουμε μεγάλη εμπειρία με αυτά τα DBMS, αλλά δεν μου αρέσει η πολυπλοκότητα της υποκείμενης υποδομής που απαιτείται για την εκτέλεση των Druid και Pinot - είναι μια ολόκληρη δέσμη "κινητών μερών" που περιβάλλονται από Java από όλες τις πλευρές.
Το Druid και το Pinot είναι έργα θερμοκοιτίδας Apache, τα οποία καλύπτονται λεπτομερώς από τον Apache στις σελίδες του έργου GitHub. Ο Pinot εμφανίστηκε στη θερμοκοιτίδα τον Οκτώβριο του 2018 και ο Druid γεννήθηκε 8 μήνες νωρίτερα - τον Φεβρουάριο.
Η έλλειψη πληροφοριών σχετικά με τον τρόπο λειτουργίας του AFS εγείρει ορισμένα, και ίσως ανόητα, ερωτήματα για μένα. Αναρωτιέμαι αν οι συγγραφείς του Pinot παρατήρησαν ότι το Ίδρυμα Apache είναι πιο διατεθειμένο προς τον Druid και μήπως μια τέτοια στάση απέναντι σε έναν ανταγωνιστή προκάλεσε ένα αίσθημα φθόνου; Θα επιβραδυνθεί η ανάπτυξη του Druid και η ανάπτυξη του Pinot θα επιταχυνθεί εάν οι χορηγοί που υποστηρίζουν τον πρώτο ενδιαφέρονται ξαφνικά για το δεύτερο;
Μειονεκτήματα του ClickHouse
Ανωριμότητα: Προφανώς, αυτή είναι ακόμα μια βαρετή τεχνολογία, αλλά σε κάθε περίπτωση, τίποτα παρόμοιο δεν φαίνεται σε άλλα στήλες DBMS.
Τα μικρά ένθετα δεν έχουν καλή απόδοση σε υψηλή ταχύτητα: τα ένθετα πρέπει να χωριστούν σε μεγάλα κομμάτια επειδή η απόδοση των μικρών ενθέτων υποβαθμίζεται ανάλογα με τον αριθμό των στηλών σε κάθε σειρά. Αυτός είναι ο τρόπος με τον οποίο το ClickHouse αποθηκεύει δεδομένα στο δίσκο - κάθε στήλη σημαίνει 1 αρχείο ή περισσότερο, επομένως για να εισαγάγετε 1 σειρά που περιέχει 100 στήλες, πρέπει να ανοίξετε και να γράψετε τουλάχιστον 100 αρχεία. Αυτός είναι ο λόγος για τον οποίο η αποθήκευση στην προσωρινή μνήμη απαιτεί έναν ενδιάμεσο (εκτός εάν ο ίδιος ο πελάτης παρέχει προσωρινή αποθήκευση) - συνήθως Kafka ή κάποιο είδος συστήματος ουράς. Μπορείτε επίσης να χρησιμοποιήσετε τη μηχανή πίνακα buffer για να αντιγράψετε αργότερα μεγάλα κομμάτια δεδομένων σε πίνακες MergeTree.
Οι ενώσεις σε τραπέζια περιορίζονται από τη μνήμη RAM του διακομιστή, αλλά τουλάχιστον είναι εκεί! Για παράδειγμα, το Druid και το Pinot δεν έχουν καθόλου τέτοιες συνδέσεις, καθώς είναι δύσκολο να εφαρμοστούν απευθείας σε κατανεμημένα συστήματα που δεν υποστηρίζουν τη μετακίνηση μεγάλων τμημάτων δεδομένων μεταξύ κόμβων.
Ευρήματα
Τα επόμενα χρόνια, σχεδιάζουμε να κάνουμε εκτεταμένη χρήση του ClickHouse στο Qwintry, καθώς αυτό το DBMS παρέχει εξαιρετική ισορροπία απόδοσης, χαμηλό κόστος, επεκτασιμότητα και απλότητα. Είμαι σίγουρος ότι θα εξαπλωθεί γρήγορα μόλις η κοινότητα του ClickHouse βρει περισσότερους τρόπους για να το χρησιμοποιήσει σε μικρές και μεσαίες εγκαταστάσεις.
Μερικές διαφημίσεις 🙂
Σας ευχαριστούμε που μείνατε μαζί μας. Σας αρέσουν τα άρθρα μας; Θέλετε να δείτε πιο ενδιαφέρον περιεχόμενο; Υποστηρίξτε μας κάνοντας μια παραγγελία ή προτείνοντας σε φίλους, , ένα μοναδικό ανάλογο διακομιστών εισαγωγικού επιπέδου, το οποίο εφευρέθηκε από εμάς για εσάς: (διατίθεται με RAID1 και RAID10, έως 24 πυρήνες και έως 40 GB DDR4).
Το Dell R730xd 2 φορές φθηνότερο στο κέντρο δεδομένων Equinix Tier IV στο Άμστερνταμ; Μόνο εδώ στην Ολλανδία! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - από 99$! Διαβάστε σχετικά
Πηγή: www.habr.com