{"id":74737,"date":"2020-03-20T08:43:14","date_gmt":"2020-03-20T05:43:14","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa"},"modified":"2020-03-20T08:43:14","modified_gmt":"2020-03-20T05:43:14","slug":"optimizacziya-strok-v-clickhouse-doklad-yandeksa","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","title":{"rendered":"Optimierung von Abfragen in ClickHouse. Bericht von Yandex","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Die analytische Datenbank ClickHouse verarbeitet eine Vielzahl von verschiedenen Zeichenfolgen, wobei Ressourcen verbraucht werden. Um die Systemleistung zu steigern, werden kontinuierlich neue Optimierungen hinzugef\u00fcgt. Der Entwickler von ClickHouse, Nikolai Kochetov, spricht \u00fcber den Datentyp String, einschlie\u00dflich des neuen Typs LowCardinality, und erkl\u00e4rt, wie man die Verarbeitung von Zeichenfolgen beschleunigen kann. <\/p>\n

\r\n \"Video\r\n
<\/div>\r\n <\/div><\/center>
\nLassen Sie uns zun\u00e4chst kl\u00e4ren, wie man Zeichenfolgen speichern kann.
\n<\/a><\/noindex>
\n\"Optimierung
\n
\nWir verf\u00fcgen \u00fcber Zeichenfolgendatentypen. Der Typ String eignet sich standardm\u00e4\u00dfig gut und sollte fast immer verwendet werden. Er hat einen geringen Overhead von 9 Byte pro Zeichenfolge. Wenn wir m\u00f6chten, dass die Gr\u00f6\u00dfe der Zeichenfolgen fest und im Voraus bekannt ist, sollten wir besser FixedString verwenden. Dabei kann die gew\u00fcnschte Anzahl von Bytes festgelegt werden, was ihn ideal f\u00fcr Daten wie IP-Adressen oder Hash-Funktionen macht. <\/p>\n

\"Optimierung
\n
\nNat\u00fcrlich gibt es manchmal Engp\u00e4sse. Angenommen, Sie f\u00fchren eine Abfrage auf einer Tabelle aus. ClickHouse liest eine betr\u00e4chtliche Menge an Daten, sagen wir, mit einer Geschwindigkeit von 100 GB\/s, w\u00e4hrend nur wenige Zeichenfolgen verarbeitet werden. Wir haben zwei Tabellen, die nahezu identische Daten speichern. Aus der zweiten Tabelle liest ClickHouse die Daten schneller, verarbeitet jedoch drei Mal weniger Zeichenfolgen pro Sekunde. <\/p>\n

\"Optimierung
\n
\nWenn wir die Gr\u00f6\u00dfe der komprimierten Daten betrachten, wird sie nahezu identisch sein. Tats\u00e4chlich sind in den Tabellen die gleichen Daten aufgezeichnet \u2013 die ersten eine Milliarde Zahlen \u2013 nur im ersten Spaltenformat als UInt64 und im zweiten als String. Dadurch ben\u00f6tigt die zweite Abfrage l\u00e4nger, um die Daten von der Festplatte zu lesen und sie zu dekomprimieren. <\/p>\n

\"Optimierung
\n
\nHier ist ein weiteres Beispiel. Angenommen, es gibt eine bekannte Menge von Zeichenfolgen, die konstant auf 1000 oder 10.000 beschr\u00e4nkt ist und sich praktisch nie \u00e4ndert. F\u00fcr diesen Fall eignet sich der Datentyp Enum - in ClickHouse gibt es zwei Varianten: Enum8 und Enum16. Durch die Speicherung in Enum k\u00f6nnen wir Abfragen schnell verarbeiten. <\/p>\n

In ClickHouse gibt es Optimierungen f\u00fcr GROUP BY, IN, DISTINCT und spezifische Optimierungen f\u00fcr einige Funktionen, wie z. B. den Vergleich mit einer konstanten Zeichenfolge. Nat\u00fcrlich werden die Zahlen in der Zeichenfolge nicht konvertiert, sondern die konstante Zeichenfolge wird in den Enum-Wert umgewandelt. Danach erfolgt der Vergleich schnell. <\/p>\n

Es gibt jedoch auch Nachteile. Selbst wenn wir die exakte Menge von Zeichenfolgen kennen, muss sie manchmal erweitert werden. Wenn eine neue Zeichenfolge hinzukommt, m\u00fcssen wir einen ALTER-Befehl ausf\u00fchren. <\/p>\n

\"Optimierung
\n
\nDer ALTER-Befehl f\u00fcr Enum in ClickHouse ist optimal implementiert. Wir schreiben keine Daten auf die Festplatte um, aber ALTER kann verz\u00f6gert werden, weil die Enum-Strukturen im Schema der Tabelle gespeichert sind. Daher m\u00fcssen wir auf Leseanfragen an die Tabelle warten, zum Beispiel. <\/p>\n

Es stellt sich die Frage, ob es besser gemacht werden kann. Vermutlich ja. Man k\u00f6nnte die Enum-Struktur nicht im Tabellenschema, sondern in ZooKeeper speichern. Allerdings k\u00f6nnten hierbei Synchronisationsprobleme auftreten. Zum Beispiel k\u00f6nnte eine Replik Daten erhalten haben, w\u00e4hrend eine andere nicht, und wenn diese eine alte Enum hat, k\u00f6nnte etwas kaputtgehen. (In ClickHouse haben wir fast die nicht-blockierenden ALTER-Anfragen fertiggestellt. Sobald wir sie vollst\u00e4ndig implementiert haben, muss man nicht mehr auf Leseanfragen warten.)<\/p>\n

\"Optimierung
\n
\nUm sich mit ALTER Enum nicht herumzuschlagen, k\u00f6nnen externe Dictionnaires in ClickHouse verwendet werden. Ich erinnere daran, dass dies eine Key-Value-Datenstruktur innerhalb von ClickHouse ist, mit der Daten aus externen Quellen abgerufen werden k\u00f6nnen, zum Beispiel aus MySQL-Tabellen. <\/p>\n

Im ClickHouse-W\u00f6rterbuch speichern wir zahlreiche verschiedene Strings, w\u00e4hrend in der Tabelle deren Identifikatoren in Form von Zahlen enthalten sind. Wenn wir einen String ben\u00f6tigen, rufen wir die Funktion dictGet auf und arbeiten mit ihm. Danach sollten wir kein ALTER durchf\u00fchren. Um etwas in Enum hinzuzuf\u00fcgen, f\u00fcgen wir es in dieselbe MySQL-Tabelle ein. <\/p>\n

Hier treten jedoch weitere Probleme auf. Erstens, die unhandliche Syntax. Wenn wir einen String abrufen m\u00f6chten, m\u00fcssen wir dictGet aufrufen. Zweitens, das Fehlen einiger Optimierungen. Ein Vergleich mit einer konstanten Zeichenkette f\u00fcr W\u00f6rterb\u00fccher ist genauso schnell nicht zu bewerkstelligen. <\/p>\n

Es kann auch Probleme mit Aktualisierungen geben. Angenommen, wir haben einen String im Cache-W\u00f6rterbuch angefordert, und er ist nicht im Cache gelandet. Dann m\u00fcssen wir warten, bis die Daten aus einer externen Quelle geladen werden. <\/p>\n

\"Optimierung
\n
\nEin allgemeiner Nachteil beider Methoden ist, dass wir alle Schl\u00fcssel an einem Ort speichern und sie synchronisieren. Warum also nicht die W\u00f6rterb\u00fccher lokal speichern? Keine Synchronisierung \u2013 keine Probleme. Man kann das W\u00f6rterbuch lokal in einem Segment auf der Festplatte speichern. Das hei\u00dft, wir haben Insert gemacht und das W\u00f6rterbuch aufgezeichnet. Wenn wir mit Daten im Speicher arbeiten, k\u00f6nnen wir das W\u00f6rterbuch entweder in einem Datenblock, in einem Abschnitt der Spalte oder in einem Cache speichern, um die Berechnungen zu beschleunigen.<\/p>\n

W\u00f6rterbuchkodierung von Zeichenfolgen <\/h3>\n

\nSo sind wir zur Schaffung eines neuen Datentyps in ClickHouse gekommen \u2013 LowCardinality. Dies ist ein Datenformat: wie sie auf die Festplatte geschrieben werden und wie sie gelesen werden, wie sie im Speicher dargestellt werden und wie sie verarbeitet werden. <\/p>\n

\"Optimierung
\n
\nAuf der Folie gibt es zwei Spalten. Rechts werden die Zeichenfolgen standardm\u00e4\u00dfig im Typ String gespeichert. Man sieht, dass es sich um verschiedene Modelle von Mobiltelefonen handelt. Links gibt es eine genau gleiche Spalte, aber im Typ LowCardinality. Diese besteht aus einem W\u00f6rterbuch mit vielen verschiedenen Zeichenfolgen (Zeichenfolgen aus der rechten Spalte) und einer Liste von Positionen (Zeilennummern). <\/p>\n

Mit diesen beiden Strukturen kann die urspr\u00fcngliche Spalte wiederhergestellt werden. Es gibt auch einen umgekehrten Index \u2013 eine Hash-Tabelle, die hilft, die Position im W\u00f6rterbuch anhand der Zeichenfolge zu finden. Diese ist notwendig, um einige Anfragen zu beschleunigen. Zum Beispiel, wenn wir eine Zeichenfolge in unserer Spalte vergleichen, suchen oder zusammenf\u00fchren m\u00f6chten. <\/p>\n

LowCardinality ist ein parametrisierter Datentyp. Er kann entweder eine Zahl sein, etwas, das als Zahl gespeichert ist, oder eine Zeichenfolge, oder auch Nullable von diesen. <\/p>\n

\"Optimierung
\n
\nEin Merkmal von LowCardinality ist, dass es f\u00fcr bestimmte Funktionen gespeichert werden kann. Auf der Folie ist ein Beispielabfrage zu sehen. In der ersten Zeile habe ich eine Spalte vom Typ LowCardinality vom Typ String erstellt und sie S genannt. Anschlie\u00dfend habe ich nach ihrem Namen gefragt \u2013 ClickHouse sagte, dass es sich um LowCardinality von String handelt. Das ist korrekt.<\/p>\n

Die dritte Zeile ist fast identisch, nur dass wir die Funktion length aufgerufen haben. In ClickHouse gibt die Funktion length den Datentyp UInt64 zur\u00fcck. Aber jetzt haben wir LowCardinality von UInt64. Was ist der Sinn?<\/p>\n

\"Optimierung
\n
\nIm W\u00f6rterbuch wurden die Namen von Mobiltelefonen gespeichert, und wir haben die Funktion length angewendet. Jetzt haben wir ein \u00e4hnliches W\u00f6rterbuch, das nur aus Zahlen besteht \u2013 das sind die L\u00e4ngen der Strings. Die Spalte mit den Positionen hat sich nicht ver\u00e4ndert. Letztendlich haben wir weniger Daten verarbeitet und somit Zeit bei der Abfrage gespart. <\/p>\n

Es k\u00f6nnten auch andere Optimierungen vorgenommen werden, wie zum Beispiel die Hinzuf\u00fcgung eines einfachen Caches. Bei der Berechnung des Funktionswerts k\u00f6nnte man ihn speichern und ein gleichwertiges Ergebnis liefern, ohne ihn erneut zu berechnen. <\/p>\n

Eine Optimierung von GROUP BY kann ebenfalls vorgenommen werden, da unsere Spalte mit dem W\u00f6rterbuch bereits teilweise aggregiert ist \u2013 so k\u00f6nnen die Hash-Wertberechnungen schneller erfolgen und der Bucket, in den die n\u00e4chste Zeile eingef\u00fcgt werden soll, schneller gefunden werden. Au\u00dferdem k\u00f6nnen einige aggregierte Funktionen spezialisiert werden, wie z. B. uniq, da dort nur das W\u00f6rterbuch gesendet werden kann, w\u00e4hrend die Positionen unber\u00fchrt bleiben \u2013 das sorgt f\u00fcr eine schnellere Verarbeitung. Die ersten beiden Optimierungen haben wir bereits in ClickHouse implementiert.<\/p>\n

\"Optimierung
\n
\nWas ist, wenn wir eine Spalte mit unserem Datentyp erstellen und viele schlechte, verschiedene Zeilen einf\u00fcgen? Wird unser Speicher \u00fcberlaufen? Nein, daf\u00fcr gibt es in ClickHouse zwei spezielle Einstellungen. Die erste ist low_cardinality_max_dictionary_size. Das ist die maximale Gr\u00f6\u00dfe des W\u00f6rterbuchs, die auf die Festplatte geschrieben werden kann. Die Einf\u00fcgung erfolgt folgenderma\u00dfen: Wenn wir Daten einf\u00fcgen, erhalten wir einen Datenstrom von Zeilen, aus denen wir ein gro\u00dfes gemeinsames W\u00f6rterbuch bilden. Wenn das W\u00f6rterbuch gr\u00f6\u00dfer wird als der Wert der Konfiguration, schreiben wir das aktuelle W\u00f6rterbuch auf die Festplatte, w\u00e4hrend die anderen Zeilen \u201enebenbei\u201c, in der N\u00e4he der Indizes, gespeichert werden. So wird nie ein gro\u00dfes W\u00f6rterbuch neu gez\u00e4hlt und wir vermeiden Speicherprobleme. <\/p>\n

Die zweite Einstellung nennt sich low_cardinality_use_single_dictionary_for_part. Stellen Sie sich vor, dass unser W\u00f6rterbuch in dem vorherigen Schema \u00fcberlaufen ist, als wir Daten eingef\u00fcgt haben, und wir es auf die Festplatte geschrieben haben. Die Frage ist, warum wir jetzt nicht ein weiteres solches W\u00f6rterbuch bilden sollen? <\/p>\n

Wenn es \u00fcberl\u00e4uft, werden wir es erneut auf die Festplatte schreiben und ein drittes zu bilden beginnen. Diese Einstellung deaktiviert standardm\u00e4\u00dfig diese M\u00f6glichkeit. <\/p>\n

Tats\u00e4chlich k\u00f6nnen mehrere W\u00f6rterb\u00fccher n\u00fctzlich sein, wenn wir eine gro\u00dfe Anzahl von Zeilen einf\u00fcgen wollen, aber versehentlich 'M\u00fcll' eingef\u00fcgt haben. Angenommen, wir haben zun\u00e4chst schlechte Zeilen eingef\u00fcgt und dann gute. Dann wird das W\u00f6rterbuch in viele kleine W\u00f6rterb\u00fccher aufgeteilt. Einige davon enthalten M\u00fcll, aber die letzten beinhalten gute Zeilen. Und wenn wir sagen wir nur das letzte Granulat lesen, wird auch alles schnell funktionieren. <\/p>\n

\"Optimierung
\n
\nBevor wir \u00fcber die Vorteile von LowCardinality sprechen, m\u00f6chte ich gleich sagen, dass wir wahrscheinlich keine Reduzierung der Daten auf der Festplatte erreichen werden (obwohl das m\u00f6glich sein k\u00f6nnte), da ClickHouse die Daten komprimiert. Es gibt eine Standardoption - LZ4. Man kann auch ZSTD zur Kompression nutzen. Beide Algorithmen nutzen jedoch bereits eine W\u00f6rterbuchkompression, weshalb unser externes W\u00f6rterbuch in ClickHouse nicht sehr hilfreich sein wird. <\/p>\n

Um meine Aussagen zu untermauern, habe ich einige Daten aus der Metrik \u2013 String, LowCardinality(String) und Enum \u2013 genommen und sie in verschiedene Datentypen gespeichert. Das Ergebnis waren drei Spalten mit insgesamt einer Milliarde Zeilen. In der ersten Spalte, CodePage, gibt es nur 62 Werte. Dabei sieht man, dass LowCardinality(String) uns eine bessere Kompression liefert. String ist etwas schlechter, was wahrscheinlich daran liegt, dass die Strings kurz sind, wir deren L\u00e4ngen speichern, und sie viel Platz einnehmen und schlecht komprimiert werden. <\/p>\n

Wenn man PhoneModel betrachtet, gibt es 48.000 \u2013 das ist bereits mehr, und die Unterschiede zwischen String und LowCardinality(String) sind kaum sp\u00fcrbar. Bei den URLs haben wir ebenfalls nur 2 GB gespart \u2013 ich denke, darauf sollte man sich nicht verlassen. <\/p>\n

Bewertung der Arbeitsgeschwindigkeit<\/h3>\n

\n\"Optimierung
\nLink zur Folie<\/a><\/noindex><\/b><\/p>\n

Nun bewerten wir die Arbeitsgeschwindigkeit. Um dies zu tun, habe ich einen Datensatz mit Beschreibungen von Taxifahrten in New York verwendet. Er ist verf\u00fcgbar<\/a><\/noindex> auf GitHub. Dort sind etwas mehr als eine Milliarde Fahrten verzeichnet. Es sind Standort, Start- und Endzeit der Fahrt, Zahlungsmethode, Anzahl der Passagiere und sogar die Art des Taxis - gr\u00fcn, gelb und Uber - aufgef\u00fchrt. <\/p>\n

\"Optimierung
\n
\nIch habe die erste Abfrage ziemlich einfach gestaltet - ich habe gefragt, wo am h\u00e4ufigsten Taxis bestellt werden. Dazu muss der Standort, von dem aus das Taxi bestellt wurde, gruppiert und mit der Funktion count gez\u00e4hlt werden. ClickHouse liefert daf\u00fcr einige Ergebnisse. <\/p>\n

\"Optimierung
\n
\nUm die Geschwindigkeit der Anfragenbearbeitung zu messen, habe ich drei Tabellen mit identischen Daten erstellt, jedoch drei verschiedene Datentypen f\u00fcr unseren Startstandort verwendet - String, LowCardinality und Enum. LowCardinality und Enum waren f\u00fcnfmal schneller als String. Enum ist schneller, weil es mit Zahlen arbeitet. LowCardinality schneller, weil es eine Optimierung f\u00fcr GROUP BY implementiert. <\/p>\n

\"Optimierung
\n
\nLassen Sie uns die Abfrage noch komplizierter gestalten - wir fragen, wo sich der beliebteste Park in New York befindet. Auch hier messen wir, wo am h\u00e4ufigsten Taxis bestellt werden, filtern jedoch nur die Standorte, die das Wort \u201ePark\u201c enthalten. Zus\u00e4tzlich f\u00fcgen wir die Funktion like hinzu. <\/p>\n

\"Optimierung
\n
\nWenn wir die Zeit betrachten, sehen wir, dass Enum pl\u00f6tzlich langsamer wird. Es arbeitet sogar langsamer als der Standard-Datentyp String. Das liegt daran, dass die Funktion 'like' f\u00fcr Enum \u00fcberhaupt nicht optimiert ist. Wir m\u00fcssen unsere Strings von Enum in normale Strings umwandeln \u2013 wir erledigen also mehr Arbeit. LowCardinality(String) ist ebenfalls standardm\u00e4\u00dfig nicht optimiert, aber dort arbeitet 'like' mit einem W\u00f6rterbuch, was die Abfrage im Vergleich zu String beschleunigt. <\/p>\n

Bei der Arbeit mit Enum gibt es ein grundlegenderes Problem. Wenn wir es optimieren m\u00f6chten, m\u00fcssen wir dies an jedem Ort im Code tun. Angenommen, wir haben eine neue Funktion geschrieben \u2013 wir m\u00fcssen unbedingt eine Optimierung f\u00fcr Enum finden. Bei LowCardinality ist alles standardm\u00e4\u00dfig optimiert.<\/p>\n

\"Optimierung
\n
\nLassen Sie uns die letzte Abfrage betrachten, die k\u00fcnstlicher ist. Wir berechnen einfach die Hashfunktion f\u00fcr unseren Standort. Die Hashfunktion ist eine ziemlich langsame Abfrage, die lange dauert, daher wird alles um das Dreifache langsamer.<\/p>\n

\"Optimierung
\n
\nLowCardinality funktioniert immer noch schneller, auch wenn hier keine Filterung m\u00f6glich ist. Das liegt daran, dass unsere Funktionen nur im W\u00f6rterbuch arbeiten. Die Hash-Berechnungsfunktion hat ein Argument \u2013 sie kann weniger Daten verarbeiten und ebenfalls LowCardinality zur\u00fcckgeben. <\/p>\n

\"Optimierung
\n
\nUnser globales Ziel ist es, eine Geschwindigkeit zu erreichen, die in allen F\u00e4llen mindestens so hoch ist wie bei String, und die Beschleunigungen beizubehalten. Und vielleicht werden wir eines Tages String durch LowCardinality ersetzen, Sie aktualisieren ClickHouse, und alles l\u00e4uft dann ein bisschen schneller.
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438. \u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a ClickHouse \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u041a\u043e\u0447\u0435\u0442\u043e\u0432 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u043e \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043e \u043d\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435, LowCardinality, \u0438 \u043e\u0431\u044a\u044f\u0441\u043d\u044f\u0435\u0442, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043a\u043e\u0440\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043e \u0441\u0442\u0440\u043e\u043a\u0430\u043c\u0438. \u2014 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u0434\u0430\u0432\u0430\u0439\u0442\u0435 \u0440\u0430\u0437\u0431\u0435\u0440\u0435\u043c\u0441\u044f, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u0438. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u044b\u0435 \u0442\u0438\u043f\u044b \u0434\u0430\u043d\u043d\u044b\u0445. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":74738,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-74737","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Optimierung von Strings in ClickHouse. Vortrag von Yandex | ProHoster","description":"Die analytische Datenbank ClickHouse verarbeitet viele verschiedene Strings und verbraucht Ressourcen. Um die Systemleistung zu steigern, werden st\u00e4ndig neue Optimierungen hinzugef\u00fcgt. Der ClickHouse-Entwickler Nikolai Kochetov spricht \u00fcber den Datentyp String, einschlie\u00dflich des neuen Typs LowCardinality, und erkl\u00e4rt, wie man die Arbeit mit Strings beschleunigen kann. \u2013 Lassen Sie uns zun\u00e4chst kl\u00e4ren, wie Strings gespeichert werden k\u00f6nnen. Wir haben verschiedene String-Datentypen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u044f \u0441\u0442\u0440\u043e\u043a \u0432 ClickHouse. \u0414\u043e\u043a\u043b\u0430\u0434 \u042f\u043d\u0434\u0435\u043a\u0441\u0430 | ProHoster","og:description":"\u0410\u043d\u0430\u043b\u0438\u0442\u0438\u0447\u0435\u0441\u043a\u0430\u044f \u0421\u0423\u0411\u0414 ClickHouse \u043e\u0431\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0440\u0430\u0437\u043d\u044b\u0445 \u0441\u0442\u0440\u043e\u043a, \u043f\u043e\u0442\u0440\u0435\u0431\u043b\u044f\u044f \u0440\u0435\u0441\u0443\u0440\u0441\u044b. \u0414\u043b\u044f \u0443\u0441\u043a\u043e\u0440\u0435\u043d\u0438\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043f\u043e\u0441\u0442\u043e\u044f\u043d\u043d\u043e \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u044e\u0442\u0441\u044f \u043d\u043e\u0432\u044b\u0435 \u043e\u043f\u0442\u0438\u043c\u0438\u0437\u0430\u0446\u0438\u0438. \u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a ClickHouse \u041d\u0438\u043a\u043e\u043b\u0430\u0439 \u041a\u043e\u0447\u0435\u0442\u043e\u0432 \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u0442 \u043e \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435 \u0434\u0430\u043d\u043d\u044b\u0445, \u0432 \u0442\u043e\u043c \u0447\u0438\u0441\u043b\u0435 \u043e \u043d\u043e\u0432\u043e\u043c \u0442\u0438\u043f\u0435, LowCardinality, \u0438 \u043e\u0431\u044a\u044f\u0441\u043d\u044f\u0435\u0442, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0443\u0441\u043a\u043e\u0440\u0438\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u0443 \u0441\u043e \u0441\u0442\u0440\u043e\u043a\u0430\u043c\u0438. \u2014 \u0421\u043d\u0430\u0447\u0430\u043b\u0430 \u0434\u0430\u0432\u0430\u0439\u0442\u0435 \u0440\u0430\u0437\u0431\u0435\u0440\u0435\u043c\u0441\u044f, \u043a\u0430\u043a \u043c\u043e\u0436\u043d\u043e \u0445\u0440\u0430\u043d\u0438\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u0438. \u0423 \u043d\u0430\u0441 \u0435\u0441\u0442\u044c \u0441\u0442\u0440\u043e\u043a\u043e\u0432\u044b\u0435 \u0442\u0438\u043f\u044b \u0434\u0430\u043d\u043d\u044b\u0445.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/optimizacziya-strok-v-clickhouse-doklad-yandeksa","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-20T05:43:14+00:00","article:modified_time":"2020-03-20T05:43:14+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"74737","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:23:10","updated":"2022-09-27 14:48:44"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/74737","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=74737"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/74737\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/74738"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=74737"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=74737"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=74737"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}