Startseite Tech-Entdeckung Anti-Stress
🇬🇧 English 🇪🇸 Español 🇩🇪 Deutsch 🇫🇷 Français 🇵🇱 Polski 🇨🇿 Česky 🇨🇳 中文 🇰🇷 한국어
Zurück zur Startseite

ClickHouse-Konfiguration: Produktionssetup von config.xml und users.xml

Praktischer Leitfaden zur Konfiguration von ClickHouse für eine Produktionsumgebung. Die Hauptabschnitte von config.xml werden behandelt: Logger mit größenbasierter Rotation (10 Dateien à 1 GB), Daten- und Swap-Pfade, MergeTree-Parameter (min_bytes_for_wide_part, parts_to_throw_insert=300). Die Struktur von users.xml für drei Benutzertypen wird gezeigt: Analysten (readonly=1, Speicher- und Zeitlimits), Anwendung (eingeschränkte Ressourcen), Administrator (lokaler Zugriff). Profileinstellungen: max_memory_usage, max_execution_time, max_rows_to_read. Kontingente für die Anzahl der Abfragen und gelesenen Zeilen. LZ4 (Geschwindigkeit) vs ZSTD (Platzersparnis) Kompression. TLS/SSL für sicheren Zugriff. Konfigurationsprinzip über config.d/, um Einstellungen bei Updates zu erhalten. Minimale Sicherheitscheckliste: Standardpasswort ändern, Ports über UFW/iptables schließen, Netzwerke in users.xml einschränken, query_log aktivieren.

By Sudonull Editorial Team • Published • Updated

ClickHouse: So richten Sie die Produktion ein und verlieren keine Daten
Advertisement 728x90

ClickHouse-Konfiguration: Wie ich die Produktion eingerichtet habe und mir nicht ins Bein geschossen habe

Die Geschichte eines Tippfehlers: 300 GB Logs und ein abgestürzter Server

Standardmäßig schreibt ClickHouse Logs nach /var/log/clickhouse-server/ und rotiert sie nie. Zwei Wochen nach dem Start stellten wir fest, dass die Logdatei auf 300 GB angewachsen war und die gesamte Root-Partition gefüllt hatte. Der Server stürzte ab. Analysten konnten kein SELECT ausführen, die Produktion war down.

Die ClickHouse-Dokumentation ist riesig, aber in der Produktion müssen Sie wirklich nur etwa 20 Parameter ändern. Unten ist meine Checkliste aus 5 Jahren Betrieb von Clustern mit 1 bis 12 Knoten.

1. config.xml: Das Grundgerüst einer Produktionskonfiguration

Die Hauptkonfiguration befindet sich in /etc/clickhouse-server/config.xml. Hier sind die Abschnitte, die ich in jedem Projekt anfasse:

Google AdInline article slot
<clickhouse>
    <!-- Logging — Rotation hinzufügen, um meinen Fehler zu vermeiden -->
    <logger>
        <level>information</level>
        <log>/var/log/clickhouse-server/clickhouse-server.log</log>
        <errorlog>/var/log/clickhouse-server/clickhouse-server.err.log</errorlog>
        <size>1000M</size>
        <count>10</count>
        <!-- Das spart Speicherplatz. 10 Dateien à 1 GB — größenbasierte Rotation -->
    </logger>

    <!-- Ports — Standard, aber ich ändere sie in der Produktion -->
    <tcp_port>9000</tcp_port>           <!-- Native client -->
    <http_port>8123</http_port>         <!-- HTTP API -->
    <interserver_http_port>9009</interserver_http_port>  <!-- Replikation -->
    
    <!-- Listen interfaces — für die Produktion NICHT 0.0.0.0 ohne Firewall setzen -->
    <listen_host>0.0.0.0</listen_host>  <!-- Alle Interfaces — vorsichtig -->
    <!-- <listen_host>::</listen_host>   IPv6 -->

Warum ich davon abrate, blind 0.0.0.0 zu verwenden: In der Produktion mit einer öffentlichen IP wird Ihr ClickHouse zum Ziel von Portscans. Besser VPN oder Firewalls verwenden.

2. Datenpfade: Wo ClickHouse alles speichert

<path>/var/lib/clickhouse/</path>           <!-- Hauptdaten -->
<tmp_path>/var/lib/clickhouse/tmp/</tmp_path>
<user_files_path>/var/lib/clickhouse/user_files/</user_files_path>
<format_schema_path>/var/lib/clickhouse/format_schemas/</format_schema_path>

Was mich gebrannt hat: Das System-/tmp war im RAM (tmpfs) mit nur 2 GB gemountet. ClickHouse versuchte, temporäre Dateien für große GROUP BY-Abfragen dort zu schreiben und stürzte mit einem Fehler ab. Ich habe tmp_path auf eine 50-GB-Festplatte verschoben:

<tmp_path>/data/clickhouse_tmp/</tmp_path>

3. MergeTree-Einstellungen: Katastrophen verhindern

Ich setze diese Parameter auf allen Produktionsservern:

Google AdInline article slot
<merge_tree>
    <!-- Ein Teil wird erst zusammengeführt, wenn er 10 GB angesammelt hat — reduziert Hintergrundlast -->
    <min_bytes_for_wide_part>10000000000</min_bytes_for_wide_part>
    
    <!-- Maximale Teilgröße für die Zusammenführung (100 GB) -->
    <max_bytes_to_merge_at_max_space_in_pool>107374182400</max_bytes_to_merge_at_max_space_in_pool>
    
    <!-- Wenn Teile 300 überschreiten, werden neue INSERTs abgelehnt -->
    <parts_to_throw_insert>300</parts_to_throw_insert>
    
    <!-- Warnung bei 200 Teilen -->
    <parts_to_delay_insert>200</parts_to_delay_insert>
    
    <!-- Maximale Anzahl von Teilen in einer Partition -->
    <max_parts_in_total>10000</max_parts_in_total>
</merge_tree>

Warum parts_to_throw_insert = 300: Wenn Sie 300+ Teile haben, verlangsamt sich SELECT, und INSERTs machen es nur noch schlimmer. Besser den Insert ablehnen und nachforschen.

4. users.xml: Benutzer, Profile, Kontingente

Die Datei /etc/clickhouse-server/users.xml ist die Zugriffskontrolle. Ich erstelle drei Benutzer:

<clickhouse>
    <!-- 1. Benutzer für Analysten (schreibgeschützt) -->
    <analyst>
        <password>analyst_secure_password</password>
        <networks>
            <ip>10.0.0.0/8</ip>   <!-- Nur internes Netzwerk -->
        </networks>
        <profile>readonly_profile</profile>
        <quota>analyst_quota</quota>
    </analyst>

    <!-- 2. Anwendung (begrenzte Ressourcen) -->
    <app_user>
        <password>${CLICKHOUSE_APP_PASSWORD}</password>  <!-- Aus Umgebungsvariable -->
        <networks>
            <ip>::/0</ip>  <!-- Hier vorsichtig sein, besser spezifische Subnetze verwenden -->
        </networks>
        <profile>app_profile</profile>
    </app_user>

    <!-- 3. Administrator (voller Zugriff) -->
    <admin>
        <password>admin_strong_password</password>
        <networks>
            <host>localhost</host>
            <host>10.0.0.50</host>  <!-- Nur Bastion-Host -->
        </networks>
        <profile>admin_profile</profile>
    </admin>
</clickhouse>

Wichtige Nuance: Das Passwort des Standardbenutzers ist standardmäßig leer. Das ist das Erste, was ich nach der Installation ändere.

Google AdInline article slot

5. Einstellungsprofile: Schutz vor verrückten Abfragen

Profile sind Mengen von Einschränkungen, die den Cluster vor SELECT * FROM huge_table CROSS JOIN schützen.

<profiles>
    <!-- Analysten: können schwere Abfragen ausführen, aber mit Grenzen -->
    <readonly_profile>
        <readonly>1</readonly>   <!-- Nur SELECT -->
        <max_memory_usage>10000000000</max_memory_usage>  <!-- 10 GB -->
        <max_execution_time>300</max_execution_time>      <!-- 5 Minuten -->
        <max_rows_to_read>50000000000</max_rows_to_read>  <!-- 50 Milliarden Zeilen -->
        <max_bytes_to_read>107374182400</max_bytes_to_read> <!-- 100 GB -->
        <prefer_global_in_and_join>1</prefer_global_in_and_join>
    </readonly_profile>

    <!-- Anwendung: schnelle Abfragen, kleine Grenzen -->
    <app_profile>
        <readonly>0</readonly>
        <max_memory_usage>1000000000</max_memory_usage>   <!-- 1 GB -->
        <max_execution_time>10</max_execution_time>        <!-- 10 Sekunden -->
        <max_rows_to_read>100000000</max_rows_to_read>     <!-- 100 Millionen -->
        <timeout_before_checking_execution_speed>0</timeout_before_checking_execution_speed>
    </app_profile>

    <!-- Admin: fast keine Grenzen (aber vorsichtig) -->
    <admin_profile>
        <readonly>0</readonly>
        <max_memory_usage>0</max_memory_usage>  <!-- keine Grenze -->
        <max_execution_time>0</max_execution_time>
    </admin_profile>
</profiles>

Kontingente — damit ein Analyst nicht alle tötet:

<quotas>
    <analyst_quota>
        <interval>
            <duration>3600</duration>      <!-- pro Stunde -->
            <queries>100</queries>         <!-- nicht mehr als 100 Abfragen -->
            <errors>0</errors>             <!-- keine Fehler -->
            <result_rows>100000000</result_rows>  <!-- 100 Millionen Ergebniszeilen -->
            <read_rows>10000000000</read_rows>    <!-- 10 Milliarden gelesen -->
        </interval>
    </analyst_quota>
</quotas>

6. Standard-Komprimierungseinstellungen

ClickHouse komprimiert Daten mit LZ4 (schnell) oder ZSTD (stärker). Ich wähle basierend auf dem Datentyp:

<compression>
    <!-- LZ4 für frische Daten (Geschwindigkeit) -->
    <case>
        <last_level>1</last_level>  <!-- Komprimierungsstufe -->
        <method>LZ4</method>
    </case>
    
    <!-- ZSTD für Partitionen älter als 30 Tage (Platzersparnis) -->
    <case>
        <min_part_size>10737418240</min_part_size>  <!-- 10 GB -->
        <method>ZSTD</method>
        <level>3</level>
    </case>
</compression>

Meine Wahl in der Produktion: LZ4 für alle Daten. ZSTD spart 20-30% Platz, verliert aber bis zu 10% Geschwindigkeit bei Abfragen.

7. TLS/SSL — Wenn Sie nicht in einem isolierten Netzwerk sind

<https_port>8443</https_port>
<tcp_port_secure>9440</tcp_port_secure>

<openSSL>
    <server>
        <certificateFile>/etc/clickhouse-server/ssl/server.crt</certificateFile>
        <privateKeyFile>/etc/clickhouse-server/ssl/server.key</privateKeyFile>
        <verificationMode>none</verificationMode>
        <caConfig>/etc/clickhouse-server/ssl/CA.pem</caConfig>
        <cacheSessions>true</cacheSessions>
        <disableProtocols>sslv2,sslv3,tlsv1,tlsv1_1</disableProtocols>
        <preferServerCiphers>true</preferServerCiphers>
    </server>
</openSSL>

Was mich gebrannt hat: Ein selbstsigniertes Zertifikat ohne Verifizierung ist nur innerhalb eines vertrauenswürdigen Netzwerks sicher. Für externen Zugriff verwenden Sie Let's Encrypt oder ein kostenpflichtiges Zertifikat.

8. config.d/ — Überschreibungen ohne Schmerz

Bearbeiten Sie niemals config.xml direkt. Legen Sie alle Änderungen in /etc/clickhouse-server/config.d/ ab.

Datei config.d/memory.xml:

<clickhouse>
    <max_server_memory_usage>0.75</max_server_memory_usage>  <!-- 75% des gesamten RAM -->
    <max_concurrent_queries>100</max_concurrent_queries>
</clickhouse>

Datei config.d/networks.xml:

<clickhouse>
    <listen_host>0.0.0.0</listen_host>
    <max_connections>4096</max_connections>
</clickhouse>

Vorteile: Beim Aktualisieren von ClickHouse wird Ihre config.xml nicht überschrieben, und die Überschreibungen bleiben erhalten. Ich habe dies auf die harte Tour gelernt, nachdem ich meine Konfiguration bei einem Upgrade von 22.x auf 23.x verloren hatte.

9. Sicherheitscheckliste für eine Wettplattform

Bevor ich den ClickHouse-Zugriff für die Außenwelt öffne, überprüfe ich:

✅ Standardbenutzerpasswort ändern

clickhouse-client --password
ALTER USER default IDENTIFIED BY 'new_strong_password';

✅ Standardbenutzer entfernen oder einschränken

<!-- In users.xml den Standardabschnitt auskommentieren -->
<!-- <default>
    <password></password>
</default> -->

✅ Ports vor externem Zugriff schließen (UFW)

sudo ufw default deny incoming
sudo ufw allow from 10.0.0.0/8 to any port 9000 proto tcp  # nur internes Netzwerk
sudo ufw allow from 10.0.0.0/8 to any port 8123 proto tcp
sudo ufw allow ssh

✅ Host-Firewall aktivieren

sudo iptables -A INPUT -p tcp --dport 9000 -s 10.0.0.0/8 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 9000 -j DROP

✅ max_memory_usage setzen, damit eine Abfrage den Server nicht tötet

<max_memory_usage>10000000000</max_memory_usage>  <!-- 10 GB -->

✅ Experimentelle Funktionen deaktivieren (falls nicht benötigt)

<allow_experimental_geo_types>0</allow_experimental_geo_types>
<allow_experimental_window_functions>1</allow_experimental_window_functions> <!-- 23.8+ -->

✅ query_log und slow_log für Überwachung aktivieren

<query_log>
    <database>system</database>
    <table>query_log</table>
    <partition_by>toYYYYMM(event_date)</partition_by>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

<query_thread_log>
    <database>system</database>
    <table>query_thread_log</table>
</query_thread_log>

✅ Zugriff nach IP einschränken (Whitelist)

<analyst>
    <networks>
        <ip>10.0.0.100</ip>   <!-- Nur spezifische Analysten-IP -->
        <ip>10.0.0.101</ip>
        <ip>192.168.1.0/24</ip>
    </networks>
</analyst>

Was kommt als Nächstes

Jetzt ist Ihr ClickHouse für den Kampf konfiguriert. Der nächste Artikel handelt von Überwachung und Backups in der Produktion.

← Vorherige: → Nächste: ReplacingMergeTree: So schlagen Sie Duplikate in ClickHouse ohne Schmerzen

— Editorial Team

Advertisement 728x90

Weiterlesen

Tags

#clickhouse-configuration #database-administration #clickhouse-security #production-setup #devops

Themen

Datenbanken DevOps

FAQ

Wie richtet man die Log-Rotation in ClickHouse ein, um eine Überfüllung der Festplatte zu vermeiden?

Fügen Sie im Abschnitt <logger> von config.xml <size>1000M</size> und <count>10</count> hinzu. ClickHouse speichert 10 Dateien à 1 GB, alte werden automatisch gelöscht. Ohne diese Einstellung wächst das Log unbegrenzt – in der Produktion hatten wir 300 GB.

Was ist parts_to_throw_insert und warum sollte man es konfigurieren?

Ein Parameter im Abschnitt <merge_tree> – wenn die Anzahl der Teile in einer Tabelle 300 überschreitet, lehnt ClickHouse neue INSERTs ab. Dies schützt vor Degradation: 300+ Teile bedeuten, dass SELECT bereits langsam ist, und neue Einfügungen verschlimmern die Situation nur.

Wie erstellt man einen schreibgeschützten Benutzer in ClickHouse?

Erstellen Sie in users.xml einen Abschnitt mit <profile>readonly_profile</profile> und geben Sie im Profil <readonly>1</readonly> an. Fügen Sie außerdem Limits max_memory_usage, max_execution_time und Kontingente hinzu, damit Analysten den Server nicht mit schweren Abfragen lahmlegen.

Welche Kompressionsmethode soll man für ClickHouse wählen – LZ4 oder ZSTD?

LZ4 ist schneller bei Abfragen (fast kein Geschwindigkeitsverlust), ZSTD spart 20-30% Platz, ist aber 5-10% langsamer. Ich verwende LZ4 für frische Daten (Geschwindigkeit ist wichtiger) und ZSTD für alte Partitionen über einen bedingten Kompressionsabschnitt.

Wie aktualisiert man ClickHouse, ohne Benutzereinstellungen zu verlieren?

Platzieren Sie alle Änderungen in /etc/clickhouse-server/config.d/ und users.d/, nicht in der Hauptdatei config.xml/users.xml. Während des Updates überschreibt das Paket nur die Hauptdateien, die Überschreibungen bleiben unberührt.