لقد اختبرنا مؤخرًا الطريقة التي نسميها QDM عند العمل بكميات كبيرة من البيانات - مئات الجيجابايت. كجزء من المهمة ، قمنا بمعالجة 12-24 مليون سجل وقارننا أداء حل الخماسي مع وظائف مماثلة في الجداول العادية.
لم نقم بأي اكتشافات جديدة ، لكننا أكدنا الفرضيات التي عبرنا عنها سابقًا: كم يفقد المصمم العالمي في أيدي "إبريق الشاي" الشرطي إلى قاعدة بيانات تم تكوينها بشكل احترافي.
نعلم الآن أيضًا ما يجب القيام به في مثل هذا الموقف - الحل بسيط وموثوق به تمامًا ، ولدينا خبرة في تنظيم حل توفيقي للبيانات الضخمة بشكل تعسفي.
أثناء تطوير نظام التوفيق بين التقارير ، كنا بحاجة إلى تنزيل بيانات أحد نماذج التقارير ، والتي تحتوي على ما يصل إلى 24 مليون سجل في كل تاريخ إبلاغ. يجب أن تكون هناك بيانات لمدة 7 سنوات من الحسابات اليومية. مجلدات ، بصراحة ، ليس لمصمم عالمي ، ولكن لنظام متخصص للغاية ، لكننا شاركنا بالفعل في هذا المشروع وكان علينا البحث عن حل.
يعمل المستخدمون مع مجموعة البيانات الكبيرة هذه فقط خلال تاريخ إعداد تقرير واحد ، وبالتالي ، في النظام المرجعي ، يتم تخزين كل هذا في جدول مقسوم على هذا التاريخ. لا يتم استخدام فهارس لحقول البيانات المتبقية 26 لهذا النموذج.
أول ما فعلناه ، بالطبع ، هو إنشاء بنية البيانات المطلوبة في المُنشئ وتحميل عدة تواريخ هناك. يستغرق تنزيل واحد من أصغر التواريخ حوالي 14 ساعة ، وهي مدة غير مقبولة: 12.5 مليون سجل به 27 سمة ، وضعت في نصف مليار سجل من 5 حقول مع بناء ثلاثة مؤشرات ، اثنان منها مركبان.
المبلغ الإجمالي لهذه البيانات على القرص يزيد قليلاً عن 18 جيجابايت.
تجدر الإشارة إلى ميزات اثنين من هذا النموذج:
- يكاد لا يفسح المجال للتطبيع ، على سبيل المثال ، من النموذج 110 ، الذي تمت مناقشته في منشور سابق
- لا يستخدم الفهارس على سمات السجلات - من الأفضل للمستخدم الانتظار لمدة دقيقة بدلاً من إنفاق الأموال على الفهارس
يمكن القول أن هذه الحالة الأكثر تطرفًا والتي يمكنك اختيارها للمقارنة. في معظم الحالات ، لا يكون الاختلاف في حجم بيانات QDM وقاعدة البيانات المعتادة دراماتيكيًا أو صغيرًا جدًا .
للمقارنة ، تأخذ نفس البيانات التي تم تحميلها في جدول منتظم في قاعدة بيانات علائقية 2.3 غيغابايت (أقل 8 مرات) مع الفهرس حسب التاريخ ، ويستمر تحميلها أقل من نصف ساعة (أسرع 28 مرة). في كلتا الحالتين ، تم إدراج البيانات مباشرة من الملف في أجزاء من 100 ألف سجل ، دون تعطيل الفهارس.
مع الأخذ في الاعتبار أنه ليس من العملي استخدام مُنشئ لمثل هذه الكميات من البيانات ، فقد أجرينا اختبارات أداء: في حالات مختلفة ، قارنا المعالجة الجماعية للسجلات مع المُنشئ وجدولنا غير المفهرس. نحتاج إلى تحديد حدود كمية البيانات التي سنستخدمها من الآن فصاعدًا في جدول منتظم ، وليس منشئنا.
كما توقعنا ، فإن العمل مع مجموعات البيانات الصغيرة ، على سبيل المثال ، في حساب أو عميل منفصل ، في المصمم يبدو مريحًا جدًا (وقت الاستجابة خلال ثانية واحدة) ، على عكس جدول بدون فهارس ، حيث يتعين عليك الانتظار لمدة دقائق للرد. في الوقت نفسه ، يمكن أن تستغرق المهمة الرئيسية للتطبيق - أخذ عينات كبيرة وتجميع البيانات في أقسام مختلفة - عدة مرات في المصمم.
فيما يلي النتائج الموجزة للعينات التي قمنا بإعدادها لزيادة حجم البيانات المجمعة تدريجياً:
حيثما كان ذلك ممكنًا ، أجرينا العديد من القياسات ، بعد اختيار الإحصائيات واختيار عدد السجلات بواسطة قناع رقم الحساب.
يوضح الجدول والرسم البياني أدناه أن تجميع مجموعة كاملة من البيانات خلال يوم يستغرق وقتًا أقل بكثير من أخذ أكثر من 5٪ من البيانات باستخدام الفهرس. هذا هو السبب وراء تجاهل مُحسِّن استعلام RDBMS الفهرس في مثل هذه الحالة ، في حين أن محرك خدمتنا في الوقت الحالي محروم من هذه الفرصة.
عرض رسومي لنفس النتائج باستخدام مقياس لوغاريتمي لمقارنة أعداد الطلبات المختلفة:
تكون سرعة المصمم عند معالجة مجموعة بيانات كاملة تقريبًا أقل من تلك الموجودة في الجدول العادي ، وهو أمر طبيعي جدًا بالنسبة للمصمم - من المهم تجنب تدهور يشبه الانهيار الجليدي للأداء ، وقد تحقق هذا الهدف.
أوضحت الدراسة أن عدد السجلات في قاعدة البيانات ليس له أي تأثير عمليًا على سرعة بناء الصفحات والملاحة والعينات الصغيرة في نموذج بيانات الخماسي. من خلال كمية البيانات التي تمت معالجتها والتي تصل إلى 10000 سجل (وهذا هو الحد الأقصى لاختيار البيانات ذات الصلة لمثيل أي كيان تجاري في نظام المعلومات) ، يمكنك العمل بشكل مريح مع قاعدة بيانات من مئات غيغابايت أو أكثر.
بعد ذلك ، قمنا بتدريس المكون الإضافي للجدول (الموضح هنا ) لاستدعاء موصل لقاعدة بيانات تعسفية بحيث يعمل بشفافية مع كل من نموذج بيانات الخماسي والجداول التقليدية.
من وجهة نظر المستخدم ، لا يهتم بمصدر البيانات الذي يعمل معه بينما يمكنه القيام بالعمل المهم له في الواجهة المألوفة ، ويتلقى تقاريره:
سنقوم الآن بإخراج الجداول الضخمة المماثلة المتبقية ، والتي في قاعدة بياناتنا لا تزيد عن عشرين من مئات ، في تخزين منفصل من أجل العمل معهم بشكل مريح.
لذلك ، يمكننا استخدام المُنشئ للجداول الصغيرة والمتوسطة التي تتطلب بحثًا وتجميعًا مكثفين من خلال السمات التعسفية ، وتخزين الكائنات الكبيرة غير المفهرسة في الجداول التقليدية المسطحة ، والاتصال بهم من وحدات التخزين التابعة لجهات خارجية أو قواعد البيانات المتخصصة (Hadoop وغيرها من NoSQL).
المصمم هو الأنسب لأنظمة CRM والمنتجات المماثلة ، حيث يعمل المستخدم مع عميل واحد أو حساب أو كيان آخر ، ويتم نقل الوظائف التحليلية إلى وحدة تخزين متخصصة منفصلة.