ניהול CockroachDB למסדי נתונים SQL מבוזרים

ניהול CockroachDB עבור מסדי נתונים SQL מבוזרים

אנחנו עוזרים לצוותים לפרוס ולתחזק את CockroachDB — מסד נתונים SQL מבוזר התואם ל-PostgreSQL, הבנוי על קונצנזוס Raft. בניגוד ל-Cassandra (עקביות בסופו של דבר) או ל-sharding של MongoDB, CockroachDB מבטיח עסקאות ACID על פני כל האשכול, אפילו בין צמתים באזורים שונים. המחיר: בידוד serializable דורש סיבובים בין צמתים לתיאום עסקאות. עבור עומסי עבודה כבדים בכתיבה עם הפצה גלובלית, זהו מגבלה חשובה שאנחנו לוקחים בחשבון בעת עיצוב הסכמה.

בעיה נפוצה: מפתחים מעבירים סכמת PostgreSQL מונוליטית ונתקלים בקונפליקטים בלתי צפויים של עסקאות עקב השהיית Raft. או שהם מנסים להשתמש ב-auto-increment ומקבלים נקודות חמות על טווח יחיד. אנחנו פותרים בעיות אלה בשלב הביקורת, וחוסכים שעות של תקלות ייצור.

למומחים שלנו יש ניסיון של 5+ שנים עם מסדי נתונים מבוזרים ועשרות פרויקטים על CockroachDB. אנחנו מציעים שירות סוהר: ביקורת על הסכמה הנוכחית שלך, פריסת אשכול, הגדרת ניטור וגיבוי. לוחות זמנים נעים בין 2 ל-5 ימים לאשכול בסיסי. השלמנו 30+ הטמעות של CockroachDB, כולל תצורות מרובות אזורים עם geo-partitioning.

טופולוגיית אשכול ואזורים

אשכול ייצור מינימלי: 3 צמתים באזור אחד. זה מכפיל את סובלנות התקלות בהשוואה למופע יחיד — Raft דורש קוורום של 2/3. לפריסה מרובת אזורים, אנחנו משתמשים ב-3–5 צמתים לכל אזור. CockroachDB משכפל אוטומטית טווחים (כ-64 MB כל אחד) לפי תצורות אזור.

התחלת צומת:

cockroach start \
 --certs-dir=/cockroach/certs \
 --store=/cockroach/data \
 --listen-addr=node1.internal:26257 \
 --advertise-addr=node1.internal:26257 \
 --http-addr=node1.internal:8080 \
 --join=node1.internal:26257,node2.internal:26257,node3.internal:26257 \
 --locality=region=us-east1,zone=us-east1-a \
 --background

cockroach start \ --certs-dir=/cockroach/certs \ --store=/cockroach/data \ --listen-addr=node1.internal:26257 \ --advertise-addr=node1.internal:26257 \ --http-addr=node1.internal:8080 \ --join=node1.internal:26257,node2.internal:26257,node3.internal:26257 \ --locality=region=us-east1,zone=us-east1-a \ --background הוא פרמטר מפתח. CockroachDB משתמש בתוויות אלה למיקום עותקים. אתחול האשכול (רק פעם אחת):

cockroach init --certs-dir=/cockroach/certs --host=node1.internal:26257 

איך להגדיר Geo-Partitioning לשיהוי נמוך?

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

-- Репликация в трёх регионах с 5 репликами
ALTER DATABASE production CONFIGURE ZONE USING
  num_replicas = 5,
  constraints = '[+region=us-east1:2, +region=eu-west1:2, +region=ap-southeast1:1]',
  lease_preferences = '[[+region=us-east1]]';

--locality קובע איזה אזור מחזיק ב-leaseholder — הצומת שמטפל בקריאות ללא סיבוב. הגדר זאת לאזור שממנו מגיעות רוב בקשות הקריאה.

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

ניטור ואבחון

ממשק ניהול ביציאה 8080 ומדדי Prometheus ב-cockroach init --certs-dir=/cockroach/certs --host=node1.internal:26257 . שאילתות SQL מרכזיות:

-- Медленные запросы
SELECT query, count, mean, p99
FROM crdb_internal.node_statement_statistics
ORDER BY mean DESC
LIMIT 20;

-- Hot spots — ranges с высоким QPS
SELECT range_id, reads_per_second, writes_per_second
FROM crdb_internal.kv_node_status;

נקודות חמות הן בעיה אופיינית: מפתח ראשי רציף (למשל, serial) יוצר טווח יחיד. פתרון — השתמש ב-UUID או ב--- Репликация в трёх регионах с 5 репликами ALTER DATABASE production CONFIGURE ZONE USING num_replicas = 5, constraints = '[+region=us-east1:2, +region=eu-west1:2, +region=ap-southeast1:1]', lease_preferences = '[[+region=us-east1]]'; כמפתח ראשי, או הגדר hash sharding.

איך להימנע מנקודות חמות?

הדרך הטובה ביותר היא להימנע ממפתחות ראשיים רציפים. השתמש ב-UUID v4 או ב-lease_preferences, שאינו יוצר מפתחות מסודרים. אם טבלה כבר משתמשת ב-serial, ניתן להעביר ל-UUID או להחיל אינדקס hash. נטר טווחים דרך /_status/vars כדי לראות אילו מחיצות עמוסות. תצורות אזור עם אילוצים עוזרות לפזר עומס באופן שווה.

גיבוי ושחזור

-- Full backup в S3
BACKUP INTO 's3://my-bucket/backups/full?AUTH=implicit' AS OF SYSTEM TIME '-10s';
-- Restore
RESTORE FROM 's3://my-bucket/backups/full?AUTH=implicit';

CockroachDB תומך ב--- Медленные запросы SELECT query, count, mean, p99 FROM crdb_internal.node_statement_statistics ORDER BY mean DESC LIMIT 20; -- Hot spots — ranges с высоким QPS SELECT range_id, reads_per_second, writes_per_second FROM crdb_internal.kv_node_status; — שאילתות מסע בזמן עד 25 שעות אחורה.

CockroachDB לעומת PostgreSQL עבור יישומים גלובליים

מה כלול

• ביקורת על סכמה ועסקאות קיימות
• פריסת אשכול יחיד או מרובה אזורים
• הגדרת TLS, תצורות אזור, ניטור (Prometheus + Grafana)
• תיעוד תפעולי ו-runbook
• הכשרת צוות (1–2 מפגשים)
• חודש ראשון של תמיכה

לוחות זמנים משוערים

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

למה CockroachDB עדיף על PostgreSQL עבור יישומים גלובליים

CockroachDB מספק עסקאות ACID על פני כל האשכול ללא sharding ידני. בעוד ש-PostgreSQL דורש הרחבות ותצורה מורכבת לעקביות מרובת אזורים, CockroachDB מתמודד עם זה מובנה. עם 3 צמתים באזורים שונים, השיהוי p99 לכתיבות הוא סביב 5–15 ms, שזה פי 2–3 נמוך יותר מ-PostgreSQL עם שכפול סינכרוני.

איך אנחנו עובדים

1. ביקורת — בדיקת תאימות SQL ועומס עבודה.
2. עיצוב — בחירת טופולוגיה, הגדרת תצורות אזור.
3. פריסה — השקת אשכול עם TLS וניטור.
4. בדיקות — chaos testing: הרוג צמתים, ודא שחזור.
5. מסירה — תיעוד והכשרה.

קבל ייעוץ לפרויקט שלך — צור קשר.