ClickHouse: איך מסד נתונים עמודתי הופך אנליטיקה לפי כמה מהירה

מאת צוות מדיה דיל · 26.06.2026 · טכנולוגיה · 4 דק׳

אחסון Columnar מול Row-Oriented, דחיסת LZ4 ו-ZSTD, מנוע MergeTree, Vectorized Execution, שילוב עם Postgres וטרייד-אוף OLAP מול OLTP.

שאילתת אנליטיקה שמסכמת מיליארד שורות ("כמה הזמנות היו בכל עיר בכל חודש בשנתיים האחרונות") רצה על Postgres רגיל דקות ארוכות, גם עם אינדקסים טובים, כי מסד נתונים row-oriented קורא מהדיסק שורה שלמה בכל פעם — כולל עשרות עמודות שהשאילתה בכלל לא צריכה. ClickHouse נבנה מהיסוד כמסד נתונים columnar בשביל בדיוק המקרה הזה: לקרוא רק את העמודות הרלוונטיות, לדחוס אותן אגרסיבית, ולסרוק מיליארדי ערכים בשניות בודדות. הפער בביצועים לא נובע מטריק אחד אלא משילוב של החלטות ארכיטקטוניות שכל אחת מהן לבד לא מספיקה, אבל יחד הופכות שאילתת אגרגציה שהייתה נמשכת דקות לשאילתה שרצה בזמן שלוקח לרענן דשבורד.

אחסון עמודתי מול אחסון שורות

ב-Postgres כל שורה נשמרת ברצף אחד על הדיסק (heap), כך שכתיבה טרנזקציונית של רשומה בודדת יעילה מאוד. אבל שאילתת SUM על עמודה אחת מתוך חמישים מחייבת לקרוא את כל השורה ולזרוק את רוב הנתונים. ClickHouse שומר כל עמודה בקובץ נפרד ברצף, כך שסריקה של עמודה אחת קוראת רק אותה מהדיסק — פי כמה פחות I/O, ופי כמה יותר מהר עבור אגרגציות על טבלאות ענק.

MergeTree: מנוע האחסון שמאחורי הקלעים

משפחת מנועי MergeTree היא הלב של ClickHouse: כתיבות נכנסות ל-parts קטנים וממוינים, ותהליך רקע ממזג אותם בהדרגה ל-parts גדולים יותר, בדומה ל-LSM Tree. הנתונים ממוינים לפי מפתח primary key שנבחר מראש (בדרך כלל טווח תאריכים ומזהה), כך שסינון לפי טווח כמעט לא צריך אינדקס נפרד — sparse index קטן מצביע ישר ל-block הרלוונטי. וריאנטים כמו ReplacingMergeTree או SummingMergeTree מטפלים ב-upserts ואגרגציות תוך כדי המיזוג, כך שגם דפוסים שבדרך כלל דורשים לוגיקת עדכון מסובכת מתבצעים כחלק טבעי מתהליך הרקע.

Vectorized Execution ומקביליות

ClickHouse לא מעבד שורה-שורה אלא batch של אלפי ערכים בבת אחת, בפעולות SIMD שמנצלות את המעבד ביעילות הרבה יותר גבוהה ממנוע וקטור-אחר-וקטור. לצד זה, שאילתה בודדת מתפצלת אוטומטית לפי ליבות ולפי shards, כך שגם על שרת בודד יש ניצול מלא של כל הליבות, ובאשכול מרובה צמתים כל shard מעבד את החלק שלו במקביל ומחזיר תוצאה חלקית שמאוחדת בסוף. השילוב של אחסון עמודתי, דחיסה ו-vectorized execution הוא מה שמאפשר לענות על שאילתת אגרגציה על מיליארדי שורות תוך פחות משנייה.

מתי Postgres מספיק ומתי לא

אם העומס העיקרי הוא OLTP — הרבה כתיבות בודדות, עדכונים, טרנזקציות עם עקביות חזקה — Postgres הוא הבחירה הנכונה, ואפשר להאריך את חייו עם partitioning נכון לפי טווח תאריכים. אבל ברגע שהצורך הוא לוחות בקרה, דוחות BI, או אנליטיקת אירועים על כמויות שגדלות בעשרות מיליוני שורות ביום, ניסיון להריץ את זה על Postgres הופך למרוץ אינסופי אחרי אינדקסים חדשים. ClickHouse לא מחליף את Postgres — הוא מצטרף לצידו לתפקיד אחר לגמרי.

שילוב בארכיטקטורה קיימת

הדפוס הנפוץ הוא Change Data Capture או ETL תקופתי שמזרים נתונים מ-Postgres ל-ClickHouse, כשה-OLTP נשאר מקור האמת וה-OLAP משרת דוחות וניתוחים. לפעמים שכבת materialized views ב-Postgres מספיקה כפתרון ביניים זול לפני שקופצים לפתרון ייעודי. חשוב לזכור ש-ClickHouse לא מיועד לעדכונים תכופים של שורות בודדות ולא ל-JOIN-ים כבדים בסגנון OLTP — הוא מנוע לכתיבה בכמות ולקריאה אנליטית, לא מסד נתונים כללי.

מתכננים שכבת אנליטיקה שצריכה לענות מהר על מיליוני אירועים? נשמח לעזור לכם בוואטסאפ.

תגיות: ClickHouse · OLAP · columnar database · MergeTree · אנליטיקה בזמן אמת · Postgres

← חזרה לבלוג · צור קשר