die Tabellenfunktion input<\/a><\/noindex>.<\/p>\n<\/p>\n
<\/p>\n
Ein weiteres Antipattern ist das Mikroscharding. Wenn Sie Daten shardieren m\u00fcssen und 5 Server haben, aber morgen 6 Server ben\u00f6tigen, stellen Sie sich die Frage, wie Sie die Daten umverteilen. Anstatt auf 5 Shards zu partitionieren, erstellen Sie 1.000 Shards. Danach ordnen Sie jeden dieser Mikroschards einem einzelnen Server zu. Das bedeutet, dass Sie auf einem Server beispielsweise 200 ClickHouse-Instanzen haben k\u00f6nnten, jeweils auf separaten Ports oder in separaten Datenbanken. <\/p>\n
<\/p>\n
<\/p>\n
In ClickHouse ist das jedoch nicht optimal. Selbst ein einzelner ClickHouse-Instanz versucht, alle verf\u00fcgbaren Serverressourcen f\u00fcr die Verarbeitung einer Anfrage zu nutzen. Angenommen, Sie haben einen Server mit 56 CPU-Kernen. Wenn Sie eine Anfrage ausf\u00fchren, die eine Sekunde dauert, werden alle 56 Kerne verwendet. Wenn Sie jedoch 200 ClickHouse-Instanzen auf demselben Server hosten, werden 10.000 Threads gestartet. Das Ergebnis wird sehr ineffizient sein.<\/p>\n
<\/p>\n
Ein weiterer Grund ist, dass die Arbeitsverteilung auf diesen Instanzen ungleichm\u00e4\u00dfig sein wird. Einige werden fr\u00fcher abgeschlossen, andere sp\u00e4ter. W\u00e4re alles in einer einzigen Instanz, k\u00f6nnte ClickHouse selbst die Daten optimal auf die Threads verteilen. <\/p>\n
<\/p>\n
Ein zus\u00e4tzlicher Grund ist, dass es zu Inter-Prozess-Kommunikation \u00fcber TCP kommen wird. Daten m\u00fcssen serialisiert und deserialisiert werden, und dabei entstehen wesentlich mehr Mikroscharten. Das f\u00fchrt zu einer ineffizienten Arbeitsweise.<\/p>\n
<\/p>\n
<\/p>\n
Ein weiteres Problem, obwohl es schwer als solches zu bezeichnen ist, ist die gro\u00dfe Anzahl an Voraggregation.<\/p>\n
<\/p>\n
Im Grunde genommen ist Pr\u00e4daggregation vorteilhaft. Hatten Sie eine Milliarde Zeilen, haben Sie sie aggregiert, und es sind nur noch 1.000 Zeilen \u00fcbrig, sodass die Abfrage jetzt blitzschnell ausgef\u00fchrt wird. Alles ist wunderbar. So kann man das machen. Daf\u00fcr gibt es sogar in ClickHouse einen speziellen Tabellentyp, den AggregatingMergeTree, der inkrementelle Aggregationen w\u00e4hrend des Datenimports durchf\u00fchrt. <\/p>\n
<\/p>\n
Es gibt jedoch Situationen, in denen man denkt, dass wir die Daten so aggregieren werden und dann noch auf diese Weise. Und in einer benachbarten Abteilung, die ich lieber nicht benennen m\u00f6chte, verwenden sie SummingMergeTree-Tabellen zur Summierung nach dem Prim\u00e4rschl\u00fcssel, wobei sie als Prim\u00e4rschl\u00fcssel etwa 20 verschiedene Spalten nutzen. Ich habe zur Sicherheit einige Spaltennamen f\u00fcr die Anonymit\u00e4t ge\u00e4ndert, aber so in etwa ist es.<\/p>\n
<\/p>\n
<\/p>\n
Hierbei entstehen bestimmte Probleme. Erstens verringert sich das Datenvolumen nicht signifikant. Beispielsweise reduziert es sich nur um das Dreifache. Dreimal w\u00e4re ein akzeptabler Preis, um sich unbegrenzte Analytik-M\u00f6glichkeiten leisten zu k\u00f6nnen, die entstehen, wenn die Daten unaggregiert sind. Wenn die Daten jedoch aggregiert sind, erhalten Sie statt einer Analyse lediglich mickrige Statistiken. <\/p>\n
<\/p>\n
Und was besonders \u00e4rgerlich ist? Dass diese Leute aus der benachbarten Abteilung manchmal kommen und bitten, eine weitere Spalte zum Prim\u00e4rschl\u00fcssel hinzuzuf\u00fcgen. Das hei\u00dft, wir haben die Daten so aggregiert, und jetzt wollen wir etwas mehr. Aber in ClickHouse gibt es keinen Befehl zum \u00c4ndern des Prim\u00e4rschl\u00fcssels. Daher muss man irgendwelche Skripte in C++ schreiben. Und ich mag Skripte nicht, selbst wenn sie in C++ sind.<\/p>\n
<\/p>\n
Wenn man sich anschaut, wof\u00fcr ClickHouse entwickelt wurde, sind nicht aggregierte Daten genau das Szenario, f\u00fcr das es gedacht ist. Wenn Sie ClickHouse f\u00fcr nicht aggregierte Daten nutzen, machen Sie alles richtig. Aggregieren Sie jedoch, ist das manchmal verzeihlich. <\/p>\n
<\/p>\n
<\/p>\n
Ein weiterer interessanter Fall sind Anfragen in einer Endlosschleife. Manchmal gehe ich auf einen Produktionsserver und schaue mir dort die Prozessliste an. Und jedes Mal entdecke ich, dass etwas Schreckliches passiert. <\/p>\n
<\/p>\n
Zum Beispiel so etwas. Hier ist sofort klar, dass alles in einer einzigen Anfrage h\u00e4tte ausgef\u00fchrt werden k\u00f6nnen. Einfach dort url in und die Liste schreiben.<\/p>\n
<\/p>\n
<\/p>\n
Warum ist es schlecht, wenn viele solcher Anfragen in einer Endlosschleife auftreten? Wenn der Index nicht verwendet wird, durchlaufen Sie dieselben Daten viele Male. Aber wenn der Index verwendet wird, zum Beispiel wenn Sie einen Prim\u00e4rschl\u00fcssel f\u00fcr ru haben und url = irgendetwas schreiben. Und Sie denken, dass eine spezifische url aus der Tabelle abgerufen wird, wird alles gut sein. In Wirklichkeit ist das jedoch nicht der Fall. Denn ClickHouse macht alles in Chargen. <\/p>\n
<\/p>\n
Wenn es notwendig ist, einen bestimmten Datenbereich zu lesen, wird etwas mehr gelesen, da der Index in ClickHouse sp\u00e4rlich ist. Dieser Index kann nicht eine einzelne Zeile in der Tabelle finden, sondern nur einen bestimmten Bereich. Die Daten werden blockweise komprimiert. Um eine einzige Zeile zu lesen, muss der gesamte Block genommen und dekomprimiert werden. Wenn Sie also viele Anfragen ausf\u00fchren, wird es viele \u00dcberschneidungen geben und eine Menge Arbeit wird immer wiederholt.<\/p>\n
<\/p>\n
<\/p>\n
Ein Bonus, den man erw\u00e4hnen sollte, ist, dass man in ClickHouse keine Angst haben muss, sogar Megabytes und Hundert Megabytes in die IN-Klausel zu \u00fcbergeben. Aus unserer Erfahrung wei\u00df ich, dass MySQL, wenn wir viele Werte in die IN-Klausel \u00fcbergeben, beispielsweise 100 Megabyte irgendwelcher Zahlen, 10 Gigabyte Arbeitsspeicher ben\u00f6tigt und dann nichts weiter passiert \u2013 alles funktioniert schlecht. <\/p>\n
<\/p>\n
Und der zweite Punkt ist, dass in ClickHouse, wenn Ihre Abfragen einen Index verwenden, sie niemals langsamer sind als ein Full Scan, d. h. wenn nahezu die gesamte Tabelle gelesen werden muss, erfolgt dies sequentiell und es wird die gesamte Tabelle gelesen. ClickHouse organisiert das selbst.<\/p>\n
<\/p>\n
Dennoch gibt es einige Herausforderungen. Zum Beispiel wird der IN-Befehl mit Unterabfragen keinen Index benutzen. Das ist unser Problem und wir m\u00fcssen das beheben. Es gibt hier nichts Fundamentales. Wir werden es reparieren. <\/p>\n
<\/p>\n
Und noch etwas Interessantes \u2013 wenn Sie eine sehr lange Abfrage haben und die Abfragedistribution auf mehreren Servern erfolgt, wird diese sehr lange Abfrage auf jeden Server ohne Kompression gesendet. Zum Beispiel 100 Megabyte und 500 Server. Somit werden \u00fcber das Netzwerk 50 Gigabyte \u00fcbertragen. Es wird \u00fcbertragen und alles wird anschlie\u00dfend erfolgreich ausgef\u00fchrt.<\/p>\n
<\/p>\n
* nutzt bereits; alles wurde wie versprochen repariert.<\/p>\n
<\/p>\n
<\/p>\n
Es ist durchaus h\u00e4ufig, dass Anfragen aus APIs kommen. Angenommen, Sie haben einen eigenen Dienst. Und wenn dieser Dienst ben\u00f6tigt wird, haben Sie eine API ge\u00f6ffnet und sehen bereits nach zwei Tagen, dass etwas Ungew\u00f6hnliches passiert. Alles ist \u00fcberlastet und es kommen schreckliche Anfragen, die niemals gestellt werden sollten. <\/p>\n
<\/p>\n
Die L\u00f6sung ist einfach. Wenn Sie eine API ge\u00f6ffnet haben, m\u00fcssen Sie sie limitieren. Zum Beispiel, indem Sie Quoten einf\u00fchren. Es gibt keine anderen vern\u00fcnftigen Optionen. Andernfalls wird sofort ein Skript geschrieben, und es gibt Probleme. <\/p>\n
<\/p>\n
In ClickHouse gibt es eine spezielle Funktion - die Quotenverwaltung. Sie k\u00f6nnen sogar Ihren eigenen Quoten-Schl\u00fcssel \u00fcbergeben. Dies k\u00f6nnte beispielsweise eine interne Benutzer-ID sein. Die Quoten werden dann unabh\u00e4ngig f\u00fcr jeden einzelnen von ihnen gez\u00e4hlt. <\/p>\n
<\/p>\n
<\/p>\n
Jetzt noch etwas Interessantes. Dies betrifft die manuelle Replikation. <\/p>\n
<\/p>\n
Ich kenne viele F\u00e4lle, in denen, obwohl ClickHouse eine integrierte Unterst\u00fctzung f\u00fcr Replikation bietet, die Leute ClickHouse manuell replizieren.<\/p>\n
<\/p>\n
Welches Prinzip? Sie haben eine Datenverarbeitungspipeline, die unabh\u00e4ngig funktioniert, zum Beispiel in verschiedenen Rechenzentren. Sie zeichnen die gleichen Daten auf die gleiche Weise in ClickHouse auf. Allerdings zeigt die Praxis, dass die Daten aufgrund bestimmter Besonderheiten in Ihrem Code trotzdem voneinander abweichen werden. Ich hoffe, das ist bei Ihnen nicht der Fall. <\/p>\n
<\/p>\n
Und hin und wieder m\u00fcssen Sie trotzdem manuell synchronisieren. Beispielsweise f\u00fchren die Administratoren einmal im Monat einen rsync durch.<\/p>\n
<\/p>\n
Tats\u00e4chlich ist es viel einfacher, die eingebaute Replikation in ClickHouse zu verwenden. Es gibt jedoch einige Vorbehalte, denn daf\u00fcr muss ZooKeeper verwendet werden. Ich werde nichts Schlechtes \u00fcber ZooKeeper sagen; grunds\u00e4tzlich ist das System funktional, aber manchmal vermeiden es die Leute aufgrund von Java-Phobie, weil ClickHouse ein tolles System ist, das in C++ geschrieben wurde und sehr gut funktioniert. ZooKeeper hingegen l\u00e4uft auf Java. Und es ist irgendwie nicht angenehm, sich damit zu besch\u00e4ftigen; dann k\u00f6nnen Sie auch die manuelle Replikation nutzen. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse ist ein praktisches System, das auf Ihre Bed\u00fcrfnisse zugeschnitten ist. Wenn Sie manuelle Replikation verwenden, k\u00f6nnen Sie eine verteilte Tabelle erstellen, die auf Ihre manuellen Replikate zugreift und automatisch zwischen ihnen Failover durchf\u00fchrt. Es gibt sogar eine spezielle Option, die es Ihnen erm\u00f6glicht, Flaps zu vermeiden, selbst wenn Ihre Replikate systematisch voneinander abweichen.<\/p>\n
<\/p>\n
<\/p>\n
Es k\u00f6nnen Probleme auftreten, wenn Sie primitive Tabellen-Engines verwenden. ClickHouse ist ein Aufbau mit einer Vielzahl verschiedener Tabellengere, die Sie nutzen k\u00f6nnen. F\u00fcr alle ernsthaften Anwendungsf\u00e4lle, wie in der Dokumentation beschrieben, verwenden Sie Tabellen der MergeTree-Familie. Alle anderen sind f\u00fcr spezielle F\u00e4lle oder f\u00fcr Tests gedacht.<\/p>\n
<\/p>\n
In einer MergeTree-Tabelle ist es nicht unbedingt erforderlich, dass Sie ein Datum und eine Uhrzeit haben. Sie k\u00f6nnen es dennoch verwenden. Wenn kein Datum und keine Uhrzeit vorhanden sind, geben Sie an, dass das Standarddatum das Jahr 2000 ist. Das funktioniert und erfordert keine zus\u00e4tzlichen Ressourcen. <\/p>\n
<\/p>\n
In der neuen Serverversion k\u00f6nnen Sie sogar angeben, dass Sie eine benutzerdefinierte Partitionierung ohne Partitionierungsschl\u00fcssel haben m\u00f6chten. Es wird dasselbe sein. <\/p>\n
<\/p>\n
<\/p>\n
Auf der anderen Seite k\u00f6nnen primitive Tabellen-Engines verwendet werden. Zum Beispiel, einmalige Datenzufuhr und dann analysieren, drehen und l\u00f6schen. Sie k\u00f6nnen Log verwenden.<\/p>\n
<\/p>\n
Oder die Speicherung kleiner Datenmengen f\u00fcr die Zwischenverarbeitung \u2013 das ist StripeLog oder TinyLog.<\/p>\n
<\/p>\n
Memory kann genutzt werden, wenn nur eine kleine Datenmenge vorhanden ist und einfach etwas im RAM gedreht werden soll. <\/p>\n
<\/p>\n
<\/p>\n
ClickHouse mag \u00fcbernormalisierte Daten nicht besonders. <\/p>\n
<\/p>\n
Hier ist ein typisches Beispiel. Das ist eine gro\u00dfe Anzahl von URLs. Sie haben sie in eine benachbarte Tabelle gesteckt. Dann haben Sie entschieden, einen JOIN damit durchzuf\u00fchren, aber das wird in der Regel nicht funktionieren, da ClickHouse nur Hash JOIN unterst\u00fctzt. Wenn nicht gen\u00fcgend RAM vorhanden ist, um mit den vielen Daten, die verbunden werden m\u00fcssen, umzugehen, kann der JOIN nicht durchgef\u00fchrt werden*. <\/p>\n
<\/p>\n
Wenn die Daten eine hohe Kardinalit\u00e4t haben, machen Sie sich keine Sorgen, speichern Sie sie in denormalisierter Form, URLs direkt inplace in der Haupttabelle. <\/p>\n
<\/p>\n
* mittlerweile gibt es in ClickHouse auch den Merge-Join, der funktioniert, wenn die Zwischendaten nicht in den RAM passen. Aber es ist ineffizient und die Empfehlung bleibt bestehen.<\/p>\n
<\/p>\n
<\/p>\n
Hier sind noch ein paar Beispiele, aber ich bin mir nicht mehr sicher, ob sie wirklich Antipattern sind oder nicht. <\/p>\n
<\/p>\n
ClickHouse hat einen bekannten Nachteil: Es unterst\u00fctzt keine Updates*. Das hat sogar seine Vorteile. Wenn Sie wichtige Daten haben, etwa aus der Buchhaltung, k\u00f6nnen diese nicht versendet werden, da keine Updates vorhanden sind.<\/p>\n
<\/p>\n
* Unterst\u00fctzung f\u00fcr Updates und Deletes im Batch-Modus wurde bereits lange hinzugef\u00fcgt.<\/p>\n
<\/p>\n
Es gibt jedoch einige spezielle Methoden, mit denen Updates quasi im Hintergrund durchgef\u00fchrt werden k\u00f6nnen. Zum Beispiel Tabellen des Typs ReplaceMergeTree, die Updates w\u00e4hrend der Hintergrundmerges durchf\u00fchren. Sie k\u00f6nnen dies mit dem Befehl optimize table forcieren. Aber machen Sie das nicht zu oft, denn das f\u00fchrt zur vollst\u00e4ndigen Neubeschreibung der Partition. <\/p>\n
<\/p>\n
Verteilte JOINS in ClickHouse werden vom Abfrageplaner ebenfalls schlecht behandelt. <\/p>\n
<\/p>\n
Schlecht, aber manchmal in Ordnung.<\/p>\n
<\/p>\n
Die Nutzung von ClickHouse nur, um Daten \u00fcber select* wieder abzurufen.<\/p>\n
<\/p>\n
Ich w\u00fcrde nicht empfehlen, ClickHouse f\u00fcr rechenintensive Berechnungen zu verwenden. Das ist jedoch nicht ganz richtig, weil wir von dieser Empfehlung abweichen. Neu hinzugekommen ist die M\u00f6glichkeit, Machine-Learning-Modelle in ClickHouse zu verwenden \u2013 Catboost. Das beunruhigt mich, denn ich frage mich: \u201eWie viele Taktzyklen pro Byte gibt es da?\u201c Es tut mir leid, Taktzyklen f\u00fcr Bytes zu verwenden. <\/p>\n
<\/p>\n
<\/p>\n
Keine Sorge, installieren Sie ClickHouse, alles wird gut. Sollte es Probleme geben, haben wir eine Community. \u00dcbrigens, die Community sind Sie. Falls Sie Schwierigkeiten haben, k\u00f6nnen Sie gerne 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 Ausfall von ClickHouse beschweren?<\/em><\/p>\n<\/p>\n
Sie k\u00f6nnen sich direkt jetzt an mich wenden. <\/p>\n
<\/p>\n
Ich habe vor kurzem angefangen, ClickHouse zu nutzen. Ich habe sofort die CLI-Oberfl\u00e4che zum Absturz gebracht.<\/em><\/p>\n<\/p>\n
Sie haben Gl\u00fcck gehabt. <\/p>\n
<\/p>\n
Ein wenig sp\u00e4ter habe ich den Server mit einer kleinen SELECT-Abfrage 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
Mal sehen. <\/p>\n
<\/p>\n
Alexey hat mich unter falschem Vorwand zur Pr\u00e4sentation gebracht, indem er versprach, mir zu zeigen, wie Sie die Daten intern komprimieren.<\/em><\/p>\n<\/p>\n
Sehr einfach. <\/p>\n
<\/p>\n
Das habe ich schon gestern verstanden. Mehr Details bitte.<\/em> <\/p>\n<\/p>\n
Es gibt keine furchtbaren Tricks. Es handelt sich einfach um eine Blockkomprimierung. Standardm\u00e4\u00dfig wird LZ4 verwendet, ZSTD* kann jedoch aktiviert werden. Bl\u00f6cke reichen von 64 Kilobyte bis 1 Megabyte.<\/p>\n
<\/p>\n
* Es gibt auch Unterst\u00fctzung f\u00fcr spezialisierte Komprimierungs-Codecs, die in Kombination mit anderen Algorithmen verwendet werden k\u00f6nnen.<\/p>\n
<\/p>\n
Sind in den Bl\u00f6cken einfach nur rohe Daten?<\/em><\/p>\n<\/p>\n
Nicht ganz roh. Es sind dort Arrays. Wenn Sie eine numerische Spalte haben, sind die Zahlen hintereinander in einem Array angeordnet. <\/p>\n
<\/p>\n
Verstanden.<\/em> <\/p>\n<\/p>\n
Alexej, ein Beispiel, das mit uniqExact bei IP-Adressen gezeigt wurde, d. h. dass uniqExact f\u00fcr Strings l\u00e4nger ben\u00f6tigt als f\u00fcr Zahlen usw. Aber was passiert, wenn wir einen Trick anwenden und beim Lesen casten? Sie haben anscheinend gesagt, dass sich das auf der Festplatte nicht wesentlich unterscheidet. Wenn wir beim Lesen von Strings von der Festplatte casten, werden unsere Aggregationen dann schneller oder nicht? Oder gewinnen wir hier doch nur minimal? Ich glaube, Sie haben das getestet, aber warum haben Sie es im Benchmark nicht angegeben?<\/em> <\/p>\n<\/p>\n
Ich denke, es wird langsamer sein als ohne Casting. In diesem Fall m\u00fcsste die IP-Adresse aus der Zeichenfolge geparst werden. Nat\u00fcrlich ist das Parsen von IP-Adressen in ClickHouse auch optimiert. Wir haben uns wirklich M\u00fche gegeben, aber die Zahlen sind bei Ihnen in einer Zehntausenderdarstellung gespeichert. Sehr unpraktisch. Andererseits wird die Funktion uniqExact bei Strings langsamer arbeiten, nicht nur weil es Strings sind, sondern auch weil eine andere Algorithmusspezialisierung ausgew\u00e4hlt wird. Strings werden einfach anders verarbeitet.<\/p>\n
<\/p>\n
Und was ist, wenn wir einen primitiveren Datentyp nehmen? Zum Beispiel, wir haben die user id, die wir als String gespeichert haben, und dann gecastet, wird es interessanter oder nicht?<\/em><\/p>\n<\/p>\n
Ich habe Zweifel. Ich denke, es wird sogar noch trauriger, denn das Parsen von Zahlen ist ein ernstes Problem. Ich glaube, dieser Kollege hatte sogar einen Vortrag dar\u00fcber gehalten, wie schwierig es ist, Zahlen im Zehntausenderformat zu parsen, oder vielleicht auch nicht. <\/p>\n
<\/p>\n
Alexey, vielen Dank f\u00fcr den Vortrag! Und auch vielen Dank f\u00fcr ClickHouse! Ich habe eine Frage zu den Pl\u00e4nen. Ist eine Funktion f\u00fcr ein teilweises Update der Dictionate geplant?<\/em><\/p>\n<\/p>\n
Also eine partielle Neuinitialisierung?<\/p>\n
<\/p>\n
Ja, genau. Eine M\u00f6glichkeit, ein MySQL-Feld anzugeben, um nur die Daten zu aktualisieren, die nach einem bestimmten Punkt geladen werden, wenn das Dictionary sehr gro\u00df ist.<\/em><\/p>\n<\/p>\n
Eine sehr interessante Funktion. Ich glaube, jemand hat das 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
Ausgezeichnet, jetzt haben wir also zwei Anfragen. Und wir k\u00f6nnen gem\u00fctlich damit anfangen. Aber ich m\u00f6chte Sie gleich warnen, dass diese Funktion recht einfach zu implementieren ist. Man m\u00fcsste theoretisch einfach die Versionsnummer in die Tabelle schreiben und dann angeben: Version ist kleiner als die bestimmte Zahl. Das bedeutet, dass wir wahrscheinlich den Enthusiasten vorschlagen werden, dies zu \u00fcbernehmen. 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 sein 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 ihm zur Verf\u00fcgung stehenden Ressourcen sehr gut nutzt. Der Referent neben Luxoft sprach \u00fcber seine L\u00f6sung f\u00fcr die russische Post. Er sagte, dass ihnen ClickHouse sehr gefallen hat, sie es aber nicht anstelle ihres Hauptkonkurrenten verwendet haben, weil es die gesamte CPU verschlang. Und sie konnten es nicht in ihre Architektur integrieren, in ihren ZooKeeper mit den Docker-Containern. Gibt es eine M\u00f6glichkeit, ClickHouse so zu beschr\u00e4nken, dass 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, dann schreiben Sie einfach set max_threads = 1<\/code>. Und dann wird die Anfrage auf einem Kern ausgef\u00fchrt. Au\u00dferdem k\u00f6nnen verschiedenen Benutzern unterschiedliche Einstellungen zugewiesen werden. Das sind also \u00fcberhaupt keine Probleme. Und bitte teilen Sie den Kollegen von Luxoft mit, dass es nicht gut ist, dass sie diese Einstellung nicht in der Dokumentation gefunden haben. <\/p>\n<\/p>\n
Hallo Alexey! Ich m\u00f6chte eine Frage stellen. Ich habe schon \u00f6fter geh\u00f6rt, dass viele ClickHouse als Speichersystem f\u00fcr Logs verwenden. In Ihrem Vortrag haben Sie gesagt, dass man das nicht tun sollte, also dass man keine langen Zeilen speichern sollte. Wie stehen Sie dazu?<\/em><\/p>\n<\/p>\n
Zun\u00e4chst einmal sind Logs in der Regel keine langen Zeilen. Es gibt nat\u00fcrlich Ausnahmen. Zum Beispiel, wenn ein Service, der in Java geschrieben ist, eine Ausnahme ausl\u00f6st, wird dies protokolliert. Und das geschieht in einer Endlosschleife, wodurch der Speicherplatz auf der Festplatte knapp wird. Die L\u00f6sung ist ganz einfach: Wenn die Zeilen sehr lang sind, schneiden Sie sie ab. Aber was bedeutet 'lang'? Zehntausende von Bytes \u2013 das ist schlecht*.<\/p>\n
<\/p>\n
* In den neuesten Versionen von ClickHouse ist die "adaptive Granularit\u00e4t des Indexes" aktiviert, was das Problem der Speicherung langer Strings gr\u00f6\u00dftenteils behebt.<\/p>\n
<\/p>\n
Ist ein Kilobyte normal?<\/em><\/p>\n<\/p>\n
Das ist normal. <\/p>\n
<\/p>\n
Hallo! Danke f\u00fcr Ihren Vortrag! Ich habe dazu bereits im Chat gefragt, erinnere mich aber nicht, ob ich eine Antwort erhalten habe. Ist es geplant, die WITH-Sektion in der Art von CTE zu erweitern?<\/em><\/p>\n<\/p>\n
Momentan nicht. Die WITH-Sektion ist bei uns etwas unbedeutend. Sie ist eine kleine Funktion.<\/p>\n
<\/p>\n
Ich verstehe. Danke!<\/em><\/p>\n<\/p>\n
Vielen Dank f\u00fcr den Vortrag! Sehr interessant! Eine globale Frage. Ist geplant, eventuell in Form von Platzhaltern eine Modifikation f\u00fcr die Datenl\u00f6schung zu erstellen?<\/em><\/p>\n<\/p>\n
Ja, unbedingt. Das ist unsere erste Aufgabe in der Warteschlange. Wir haben bereits aktiv \u00fcberlegt, wie wir alles richtig umsetzen k\u00f6nnen. Und es ist Zeit, mit dem Tippen auf der Tastatur zu beginnen*.<\/p>\n
<\/p>\n
* Wir 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 die Einf\u00fcgung genauso schnell sein wie bisher?<\/em><\/p>\n<\/p>\n
M\u00f6glicherweise werden die L\u00f6sch- und Aktualisierungsoperationen sehr aufwendig sein, aber das wird sich nicht auf die Leistung der Abfragen und Einf\u00fcgungen auswirken.<\/p>\n
<\/p>\n
Und noch eine kleine Frage. In der Pr\u00e4sentation sprachen Sie \u00fcber den Prim\u00e4rschl\u00fcssel. Entsprechend haben wir eine Partitionierung, die standardm\u00e4\u00dfig monatlich ist, richtig? Und wenn wir einen Datumsbereich angeben, 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 definieren k\u00f6nnen, ist es sinnvoll, ihn anhand des Feldes \"Datum\" zu erstellen, um eine geringere Umschichtung dieser Daten im Hintergrund zu erm\u00f6glichen, damit sie ordentlicher sortiert werden? Wenn Sie keine Bereichsanfragen haben und keinen Prim\u00e4rschl\u00fcssel ausw\u00e4hlen k\u00f6nnen, sollte dann das Datum im Prim\u00e4rschl\u00fcssel enthalten sein?<\/em><\/p>\n<\/p>\n
Ja.<\/p>\n
<\/p>\n
Vielleicht macht es Sinn, ein Feld im Prim\u00e4rschl\u00fcssel zu haben, nach dem die Daten besser komprimiert werden, wenn sie nach diesem Feld sortiert sind. Zum Beispiel die ID des Benutzers. Der Benutzer besucht h\u00e4ufig dieselbe Website. In diesem Fall f\u00fcgen Sie die Benutzer-ID und die Zeit hinzu. Dann werden Ihre Daten besser komprimiert. Was das Datum betrifft: Wenn Sie wirklich keine und niemals Bereichsanfragen nach Daten haben, k\u00f6nnen Sie das Datum auch aus dem Prim\u00e4rschl\u00fcssel herauslassen. <\/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
![\"Effektive](\"\/wp-content\/uploads\/2020\/08\/8e42c1fffffcc964eacef240ea90bbc5.jpg\")
<\/p>\n