ניהול Apache Cassandra ו-ScyllaDB: ביקורת ותמיכה

קסנדרה ו-ScyllaDB הם מסדי נתונים למשימות שבהן PostgreSQL ו-MySQL נכנעים: מיליוני כתיבות בשנייה, פטה-בייטים של נתונים, אפס סובלנות לזמן השבתה. אבל המחיר עבור קנה המידה הליניארי הזה הוא מורכבות תפעולית גבוהה בסדר גודל. אנו נתקלים לעתים קרובות במצבים שבהם מפתח חלוקה שנבחר בצורה גרועה או ALLOW FILTERING תועה בייצור משפיעים על כל האשכול. במשך שנים של עבודה פיתחנו מתודולוגיה למניעת תרחישים כאלה. ניתן לקרוא עוד על Apache Cassandra בתיעוד הרשמי.

הבדלים עיקריים בין ScyllaDB לקסנדרה

ScyllaDB כתובה ב-C++ ומיישמת ארכיטקטורת shard-per-core: כל ליבת CPU מעבדת את מערך הנתונים שלה ללא מצב משותף בין תהליכונים. זה נותן חביון p99 נמוך פי 10 תחת אותו עומס בהשוואה לקסנדרה מבוססת JVM. בפועל: מה שדרש 6 צמתי קסנדרה רץ על 2 צמתי ScyllaDB עם ביצועים טובים יותר.

קסנדרה היא מוצר בוגר עם מערכת אקולוגית עשירה, תאימות טובה יותר לכלים ארגוניים, ואופי שחרור שמרני יותר. ScyllaDB תואמת ל-CQL ולנהגי קסנדרה אך יש לה מאפיינים משלה (לדוגמה, יישום שונה של טרנזקציות קלות משקל). הניסיון שלנו מראה שהבחירה תלויה בדרישות החביון ובצפיפות הצמתים.

טופולוגיית אשכול ותצורה

אשכול ייצור מינימלי: 3 צמתים עם RF=3. משמעות הדבר שכל מחיצה משוכפלת לכל שלושת הצמתים, ואובדן של צומת אחד אינו מאבד נתונים. אנו ממליצים על מופעים עם CPUs ייעודיים ו-SSDs עבור ה-commitlog.

cassandra.yaml עבור צומת ייצור:

---
cluster_name: 'prod-cluster'
num_tokens: 256
seed_provider:
  - class_name: org.apache.cassandra.locator.SimpleSeedProvider
    parameters:
      - seeds: "10.0.1.10,10.0.1.11"
listen_address: 10.0.1.10
rpc_address: 0.0.0.0
broadcast_rpc_address: 10.0.1.10
endpoint_snitch: GossipingPropertyFileSnitch
auto_bootstrap: true
# Compaction
compaction_throughput_mb_per_sec: 64
# Memtable
memtable_allocation_type: offheap_objects
memtable_heap_space_in_mb: 2048
# Commitlog
commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000
commitlog_segment_size_in_mb: 64
concurrent_reads: 32
concurrent_writes: 32
concurrent_counter_writes: 16

cluster_name: 'prod-cluster' num_tokens: 256 seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "10.0.1.10,10.0.1.11" listen_address: 10.0.1.10 rpc_address: 0.0.0.0 broadcast_rpc_address: 10.0.1.10 endpoint_snitch: GossipingPropertyFileSnitch auto_bootstrap: true # Compaction compaction_throughput_mb_per_sec: 64 # Memtable memtable_allocation_type: offheap_objects memtable_heap_space_in_mb: 2048 # Commitlog commitlog_sync: periodic commitlog_sync_period_in_ms: 10000 commitlog_segment_size_in_mb: 64 concurrent_reads: 32 concurrent_writes: 32 concurrent_counter_writes: 16 משמש בייצור — הוא קורא את GossipingPropertyFileSnitch כדי לקבוע את מרכז הנתונים והמדף:

dc=DC1 rack=RAC1 

למה בחירת מפתח חלוקה נכון חשובה

מפתח החלוקה קובע באיזה צומת הנתונים מאוחסנים. אם המפתח נבחר בצורה גרועה, נוצרת מחיצה חמה — צומת אחד מקבל 80% מהעומס בעוד אחרים בטלים. קסנדרה אינה רלציונית: אין JOINs, אין אינדקסים משניים במובן המסורתי. הסכמה מעוצבת עבור שאילתות, לא עבור נורמליזציה.

דוגמה לטבלה נכונה לאחסון אירועים ממוינים לפי זמן:

CREATE TABLE events_by_user (
    user_id UUID,
    event_time TIMEUUID,
    event_type TEXT,
    payload TEXT,
    PRIMARY KEY (user_id, event_time)
) WITH CLUSTERING ORDER BY (event_time DESC)
    AND compaction = {
        'class': 'TimeWindowCompactionStrategy',
        'compaction_window_size': '1',
        'compaction_window_unit': 'DAYS'
    };

cassandra-rackdc.properties הוא מפתח החלוקה; הנתונים של משתמש אחד מאוחסנים יחד. dc=DC1 rack=RAC1 הוא מפתח המיון, הקובע את הסדר בתוך מחיצה. שאילתה CREATE TABLE events_by_user ( user_id UUID, event_time TIMEUUID, event_type TEXT, payload TEXT, PRIMARY KEY (user_id, event_time) ) WITH CLUSTERING ORDER BY (event_time DESC) AND compaction = { 'class': 'TimeWindowCompactionStrategy', 'compaction_window_size': '1', 'compaction_window_unit': 'DAYS' }; מתבצעת ביעילות ללא user_id.

הגדרת דחיסה לעומס גבוה

דחיסות (Compactions) אורזות מחדש SSTables ומסירות רשומות שנמחקו. טעות אופיינית היא בחירת אסטרטגיה שגויה. עבור נתוני סדרות זמן השתמשו ב-event_time (TWCS): היא ממזגת SSTables רק בתוך חלון זמן, ומפחיתה עומס. עבור גישה אקראית — WHERE user_id = ? AND event_time > ? (STCS), אבל שימו לב ל-ALLOW FILTERING (ברירת מחדל 4) — דחיסה תכופה מדי הורגת את ה-IO. עבור ScyllaDB הגדירו בנוסף את TimeWindowCompactionStrategy:

compaction_static_shares: 0.5 table_compaction_dynamic_shares: true 

הפרמטר SizeTieredCompactionStrategy ב-min_threshold מגביל את תפוקת הדחיסה. אנו ממליצים להגדיר 64-128 MB/s כדי להימנע מהשפעה על חביון הקריאה/כתיבה.

תחזוקת אשכול: nodetool וניטור

scylla.yaml היא פעולה קריטית שלעתים קרובות מתעלמים ממנה. ללא תיקון (repair) קבוע, העתקים מתפצלים. הרצו כל compaction_static_shares: 0.5 table_compaction_dynamic_shares: true (ברירת מחדל 10 ימים). השתמשו בתיקון מצטבר כדי להפחית עומס:

# Инкрементальный repair — менее нагружает кластер
nodetool repair -inc -pr keyspace_name table_name

# Мониторинг состояния нод
nodetool status
nodetool tpstats # thread pool statistics
nodetool compactionstats # текущие compaction задачи

ScyllaDB מוסיפה את compaction_throughput_mb_per_sec — top אינטראקטיבי לניטור ברמת shard. עבור Prometheus: cassandra.yaml או JMX exporter מובנה עבור קסנדרה, מחסנית nodetool repair עבור ScyllaDB (כוללת לוחות מחוונים מוכנים של Grafana). אנו מגדירים התראות על חביון p99, צבר דחיסות, וסטטוס תיקון.

מאפיינים ייחודיים של ScyllaDB

ב-ScyllaDB אין gc_grace_seconds נפרד — במקום זאת # Инкрементальный repair — менее нагружает кластер nodetool repair -inc -pr keyspace_name table_name # Мониторинг состояния нод nodetool status nodetool tpstats # thread pool statistics nodetool compactionstats # текущие compaction задачи (שירות נפרד) מנהל משימות תיקון ברקע, ומפיץ את העומס לאורך זמן. זה הרבה יותר נוח. ל-scyllatop יש פרמטרים נוספים:

---
# Developer mode (отключить в production!)
developer_mode: false

# SMP — количество потоков (по числу ядер)
smp: 8

# Overprovisioning (для виртуалок)
overprovisioned: false
---

מה כולל שירות הניהול שלנו

• ביקורת אשכול קיים: ניתוח cassandra-exporter, התפלגות נתונים (scylla-monitoring), טבלאות עם העומס הגבוה ביותר, זיהוי nodetool repair ביומנים, מצב דחיסה.
• פריסת אשכול חדש: תפקיד Ansible להתקנה, כוונון תצורה, אתחול צומת seed, יצירת keyspaces עם RF אופטימלי, בדיקת עומס באמצעות scylladb-manager.
• מסירת תוצאות: runbook מלא עם הוראות להוספה/החלפת צמתים, לוח זמנים לתיקון, הגדרת התראות Prometheus, הדרכת צוות.
• אחריות: אנו תומכים באשכול למשך 30 יום לאחר המסירה, ומתקנים כל בעיה. הניסיון שלנו: 10+ שנים בייצור, 50+ פרויקטים מוצלחים.

העלות מחושבת באופן אישי לאחר ביקורת של דרישות העומס ונפח הנתונים. לייעוץ או להזמנת ביקורת, צרו קשר — אנו נבחר את התוכנית האופטימלית.

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