QuestDB للتداول الخوارزمي: بنية تتحدث لغة الأسواق

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

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

مرحباً! اليوم نبدأ سلسلة من ثلاثة أجزاء للتعمق في QuestDB — قاعدة بيانات السلاسل الزمنية مفتوحة المصدر التي تصبح بهدوء العمود الفقري للبنية التحتية الحديثة للتداول. هذا ليس مقال قائمة "أفضل 10 قواعد بيانات". سندخل في التفاصيل التقنية، لأن هذا ما يتطلبه التداول الخوارزمي.

إذا عانيت يوماً من قيود الكاردينالية في InfluxDB، أو حاربت حمل TimescaleDB الإضافي على بيانات التكات، أو تساءلت لماذا لا يستطيع PostgreSQL مواكبة مليون إدراج في الثانية — فهذه السلسلة لك.

لماذا قواعد بيانات السلاسل الزمنية مهمة للتداول

كل نظام تداول خوارزمي — من بوت الشبكة البسيط إلى محرك HFT الكامل — لديه نفس التبعية الأساسية: البيانات. تحديداً، بيانات مرتبة زمنياً تصل بسرعة هائلة وتحتاج أن تكون قابلة للاستعلام في الوقت الفعلي.

لم تُصمم قواعد البيانات العلائقية التقليدية لهذا. تتفوق في معاملات ACID وعمليات JOIN المعقدة عبر المخططات المُطبَّعة، لكنها تختنق بأعباء العمل الإلحاقية المقسمة زمنياً التي تُعرّف الأسواق المالية. ينتهي بك الأمر بمحاربة قاعدة البيانات بدلاً من السماح لها بالعمل من أجلك.

قواعد بيانات السلاسل الزمنية تقلب هذا النموذج. تفترض أن بياناتك تحتوي على طابع زمني، وأنها تصل بترتيب تقريبي، وأن استعلاماتك ستتضمن دائماً تقريباً نطاقات زمنية. QuestDB يذهب أبعد من ذلك بكونه مُصمماً خصيصاً مع وضع أسواق رأس المال في الاعتبار — فريقه الهندسي يأتي من بنوك استثمارية من المستوى الأول (BoA وUBS وHSBC)، وهذا يظهر في كل قرار تصميمي.

QuestDB في لمحة

QuestDB هو قاعدة بيانات سلاسل زمنية مفتوحة المصدر (Apache 2.0) مكتوبة بلغة Java بدون GC وC++ وRust. الجزء "بدون GC" حاسم: المحرك الأساسي يتجنب جامع القمامة في Java بالكامل، ويدير الذاكرة يدوياً للقضاء على ارتفاعات الكمون غير المتوقعة التي تصيب معظم الأنظمة المبنية على JVM.

خصائص الأداء الرئيسية الجديرة بالملاحظة:

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

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

محرك التخزين ثلاثي الطبقات

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

الطبقة 1: WAL (سجل الكتابة المسبقة)

البيانات الواردة تصل أولاً إلى سجل الكتابة المسبقة. هذه طبقة الإلحاق فائقة الكمون المنخفض. كل كتابة تُجعل دائمة قبل حدوث أي معالجة — تنجو من الأعطال وانقطاعات الطاقة بدون فقدان بيانات. WAL هو كتابة تسلسلية فقط، مما يعني أنه يتوافق تماماً مع محركات SSD وNVMe الحديثة.

لأنظمة التداول، هذا يعني أن خط أنابيب استيعاب بيانات السوق يمكنه ضخ البيانات في QuestDB دون القلق بشأن تضخيم الكتابة أو تنافس الأقفال. سواء كنت تتلقى تحديثات WebSocket من 50 بورصة عملات مشفرة أو تعالج تدفقاً هائلاً من رسائل FIX، فإن WAL يمتص كل شيء.

يُشحن WAL أيضاً بشكل غير متزامن إلى تخزين الكائنات، مما يمكّن النسخ الجديدة من التمهيد السريع وقراءة نفس السجل — خاصية حاسمة للتعافي من الكوارث في بيئات التداول الإنتاجية.

الطبقة 2: التخزين العمودي

بشكل غير متزامن، يتم ترتيب البيانات زمنياً وإزالة التكرارات وكتابتها في تنسيق QuestDB العمودي الأصلي. هذا التنسيق مُقسم زمنياً (حسب الساعة أو اليوم أو الأسبوع أو الشهر حسب حجم بياناتك) وقابل للاستعلام فوراً.

التخطيط العمودي هو ما يمكّن أداء استعلام QuestDB. عندما تسأل عن متوسط سعر BTC-USD خلال الساعة الأخيرة، يقرأ المحرك عمود price فقط من أقسام الوقت ذات الصلة — ليس صفوفاً كاملة. مع التنفيذ المتجه بـ SIMD عبر نوى متعددة، ينتج عن ذلك أوقات استعلام دون الميلي ثانية تجعل لوحات المعلومات في الوقت الفعلي وحسابات الاستراتيجية المباشرة ممكنة.

يُخزن كل جدول كملفات منفصلة لكل عمود، مع الأنواع ثابتة الحجم تحصل على ملف واحد لكل عمود والأنواع متغيرة الحجم (مثل VARCHAR) تستخدم اثنين. هذا التخطيط مبني خصيصاً لأنواع المسح التسلسلي التي تهيمن على تحليلات السلاسل الزمنية.

الطبقة 3: تخزين الكائنات (Parquet)

هنا تلتقي إدارة التكاليف مع التوافقية. يتم تحويل الأقسام الأقدم تلقائياً إلى تنسيق Apache Parquet وشحنها إلى تخزين الكائنات (S3 أو Azure Blob أو GCS). لكن — وهذا هو الابتكار الرئيسي — يمكنك الاستعلام عنها بشفافية من خلال واجهة SQL الخاصة بـ QuestDB. مخطط الاستعلام يمتد عبر الطبقات الثلاث بسلاسة.

للمتداولين الخوارزميين، هذا يعني أنه يمكنك الاحتفاظ بسنوات من بيانات التكات التاريخية متاحة للاختبار الرجعي دون الدفع مقابل تيرابايت من تخزين SSD. يمكن لإطار الاختبار الرجعي بلغة Python قراءة نفس ملفات Parquet مباشرة عبر Polars أو Pandas أو Spark — لا حاجة لتصدير قاعدة البيانات. يمكن لخط أنابيب تدريب ML الوصول لنفس البيانات عبر Arrow/ADBC للمعالجة في الذاكرة. صفر حبس للمورد.

هذا اقتراح مختلف جذرياً عن تنسيقات قواعد البيانات الاحتكارية التي تحبس بياناتك خلف واجهة استعلام واحدة.

تصميم المخطط لبيانات التداول

فلسفة تصميم المخطط في QuestDB تدور حول بضعة مفاهيم حاسمة تتوافق تماماً مع بيانات التداول:

الطابع الزمني المُعيَّن

كل جدول سلاسل زمنية يحتاج عمود طابع زمني مُعيَّن. هذا ليس مجرد بيانات وصفية — يحدد ترتيب التخزين الفعلي ويُمكّن تقليم الأقسام. بدونه، تفقد معظم فوائد أداء QuestDB:

CREATE TABLE trades (
  timestamp TIMESTAMP,
  symbol SYMBOL,
  side SYMBOL,
  price DOUBLE,
  quantity DOUBLE
) TIMESTAMP(timestamp) PARTITION BY DAY;

نوع SYMBOL

نوع SYMBOL هو إجابة QuestDB على مشكلة السلاسل النصية عالية الكاردينالية. أزواج التداول مثل "BTC-USD" أو "ETH-USDT" تُخزن كإدخالات قاموس مفهرسة بأعداد صحيحة. التصفية والتجميع على أعمدة SYMBOL أسرع بشكل كبير من VARCHAR — يحل QuestDB مقارنات السلاسل النصية إلى مقارنات أعداد صحيحة في وقت الترجمة.

إذا كنت تستوعب بيانات من أكثر من 100 بورصة بآلاف أزواج التداول، فإن هذا التحسين وحده يمكن أن يكون الفرق بين استعلام يستغرق 5ms و500ms.

استراتيجية التقسيم

يجب أن يتناسب حجم القسم مع حجم بياناتك. بيانات التكات عالية التردد (ملايين الصفوف يومياً لكل رمز) يجب أن تستخدم PARTITION BY HOUR. بيانات نهاية اليوم منخفضة الحجم تعمل بشكل جيد مع PARTITION BY MONTH. الهدف هو الحفاظ على الأقسام الفردية قابلة للإدارة مع تمكين التقليم الفعال:

-- High-volume tick data
CREATE TABLE ticks (...) TIMESTAMP(ts) PARTITION BY HOUR;

-- Lower-volume daily prices
CREATE TABLE eod_prices (...) TIMESTAMP(ts) PARTITION BY MONTH;

إزالة تكرار البيانات

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

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

اعتبارات النشر الإنتاجي

عملاء QuestDB الإنتاجيون يشملون B3 (أكبر بورصة في أمريكا اللاتينية)، وOne Trading (بورصة عملات مشفرة منظمة تستوعب حتى 4 ملايين صف في الثانية)، وLaser Digital (مجموعة نومورا)، والعديد من البنوك وصناديق التحوط من المستوى الأول.

بعض ملاحظات النشر العملية:

• يدعم QuestDB بروتوكول PostgreSQL السلكي، لذا تعمل معظم مكتبات عملاء PG مباشرة
• للاستيعاب عالي الإنتاجية، يُعد InfluxDB Line Protocol (ILP) عبر HTTP أو TCP المسار المُوصى به
• Protocol Version 2 (من QuestDB 9.0+) يضيف ترميز ثنائي للمصفوفات والأرقام المزدوجة، مما يقلل بشكل كبير من عرض النطاق الترددي وحمل المعالجة على الخادم
• إنشاء المخطط التلقائي وتغييرات المخطط المتزامنة تتيح التعامل مع تدفقات بيانات متعددة مع تعديلات أثناء التشغيل

الإصدار المؤسسي يضيف RBAC (بما في ذلك صلاحيات على مستوى العمود)، وتشفير TLS، والنسخ والتجاوز التلقائي، والتخزين المتدرج إلى مخازن كائنات السحابة، ودعم مخصص مع اتفاقيات مستوى الخدمة. للبيئات المُنظمة، هذه متطلبات أساسية.

ما سيأتي في الجزء 2 و3

في الجزء 2، سنتعمق في ملحقات SQL للسلاسل الزمنية في QuestDB — SAMPLE BY وASOF JOIN وHORIZON JOIN وWINDOW JOIN وLATEST ON — مع أمثلة تداول حقيقية. هذه ليست تحسينات تدريجية على SQL القياسي؛ إنها أدوات مختلفة جذرياً تُلغي فئات كاملة من الاستعلامات المعقدة.

في الجزء 3، سنغطي التطبيقات التجارية العملية: العروض المادية لـ OHLC في الوقت الفعلي، والمصفوفات ثنائية الأبعاد لتحليلات دفتر الأوامر، والبنية المرجعية الكاملة لمنصة تداول خوارزمي مبنية على QuestDB.

ترقبوا.

Citation

@software{soloviov2025questdb_algotrading_p1,
  author = {Soloviov, Eugen},
  title = {QuestDB for Algorithmic Trading: Architecture That Speaks the Language of Markets},
  year = {2025},
  url = {https://marketmaker.cc/en/blog/post/questdb-algotrading-architecture},
  version = {0.1.0},
  description = {Deep dive into QuestDB's three-tier storage architecture and schema design for algorithmic trading systems.}
}