האם אשכול ה-Cassandra שלך סובל מחביון קריאה גבוה או מלחץ על הדיסק? לעיתים קרובות האשם הוא אסטרטגיית דחיסה (compaction) לא מתאימה. אנחנו לא בוחרים אסטרטגיות "בעין" — אנו מנתחים את פרופיל העומס שלך, TTL, תדירות עדכונים, וגדלי SSTable. בחירה שגויה יכולה להחמיר את חביון הקריאה פי 2-3, לגרום לגלישת דיסק, או לעורר TombstoneOverwhelmingException. לצוות שלנו יש ניסיון של למעלה מ-7 שנים עם Apache Cassandra ויותר מ-50 פרויקטים של אופטימיזציית ביצועים. תוך 1-3 ימים אנו מבצעים ביקורת, בוחרים את האסטרטגיה הנכונה (STCS, LCS, TWCS), ומבצעים מעבר ללא השבתה.
אנו מתמחים באסטרטגיות דחיסה של Cassandra ובכוונון דחיסה. המומחים שלנו עוזרים לך לבחור וליישם את האסטרטגיה הטובה ביותר עבור העומס שלך.
STCS, LCS, ו-TWCS הם שלושת המנגנונים המרכזיים, לכל אחד הפיזיקה שלו. STCS ממזג SSTables בגודל דומה כאשר מגיעים לסף (ברירת מחדל 4). הגברת כתיבה (write amplification) מינימלית, אך הקריאה סובלת מהרבה SSTables מפוזרים. LCS מסדר נתונים ברמות: כל קריאה נוגעת ב-SSTable אחד לכל היותר בכל רמה, מה שמעניק ביצועי קריאה מצוינים במחיר של הגברת כתיבה פי עשרה. TWCS מיועד לסדרות זמן: הוא מפצל נתונים לחלונות זמן ומסיים כל חלון; כאשר TTL פוקע, כל ה-SSTable נמחק — ללא סריקה לפי שורה. במבחני הביצועים שלנו, TWCS מפחית את הגברת הכתיבה עד פי 8 בהשוואה ל-LCS עבור נתוני סדרות זמן — כלומר פי 8 יותר יעיל.
| מאפיין | STCS | LCS | TWCS |
|---|---|---|---|
| הגברת כתיבה | נמוכה | גבוהה (~פי 10) | נמוכה |
| ביצועי קריאה | בינוניים | מצוינים | טובים |
| שטח דיסק | דורש ~פי 2 בשיא | ~פי 1.1 | ~פי 1.1 |
| טיפול ב-TTL | חלש | סביר | מצוין |
| עומס מומלץ | הוספה בלבד, עומס כתיבה כבד | קריאה/כתיבה, עדכונים | סדרות זמן עם TTL |
איך לבחור עבור העומס שלך
לטבלאות עם הוספה בלבד ללא מחיקות — STCS. לעומס מאוזן של קריאה/כתיבה עם עדכונים תכופים — LCS. עבור מדדים, לוגים, וסדרות זמן אחרות עם TTL — TWCS. בפועל, אסטרטגיות שונות מתקיימות במקביל באשכול אחד. דוגמה: events (הוספה בלבד, TTL) -> TWCS; user_profiles (שאילתות ועדכונים תכופים) -> LCS; raw_data (הכנסה בכמות גדולה, ללא TTL) -> STCS. אנו עוזרים לכוון כל טבלה בנפרד. הבנת יחסי הגומלין בין אסטרטגיית דחיסה, מסנני בלום (bloom filters), וגיזום מחיצות (partition pruning) היא קריטית לביצועים.
מה אם הדחיסה מפגרת?
הפקודה nodetool compactionstats מציגה משימות ממתינות. אם הן גדלות, הדחיסה לא עומדת בקצב הכתיבות. פתרון לטווח קצר: הגדל את compaction_throughput_mb_per_sec ל-64-128 MB/s (תלוי במערכת הדיסקים). לטווח ארוך: שקול מחדש את האסטרטגיה או הוסף צמתים. טעות נפוצה היא להשאיר את ברירת המחדל עבור SSDs (16 MB/s), מה שמוביל לעלייה בחביון הקריאה. בניסיון שלנו, העלינו את התפוקה ל-200 MB/s על NVMe ללא פגיעה ביציבות.
Tombstones הם רוצח ביצועים נוסף. קריאת מחיצה אחת עלולה להיתקל ביותר מ-100,000 tombstones, מה שמעורר TombstoneOverwhelmingException. סיבה: DELETE או UPDATE תכופים ללא דחיסה בזמן. פתרון: בחר את האסטרטגיה הנכונה וכוון את TombstoneOverwhelmingException. ב-LCS tombstones מוסרים מהר יותר, ב-STCS לאט יותר. עבור סדרות זמן עם TTL, tombstones כמעט ואינם קיימים. הביקורות שלנו הפחיתו את חביון הקריאה בממוצע ב-55% ואת ניצול הדיסק ב-35%.
| תרחיש | אסטרטגיה מומלצת | סיבה |
|---|---|---|
| כתיבה גבוהה, ללא מחיקות | STCS | הגברת כתיבה נמוכה |
| עומס קריאה, עדכונים | LCS | מינימום SSTables לכל קריאה |
| סדרות זמן, TTL | TWCS | מחיקה אוטומטית של SSTables שפג תוקפם |
למה Tombstones הורגים את חביון הקריאה
Tombstones הם סמנים לשורות שנמחקו. בעת קריאת מחיצה, Cassandra סורקת את כל ה-SSTables, אוספת נתונים חיים ומתעלמת מ-tombstones. אם יש רבים (למשל, DELETE תכופים ללא דחיסה בזמן), החביון מזנק. TWCS פותר זאת עבור סדרות זמן: SSTables שפג תוקפם נמחקים כשלמות, ללא השארת tombstones. במקרים אחרים, כוונון gc_grace_seconds ובחירת האסטרטגיה הנכונה עוזרים.
התהליך שלנו: מביקורת ועד פריסה
- ביקורת — ניתוח
nodetool tablestats, מדדי דחיסה ועומס, זיהוי צווארי בקבוק. - תכנון — עבור כל טבלה, בחירת אסטרטגיה ופרמטרים (סף מינימלי/מקסימלי, גודל דלי עבור TWCS).
- יישום — החלת
ALTER TABLEבשעות שפל. במידת הצורך, הרצתnodetool compactלפני המעבר. - בדיקות — אימות חביון קריאה/כתיבה, ניצול דיסק, מספר tombstones.
- פריסה וניטור — הגדרת התראות על משימות ממתינות ויחס tombstones ב-Prometheus/Grafana.
מקרה בוחן
עבור טבלת סדרות זמן עם מיליארד שורות, TTL = 30 ימים, עברנו מ-LCS ל-TWCS. הגברת הכתיבה ירדה מפי 8 לפי 1.5, חביון הקריאה ירד ב-40%. ניצול הדיסק ירד ב-30%, וחסכנו כ-$500 לחודש בעלויות אחסון. כל התהליך ארך יומיים ללא השבתה.מה כלול בשירות אופטימיזציית הדחיסה שלנו
- תיעוד עם הגדרות חדשות והמלצות.
- ניטור דחיסה לאחר השינוי (שבוע תמיכה).
- הכשרת צוות לאבחון בעיות דחיסה.
- גישה ללוח מחוונים של Grafana עם מדדי דחיסה.
- הבטחת שביעות רצון — אם הביצועים לא משתפרים, אנו מבצעים ביקורת חוזרת בחינם.
ביקורת הדחיסה שלנו עולה $1,500 ובדרך כלל חוסכת ללקוחות $6,000 בשנה בעלויות אחסון.
ציר זמן: 1 עד 3 ימים תלוי במספר הטבלאות ובמורכבות הארגון מחדש. אנו מעריכים לאחר הביקורת — צור קשר לייעוץ.
טעויות נפוצות בתצורת דחיסה
- שימוש ב-STCS לטבלאות עם מחיקות תכופות — tombstones מצטברים.
- מעבר ל-TWCS ללא דחיסה מוקדמת של SSTables ישנים.
- התעלמות מ-
compaction_throughput_mb_per_sec— השארת ערך ברירת המחדל. - יישום LCS על עומסי כתיבה כבדים — שורף I/O של דיסק.
אם האשכול שלך זקוק לכוונון דחיסה, צור קשר — נבצע ביקורת ונציע הגדרות אופטימליות עבור העומס שלך. התוצאה: חביון קריאה צפוי וחסכון של עד 40% בדיסק. קבע ביקורת דחיסה עוד היום כדי למנוע השבתות. למד עוד על אסטרטגיות דחיסה בתיעוד הרשמי של Apache Cassandra.