ניהול ClickHouse: התקנה, תצורה ואופטימיזציה

ClickHouse נפרס כאשר PostgreSQL או MySQL כבר לא יכולים להתמודד עם שאילתות אנליטיות. תרחיש טיפוסי: טבלת אירועים עם 500 מיליון שורות, שאילתה SELECT date, COUNT(*) FROM events WHERE user_id = ? GROUP BY date לוקחת 30 שניות. ב-ClickHouse, אותה שאילתה לוקחת פחות משנייה. אבל ClickHouse אינו תחליף למסדי נתונים OLTP. הוא לא מתמודד היטב עם עדכוני שורות, טרנזקציות או כתיבות נקודתיות בריבוי גבוה. עזרנו לעשרות פרויקטים לבצע מיגרציה ל-ClickHouse ואנחנו יודעים איך להימנע ממלכודות נפוצות במהלך ההתקנה והתצורה. קבלו ייעוץ לפרויקט שלכם — נבחר את התצורה האופטימלית.

איך אנו מגדירים את ClickHouse לעומס העבודה שלכם?

אנחנו מתחילים באודיט: נפח נתונים, סוגי שאילתות, תדירות כתיבה, דרישות SLA. בהתבסס על כך, אנו בוחרים את הטופולוגיה — עצמאי, אשכול sharded, או משוכפל. אנו מתקינים את השרת עם פרמטרי תצורה אופטימליים, מגדירים מדיניות אחסון לאחסון מדורג, יוצרים משתמשים עם הרשאות מינימליות, ומפעילים ניטור דרך system.query_log ו-Prometheus. הכל נעשה turnkey — מהתקנה ועד תיעוד.

מבנה התקנה ותצורה בסיסית

ClickHouse מאחסן תצורה במספר קבצים:

• /etc/clickhouse-server/config.xml — תצורה ראשית
• /etc/clickhouse-server/users.xml — משתמשים והרשאות
• /etc/clickhouse-server/config.d/ — קבצי override (מועדפים להתאמה אישית)
• /etc/clickhouse-server/users.d/ — אותו דבר עבור משתמשים

הפרקטיקה המומלצת היא לא לגעת בקבצים הראשיים, אלא ליצור overrides ב-config.d/:

<!-- /etc/clickhouse-server/config.d/custom.xml -->
<clickhouse>
  <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>5</count>
  </logger>
  <max_connections>4096</max_connections>
  <listen_host>0.0.0.0</listen_host>
  <http_port>8123</http_port>
  <tcp_port>9000</tcp_port>
  <interserver_http_port>9009</interserver_http_port>
  <path>/var/lib/clickhouse/</path>
  <tmp_path>/var/lib/clickhouse/tmp/</tmp_path>
  <mark_cache_size>5368709120</mark_cache_size>
  <uncompressed_cache_size>8589934592</uncompressed_cache_size>
</clickhouse>

פרמטרי ביצועים מרכזיים

<!-- /etc/clickhouse-server/config.d/custom.xml --> <clickhouse> <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>5</count> </logger> <max_connections>4096</max_connections> <listen_host>0.0.0.0</listen_host> <http_port>8123</http_port> <tcp_port>9000</tcp_port> <interserver_http_port>9009</interserver_http_port> <path>/var/lib/clickhouse/</path> <tmp_path>/var/lib/clickhouse/tmp/</tmp_path> <mark_cache_size>5368709120</mark_cache_size> <uncompressed_cache_size>8589934592</uncompressed_cache_size> </clickhouse> — המטמון עבור סימני אינדקס MergeTree. לכל קובץ נתונים ב-MergeTree יש קובץ mark_cache_size עם מיקומים של granules. מטמון הסימנים שומר אותם בזיכרון ומאיץ קריאות. 5 GB הוא התחלה סבירה לשרת עם 32 GB RAM.

.mrk — מטמון לנתונים לא דחוסים. ClickHouse מאחסן נתונים דחוסים (LZ4 כברירת מחדל). בשאילתות חוזרות לאותם נתונים, המטמון חוסך CPU על דחיסה. 8 GB הוא הגיוני, אבל עבור שאילתות אנליטיות עם נתונים מגוונים מאוד, המטמון הזה פחות יעיל מאשר עבור OLTP.

uncompressed_cache_size בהקשר השאילתה — כמה חוטי CPU שאילתה אחת יכולה להשתמש:

<!-- users.d/default-settings.xml -->
<clickhouse>
  <profiles>
    <default>
      <max_threads>8</max_threads>
      <max_memory_usage>10000000000</max_memory_usage>
      <max_bytes_before_external_group_by>5000000000</max_bytes_before_external_group_by>
    </default>
  </profiles>
</clickhouse>

max_threads — מגבלת זיכרון לכל שאילתה. כאשר חורגים ממנה, ClickHouse נכשל עם שגיאת <!-- users.d/default-settings.xml --> <clickhouse> <profiles> <default> <max_threads>8</max_threads> <max_memory_usage>10000000000</max_memory_usage> <max_bytes_before_external_group_by>5000000000</max_bytes_before_external_group_by> </default> </profiles> </clickhouse> . עבור שאילתות אנליטיות כבדות, העלו אותה או השתמשו ב-max_memory_usage — זה מאפשר Memory limit exceeded על הדיסק כאשר הזיכרון אינו מספיק.

השוואת מטמונים:

מערכת דיסק ואחסון מדורג

ClickHouse קורא באופן פעיל מהדיסק — נתונים דחוסים בנתחים (granules). SSD הוא קריטי לביצועים טובים. HDD יכול לעבוד, אבל אגרגציות על טבלאות גדולות יהיו איטיות.

איך להגדיר מדיניות אחסון?

כדי להפריד נתונים חמים וקרים, אנו משתמשים במדיניות אחסון:

<!-- config.d/storage.xml -->
<clickhouse>
  <storage_configuration>
    <disks>
      <hot>
        <path>/data/hot/</path>
      </hot>
      <cold>
        <path>/data/cold/</path>
      </cold>
    </disks>
    <policies>
      <tiered>
        <volumes>
          <hot_volume>
            <disk>hot</disk>
            <max_data_part_size_bytes>1073741824</max_data_part_size_bytes>
          </hot_volume>
          <cold_volume>
            <disk>cold</disk>
          </cold_volume>
        </volumes>
        <move_factor>0.2</move_factor>
      </tiered>
    </policies>
  </storage_configuration>
</clickhouse>

חלקי נתונים ישנים יותר מסף מסוים עוברים אוטומטית מ-NVMe לדיסק איטי יותר (זול יותר). זה יכול לחסוך עד 60% בעלויות אחסון, לדוגמה הפחתת הוצאות חודשיות מ-$5,000 ל-$2,000 עבור מערך נתונים של 50 TB.

ניטור דרך טבלאות מערכת

ClickHouse עשיר בסטטיסטיקות פנימיות:

-- Текущие запросы
SELECT query_id, user, elapsed, read_rows, memory_usage, query
FROM system.processes
ORDER BY elapsed DESC;

-- Медленные запросы (last 24h)
SELECT normalized_query_hash, count() AS cnt, avg(query_duration_ms) AS avg_ms, max(query_duration_ms) AS max_ms, any(query) AS sample_query
FROM system.query_log
WHERE event_time > now() - INTERVAL 24 HOUR AND type = 'QueryFinish'
GROUP BY normalized_query_hash
ORDER BY avg_ms DESC
LIMIT 20;

-- Размер таблиц
SELECT database, table, formatReadableSize(sum(bytes_on_disk)) AS disk_size, sum(rows) AS total_rows
FROM system.parts
WHERE active
GROUP BY database, table
ORDER BY sum(bytes_on_disk) DESC;

תיעוד רשמי של ClickHouse קובע ש-max_bytes_before_external_group_by הוא זהב לאופטימיזציה. הוא מכיל סטטיסטיקות מלאות של כל שאילתה: משך, שורות שנקראו, זיכרון בשימוש, תוכנית ביצוע.

למה ClickHouse מהיר יותר מ-PostgreSQL לאנליטיקה?

ב-DBMS עמודי, נתונים מאוחסנים לפי עמודות, כך שלאגרגציות רק העמודה הדרושה נקראת, לא כל השורה. בנוסף, ClickHouse משתמש בהוראות SIMD, דחיסת LZ4/ZSTD, ו-מחשוב וקטורי. בבדיקות שלנו, ClickHouse מריץ GROUP BY פי 50–100 מהר יותר מ-PostgreSQL על אותה טבלה עם מיליארד שורות. לפי תיעוד רשמי של ClickHouse, אחסון עמודי ומחשוב וקטורי מאפשרים האצה כזו.

איך לאבטח את ClickHouse לאחר ההתקנה?

טעות נפוצה אחת היא להשאיר את המשתמש <!-- config.d/storage.xml --> <clickhouse> <storage_configuration> <disks> <hot> <path>/data/hot/</path> </hot> <cold> <path>/data/cold/</path> </cold> </disks> <policies> <tiered> <volumes> <hot_volume> <disk>hot</disk> <max_data_part_size_bytes>1073741824</max_data_part_size_bytes> </hot_volume> <cold_volume> <disk>cold</disk> </cold_volume> </volumes> <move_factor>0.2</move_factor> </tiered> </policies> </storage_configuration> </clickhouse> ללא סיסמה. ל-ClickHouse אין אימות כברירת מחדל, כך שכל אחד יכול להתחבר לממשק HTTP ולבצע שאילתות. כדי לתקן זאת, בצעו ארבעה שלבים:

1. הגדירו סיסמה למשתמש -- Текущие запросы SELECT query_id, user, elapsed, read_rows, memory_usage, query FROM system.processes ORDER BY elapsed DESC; -- Медленные запросы (last 24h) SELECT normalized_query_hash, count() AS cnt, avg(query_duration_ms) AS avg_ms, max(query_duration_ms) AS max_ms, any(query) AS sample_query FROM system.query_log WHERE event_time > now() - INTERVAL 24 HOUR AND type = 'QueryFinish' GROUP BY normalized_query_hash ORDER BY avg_ms DESC LIMIT 20; -- Размер таблиц SELECT database, table, formatReadableSize(sum(bytes_on_disk)) AS disk_size, sum(rows) AS total_rows FROM system.parts WHERE active GROUP BY database, table ORDER BY sum(bytes_on_disk) DESC; באמצעות hash SHA256 וציין אותה ב-system.query_log.
2. הגבילו גישה לרשת על ידי ציון כתובות IP מותרות באותו קובץ.
3. סגרו את SELECT SUM(amount) FROM transactions WHERE date > '2023-01-01' עם חומת אש — הוא משמש לשכפול ואינו דורש אימות.
4. הפעילו HTTPS עבור ממשק HTTP.

תצורה לדוגמה:

<!-- users.d/users.xml -->
<clickhouse>
  <users>
    <default>
      <password_sha256_hex>hash-of-your-password</password_sha256_hex>
      <networks>
        <ip>::1</ip>
        <ip>127.0.0.1</ip>
        <ip>10.0.0.0/8</ip>
      </networks>
    </default>
  </users>
</clickhouse>

אמצעים אלה מונעים גישה לא מורשית.

מה כוללת עבודת ניהול ClickHouse?

אנו מספקים מגוון מלא של שירותים:

• התקנה ותצורה — בחירת הגדרות נכונות לעומס העבודה שלכם, הגדרת אחסון (אחסון מדורג), יצירת משתמשים והרשאות.
• אופטימיזציה — כוונון מטמון, חלוקה (partitioning), בחירת מנוע טבלה נכון (MergeTree, ReplacingMergeTree, SummingMergeTree), פרופיל שאילתות.
• ניטור והתראות — אינטגרציה עם Prometheus, הגדרת לוחות מחוונים ב-Grafana, התראות על שאילתות איטיות ואנומליות.
• אבטחה — הגדרת סיסמאות, הגבלת גישה לרשת, הפעלת HTTPS.
• תיעוד — סכמת תצורה, מדריך תפעול, runbook לאירועים טיפוסיים.
• תמיכה — לאחר ההפעלה, אנו עונים על שאלות ומסייעים בשינויים.

אנו נעריך את הפרויקט שלכם — כתבו לנו, נבחר תצורה ונתחיל תוך 1–2 ימים. לצוות שלנו יש ניסיון של למעלה מ-5 שנים בניהול ClickHouse ויותר מ-50 פרויקטים מוצלחים, עם הבטחת שביעות רצון לקוחות של 100%. צרו קשר לייעוץ.