it-swarm.asia

الأوقات: SQL أو NoSQL؟

لا أهتم بالاختلافات العامة بين SQL و NoSQL (أو اختلافاتهم التقليدية).

إنني أتطلع حاليًا إلى تغيير سعة تخزين السلسلة الزمنية الداخلية. تحتوي جميعها على بيانات مالية من عدد من المصادر المختلفة. حاليًا ، نقوم بتخزين بياناتنا في قاعدة بيانات خاصة. إنها إلى حد كبير NoSQL ، ولها لغة استعلام خاصة بها.

أنا مهتم بإدخال المجتمع: كيف يمكنك تخزين البيانات في قاعدة بيانات SQL؟ ما هي مزايا استخدام SQL عبر NoSQL ، وتحديدا للسلسلة الزمنية؟ هل أنا مجنون للنظر في تخزين هذا في SQL؟

تتكون مجموعة بياناتنا من ملايين السلاسل الزمنية ، مع احتواء حوالي 10٪ منها على ملايين السجلات لكل منها. يتم تنظيم السلاسل الزمنية بشكل هرمي:/Market/Instrument/Value/Frequency ، حيث:

  • السوق عبارة عن سوق للأوراق المالية ، وما إلى ذلك ، هي في الأساس مجموعة من الأدوات ، وعادة ما تكون أدوات مماثلة.
  • الصك هو أداة. قد يكون هذا مؤشرًا (خام برنت) ، أو أسهم (GOOG) ، إلخ
  • القيمة هي أحد أنواع البيانات المتعددة للأداة. قد يكون هذا قريبًا ، مرتفعًا ، منخفضًا ، إلخ
  • التردد هو تردد قيم سلسلة زمنية معينة. أسبوعيًا ، يوميًا ، شهريًا ، علامة ، تعسفي ، إلخ.

كيف يتم تخزين البيانات في قاعدة بيانات SQL؟ طاولة كبيرة واحدة (ربما مقسمة حسب شيء) ، طاولة واحدة لكل سوق أو أداة ، طاولة واحدة لكل سلسلة زمنية.

شكرا لكم مقدما.

33
Nicolas

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

إذا طُلب مني إعداد قاعدة بيانات لتخزين تلك البيانات ، فسأفعل ما يلي:

المخطط المقترح

(1) يتم وضع البيانات الأساسية في العديد من (1000) من الجداول الفردية ، يحتوي كل منها على عمودين:

  1. الوقت: إما نوع بيانات SQL DATETIME أو نوع رقمي من بعض العصر (هذا هو المفتاح الأساسي)
  2. القيمة: تمت كتابتها بالشكل المناسب لبياناتك. قد أقوم بالتعويم بدقة واحدة ، ولكن قد يكون نوع البيانات الثابتة أكثر ملاءمة للمعاملات المالية. ربما هذا غير مفهرس.

ستصبح هذه الجداول كبيرة جدًا ، وقد ترغب في تقسيمها يدويًا حسب السنة (على سبيل المثال). ولكن عليك التحقق من أداء النظام وضبطه حسب الاقتضاء.

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

(2) يتم تخزين بيانات التعريف في جداول منفصلة ، كما هو مطلوب من قبل التطبيق :

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

إذا كانت هناك بيانات كافية ، يمكن أن يوفر هذا البحث في الواقع اسم جدول واسم قاعدة بيانات ، مما يسمح بنوع من مشاركة البيانات ذاتية التنفيذ (إذا كان هذا هو الاستخدام الصحيح للمصطلح). ولكن سأحتفظ بذلك في الاحتياطي.

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

المزايا:

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

  • يجب أن يسمح مفهوم الجدول النحيف هذا أيضًا بالوصول السريع إلى القرص لما أعتقد أنه الاستفسار الأكثر شيوعًا ، وهو نطاق متجاور من البيانات من كيان واحد. معظم تطبيقات البيانات محدودة على القرص I/O ، لذا فإن الأمر يستحق النظر. كما أشار أحد المعلقين بالفعل ، فإن هذا هو التطبيق المثالي لقاعدة بيانات موجهة نحو الأعمدة ، ولكن لم أجد بعد منتجًا موجهًا للأعمدة يكون سائدًا بما يكفي ليراهن على مهنتي. هذا المخطط يقترب جدا.

العيوب:

  • تم تخصيص حوالي نصف مساحة القرص الخاص بك لتخزين الطوابع الزمنية ، عندما يكون من 100 إلى 1000 من الجداول بصراحة نفس البيانات بالضبط في عمود الطابع الزمني. (في الواقع هذا مطلب إذا كنت ترغب في تنفيذ صلات الجدول سهلة).

  • يتطلب تخزين أسماء الجداول وإجراء البحث الديناميكي الكثير من تعقيد التطبيقات وعمليات السلسلة ، وهو ما يجعلني أشعر بالضيق. ولكن لا يزال يبدو أفضل من البدائل (نناقش أدناه).

اعتبارات:

  • احذر من التقريب في مجال وقتك. تريد قيمك تقريبًا بما يكفي لتمكين الصلات (إذا كان ذلك مناسبًا) ، ولكن دقيقة بما يكفي لتكون غير غامضة.

  • كن حذرا من المناطق الزمنية والتوقيت الصيفي. هذه صعبة الاختبار. سأفرض متطلب UTC على مخزن البيانات (مما قد يجعلني غير محبوب) وأتعامل مع التحويلات في التطبيق.

الاختلافات:

بعض الاختلافات التي فكرت فيها هي:

طي البيانات: إذا كانت المسافات الزمنية متساوية ، فاستخدم عمود الطابع الزمني و (على سبيل المثال) 10 أعمدة بيانات. يشير الطابع الزمني الآن إلى وقت عمود البيانات الأول ، ويفترض أن تكون أعمدة البيانات الأخرى متباعدة بشكل متساوٍ بين الطابع الزمني والعام التالي. هذا يوفر الكثير من التخزين الذي تم استخدامه سابقًا لتخزين الطوابع الزمنية ، بتكلفة استعلام و/أو تعقيد تطبيق كبير. نطاق متجاور ، تتطلب استعلامات الكيانات المفردة الآن وصولاً أقل إلى القرص.

تعدد الإرسال: إذا كان من المعروف أن سلاسل زمنية متعددة تستخدم نفس السلسلة الزمنية ، فاستخدم طابعًا زمنيًا واحدًا و (على سبيل المثال) 10 أعمدة بيانات كما هو موضح أعلاه . لكن الآن يمثل كل عمود سلسلة زمنية مختلفة. يتطلب ذلك تحديثًا لجدول البيانات الوصفية ، وهو ليس بحثًا عن اسم الجدول والعمود. يتم تقليل مساحة التخزين. تظل الاستفسارات بسيطة. على الرغم من النطاق المتجاور ، تتطلب استعلامات الكيانات المفردة الآن وصولاً أكبر إلى القرص بشكل ملحوظ.

جدول ضخم: خذ مفهوم "التعددية المتعددة" إلى أقصى حد ، وضع جميع البيانات في جدول واحد ، مرة واحدة في السلسلة الزمنية لكل عمود. هذا يتطلب كميات كبيرة من الوصول إلى القرص للنطاق المتجاور ، واستعلامات كيان واحد ، وهو كابوس للصيانة. على سبيل المثال ، تتطلب إضافة كيان جديد الآن أمر MODIFY TABLE على الكثير TB table.

لمزيد من المناقشة حول هذا التنسيق ، راجع الإجابات المتنوعة في: أعمدة كثيرة جدًا في MySQL

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

يتم استهلاك حوالي 2/3 من مساحة التخزين الآن مع أعمدة التطبيع ، لذلك سيستخدم هذا مساحة كبيرة من القرص.

يمكنك استخدام ترتيب مفتاح أساسي لـ (dataid ، timestamp) لاستعلامات الكيانات الفردية المتجاورة بسرعة. أو يمكنك استخدام ترتيب مفتاح أساسي من (الطابع الزمني. dataid) لإدراج أسرع.

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

26
Pursuit

باستخدام MongoDB ، يمكنك إنشاء مجموعات بسرعة فائقة. انظر إلى ترتيب بياناتك في قواعد بيانات منفصلة ، ومجموعات داخل قواعد البيانات هذه. ضع في اعتبارك مقدار الذاكرة التي ستحتاجها لمحاولة الاحتفاظ بكل جزء داخل ذاكرة النظام - إذا كنت بحاجة إلى استرجاع سريع. من السخف التمسك بمحلول داخلي ، إذا كان هناك شيء أعذب هناك سيتطور على طول الخطوط التي تحتاجها. تبدو مبادرة جيدة.

1
Dantalion