QuestDB للتداول الخوارزمي: من دفتر الأوامر إلى بنية الإنتاج

الجزء 3 من 3 — متاح أيضاً بـ RU · ZH

إخلاء مسؤولية: المعلومات الواردة في هذا المقال هي لأغراض تعليمية وإعلامية فقط ولا تشكل نصيحة مالية أو استثمارية أو تداولية. ينطوي تداول العملات المشفرة على مخاطر خسارة كبيرة.

مرحباً بكم في الجزء الأخير من سلسلة QuestDB. في الجزء الأول تناولنا بنية التخزين. وفي الجزء الثاني استكشفنا امتدادات SQL. والآن لنجمع كل ذلك معاً: العروض المادية المحسوبة مسبقاً للتحليلات في الوقت الفعلي، وتخزين دفتر الأوامر الأصلي بمصفوفات ثنائية الأبعاد، والبنية المرجعية لمنصة تداول خوارزمي في بيئة الإنتاج.

العروض المادية المحسوبة مسبقاً: تحليلات بسرعة السلك

العروض المادية المتتالية: تتدفق بيانات التكات الخام عبر طبقات تجميع أكثر خشونة تدريجياً، حيث يعالج كل مستوى مجموعة بيانات أصغر بشكل جذري

إذا كان SAMPLE BY هو الاستعلام الأكثر استخداماً في QuestDB، فإن العروض المادية هي التحسين الأكثر تأثيراً. المفهوم بسيط: بدلاً من حساب تجميعات OHLCV عند كل تحديث للوحة المعلومات أو استدعاء API، يتم حسابها مسبقاً مرة واحدة مع الحفاظ على تحديث النتيجة باستمرار.

عرض مادي أساسي لـ OHLC

CREATE MATERIALIZED VIEW trades_OHLC_15m
  WITH BASE 'trades'
  REFRESH IMMEDIATE
AS
SELECT timestamp, symbol,
  first(price) AS open,
  max(price) AS high,
  min(price) AS low,
  last(price) AS close,
  sum(quantity) AS volume
FROM trades
SAMPLE BY 15m;

هذا هو التعريف بالكامل. في كل مرة يتم فيها إدراج صفوف جديدة في جدول trades، يقوم QuestDB تلقائياً بتحديث هذا العرض بشكل تزايدي. ليست إعادة حساب كاملة — بل يتم تحديث دلاء الوقت المتأثرة فقط. تصبح الاستعلامات على trades_OHLC_15m عمليات بحث بسيطة على مجموعة بيانات مجمعة مسبقاً أصغر بكثير.

الفرق في الأداء هائل. على جدول يحتوي مليارات الصفوف، قد يستغرق استعلام OHLC من الجدول الأساسي 200 مللي ثانية. يعيد العرض المادي النتيجة نفسها في أقل من 5 مللي ثانية. مع عدة مستخدمين متزامنين للوحة المعلومات، هذا ليس مجرد تحسين — إنه الفرق بين نظام متجاوب ونظام ينهار.

العروض المتتالية: أطر زمنية متعددة من مصدر واحد

هنا تصبح العروض المادية أنيقة من الناحية المعمارية. يمكنك ربطها في سلسلة — كل عرض يغذي التالي، مما يخلق تسلسلاً هرمياً لمستويات التجميع من مصدر بيانات خام واحد:

-- أعمدة ثانية واحدة من الصفقات الخام
CREATE MATERIALIZED VIEW ohlc_1s AS
SELECT timestamp, symbol,
  first(price) AS open, max(price) AS high,
  min(price) AS low, last(price) AS close,
  sum(quantity) AS volume
FROM trades
SAMPLE BY 1s;

-- أعمدة 5 ثوانٍ من أعمدة الثانية الواحدة
CREATE MATERIALIZED VIEW ohlc_5s AS
SELECT timestamp, symbol,
  first(open) AS open, max(high) AS high,
  min(low) AS low, last(close) AS close,
  sum(volume) AS volume
FROM ohlc_1s
SAMPLE BY 5s;

-- أعمدة دقيقة واحدة من أعمدة 5 ثوانٍ
CREATE MATERIALIZED VIEW ohlc_1m AS
SELECT timestamp, symbol,
  first(open) AS open, max(high) AS high,
  min(low) AS low, last(close) AS close,
  sum(volume) AS volume
FROM ohlc_5s
SAMPLE BY 1m;

يعالج كل مستوى مجموعة بيانات أصغر بشكل جذري من المستوى الذي يسبقه. لا يفحص عرض الدقيقة الواحدة الصفقات الخام — بل يقرأ فقط أعمدة 5 ثوانٍ المجمعة مسبقاً. يمتد هذا النمط المتتالي إلى أي عدد من الأطر الزمنية: 1s → 5s → 1m → 5m → 15m → 1h → 4h → 1d.

بالنسبة لمنصة بيانات العملات المشفرة التي تستقبل البيانات من أكثر من 100 بورصة، يعد هذا العمود الفقري لخط أنابيب تسليم OHLC بالكامل.

استراتيجيات التحديث

يقدم QuestDB ثلاثة أوضاع تحديث، كل منها مناسب لأحمال عمل مختلفة:

REFRESH IMMEDIATE يُطلق تحديثاً غير متزامن بعد كل معاملة في الجدول الأساسي. الأفضل للوحات المعلومات في الوقت الفعلي حيث يهم زمن الاستجابة دون الثانية.

REFRESH EVERY 1h (قائم على المؤقت) يجمع التحديثات في عمليات تحديث دورية. أفضل للاستيعاب عالي الإنتاجية حيث يؤدي تشغيل التحديث عند كل دفعة صغيرة إلى إنشاء حمل إضافي.

REFRESH PERIOD (LENGTH 1d TIME ZONE 'Europe/London' DELAY 2h) يحدد فترات متوافقة مع التقويم. يراعي "التأخير" البيانات المتأخرة الوصول — وهو أمر بالغ الأهمية للأسواق التي قد ترسل تصحيحات بعد ساعات من جلسة التداول.

REFRESH MANUAL يمنح تحكماً كاملاً. لا يتم تحديث العرض إلا عند تشغيل أمر REFRESH بشكل صريح — مفيد لسير عمل التسوية في نهاية اليوم.

نمط تسريع LATEST ON

أحد أقوى الأنماط يجمع بين العروض المادية وLATEST ON للحصول على لقطات فورية للمحفظة. فحص 1.3 مليار صف خام للحصول على أحدث سعر لكل رمز يستغرق ثوانٍ. لكن مع عرض يومي مجمع مسبقاً:

CREATE MATERIALIZED VIEW trades_latest_1d AS
SELECT timestamp, symbol, side,
  last(price) AS price,
  last(quantity) AS quantity,
  last(timestamp) AS latest
FROM trades
SAMPLE BY 1d;

يفحص استعلام LATEST ON حوالي 25,000 صف مجمع مسبقاً بدلاً من المليارات:

SELECT symbol, side, price, quantity, latest AS timestamp
FROM (
  trades_latest_1d
  LATEST ON timestamp PARTITION BY symbol, side
)
ORDER BY timestamp DESC;

من ثوانٍ إلى مللي ثوانٍ. هكذا تحقق لوحات معلومات التداول في بيئة الإنتاج الاستجابة في الوقت الفعلي عبر مجموعات بيانات ضخمة.

TTL: دورة حياة البيانات التلقائية

تدعم العروض المادية سياسات TTL (مدة البقاء) لانتهاء صلاحية البيانات التلقائي:

CREATE MATERIALIZED VIEW ohlc_1h AS (
  SELECT timestamp, symbol,
    avg(price) AS avg_price
  FROM trades
  SAMPLE BY 1h
) PARTITION BY WEEK TTL 8 WEEKS;

يحتفظ هذا بـ 8 أسابيع من البيانات بالساعة، ويحذف الأقسام الأقدم تلقائياً. بالدمج مع محرك التخزين ثلاثي الطبقات، تحصل على دورة حياة بيانات طبيعية: تتدفق التكات الخام عبر WAL → التخزين العمودي → Parquet على التخزين الكائني، بينما تحافظ العروض المادية على الملخصات المجمعة مسبقاً التي تستعلم عنها تطبيقاتك فعلياً.

المصفوفات ثنائية الأبعاد: تحليلات دفتر الأوامر الأصلية

عمق دفتر الأوامر ثلاثي الأبعاد: مستويات العرض والطلب مخزنة كمصفوفات أصلية ثنائية الأبعاد، مما يتيح حسابات الفروقات المحسنة بـ SIMD وتحليل السيولة

قدم QuestDB 9.0 مصفوفات N-الأبعاد — مصفوفات حقيقية ذات أشكال وخطوات شبيهة بـ NumPy تتعامل مع العمليات الشائعة (التقطيع، التبديل) بدون نسخ. في التداول، التطبيق القاتل هو تخزين دفتر الأوامر.

المشكلة التقليدية

تاريخياً، كان تخزين لقطات دفتر الأوامر في قاعدة بيانات علائقية مؤلماً. كان لديك خياران: صف واحد لكل مستوى سعري (انفجار في عدد الصفوف، استعلام العمق مكلف)، أو عدد ثابت من الأعمدة مثل bid1_price، bid1_size، bid2_price، bid2_size، إلخ (جامد، مهدر، وقبيح).

تقضي مصفوفات QuestDB ثنائية الأبعاد على كلتا المشكلتين:

CREATE TABLE market_data (
  timestamp TIMESTAMP,
  symbol SYMBOL,
  bids DOUBLE[][],
  asks DOUBLE[][]
) TIMESTAMP(timestamp) PARTITION BY HOUR;

يخزن كل عمود bids وasks مصفوفة ثنائية الأبعاد حيث يحتوي الصف الأول على الأسعار والصف الثاني على الأحجام عند كل مستوى. دفتر أوامر من 20 مستوى هو مصفوفة مدمجة واحدة، وليس 40 عموداً منفصلاً.

تحليلات دفتر الأوامر في SQL

حساب الفارق السعري — المقياس الأبسط والأكثر حساباً:

SELECT timestamp,
  spread(bids[1][1], asks[1][1]) AS spread
FROM market_data
WHERE symbol = 'EURUSD'
  AND timestamp IN today();

دالة spread() هي دالة مدمجة تحسب الفرق بين أفضل سعر طلب وأفضل سعر عرض. bids[1][1] تصل إلى العنصر الأول (أفضل سعر) من الصف الأول (الأسعار) في مصفوفة العروض.

للتحليلات الأكثر تطوراً — عمق السيولة، اختلال توازن دفتر الأوامر، احتمال التنفيذ عند مستوى سعري معين — يجعل تقطيع المصفوفات والعمليات المتجهة الاستعلامات المعقدة سابقاً بسيطة:

-- إيجاد المستوى الذي سيتم الوصول فيه إلى سعر مستهدف
-- وجمع جميع الأحجام حتى ذلك المستوى
DECLARE @target := bids[1][1] * 1.01;
SELECT timestamp,
  array_sum(asks[2][1:level_idx]) AS volume_to_fill
FROM market_data
WHERE symbol = 'EURUSD';

تعني عمليات المصفوفات المحسنة بـ SIMD أن هذه الحسابات تعمل بسرعة قريبة من العتاد، حتى على ملايين اللقطات.

استيعاب بيانات المصفوفات

تدعم مكتبات عملاء QuestDB استيعاب المصفوفات الأصلية. يتكامل عميل Python مباشرة مع مصفوفات NumPy:

import numpy as np
from questdb.ingress import Sender

bids = np.array([[9.3, 9.2, 9.1], [100, 200, 150]])  # prices, volumes
asks = np.array([[9.5, 9.6, 9.7], [80, 160, 120]])

with Sender.from_conf("http::addr=localhost:9000;") as sender:
    sender.row(
        'market_data',
        symbols={'symbol': 'EURUSD'},
        columns={'bids': bids, 'asks': asks},
        at=timestamp
    )

يشفر Protocol Version 2 المصفوفات بصيغة ثنائية، مما يقلل بشكل كبير من عرض النطاق الترددي والحمل الإضافي للتحليل من جانب الخادم مقارنة بالبروتوكولات النصية. لاستيعاب دفتر الأوامر عالي التردد — حيث قد تتلقى آلاف اللقطات في الثانية لكل رمز — هذه الكفاءة مهمة.

تستخدم عملاء C/C++ مصفوفات مسطحة بترتيب الصف الرئيسي مع واصفات الشكل، مما يتيح الاستيعاب بدون نسخ من هياكل بيانات نظام التداول الحالية.

تجميع كل شيء معاً: البنية المرجعية

البنية المرجعية: موصلات البورصة، نواة قاعدة البيانات العمودية، طبقة التحليلات، محرك الاستراتيجيات، ولوحات المراقبة — جميعها مترابطة

لنصمم منصة تداول خوارزمي كاملة مدعومة بـ QuestDB لأسواق العملات المشفرة. تتعامل هذه البنية مع الاستيعاب من بورصات متعددة، والتحليلات في الوقت الفعلي، والاختبار الرجعي، وتنفيذ الاستراتيجيات.

طبقة استيعاب البيانات

استيعاب البيانات: موصلات بورصات متعددة تغذي بيانات السوق في الوقت الفعلي عبر أنابيب WebSocket إلى QuestDB عبر ILP

اتصالات WebSocket متعددة بالبورصات (Binance، Bybit، OKX، إلخ) تغذي بيانات السوق الخام إلى QuestDB عبر ILP over HTTP. كل موصل بورصة هو عملية منفصلة، مما يوفر العزل والتسامح مع الأخطاء.

تشمل تدفقات البيانات: الصفقات (timestamp، symbol، side، price، quantity)، لقطات دفتر الأوامر (timestamp، symbol، bids[][]، asks[][])، ومعدلات التمويل والتصفيات كتدفقات مساعدة.

هدف إنتاجية الاستيعاب: ملايين الصفوف في الثانية عبر جميع البورصات مجتمعة. يتعامل WAL في QuestDB مع هذا بسهولة، مع التقاط التكرارات الحتمية من اتصالات البورصة المتكررة عبر إزالة التكرار.

طبقة التحليلات في الوقت الفعلي

تشكل العروض المادية جوهر طبقة التحليلات:

Raw trades → ohlc_1s → ohlc_5s → ohlc_1m → ohlc_5m → ohlc_15m → ohlc_1h → ohlc_1d

يتم تحديث كل مستوى بشكل تزايدي. لوحة معلومات Grafana المتصلة عبر المكون الإضافي الأصلي لـ QuestDB تستعلم عن هذه العروض لمخططات الشموع اليابانية، بأوقات استجابة أقل من 5 مللي ثوانٍ بغض النظر عن كمية البيانات التاريخية الموجودة.

تحسب عروض مادية إضافية: VWAP (متوسط السعر المرجح بالحجم) لكل رمز يومياً، تقديرات التقلب المتداولة، ومراقبة الفروقات بين البورصات.

تعمل استعلامات LATEST ON ضد العروض المجمعة مسبقاً على تشغيل لوحة معلومات المحفظة في الوقت الفعلي — لعرض المراكز الحالية، والأرباح والخسائر غير المحققة، والتعرض لكل بورصة.

محرك الاستراتيجيات

محرك الاستراتيجيات: حسابات المؤشرات في الوقت الفعلي تغذي اتخاذ القرار الخوارزمي، مع مسارات تنفيذ البيع/الشراء المحسنة بالعروض المادية

تستعلم استراتيجيات التداول من QuestDB عن حالة السوق الحالية والأنماط التاريخية. بروتوكول PG wire الخاص بـ QuestDB يعني أن أي لغة تحتوي على مشغل PostgreSQL يمكنها الاتصال: Python لاستراتيجيات البحث، Rust أو C++ للتنفيذ الحساس لزمن الاستجابة.

أنماط الاستعلام الرئيسية للاستراتيجيات: ASOF JOIN لمطابقة عمليات التنفيذ مع ظروف السوق في وقت التنفيذ، WINDOW JOIN لحساب مقاييس الأفق القصير حول كل حدث، ودوال النوافذ لحساب المؤشرات في الوقت الفعلي (RSI، نطاقات بولينجر، ATR).

بالنسبة للاستراتيجيات الحساسة لزمن الاستجابة، تقلل العروض المادية المحسوبة مسبقاً من وقت الاستعلام. روبوت الشبكة الذي يراقب 50 رمزاً لا يحتاج إلى حساب 50 متوسطاً متحركاً منفصلاً عند كل تكة — بل يقرأها من عرض مادي.

خط أنابيب الاختبار الرجعي

تعيش البيانات التاريخية في Parquet على التخزين الكائني. يستعلم QuestDB عنها بشفافية، ولكن لأحمال الاختبار الرجعي الثقيلة، يمكن أيضاً قراءة البيانات مباشرة بواسطة Polars أو Pandas أو DuckDB — متجاوزاً قاعدة البيانات بالكامل.

هذا النمط مزدوج الوصول قوي: تستخدم الاستراتيجية المباشرة واجهة SQL الخاصة بـ QuestDB للقرارات في الوقت الفعلي، بينما يقرأ إطار الاختبار الرجعي نفس البيانات عبر Parquet/Arrow للمعالجة الدفعية. نفس البيانات، مساران محسنان للوصول.

المراقبة وتحليل ما بعد التداول

يشغل HORIZON JOIN خط أنابيب تحليل ما بعد التداول:

• تحليل الانزلاق السعري: مقارنة سعر التنفيذ بالسعر المتوسط في وقت التنفيذ
• منحنيات العلامة المستقبلية: تتبع تطور السعر بعد كل تنفيذ بمقدار 1 ثانية، 5 ثوانٍ، 30 ثانية، 60 ثانية
• قصور التنفيذ: تحليل تكاليف التنفيذ إلى فارق سعري، وتأثير مؤقت، وتأثير دائم
• تقييم الأماكن: مقارنة جودة التنفيذ عبر البورصات لتحسين توجيه الأوامر

تُنفذ هذه التحليلات كاستعلامات مجدولة، تكتب النتائج في جداول مخصصة تغذي لوحات المراقبة. تُطلق قواعد التنبيه عند الشذوذ — ارتفاعات مفاجئة في الانزلاق السعري، أنماط علامة مستقبلية غير عادية، أو تدهور جودة التنفيذ في أماكن محددة.

اعتبارات الأداء

ضبط أداء الإنتاج: مراقبة زمن الاستجابة والإنتاجية والذاكرة إلى جانب دورة حياة البيانات الساخنة-الدافئة-الباردة

بعض الملاحظات العملية من عمليات النشر في بيئة الإنتاج:

حجم الأقسام: لبيانات تكات العملات المشفرة بملايين الصفوف يومياً، يكون PARTITION BY HOUR هو الأمثل عادةً. هذا يبقي الأقسام الفردية قابلة للإدارة لكل من التخزين وأداء الاستعلام.

تتالي العروض المادية: لا تنشئ مستويات وسيطة كثيرة جداً. كل مستوى يضيف زمن تأخير للتحديث. لمعظم حالات الاستخدام، توفر 3-4 مستويات (1s → 1m → 15m → 1d) توازناً جيداً بين أداء الاستعلام وحداثة البيانات.

حمل إزالة التكرار: فعّل إزالة التكرار على الجداول ذات مصادر البيانات المتكررة. التكلفة ضئيلة للبيانات ذات الطوابع الزمنية الفريدة لكنها تزداد مع الصفوف الكثيرة ذات الطوابع الزمنية المتماثلة التي تحتاج إزالة تكرار على مستوى العمود.

تخصيص الذاكرة: محرك QuestDB الخالي من جمع القمامة فعال، لكن خصص ذاكرة كافية للأقسام الساخنة وذاكرة التخزين المؤقت للكتابة. راقب عبر نقطة نهاية المقاييس المدمجة.

اختيار بروتوكول العميل: استخدم ILP over HTTP للاستيعاب (مع إعادة المحاولة التلقائية وفحوصات الصحة). استخدم PG wire للاستعلامات. ILP Protocol Version 2 (الترميز الثنائي) أكثر كفاءة بشكل ملحوظ لبيانات المصفوفات وقيم double عالية الإنتاجية.

QuestDB مقابل البدائل

المشهد التنافسي: موقع QuestDB مقارنة بـ TimescaleDB وClickHouse وInfluxDB وkdb+ عبر أبعاد القدرات الرئيسية

موقع موجز مقارنة بقواعد البيانات المستخدمة عادةً في التداول:

مقابل TimescaleDB: TimescaleDB هو PostgreSQL مع امتدادات السلاسل الزمنية. يرث عمومية PG ولكن أيضاً حملها الإضافي. يقدم محرك QuestDB العمودي الأصلي وتنفيذ SIMD أداء استعلام أفضل بشكل ملحوظ على أحمال عمل السلاسل الزمنية، وميزات مثل ASOF JOIN ليس لها مكافئ مباشر في TimescaleDB.

مقابل ClickHouse: يتفوق ClickHouse في الاستعلامات التحليلية على مجموعات البيانات الضخمة. لكنه لم يُصمم للسلاسل الزمنية تحديداً — لا يوجد ASOF JOIN أصلي، ولا SAMPLE BY مع FILL، ولا مصفوفات ثنائية الأبعاد لدفتر الأوامر. لأحمال العمل المختلطة OLAP + السلاسل الزمنية، قد يتفوق ClickHouse؛ لبيانات التداول الصرفة، QuestDB أكثر ملاءمة.

مقابل InfluxDB: لدى InfluxDB قيود على العلاقة العالية التي تكون مؤلمة لبيانات العملات المشفرة متعددة البورصات. تفتقر لغة الاستعلام الخاصة به (Flux، المهملة الآن؛ InfluxQL) إلى تعبيرية امتدادات SQL الخاصة بـ QuestDB. الأداء على الاستعلامات التاريخية الكبيرة عموماً أسوأ.

مقابل kdb+/q: المعيار الذهبي للتداول عالي التردد. kdb+ أسرع لعمليات متجهية معينة أحادية الخيط ولغة q مقتضبة بشكل لا يصدق. لكنها مملوكة ومكلفة وذات منحنى تعلم حاد. يقدم QuestDB نسبة 80-90% من القدرات بجزء بسيط من التكلفة، مع SQL قياسي وترخيص مفتوح المصدر.

الخاتمة: قاعدة بيانات تفهم التداول

عبر هذه المقالات الثلاث، غطينا بنية QuestDB (التخزين ثلاثي الطبقات مع WAL والعمودي وParquet)، وامتدادات SQL (SAMPLE BY، ASOF JOIN، HORIZON JOIN، WINDOW JOIN، LATEST ON، TWAP)، وتطبيقاتها العملية (العروض المادية، مصفوفات دفتر الأوامر، البنية المرجعية).

الخيط المتسق واضح: صُمم QuestDB بالضبط لأحمال العمل التي ينتجها التداول الخوارزمي. لا يجبرك على التحايل على قاعدة البيانات — بل تتطابق عناصره الأولية مباشرة مع مفاهيم التداول. تجميع OHLC سطر واحد. محاذاة الصفقة مع عرض السعر هي JOIN واحد. تحليل ما بعد التداول هو HORIZON JOIN، وليس إجراء PL/SQL من عدة صفحات.

للفرق التي تبني بنية تحتية للتداول — سواء كانت منصة بيانات سوق العملات المشفرة، أو بيئة بحث كمي، أو محرك تداول خوارزمي كامل — يستحق QuestDB تقييماً جاداً. تغطي النسخة مفتوحة المصدر معظم حالات الاستخدام، وتملأ نسخة Enterprise الثغرات للبيئات المنظمة.

يتطور مشهد البنية التحتية للبيانات المالية بسرعة. قواعد البيانات التي تتحدث لغة الأسواق ستفوز. QuestDB يتحدثها بطلاقة.

تداول سعيد، ونتمنى أن تكون أزمنة الاستجابة لديك منخفضة.

Citation

@software{soloviov2025questdb_algotrading_p3,
  author = {Soloviov, Eugen},
  title = {QuestDB for Algorithmic Trading: From Order Books to Production Architecture},
  year = {2025},
  url = {https://marketmaker.cc/en/blog/post/questdb-algotrading-production},
  version = {0.1.0},
  description = {Materialized views, 2D array order book analytics, and reference architecture for a QuestDB-powered algorithmic trading platform.}
}