die tabellarische Funktion input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Ein weiteres Antipattern ist Mikroscharding. Zum Beispiel m\u00fcssen Sie Daten sharden und Sie haben 5 Server, und morgen wird es 6 Server geben. Und Sie denken dar\u00fcber nach, wie Sie diese Daten umverteilen k\u00f6nnen. Stattdessen teilen Sie nicht in 5 Shards auf, sondern in 1.000 Shards. Und dann weisen Sie jeden dieser Mikroschards einem separaten Server zu. Und Sie haben zum Beispiel auf einem Server 200 ClickHouse-Instanzen. Separate Instanzen auf unterschiedlichen Ports oder separate Datenbanken. <\/p>\n
<\/p>\n
<\/p>\n
Aber in ClickHouse ist das nicht sehr gut. Denn selbst eine Instanz von ClickHouse versucht, alle verf\u00fcgbaren Ressourcen des Servers zu nutzen, um eine Anfrage zu verarbeiten. Das hei\u00dft, Sie haben einen Server und dort zum Beispiel 56 CPU-Kerne. Sie f\u00fchren eine Anfrage aus, die eine Sekunde dauert, und sie wird 56 Kerne nutzen. Wenn Sie dort jedoch 200 ClickHouse-Instanzen auf einem Server platziert haben, werden 10.000 Threads gestartet. Insgesamt wird alles sehr schlecht sein.<\/p>\n
<\/p>\n
Ein weiterer Grund ist, dass die Verteilung der Arbeit auf diese Instanzen ungleichm\u00e4\u00dfig sein wird. Einige werden fr\u00fcher fertig, andere sp\u00e4ter. Wenn das alles in einer Instanz passieren w\u00fcrde, w\u00fcrde ClickHouse selbst herausfinden, wie man die Daten korrekt auf die Threads verteilt. <\/p>\n
<\/p>\n
Und ein weiterer Grund ist, dass es inter-prozessorale Kommunikation \u00fcber TCP geben wird. Die Daten m\u00fcssen serialisiert und deserialisiert werden, und das ist eine enorme Anzahl von Mikroschards. Es wird einfach ineffizient funktionieren.<\/p>\n
<\/p>\n
<\/p>\n
Ein weiteres Antipattern, obwohl es schwierig ist, es als solches zu bezeichnen. Das ist eine gro\u00dfe Anzahl an Pre-Aggregationen.<\/p>\n
<\/p>\n
Im Allgemeinen ist Pre-Aggregation gut. Sie hatten eine Milliarde Zeilen, Sie haben sie aggregiert und es sind 1.000 Zeilen geworden, und jetzt wird die Anfrage sofort ausgef\u00fchrt. Alles wunderbar. So kann man das machen. Und daf\u00fcr gibt es sogar in ClickHouse einen speziellen Tabellentyp, den AggregatingMergeTree, der inkrementelle Aggregation w\u00e4hrend des Einf\u00fcgens von Daten durchf\u00fchrt. <\/p>\n
<\/p>\n
Es gibt jedoch F\u00e4lle, in denen Sie denken, dass wir die Daten so aggregieren werden und dann noch so aggregieren. In einer benachbarten Abteilung, von der ich nicht sprechen m\u00f6chte, verwenden sie die SummingMergeTree-Tabellen zur Aggregation nach dem Prim\u00e4rschl\u00fcssel, und als Prim\u00e4rschl\u00fcssel verwenden sie etwa 20 verschiedene Spalten. Ich habe zur Sicherheit einige Spaltennamen zur Tarnung ge\u00e4ndert, aber ungef\u00e4hr so ist es.<\/p>\n
<\/p>\n
<\/p>\n
Und es treten solche Probleme auf. Erstens, das Datenvolumen verringert sich nicht drastisch. Zum Beispiel reduziert es sich um das Dreifache. Ein Dreifaches w\u00e4re ein guter Preis, um sich unbegrenzte M\u00f6glichkeiten f\u00fcr Analysen zu erm\u00f6glichen, die entstehen, wenn Ihre Daten nicht aggregiert sind. Wenn die Daten aggregiert sind, erhalten Sie anstelle von Analysen lediglich mickrige Statistiken. <\/p>\n
<\/p>\n
Was besonders nervt? Dass diese Leute aus der benachbarten Abteilung manchmal kommen und darum bitten, noch eine Spalte zum Prim\u00e4rschl\u00fcssel hinzuzuf\u00fcgen. D. h. wir haben die Daten so aggregiert, wollen jetzt aber etwas mehr. Aber in ClickHouse gibt es kein \u00c4ndern des Prim\u00e4rschl\u00fcssels. Deshalb muss man irgendwelche Skripte in C++ schreiben. Und ich mag keine Skripte, selbst wenn sie in C++ sind.<\/p>\n
<\/p>\n
Wenn man sich ansieht, wof\u00fcr ClickHouse entwickelt wurde, sind nicht aggregierte Daten genau das Szenario, f\u00fcr das es geboren wurde. Wenn Sie ClickHouse f\u00fcr nicht aggregierte Daten verwenden, machen Sie alles richtig. Wenn Sie aggregieren, ist das manchmal verzeihlich. <\/p>\n
<\/p>\n
<\/p>\n
Ein weiterer interessanter Fall sind Abfragen in einer Endlosschleife. Manchmal gehe ich auf einen Produktionsserver und sehe mir die Prozessliste an. Und jedes Mal stelle ich fest, dass etwas Schreckliches passiert. <\/p>\n
<\/p>\n
Zum Beispiel so etwas. Hier wird sofort klar, dass man alles in einer Abfrage h\u00e4tte ausf\u00fchren k\u00f6nnen. Schreiben Sie einfach dort url in und die Liste.<\/p>\n
<\/p>\n
<\/p>\n
Warum sind so viele solcher Abfragen in einer Endlosschleife schlecht? Wenn der Index nicht verwendet wird, haben Sie viele Durchl\u00e4ufe \u00fcber dieselben Daten. Aber wenn der Index verwendet wird, zum Beispiel, wenn Sie einen Prim\u00e4rschl\u00fcssel nach ru haben und Sie schreiben url = irgendetwas. Und Sie denken, dass nur dieser eine url genau aus der Tabelle gelesen wird, wird alles in Ordnung sein. Aber in Wirklichkeit ist das nicht der Fall. Denn ClickHouse arbeitet alles in B\u00fcndeln ab. <\/p>\n
<\/p>\n
Wenn er einen bestimmten Datenbereich lesen muss, liest er ein wenig mehr, da der Index in ClickHouse sp\u00e4rlich ist. Dieser Index erm\u00f6glicht es nicht, eine individuelle Zeile in der Tabelle zu finden, sondern nur einen bestimmten Bereich. Die Daten werden in Bl\u00f6cken komprimiert. Um eine Zeile zu lesen, muss man einen ganzen Block nehmen und ihn dekomprimieren. Wenn Sie viele Abfragen durchf\u00fchren, gibt es viele \u00dcberschneidungen, und eine Menge Arbeit wird immer wiederholt.<\/p>\n
<\/p>\n
<\/p>\n
Und als Bonus kann man bemerken, dass man in ClickHouse keine Angst haben muss, selbst Megabyte und sogar Hunderte von Megabyte in die IN-Klausel zu \u00fcbergeben. Ich erinnere mich aus unserer Praxis, dass wenn wir in MySQL eine Menge Werte in die IN-Klausel \u00fcbergeben, zum Beispiel 100 Megabyte irgendwelcher Zahlen, dann schluckt MySQL 10 Gigabyte Speicher und sonst passiert nichts, alles funktioniert schlecht. <\/p>\n
<\/p>\n
Und das Zweite ist, dass in ClickHouse, wenn Ihre Abfragen den Index nutzen, es immer nicht langsamer ist als ein Full Scan, d.h. wenn fast die gesamte Tabelle gelesen werden muss, wird es sequenziell durchgef\u00fchrt und die gesamte Tabelle gelesen. Insgesamt k\u00fcmmert sich ClickHouse selbst darum.<\/p>\n
<\/p>\n
Dennoch gibt es einige Schwierigkeiten. Zum Beispiel nutzt die IN-Klausel mit einer Unterabfrage den Index nicht. Aber das ist unser Problem und wir m\u00fcssen das beheben. Es gibt hier nichts Fundamentales. Wir werden es reparieren. <\/p>\n
<\/p>\n
Und eine weitere interessante Sache ist, dass wenn Sie eine sehr lange Abfrage haben und die Verarbeitung der Abfragen verteilt erfolgt, dann wird diese sehr lange Abfrage ohne Kompression an jeden Server gesendet. Zum Beispiel 100 Megabyte und 500 Server. Entsprechend werden \u00fcber das Netzwerk 50 Gigabyte \u00fcbertragen. Es wird \u00fcbertragen und dann wird alles erfolgreich ausgef\u00fchrt.<\/p>\n
<\/p>\n
* benutzt bereits; alles repariert, wie versprochen.<\/p>\n
<\/p>\n
<\/p>\n
Und ein recht h\u00e4ufiger Fall ist, wenn Abfragen aus APIs kommen. Zum Beispiel, Sie haben einen eigenen Service erstellt. Und wenn Ihr Service jemandem wichtig ist, dann haben Sie eine API ge\u00f6ffnet und sehen bereits nach zwei Tagen, dass etwas Unverst\u00e4ndliches passiert. Alles ist \u00fcberlastet und es kommen schreckliche Abfragen, die niemals h\u00e4tten kommen sollen. <\/p>\n
<\/p>\n
Und die L\u00f6sung ist einfach. Wenn Sie eine API ge\u00f6ffnet haben, m\u00fcssen Sie sie k\u00fcrzen. Zum Beispiel Quoten einf\u00fchren. Es gibt keine anderen vern\u00fcnftigen Optionen. Andernfalls wird sofort ein Skript geschrieben und es gibt Probleme. <\/p>\n
<\/p>\n
Und ClickHouse bietet eine spezielle M\u00f6glichkeit \u2013 die Z\u00e4hlung von Quoten. Dabei kann man seinen eigenen Quoten-Schl\u00fcssel \u00fcbergeben. Das kann zum Beispiel eine interne Benutzer-ID sein. Und die Quoten werden unabh\u00e4ngig f\u00fcr jeden von ihnen gez\u00e4hlt. <\/p>\n
<\/p>\n
<\/p>\n
Jetzt noch eine interessante Sache. Das ist die Replikation mit manueller Steuerung. <\/p>\n
<\/p>\n
Ich kenne viele F\u00e4lle, in denen, trotz der integrierten Unterst\u00fctzung f\u00fcr Replikation in ClickHouse, die Leute ClickHouse manuell replizieren.<\/p>\n
<\/p>\n
Welches Prinzip steckt dahinter? Sie haben eine Datenverarbeitungs-Pipeline. Und diese funktioniert unabh\u00e4ngig, zum Beispiel in verschiedenen Rechenzentren. Sie schreiben die gleichen Daten auf die gleiche Art in ClickHouse. Allerdings zeigt die Praxis, dass die Daten aufgrund bestimmter Besonderheiten in Ihrem Code dennoch auseinanderdriften werden. Ich hoffe, in Ihrem nicht. <\/p>\n
<\/p>\n
Und gelegentlich m\u00fcssen Sie trotzdem manuell synchronisieren. Zum Beispiel f\u00fchren die Administratoren einmal im Monat ein rsync durch.<\/p>\n
<\/p>\n
In der Tat ist es viel einfacher, die in ClickHouse integrierte Replikation zu verwenden. Aber es kann einige Vorbehalte geben, denn daf\u00fcr m\u00fcssen Sie ZooKeeper verwenden. Ich will nichts Schlechtes \u00fcber ZooKeeper sagen, grunds\u00e4tzlich ist das System funktional, aber es kommt vor, dass Menschen es aufgrund von Java-Phobie nicht verwenden, denn ClickHouse ist ein gutes System, das in C++ geschrieben ist, das man nutzen kann und das hervorragend funktioniert. Aber ZooKeeper ist in Java. Und man hat irgendwie nicht das Bed\u00fcrfnis, sich das anzusehen, aber dann k\u00f6nnen Sie die Replikation mit manueller Steuerung verwenden. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse ist ein praktisches System. Es ber\u00fccksichtigt Ihre Bed\u00fcrfnisse. Wenn Sie Replikation mit manueller Steuerung haben, k\u00f6nnen Sie eine verteilte Tabelle erstellen, die auf Ihre manuellen Replikate schaut und selbst zwischen diesen einen Failover durchf\u00fchrt. Es gibt sogar eine spezielle Option, die es erm\u00f6glicht, Flaps zu vermeiden, selbst wenn Ihre Replikate systematisch auseinandergehen.<\/p>\n
<\/p>\n
<\/p>\n
Es k\u00f6nnen Probleme auftreten, wenn Sie primitive Table Engines verwenden. ClickHouse ist eine Art Baukasten mit einer Vielzahl verschiedener Tabellen-Engines. F\u00fcr alle ernsten F\u00e4lle sollte, wie in der Dokumentation angegeben, die MergeTree-Familie verwendet werden. Alle anderen sind eher f\u00fcr spezielle F\u00e4lle oder Tests gedacht.<\/p>\n
<\/p>\n
In der MergeTree-Tabelle ist es nicht unbedingt erforderlich, dass Sie ein Datum und eine Uhrzeit haben. Sie k\u00f6nnen sie dennoch verwenden. Wenn es kein Datum und keine Uhrzeit gibt, geben Sie an, dass das Standarddatum das Jahr 2000 ist. Das wird funktionieren und ben\u00f6tigt keine Ressourcen. <\/p>\n
<\/p>\n
In der neuen Serverversion k\u00f6nnen Sie sogar angeben, dass Sie eine benutzerdefinierte Partitionierung ohne Partitionsschl\u00fcssel haben m\u00f6chten. Es bleibt dasselbe. <\/p>\n
<\/p>\n
<\/p>\n
Andererseits k\u00f6nnen primitive Tabellensysteme verwendet werden. Zum Beispiel k\u00f6nnen Sie Daten einmal importieren und dann spielen, drehen und l\u00f6schen. Sie k\u00f6nnen Log verwenden.<\/p>\n
<\/p>\n
Oder die Speicherung kleiner Datenmengen zur Zwischenverarbeitung \u2013 das ist StripeLog oder TinyLog.<\/p>\n
<\/p>\n
Memory kann verwendet werden, wenn Sie eine kleine Datenmenge haben und einfach etwas im RAM bewegen m\u00f6chten. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse mag keine \u00fcber-normalisierten Daten. <\/p>\n
<\/p>\n
Hier ist ein typisches Beispiel. Es gibt eine riesige Menge an URLs. Sie haben sie in eine benachbarte Tabelle gesteckt. Und dann wollten Sie damit JOIN machen, aber das funktioniert normalerweise nicht, da ClickHouse nur Hash JOIN unterst\u00fctzt. Wenn nicht gen\u00fcgend RAM f\u00fcr die vielen Daten vorhanden ist, die verbunden werden m\u00fcssen, kann der JOIN nicht ausgef\u00fchrt werden*. <\/p>\n
<\/p>\n
Wenn die Daten eine hohe Kardinalit\u00e4t haben, machen Sie sich keine Sorgen, halten Sie sie in denormalisierter Form, URLs direkt inplace in der Haupttabelle. <\/p>\n
<\/p>\n
* Aber jetzt gibt es in ClickHouse auch Merge JOIN, und er funktioniert unter Bedingungen, wenn die Zwischendaten nicht im RAM Platz finden. Aber das ist ineffizient, und die Empfehlung bleibt bestehen.<\/p>\n
<\/p>\n
<\/p>\n
Hier sind noch ein paar Beispiele, aber ich zweifle bereits, ob sie antipattern sind oder nicht. <\/p>\n
<\/p>\n
In ClickHouse gibt es einen bekannten Nachteil. Er kann keine Updates durchf\u00fchren*. In gewissem Sinne ist das sogar gut. Wenn Sie wichtige Daten haben, zum Beispiel Buchhaltungsdaten, kann niemand sie senden, weil es keine Updates gibt.<\/p>\n
<\/p>\n
* Unterst\u00fctzung f\u00fcr Updates und Deletes im Batch-Modus wurde schon lange hinzugef\u00fcgt.<\/p>\n
<\/p>\n
Aber es gibt einige spezielle Methoden, die es erm\u00f6glichen, Updates gewisserma\u00dfen im Hintergrund durchzuf\u00fchren. Zum Beispiel Tabellen vom Typ ReplaceMergeTree. Sie f\u00fchren Updates w\u00e4hrend der Hintergrund-Merges durch. Sie k\u00f6nnen dies mit optimize table erzwingen. Aber machen Sie das nicht zu oft, denn das f\u00fchrt zur vollst\u00e4ndigen Neuschreibung der Partition. <\/p>\n
<\/p>\n
Verteilte JOINs in ClickHouse werden vom Query-Planer ebenfalls schlecht verarbeitet. <\/p>\n
<\/p>\n
Schlecht, aber manchmal in Ordnung.<\/p>\n
<\/p>\n
Die Verwendung von ClickHouse nur, um Daten \u00fcber select* zur\u00fcckzulesen.<\/p>\n
<\/p>\n
Ich w\u00fcrde nicht empfehlen, ClickHouse f\u00fcr umfangreiche Berechnungen zu verwenden. Aber so ganz stimmt das nicht, denn wir gehen bereits von dieser Empfehlung ab. Und k\u00fcrzlich haben wir die M\u00f6glichkeit hinzugef\u00fcgt, Machine-Learning-Modelle in ClickHouse anzuwenden \u2013 Catboost. Das bereitet mir Sorgen, denn ich denke: \"Wie schrecklich. Wie viele Taktzyklen pro Byte sind das!\" Es tut mir leid, Taktrate f\u00fcr Bytes zu verschwenden. <\/p>\n
<\/p>\n
<\/p>\n
Aber keine Angst, installieren Sie ClickHouse, alles wird gut. Wenn Sie Fragen haben, haben wir eine Community. \u00dcbrigens, die Community sind Sie. Und wenn Sie irgendwelche Probleme haben, k\u00f6nnen Sie zumindest in unseren Chat kommen, und ich hoffe, dass Ihnen geholfen wird. <\/p>\n
<\/p>\n
Fragen<\/p>\n
<\/p>\n
Danke f\u00fcr die Pr\u00e4sentation! Wo kann ich mich \u00fcber einen ClickHouse-Absturz beschweren?<\/em><\/p>\n<\/p>\n
Sie k\u00f6nnen sich gerne direkt jetzt an mich wenden. <\/p>\n
<\/p>\n
Ich habe k\u00fcrzlich angefangen, ClickHouse zu verwenden. Ich habe sofort die CLI-Oberfl\u00e4che zum Absturz gebracht.<\/em><\/p>\n<\/p>\n
Sie haben Gl\u00fcck. <\/p>\n
<\/p>\n
Kurze Zeit sp\u00e4ter habe ich den Server mit einer kleinen SELECT-Anfrage zum Absturz gebracht.<\/em><\/p>\n<\/p>\n
Sie haben Talent. <\/p>\n
<\/p>\n
Ich habe einen Bug auf GitHub gemeldet, aber er wurde ignoriert.<\/em> <\/p>\n<\/p>\n
Schauen wir mal. <\/p>\n
<\/p>\n
Alexey hat mich mit einem Trick dazu gebracht, einen Vortrag zu halten, indem er versprochen hat zu erkl\u00e4ren, wie ihr die Daten intern komprimiert.<\/em><\/p>\n<\/p>\n
Ganz einfach. <\/p>\n
<\/p>\n
Das habe ich auch schon gestern verstanden. Mehr Konkretes.<\/em> <\/p>\n<\/p>\n
Es gibt keine fiesen Tricks. Es handelt sich einfach um Blockkompression. Standardm\u00e4\u00dfig wird LZ4 verwendet, Sie k\u00f6nnen ZSTD aktivieren*. Die Bl\u00f6cke sind von 64 Kilobyte bis 1 Megabyte.<\/p>\n
<\/p>\n
* Es gibt auch Unterst\u00fctzung f\u00fcr spezialisierte Kompressionscodecs, die in Kombination mit anderen Algorithmen verwendet werden k\u00f6nnen.<\/p>\n
<\/p>\n
Sind die Daten in den Bl\u00f6cken einfach rohe Daten?<\/em><\/p>\n<\/p>\n
Nicht ganz roh. Dort sind Arrays. Wenn Sie eine numerische Spalte haben, sind die Zahlen in einem Array hintereinander angeordnet. <\/p>\n
<\/p>\n
Verstanden.<\/em> <\/p>\n<\/p>\n
Alexey, das Beispiel mit uniqExact \u00fcber die IP-Adressen, d. h. dass uniqExact \u00fcber Strings l\u00e4nger braucht als \u00fcber Zahlen usw. Und was ist, wenn wir einen Trick anwenden und beim Auslesen casten? Das hei\u00dft, Sie haben anscheinend gesagt, dass es auf der Festplatte nicht so viel Unterschied gibt. Wenn wir Strings von der Festplatte lesen und casten, sind die Aggregationen dann schneller oder nicht? Oder gewinnen wir hier dennoch nur geringf\u00fcgig? Mir scheint, dass Sie das getestet haben, aber aus irgendeinem Grund nicht im Benchmark angegeben haben.<\/em> <\/p>\n<\/p>\n
Ich denke, dass es langsamer sein wird als ohne Casting. In diesem Fall muss die IP-Adresse aus der Zeichenkette geparsed werden. Nat\u00fcrlich ist in ClickHouse auch das Parsen von IP-Adressen optimiert. Wir haben uns sehr angestrengt, aber die Zahlen sind in Zehntausenderform geschrieben. Sehr unpraktisch. Auf der anderen Seite wird die Funktion uniqExact bei Zeichenfolgen langsamer arbeiten, nicht nur weil es Zeichenfolgen sind, sondern auch weil eine andere Algorithmusspezialisierung gew\u00e4hlt wird. Zeichenfolgen werden einfach anders verarbeitet.<\/p>\n
<\/p>\n
Und wenn wir einen primitiveren Datentyp nehmen? Zum Beispiel haben wir die Benutzer-ID, die wir im Input haben, als Zeichenkette gespeichert und dann gecastet. Wird es dann besser oder schlechter?<\/em><\/p>\n<\/p>\n
Ich habe Zweifel. Ich denke sogar, dass es trauriger sein wird, denn das Parsen von Zahlen ist schlie\u00dflich ein ernsthaftes Problem. Mir scheint, dass ein Kollege sogar einen Vortrag \u00fcber die Schwierigkeiten beim Parsen von Zahlen in Zehntausenderform gehalten hat, oder vielleicht auch nicht. <\/p>\n
<\/p>\n
Alexey, vielen Dank f\u00fcr den Vortrag! Und danke auch f\u00fcr ClickHouse! Ich habe eine Frage zu den Pl\u00e4nen. Gibt es Pl\u00e4ne f\u00fcr eine Funktion, um W\u00f6rterb\u00fccher nicht vollst\u00e4ndig zu aktualisieren?<\/em><\/p>\n<\/p>\n
Das hei\u00dft, partielle Neulandung?<\/p>\n
<\/p>\n
Ja, genau. So eine M\u00f6glichkeit, ein MySQL-Feld anzugeben, d. h. nachtr\u00e4glich zu aktualisieren, sodass nur diese Daten geladen werden, wenn das W\u00f6rterbuch sehr gro\u00df ist.<\/em><\/p>\n<\/p>\n
Eine sehr interessante Funktion. Und ich glaube, jemand hat dies in unserem Chat vorgeschlagen. Vielleicht waren Sie das sogar. <\/p>\n
<\/p>\n
Ich glaube nicht, dass ich das war.<\/em><\/p>\n<\/p>\n
Gro\u00dfartig, jetzt ergibt sich, dass es zwei Anfragen gibt. Und wir k\u00f6nnen in Ruhe anfangen, daran zu arbeiten. Aber ich m\u00f6chte Sie sofort warnen, dass diese Funktion ziemlich einfach umzusetzen ist. Das hei\u00dft, theoretisch muss man einfach die Versionsnummer in die Tabelle schreiben und dann schreiben: Version kleiner als diese. Das bedeutet, dass wir wahrscheinlich vorschlagen werden, dies Enthusiasten zu \u00fcberlassen. Sind Sie ein Enthusiast? <\/p>\n
<\/p>\n
Ja, aber leider nicht in C++.<\/em><\/p>\n<\/p>\n
K\u00f6nnen Ihre Kollegen in C++ programmieren? <\/p>\n
<\/p>\n
Ich werde jemanden finden.<\/em><\/p>\n<\/p>\n
Ausgezeichnet*.<\/p>\n
<\/p>\n
* Die M\u00f6glichkeit wurde zwei Monate nach dem Vortrag hinzugef\u00fcgt \u2013 sie wurde vom Autor der Frage entwickelt und gesendet. Pull-Request<\/a><\/noindex>.<\/p>\n<\/p>\n
Danke!<\/em><\/p>\n<\/p>\n
Hallo! Vielen Dank f\u00fcr den Vortrag! Sie haben erw\u00e4hnt, dass ClickHouse alle verf\u00fcgbaren Ressourcen sehr gut nutzt. Der Referent, der neben Luxoft sprach, berichtete von seiner L\u00f6sung f\u00fcr die Post Russland. Er sagte, dass ihnen ClickHouse sehr gefallen hat, aber sie es nicht anstelle ihres Hauptkonkurrenten verwendet haben, gerade weil es die gesamte CPU-Auslastung beansprucht hat. Und sie konnten es nicht in ihre Architektur, in ihren ZooKeeper mit Docker-Containern integrieren. Gibt es eine M\u00f6glichkeit, ClickHouse irgendwie zu begrenzen, damit es nicht alles verbraucht, was ihm zur Verf\u00fcgung steht?<\/em><\/p>\n<\/p>\n
Ja, das ist m\u00f6glich und sehr einfach. Wenn Sie m\u00f6chten, dass weniger Kerne verwendet werden, schreiben Sie einfach set max_threads = 1<\/code>. Und das war's, er wird die Anfrage auf einem Kern ausf\u00fchren. Au\u00dferdem k\u00f6nnen verschiedene Benutzer unterschiedliche Einstellungen festlegen. Es gibt also keine Probleme. Und sagen Sie den Kollegen von Luxoft, dass es nicht gut ist, dass sie diese Einstellung in der Dokumentation nicht gefunden haben. <\/p>\n<\/p>\n
Alexei, hallo! Ich w\u00fcrde gerne eine Frage stellen. Ich habe schon mehrmals geh\u00f6rt, dass viele ClickHouse als Log-Speicher verwenden. In Ihrem Vortrag haben Sie gesagt, dass man das nicht tun sollte, d. h. dass man keine langen Zeilen speichern sollte. Was halten Sie davon?<\/em><\/p>\n<\/p>\n
Erstens sind Logs in der Regel keine langen Zeilen. Es gibt nat\u00fcrlich Ausnahmen. Zum Beispiel, wenn ein Dienst, der in Java geschrieben ist, eine Ausnahme ausl\u00f6st, wird sie protokolliert. Und das in einer endlosen Schleife, bis der Speicherplatz auf der Festplatte ersch\u00f6pft ist. Die L\u00f6sung ist sehr einfach. Wenn die Zeilen sehr lang sind, schneiden Sie sie ab. Und was bedeutet lang? Dutzende Kilobyte sind schlecht*.<\/p>\n
<\/p>\n
* In den aktuellen Versionen von ClickHouse ist die \"adaptive Granularit\u00e4t des Index\" aktiviert, was das Problem der Speicherung von langen Zeichenfolgen weitgehend l\u00f6st.<\/p>\n
<\/p>\n
Ist ein Kilobyte normal?<\/em><\/p>\n<\/p>\n
Normal. <\/p>\n
<\/p>\n
Hallo! Vielen Dank f\u00fcr den Vortrag! Ich habe bereits in der Chat gefragt, wei\u00df aber nicht, ob ich eine Antwort erhalten habe. Ist geplant, den WITH-Abschnitt \u00e4hnlich wie CTE zu erweitern?<\/em><\/p>\n<\/p>\n
Im Moment nicht. Der WITH-Abschnitt ist bei uns etwas unseri\u00f6s. Er ist f\u00fcr uns nur ein kleines Feature.<\/p>\n
<\/p>\n
Ich verstehe. Vielen Dank!<\/em><\/p>\n<\/p>\n
Vielen Dank f\u00fcr den Vortrag! Sehr interessant! Eine allgemeine Frage. Ist geplant, vielleicht eine Art Schnittstelle f\u00fcr die Datenl\u00f6schung zu schaffen?<\/em><\/p>\n<\/p>\n
Unbedingt. Das ist unsere erste Aufgabe in unserer Warteschlange. Wir haben jetzt aktiv dar\u00fcber nachgedacht, wie wir alles richtig machen k\u00f6nnen. Und es ist an der Zeit, mit dem Tippen zu beginnen*.<\/p>\n
<\/p>\n
* Haben die Tasten auf der Tastatur gedr\u00fcckt und alles erledigt.<\/p>\n
<\/p>\n
Wird sich das irgendwie auf die Systemleistung auswirken oder nicht? Wird das Einf\u00fcgen genauso schnell sein wie jetzt?<\/em><\/p>\n<\/p>\n
Vielleicht werden die deletes, die updates sehr schwer sein, aber das wird die Leistung der selects und der inserts nicht beeintr\u00e4chtigen.<\/p>\n
<\/p>\n
Und noch eine kleine Frage. Bei der Pr\u00e4sentation sprachen Sie \u00fcber den Prim\u00e4rschl\u00fcssel. Haben wir also eine Partitionierung, die standardm\u00e4\u00dfig monatlich ist, richtig? Und wenn wir einen Datumsbereich festlegen, der in einen Monat f\u00e4llt, wird nur diese Partition gelesen, korrekt?<\/em><\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
Eine solche Frage. Wenn wir keinen Prim\u00e4rschl\u00fcssel festlegen k\u00f6nnen, ist es dann richtig, ihn nach dem Feld \"Datum\" zu erstellen, um im Hintergrund eine geringere Umstrukturierung dieser Daten zu gew\u00e4hrleisten, damit sie geordneter sind? Wenn Sie keine Bereichsanfragen haben und keinen Prim\u00e4rschl\u00fcssel w\u00e4hlen k\u00f6nnen, sollten Sie dann das Datum in den Prim\u00e4rschl\u00fcssel aufnehmen?<\/em><\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
Vielleicht macht es Sinn, ein Feld im Prim\u00e4rschl\u00fcssel aufzunehmen, bei dem die Daten besser komprimiert werden, wenn sie nach diesem Feld sortiert sind. Zum Beispiel die Benutzer-ID. Ein Benutzer besucht beispielsweise immer dieselbe Website. In diesem Fall legen Sie die Benutzer-ID und die Uhrzeit ab. Dann werden Ihre Daten besser komprimiert. Was das Datum betrifft, wenn Sie wirklich keine und niemals Bereichsanfragen nach Datumsangaben haben, dann m\u00fcssen Sie das Datum nicht im Prim\u00e4rschl\u00fcssel ablegen. <\/p>\n
<\/p>\n
Gut, vielen Dank!<\/em><\/p>\nQuelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0422\u0430\u043a \u043a\u0430\u043a ClickHouse \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0437\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u043e\u0439 \u0441\u0438\u0441\u0442\u0435\u043c\u043e\u0439, \u043f\u0440\u0438 \u0435\u0433\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 \u0432\u0430\u0436\u043d\u043e \u0443\u0447\u0438\u0442\u044b\u0432\u0430\u0442\u044c \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e\u0441\u0442\u0438 \u0435\u0433\u043e \u0430\u0440\u0445\u0438\u0442\u0435\u043a\u0442\u0443\u0440\u044b. \u0412 \u044d\u0442\u043e\u043c \u0434\u043e\u043a\u043b\u0430\u0434\u0435 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u0442 \u043e \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0442\u0438\u043f\u0438\u0447\u043d\u044b\u0445 \u043e\u0448\u0438\u0431\u043e\u043a \u043f\u0440\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u043d\u0438\u0438 ClickHouse, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u043c\u043e\u0433\u0443\u0442 \u043f\u0440\u0438\u0432\u0435\u0441\u0442\u0438 \u043a \u043d\u0435\u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u043e\u0439 \u0440\u0430\u0431\u043e\u0442\u0435. \u041d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0430\u0445 \u0438\u0437 \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0431\u0443\u0434\u0435\u0442 \u043f\u043e\u043a\u0430\u0437\u0430\u043d\u043e, \u043a\u0430\u043a \u0432\u044b\u0431\u043e\u0440 \u0442\u043e\u0439 \u0438\u043b\u0438 \u0438\u043d\u043e\u0439 \u0441\u0445\u0435\u043c\u044b \u043e\u0431\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0434\u0430\u043d\u043d\u044b\u0445 \u043c\u043e\u0436\u0435\u0442 \u0438\u0437\u043c\u0435\u043d\u0438\u0442\u044c \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044c\u043d\u043e\u0441\u0442\u044c \u043d\u0430 \u043f\u043e\u0440\u044f\u0434\u043a\u0438. \u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91439,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91438","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Effektiver](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n