הגדרת פיצול מסד נתונים (PlanetScale/Neon) ל-DevOps

הגדרת פיצול מסד נתונים (PlanetScale/Neon) ל-DevOps

כאב קלאסי בעבודה עם feature branches: מפתח מריץ ALTER TABLE במסד הנתונים המקומי שלו, מפתח אחר מריץ ALTER TABLE אחר, הם נפגשים ב-staging ומתנגשים. ה-PR לא ניתן למיזוג — הסכמה התפצלה. פיצול מסד נתונים פותר זאת ברמת הפלטפורמה: כל feature branch מקבל עותק מבודד של סכמת מסד הנתונים. אנו מיישמים גישה זו באופן turnkey: מניתוח תאימות ועד אוטומציה ב-CI/CD. תוצאה — הפחתת MTTR פי 3–5 וחיסכון משמעותי בעלויות מיגרציות. הלקוחות שלנו מדווחים על הפחתה של 70% בהתנגשויות סכמה והאצה של 90% ביצירת סביבות preview.

איך זה עובד ב-PlanetScale וב-Neon

PlanetScale בונה פיצול על גבי Vitess (אותו מנוע המשמש ל-MySQL ב-YouTube/Slack). כל branch הוא keyspace נפרד ב-Vitess. שינויי סכמה עוברים דרך Deploy Requests (מקביל ל-Pull Requests עבור DDL). בעת מיזוג branch, PlanetScale מיישם שינויי סכמה ללא downtime באמצעות ghost migrations מתחת למכסה. הניסיון שלנו מראה שזה מקצר את זמן ה-rollback משעות לדקות.

Neon רץ על PostgreSQL עם שכבת אחסון copy-on-write על גבי מנוע האחסון שלו. יצירת branch אורכת שניות ללא קשר לגודל מסד הנתונים — מכיוון שהנתונים לא מועתקים פיזית עד שמתרחשת כתיבה. זה הופך את ה-branches של Neon לנוחים במיוחד עבור סביבות preview ב-CI/CD. אורך חיים ממוצע של branch הוא 2-4 שעות, מה שחוסך משאבים.

למה פיצול מסד נתונים מהיר יותר ממיגרציות מסורתיות

גישה מסורתית — מסד נתונים staging יחיד שבו כולם ממזגים מיגרציות ברצף. אם שני מפתחים מוסיפים בו-זמנית עמודה עם אותו שם אבל סוג שונה — התנגשות. פיצול מסד נתונים מבודד כל branch, ובדיקת מיזוג בודקת תאימות לפני deploy. PlanetScale משתמש בניתוח schema diff, ו-Neon משתמש ב-snapshot isolation. תוצאה: MTTR מופחת פי 3–5, לפי המדידות שלנו. קבלו אודיט — נראה לכם כמה שעות downtime תוכלו לחסוך.

איך לשלב פיצול מסד נתונים עם CI/CD

דוגמה עבור Neon עם GitHub Actions:

---
# .github/workflows/preview.yml
name: Preview Environment
on:
  pull_request:
    types: [opened, synchronize]
jobs:
  create-branch:
    runs-on: ubuntu-latest
    outputs:
      db_url: ${{ steps.create-branch.outputs.db_url }}
    steps:
      - uses: neondatabase/create-branch-action@v5
        id: create-branch
        with:
          project_id: ${{ vars.NEON_PROJECT_ID }}
          branch_name: preview/pr-${{ github.event.number }}
          api_key: ${{ secrets.NEON_API_KEY }}
          username: app_user
  deploy-preview:
    needs: create-branch
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run migrations on branch
        run: |
          DATABASE_URL="${{ needs.create-branch.outputs.db_url }}" \
          npx prisma migrate deploy
      - name: Deploy preview app
        env:
          DATABASE_URL: ${{ needs.create-branch.outputs.db_url }}
        run: |
          # деплой preview окружения с URL этой ветки
          vercel deploy --env DATABASE_URL="$DATABASE_URL" 

ניקוי לאחר מיזוג PR:

---
cleanup:
  if: github.event.action == 'closed'
  runs-on: ubuntu-latest
  steps:
    - uses: neondatabase/delete-branch-action@v3
      with:
        project_id: ${{ vars.NEON_PROJECT_ID }}
        branch: preview/pr-${{ github.event.number }}
        api_key: ${{ secrets.NEON_API_KEY }}

PlanetScale: Deploy Requests ומיגרציות בטוחות

ב-PlanetScale, פעולות DDL ישירות על ה-main branch חסומות — אילוץ מכוון. כל השינויים עוברים דרך development branch → deploy request:

# Создать dev-ветку
pscale branch create myapp add-payment-table --org myorg

# Подключиться к ветке через proxy
pscale connect myapp add-payment-table --port 3309

# Применить миграцию (через любой ORM или прямым SQL)
mysql -h 127.0.0.1 -P 3309 -u root myapp < migrations/add_payment_table.sql

# Создать deploy request
pscale deploy-request create myapp add-payment-table

PlanetScale מנתח את ה-schema diff ומראה בדיוק מה ישתנה. אם הפעולה דורשת העתקת טבלה מלאה (למשל, שינוי סוג עמודה), הפלטפורמה מזהירה ומבצעת זאת דרך שינוי סכמה מקוון באמצעות gh-ost. אנו מבטיחים zero-downtime לייצור עם תצורה נכונה.

מגבלות ומתי זה לא מתאים

PlanetScale לא תומך במפתחות זרים — מגבלה יסודית של Vitess. אם הסכמה משתמשת באופן פעיל ב-FK עם מחיקות מדורגות, PlanetScale דורש refactoring ברמת האפליקציה. זהו שינוי ארכיטקטוני משמעותי שדורש הערכה נפרדת. יש לנו ניסיון בהעברת פרויקטים מ-FK לאילוצים לוגיים — צרו קשר לפרטים. Neon לא מתאים לעומסי כתיבה גבוהים על branch יחיד — שכבת האחסון מותאמת לעומסי קריאה כבדים ופיצול מהיר, לא לאלפי טרנזקציות בשנייה.

מה העבודה שלנו כוללת

1. אודיט סכמה — בדיקת תאימות לפלטפורמת היעד (Vitess/Neon).
2. עיצוב זרימת עבודה ב-CI/CD — GitHub Actions / GitLab CI ליצירה/מחיקה אוטומטית של branches לכל PR.
3. שילוב מיגרציות — חיבור Prisma, Flyway, Liquibase ל-branches.
4. הגדרת תהליך review — Deploy Requests ב-PlanetScale, policy-as-code עבור Neon.
5. תיעוד והדרכה — runbook למפתחים לעבודה עם branches.
6. תמיכה לשבועיים לאחר היישום — תיקון מקרי קצה.

לוח זמנים ואיך להזמין

פרויקט סטנדרטי עם ORM אחד ו-GitHub Actions אורך 3–5 ימי עסקים. ארכיטקטורות מורכבות עם מספר שירותים — עד 10 ימים. קבלו ייעוץ — נשלח תוכנית ולוח זמנים מדויק. אנו מציעים גם אודיט תאימות סכמה — צרו קשר כדי לבקש זאת.

טעויות נפוצות בפיצול מסד נתונים

• אין ניקוי branches לאחר מיזוג ב-CI — מסדי נתונים מצטברים, עלויות גדלות. ניקוי נכון חוסך משמעותית.
• התעלמות מנעילות עם gh-ost על טבלאות גדולות — סיכון ל-downtime.
• ניסיון להשתמש ב-Neon עבור OLTP עם עומס כתיבה גבוה — ביצועים מתדרדרים.
• חוסר RBAC על branches — מפתחים ממזגים בטעות את ה-branch הלא נכון.

אנו מבטיחים שתרחישים אלה מטופלים ב-pipeline שלכם. מעל 5 שנות ניסיון ב-DevOps, 30+ יישומי פיצול מסד נתונים ללקוחות fintech ו-e-commerce.