אחסון היסטוריית הזמנות: סכמה, אופטימיזציה, צינור נתונים

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

כיצד לבחור סכמת מסד נתונים להזמנות?

הזמנה במערכת מסחר היא לא רק רשומה "קנה 1 BTC ב-50000". המודל המלא כולל מספר סוגי אירועים. אחסון אירועים אלה בנפרד (Event sourcing) מספק שחזור מלא: אתה תמיד יכול לשחזר את המצב של כל הזמנה בכל נקודת זמן. עבור סדרות זמן של הזמנות, TimescaleDB או ClickHouse הן אופטימליות.

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

CREATE TABLE order_events (
    event_id UUID DEFAULT gen_random_uuid(),
    event_time TIMESTAMPTZ NOT NULL,
    order_id UUID NOT NULL,
    exchange VARCHAR(32) NOT NULL,
    symbol VARCHAR(32) NOT NULL,
    event_type VARCHAR(32) NOT NULL,
    side VARCHAR(8),
    order_type VARCHAR(16),
    price NUMERIC(24, 8),
    quantity NUMERIC(24, 8),
    filled_qty NUMERIC(24, 8),
    avg_fill_price NUMERIC(24, 8),
    commission NUMERIC(24, 8),
    commission_asset VARCHAR(16),
    client_order_id VARCHAR(64),
    strategy_id VARCHAR(64),
    metadata JSONB
);
SELECT create_hypertable('order_events', 'event_time', chunk_time_interval => INTERVAL '1 day');

כיצד לבצע אופטימיזציה של שאילתות להיסטוריית הזמנות?

שחזור מצב הזמנה הוא פעולה תכופה. במקום לחשב מחדש מאירועים בכל פעם, שמור טבלה מהותית (materialized) CREATE TABLE order_events ( event_id UUID DEFAULT gen_random_uuid(), event_time TIMESTAMPTZ NOT NULL, order_id UUID NOT NULL, exchange VARCHAR(32) NOT NULL, symbol VARCHAR(32) NOT NULL, event_type VARCHAR(32) NOT NULL, side VARCHAR(8), order_type VARCHAR(16), price NUMERIC(24, 8), quantity NUMERIC(24, 8), filled_qty NUMERIC(24, 8), avg_fill_price NUMERIC(24, 8), commission NUMERIC(24, 8), commission_asset VARCHAR(16), client_order_id VARCHAR(64), strategy_id VARCHAR(64), metadata JSONB ); SELECT create_hypertable('order_events', 'event_time', chunk_time_interval => INTERVAL '1 day'); עם המצב הנוכחי. עדכן טבלה זו בכל אירוע חדש באמצעות טריגר או לוגיקה בצד היישום.

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

SELECT strategy_id, symbol,
       SUM(CASE WHEN side = 'BUY' THEN -filled_qty * avg_fill_price ELSE filled_qty * avg_fill_price END) as realized_pnl,
       SUM(total_commission) as total_fees,
       COUNT(*) as order_count
FROM orders
WHERE created_at BETWEEN CURRENT_DATE - INTERVAL '1 year' AND CURRENT_DATE
  AND status = 'FILLED'
GROUP BY strategy_id, symbol
ORDER BY realized_pnl DESC;

אגרגציות רציפות של TimescaleDB מאפשרות חישוב מוקדם של אגרגציות אלה ועדכון שלהן באופן מצטבר.

אחסון ביצועים (Fills) בנפרד

לניתוח מפורט של איכות ביצוע, קריטי לאחסן ביצועים בודדים בנפרד מהזמנות. זה מאפשר חישוב VWAP של ביצוע, השוואה למחיר האמצע בזמן הביצוע (השפעת שוק), וניתוח יחס maker/taker לפי אסטרטגיה.

מדיניות שמירה וארכוב

נתונים חמים מאוחסנים ללא דחיסה למהירות כתיבה וקריאה מקסימלית. נתונים ישנים יותר דחוסים. דחיסת TimescaleDB משיגה הפחתת גודל של פי 10–20 עבור סדרות זמן עם ערכים חוזרים. ניתן לייצא נתונים מעל שנתיים לקבצי Parquet על S3 באמצעות pg_parquet או ETL מותאם, תוך שמירה על יכולת ניתוח היסטורי באמצעות Athena או ClickHouse.

צינור קליטת נתונים

כתיבות בתדירות גבוהה דורשות אצווה (batching). במקום INSERT לכל אירוע, השתמש ב-COPY להכנסות בכמות גדולה — מהיר פי 10–50. צבור אירועים בזיכרון (100ms או 1000 אירועים) וכתוב עם COPY יחיד. טבלאות לא רשומות (Unlogged) עבור חיץ ביניים נמנעות מכתיבת WAL, ומאיצות משמעותית הכנסות. איגוד חיבורים באמצעות PgBouncer מאפשר לשרת אלפי לקוחות.

ALTER TABLE order_events SET (
    timescaledb.compress,
    timescaledb.compress_segmentby = 'exchange, symbol',
    timescaledb.compress_orderby = 'event_time DESC'
);
SELECT add_compression_policy('order_events', INTERVAL '30 days');

ניטור והתראות

מדדים מרכזיים לניטור אחסון:

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

שכפול וסבילות לתקלות

אחסון הייצור מריץ שכפול סטרימינג של PostgreSQL: ראשי לכתיבות, עותק (replica) לשאילתות אנליטיות. במקרה של כשל ראשי, מעבר אוטומטי באמצעות Patroni עם החלפה אוטומטית. RPO עם הגדרות synchronous_commit נכונות הוא אפס. תיעוד TimescaleDB ממליץ על תצורה זו עבור מערכות קריטיות. לצוות שלנו יש 10 שנות ניסיון בפיתוח בלוקצ'יין ויישמנו פתרונות דומים לקרנות עם מחזור של מעל מיליארד דולר. עם למעלה מ-5 שנים בשוק ו-50+ פרויקטים שנמסרו בהצלחה, אנו מבטיחים פתרון חזק וניתן להרחבה.

מה כלול בעבודה

• תיעוד של סכמת הנתונים וארכיטקטורת הצינור.
• קוד לסכמת TimescaleDB/ClickHouse, טריגרים, מדיניות דחיסה.
• צינור קליטה מוגדר עם אצווה ואיגוד חיבורים.
• סקריפטי הגירה ופריסה (CI/CD).
• לוחות ניטור (Grafana + Prometheus).
• מדריך הפעלה (Runbook) והדרכה לצוות שלך (2–3 מפגשים).
• תמיכה לאחר השחרור למשך שבועיים.

כיצד אנו מפתחים את האחסון

1. ניתוח עומס — פרופיל תעבורה קיימת, קביעת RPS ושאילתות אופייניות.
2. עיצוב סכמה — בחירה בין TimescaleDB ל-ClickHouse, עיצוב hypertables ואינדקסים.
3. יישום צינור — הגדרת אצווה, איגוד חיבורים, טבלאות לא רשומות.
4. הגדרת דחיסה ושמירה — קביעת מדיניות לנתונים חמים וקרים.
5. שכפול וניטור — פריסת Patroni, הגדרת התראות ולוחות.
6. בדיקת עומס — סימולציה של 50,000 אירועים/שנייה ואימות זמן השהיית p99.
7. תיעוד והדרכה — מסירת קוד, סכמות ומדריך הפעלה לצוות שלך.

הערכת פרויקט

נעריך את הפרויקט שלך בחינם תוך 2 ימי עסקים. נשלח המלצות ארכיטקטורה והצעת מחיר בחודשי אדם. צור קשר — נדון במקרי השימוש שלך ונעזור לתכנן אחסון אמין שלא יאכזב אותך. חיסכון אופייני של 40% בעלויות אחסון בהשוואה לפתרונות מסורתיים. עבור חברת מסחר בינונית, זה מתורגם לחיסכון שנתי של מעל 45,000 דולר. קבל ייעוץ היום.