מערכת רישום עסקאות לבוט מסחר
בוט מסחר מראה רווח, אך לאחר התאמה ידנית מול הבורסה, 15% מהעסקאות אבדו עקב תקלת חיבור WebSocket. ללא לוג מפורט, שחזור רווח והפסד (P&L) בלתי אפשרי. בנינו מערכת רישום הלוכדת כל מיקרו-שנייה: מהאות ועד אישור הביצוע, ומתאמת אוטומטית מול Binance, Bybit ו-OKX כל 30 דקות. התוצאה — פער של פחות מ-0.01%. דיוק זה מאפשר הערכה בטוחה של יעילות האסטרטגיה ואיתור בעיות בזמן, כמו החלקת מחירים (slippage) מוגברת מעדכוני מחיר מיושנים. מערכת זו חוסכת לסוחרים עד 5,000 דולר בשנה בהפסדים נסתרים. עבור לקוח הסוחר 500 BTC ביום, פער העמלות בלבד עלה 3,200 דולר בחודש לפני ההתאמה.
לוג גרוע גורם להפסדים שמגלים מאוחר מדי. רישום העסקה הוא מקור האמת לחישוב התשואה, הבסיס לניתוח האלגוריתם, ראיה במחלוקות מול הבורסה, וכלי הניפוי העיקרי. רישום מפורט יכול לחשוף חריגות: החלקת מחירים מוגזמת ממחירי אות מיושנים, ביצועים חלקיים שהבוט לא התחשב בהם, או פערי עמלות. כל אחת מהשגיאות הללו יכולה לעלות עד 2% מהמחזור, ובנפחים גבוהים מדובר באלפי דולרים. אנו מבטלים סיכונים כאלה בשלב התכנון.
שדות מינימליים לעסקה
להלן הסט המינימלי של שדות לכל עסקה. כל שדה קריטי לביקורת עתידית.
| שדה | תיאור |
|---|---|
trade_id |
מזהה עסקה ייחודי במערכת הבוט |
exchange_trade_id |
מזהה בצד הבורסה לצורך התאמה |
symbol |
זוג מסחר (לדוגמה, BTC/USDT) |
side |
כיוון: קנייה או מכירה |
order_type |
סוג הזמנה: שוק / גבול / עצירה |
quantity |
כמות במטבע הבסיס |
execution_price |
מחיר ביצוע בפועל (לא מתוכנן) |
fee |
עמלה במטבע בסיס או ציטוט |
fee_currency |
מטבע העמלה |
strategy_id |
מזהה האסטרטגיה שיזמה את העסקה |
signal_id |
הפניה לאות שיצר את העסקה |
timestamp |
זמן העסקה (UTC, עם מיקרו-שניות) |
exchange_timestamp |
זמן בצד הפלטפורמה |
בנוסף, אנו רושמים החלקת מחירים — ההפרש בין המחיר המתוכנן למחיר הביצוע, השהיה — עיכוב מהאות ועד אישור הביצוע, ודגלי ביצוע חלקי (קטן עד 0.001 BTC). נתונים אלה עוזרים לזהות בעיות ביצוע ולמטב את האסטרטגיה. בפרויקט אחד, הוספת שדה החלקת המחירים צמצמה את הפער בין P&L מתוכנן לריאלי ב-0.5% — מה שהוביל לחיסכון משמעותי בנפח מסחר גבוה.
מדוע התאמה מול הבורסה קריטית?
יש לאמת את הלוג הפנימי מול היסטוריית העסקאות של הבורסה לפחות פעם בשעה. פערים נוצרים מעיכובי webhook, אירועים כפולים, או אובדן חיבור ברגע הביצוע. לפי תיעוד ה-API של Binance, יש לבצע התאמה לפחות פעם בשעה כדי לשמור על שלמות הנתונים. מקור: תיעוד ה-API של Binance אנו מיישמים אימות אוטומטי: כל N שעות (בר-הגדרה), הבוט שולף את היסטוריית העסקאות מהבורסה ומשווה אותה ללוג הפנימי. כשנמצא אי-התאמה — אל תיבהלו: הוסיפו את העסקה החסרה או סמנו את החשודה לבדיקה. תיקון אוטומטי מסוכן — עדיף להבין את הסיבה ידנית. מקרה טיפוסי: הפסקת WebSocket של 2 שניות יכולה לאבד עד 5% מהעסקאות; ההתאמה מוצאת ומשחזרת אותן.
כיצד לאוטמט את ההתאמה לדיוק מתמשך?
אוטומציה של אימות צולב היא המפתח לניטור רציף של שלמות הנתונים. הגדרנו משימת cron שרצה כל 30 דקות, ומשווה את הלוג להיסטוריית העסקאות של הפלטפורמה. כדי להפחית עומס על ה-API, אנו משתמשים בניווט מבוסס זמן. כשמתגלה אי-התאמה, השירות יוצר כרטיס במערכת נבחרת (Jira, Slack) עם פרטים: מזהי עסקאות, שדות חריגים, ותיקון מוצע. המפעיל צריך רק לאשר או לדחות שינויים. גישה זו מקצרת את זמן פתרון המחלוקות ב-3 פעמים.
אחסון הלוג לניתוח
PostgreSQL עם אינדקסים על חותמת זמן, strategy_id, symbol — הפתרון הסטנדרטי. לעומסים גבוהים, אנו משתמשים בחלוקה חודשית (partitioning). השוואת גישות:
| אחסון | מהירות כתיבה | יכולות אנליטיות | עלות |
|---|---|---|---|
| PostgreSQL (מחולק) | עד 10,000 שורות/שנייה | שאילתות SQL נרחבות | בינונית |
| MongoDB | עד 20,000 שורות/שנייה | אגרגציות מוגבלות | בינונית |
| InfluxDB (סדרות זמן) | עד 100,000 שורות/שנייה | שאילתות זמן ייעודיות | גבוהה יותר |
רישום PostgreSQL מחולק מהיר פי 3 מ-MongoDB ללא אינדקסים. ייצוא CSV הוא חובה: סוחרים אוהבים Excel. אנו גם משלבים את הלוג עם Grafana להצגת P&L בזמן אמת ומדדי מפתח.
שלבי יישום
- ניתוח דרישות — קביעת תדירות עסקאות, שדות נדרשים, צרכי התאמה.
- עיצוב סכמה — יצירת טבלאות, אינדקסים, חלוקה לפי עומס.
- יישום מודול רישום — אינטגרציה עם API של הבורסה, טיפול בכל סוגי ההזמנות.
- שירות התאמה — הגדרת אימות תקופתי, טיפול בפערים.
- ייצוא והצגה — CSV, אינטגרציה עם Grafana או Power BI.
- בדיקות עומס — סימולציה של עד 1000 עסקאות/שנייה, אימות שלמות.
דוגמה לתצורת חיבור PostgreSQL
CREATE TABLE trades (
trade_id VARCHAR(36) PRIMARY KEY,
exchange_trade_id VARCHAR(36),
symbol VARCHAR(10),
side CHAR(4),
order_type VARCHAR(10),
quantity DECIMAL(18,8),
execution_price DECIMAL(18,8),
fee DECIMAL(18,8),
fee_currency CHAR(3),
strategy_id INTEGER,
signal_id VARCHAR(36),
timestamp TIMESTAMPTZ,
exchange_timestamp TIMESTAMPTZ,
slippage DECIMAL(18,8),
latency INTERVAL
);
CREATE INDEX idx_timestamp ON trades (timestamp);
CREATE INDEX idx_strategy ON trades (strategy_id);
תוצרים
- תיעוד: תיאור סכמת נתונים, הוראות להוספת שדות חדשים, מדריך לפתרון פערים.
- קוד מקור: מודול רישום, תצורת PostgreSQL, סקריפטים לייצוא.
- גישה: למאגר הקוד ולשרת מסד נתונים לקריאה בלבד עבור סוחרים.
- הדרכה: סמינר מקוון לצוות על שימוש בלוג ופרשנות נתונים.
- תמיכה: מספר חודשים של תחזוקה לאחר ההשקה.
שיפור הביקורת עם רישום עסקאות
רישום עסקאות מפורט מאפשר לא רק חישוב P&L אלא גם מעקב אחר כל פעולה מהפקת האות ועד הביצוע. אנו מבטיחים שעם המערכת שלנו הפער בין הנתונים הפנימיים לבורסה לא יעלה על 0.01%. הלקוחות שלנו חוסכים בממוצע 15,000 דולר בעלויות נסתרות בשנה ועד 30% מזמן הניפוי בזכות תמונת מסחר שקופה. עם ניסיון של למעלה מ-5 שנים בפיתוח בוטים למסחר ו-50+ אינטגרציות מוצלחות, אנו מספקים רישום אמין. אם אתם רוצים שליטה מלאה בנתוני המסחר שלכם, צרו קשר לייעוץ — נכין תיאור פרויקט מותאם לאסטרטגיה שלכם. קבלו ביקורת על לוג העסקאות הנוכחי שלכם — נזהה חולשות ונציע שיפורים.







