Domů Tech Průzkum Antistres
🇬🇧 English 🇪🇸 Español 🇩🇪 Deutsch 🇫🇷 Français 🇵🇱 Polski 🇨🇿 Česky 🇨🇳 中文 🇰🇷 한국어
Zpět na domů

Konfigurace ClickHouse: produkční nastavení config.xml a users.xml

Praktický průvodce nastavením ClickHouse pro produkční prostředí. Rozebírají se hlavní sekce config.xml: logger s rotací podle velikosti (10 souborů po 1 GB), cesty dat a swapu, parametry MergeTree (min_bytes_for_wide_part, parts_to_throw_insert=300). Je ukázána struktura users.xml pro tři typy uživatelů: analytici (readonly=1, limity paměti a času), aplikace (omezené zdroje), administrátor (lokální přístup). Nastavení profilů: max_memory_usage, max_execution_time, max_rows_to_read. Kvóty na počet dotazů a přečtených řádků. Komprese LZ4 (rychlost) versus ZSTD (úspora místa). TLS/SSL pro zabezpečený přístup. Princip konfigurace přes config.d/ pro zachování nastavení při aktualizaci. Minimální security checklist: změna hesla default, uzavření portů přes UFW/iptables, omezení sítí v users.xml, povolení query_log.

By Sudonull Editorial Team • Published • Updated

ClickHouse: jak nastavit produkci a neztratit data
Advertisement 728x90

Konfigurace ClickHouse: jak jsem nastavoval prod a nestřelil se do nohy

Příběh jedné překlepu: 300 GB logů a spadlý server

ClickHouse ve výchozím nastavení zapisuje logy do /var/log/clickhouse-server/ a nikdy je nerotuje. Po dvou týdnech od spuštění jsme zjistili, že logovací soubor narostl na 300 GB a zaplnil celý kořenový oddíl. Server spadl. Analytici nemohli provést SELECT, prod lehl.

Dokumentace ClickHouse je obrovská, ale v produkci je potřeba změnit jen asi 20 parametrů. Níže je můj checklist z 5 let provozu clusterů od 1 uzlu do 12.

1. config.xml: kostra produkční konfigurace

Hlavní konfigurak leží v /etc/clickhouse-server/config.xml. Zde jsou sekce, které upravuji v každém projektu:

Google AdInline article slot
<clickhouse>
    <!-- Logování – přidejte rotaci, abyste nezopakovali mou chybu -->
    <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>
        <!-- Toto zachraňuje disky. 10 souborů po 1 GB – rotace podle velikosti -->
    </logger>

    <!-- Porty – standardní, ale na produ měním -->
    <tcp_port>9000</tcp_port>           <!-- Nativní klient -->
    <http_port>8123</http_port>         <!-- HTTP API -->
    <interserver_http_port>9009</interserver_http_port>  <!-- Replikace -->
    
    <!-- Posloucháme rozhraní – na prod NEDÁVEJTE 0.0.0.0 bez firewallu -->
    <listen_host>0.0.0.0</listen_host>  <!-- Všechna rozhraní – opatrně -->
    <!-- <listen_host>::</listen_host>   IPv6 -->

Proč nedoporučuji 0.0.0.0 bez rozmyslu: na produ s veřejnou IP se váš ClickHouse stane cílem skenování portů. Raději použijte VPN nebo síťové firewally.

2. Cesty k datům: kam ClickHouse ukládá vše

<path>/var/lib/clickhouse/</path>           <!-- Hlavní data -->
<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>

Na čem jsem se spálil: /tmp v systému byl připojen do paměti (tmpfs) jen o velikosti 2 GB. ClickHouse se pokoušel zapsat tam dočasné soubory pro velké GROUP BY a padal s chybou. Přesunul jsem tmp_path na disk s 50 GB:

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

3. MergeTree nastavení: předcházíme katastrofám

Tyto parametry nastavuji na všech produkčních serverech:

Google AdInline article slot
<merge_tree>
    <!-- Část se neslučuje, dokud nenashromáždí 10 GB – snižuje zátěž na pozadí -->
    <min_bytes_for_wide_part>10000000000</min_bytes_for_wide_part>
    
    <!-- Maximální velikost části pro sloučení (100 GB) -->
    <max_bytes_to_merge_at_max_space_in_pool>107374182400</max_bytes_to_merge_at_max_space_in_pool>
    
    <!-- Pokud je částí > 300, nové INSERT budou odmítnuty -->
    <parts_to_throw_insert>300</parts_to_throw_insert>
    
    <!-- Varování při 200 částech -->
    <parts_to_delay_insert>200</parts_to_delay_insert>
    
    <!-- Maximální počet částí v partition -->
    <max_parts_in_total>10000</max_parts_in_total>
</merge_tree>

Proč parts_to_throw_insert = 300: pokud máte nashromážděno 300+ částí, SELECT zpomaluje a INSERT situaci jen zhoršují. Raději vložení odmítněte a vyřešte to.

4. users.xml: uživatelé, profily, kvóty

Soubor /etc/clickhouse-server/users.xml je kontrola přístupu. Vytvářím tři uživatele:

<clickhouse>
    <!-- 1. Uživatel pro analytiky (pouze čtení) -->
    <analyst>
        <password>analyst_secure_password</password>
        <networks>
            <ip>10.0.0.0/8</ip>   <!-- Pouze interní síť -->
        </networks>
        <profile>readonly_profile</profile>
        <quota>analyst_quota</quota>
    </analyst>

    <!-- 2. Aplikace (omezené zdroje) -->
    <app_user>
        <password>${CLICKHOUSE_APP_PASSWORD}</password>  <!-- Z proměnné prostředí -->
        <networks>
            <ip>::/0</ip>  <!-- Zde opatrně, raději konkrétní podsítě -->
        </networks>
        <profile>app_profile</profile>
    </app_user>

    <!-- 3. Administrátor (může vše) -->
    <admin>
        <password>admin_strong_password</password>
        <networks>
            <host>localhost</host>
            <host>10.0.0.50</host>  <!-- Pouze bastion-host -->
        </networks>
        <profile>admin_profile</profile>
    </admin>
</clickhouse>

Důležitý detail: heslo výchozího uživatele default je prázdné. To je první věc, kterou po instalaci měním.

Google AdInline article slot

5. Profily nastavení: ochrana před šílenými dotazy

Profily jsou sady omezení, které zachraňují cluster před SELECT * FROM huge_table CROSS JOIN.

<profiles>
    <!-- Analytici: mohou provádět těžké dotazy, ale s limity -->
    <readonly_profile>
        <readonly>1</readonly>   <!-- Pouze SELECT -->
        <max_memory_usage>10000000000</max_memory_usage>  <!-- 10 GB -->
        <max_execution_time>300</max_execution_time>      <!-- 5 minut -->
        <max_rows_to_read>50000000000</max_rows_to_read>  <!-- 50 miliard řádků -->
        <max_bytes_to_read>107374182400</max_bytes_to_read> <!-- 100 GB -->
        <prefer_global_in_and_join>1</prefer_global_in_and_join>
    </readonly_profile>

    <!-- Aplikace: rychlé dotazy, malé limity -->
    <app_profile>
        <readonly>0</readonly>
        <max_memory_usage>1000000000</max_memory_usage>   <!-- 1 GB -->
        <max_execution_time>10</max_execution_time>        <!-- 10 sekund -->
        <max_rows_to_read>100000000</max_rows_to_read>     <!-- 100 milionů -->
        <timeout_before_checking_execution_speed>0</timeout_before_checking_execution_speed>
    </app_profile>

    <!-- Admin: téměř bez omezení (ale opatrně) -->
    <admin_profile>
        <readonly>0</readonly>
        <max_memory_usage>0</max_memory_usage>  <!-- bez limitu -->
        <max_execution_time>0</max_execution_time>
    </admin_profile>
</profiles>

Kvóty – aby jeden analytik nezabil všechny:

<quotas>
    <analyst_quota>
        <interval>
            <duration>3600</duration>      <!-- za hodinu -->
            <queries>100</queries>         <!-- ne více než 100 dotazů -->
            <errors>0</errors>             <!-- bez chyb -->
            <result_rows>100000000</result_rows>  <!-- 100 milionů řádků výsledku -->
            <read_rows>10000000000</read_rows>    <!-- 10 miliard přečteno -->
        </interval>
    </analyst_quota>
</quotas>

6. Nastavení výchozí komprese

ClickHouse komprimuje data LZ4 (rychle) nebo ZSTD (silněji). Vybírám podle typu dat:

<compression>
    <!-- LZ4 pro čerstvá data (rychlost) -->
    <case>
        <last_level>1</last_level>  <!-- Úroveň komprese -->
        <method>LZ4</method>
    </case>
    
    <!-- ZSTD pro partition starší 30 dní (úspora místa) -->
    <case>
        <min_part_size>10737418240</min_part_size>  <!-- 10 GB -->
        <method>ZSTD</method>
        <level>3</level>
    </case>
</compression>

Můj výběr na produ: LZ4 pro všechna data. ZSTD ušetří 20-30 % místa, ale na dotazech ztrácí až 10 % rychlosti.

7. TLS/SSL – pokud nejste v izolované síti

<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>

Na čem jsem se spálil: self-signed certifikát bez ověření je bezpečný jen uvnitř důvěryhodné sítě. Pro externí přístup použijte Let's Encrypt nebo placený certifikát.

8. config.d/ – override bez trápení

Nikdy neupravujte config.xml přímo. Všechny změny dávejte do /etc/clickhouse-server/config.d/.

Soubor config.d/memory.xml:

<clickhouse>
    <max_server_memory_usage>0.75</max_server_memory_usage>  <!-- 75 % celé RAM -->
    <max_concurrent_queries>100</max_concurrent_queries>
</clickhouse>

Soubor config.d/networks.xml:

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

Výhody: při aktualizaci ClickHouse se váš config.xml nepřepíše a override zůstanou. Toto mě naučila ztráta konfigurace po aktualizaci z 22.x na 23.x.

9. Security checklist pro betting platformu

Než otevřu přístup k ClickHouse z vnějšího světa, zkontroluji:

✅ Změna hesla default uživatele

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

✅ Smazání nebo omezení default uživatele

<!-- V users.xml zakomentovat sekci default -->
<!-- <default>
    <password></password>
</default> -->

✅ Uzavření portů před vnějším přístupem (UFW)

sudo ufw default deny incoming
sudo ufw allow from 10.0.0.0/8 to any port 9000 proto tcp  # pouze interní síť
sudo ufw allow from 10.0.0.0/8 to any port 8123 proto tcp
sudo ufw allow ssh

✅ Zapnutí firewallu na úrovni hostitele

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

✅ Nastavení max_memory_usage, aby jeden dotaz nezabil server

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

✅ Vypnutí experimentálních funkcí (pokud nejsou potřeba)

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

✅ Zapnutí query_log a slow_log pro monitorování

<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>

✅ Omezení přístupu podle IP (bílý seznam)

<analyst>
    <networks>
        <ip>10.0.0.100</ip>   <!-- Pouze konkrétní IP analytika -->
        <ip>10.0.0.101</ip>
        <ip>192.168.1.0/24</ip>
    </networks>
</analyst>

Co dál

Nyní je váš ClickHouse připraven k boji. Další článek – o monitorování a zálohách v produkci.

← Předchozí: → Další: ReplacingMergeTree: Jak porazit duplikáty v ClickHouse bez bolesti

— Editorial Team

Advertisement 728x90

Číst dál

Tagy

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

Témata

Databáze DevOps

FAQ

Jak nastavit rotaci logů v ClickHouse, aby se předešlo přeplnění disku?

Do sekce <logger> config.xml přidejte <size>1000M</size> a <count>10</count>. ClickHouse bude ukládat 10 souborů po 1 GB, staré se automaticky smažou. Bez tohoto nastavení log roste nekonečně – na produkci jsme dostali 300 GB.

Co je parts_to_throw_insert a proč ho nastavovat?

Parametr v sekci <merge_tree> – pokud počet částí v tabulce přesáhne 300, ClickHouse odmítá nové INSERT. To je ochrana před degradací: 300+ částí znamená, že SELECT již zpomaluje, a nové vklady situaci jen zhorší.

Jak vytvořit uživatele pouze pro čtení v ClickHouse?

V users.xml vytvořte sekci s <profile>readonly_profile</profile> a v profilu uveďte <readonly>1</readonly>. Také přidejte omezení max_memory_usage, max_execution_time a kvóty, aby analytici nezatěžovali server těžkými dotazy.

Jakou metodu komprese zvolit pro ClickHouse – LZ4 nebo ZSTD?

LZ4 je rychlejší na dotazech (téměř bez ztráty rychlosti), ZSTD šetří 20-30 % místa, ale je o 5-10 % pomalejší. Používám LZ4 pro čerstvá data (rychlost je důležitější) a ZSTD pro staré partitiony pomocí podmíněné sekce compression.

Jak aktualizovat ClickHouse bez ztráty uživatelských nastavení?

Všechny změny ukládejte do /etc/clickhouse-server/config.d/ a users.d/, nikoli do hlavních config.xml/users.xml. Při aktualizaci balíček přepisuje pouze hlavní soubory, přepisy zůstávají nedotčeny.