ماذا يحدث لنموذج Qlik Sense القائم بالكامل على الذاكرة عندما لا تعود الذاكرة العشوائية رخيصة أو متوفرة بلا حدود؟ نقارنه بمعمارية TURBOARD الهجينة باستخدام وثائق Qlik الرسمية وبراءة الاختراع الممنوحة لنا في مجال التخزين المؤقت الذكي.
طوال معظم العقد الماضي، بُنيت منصات ذكاء الأعمال على افتراض مريح: أن الذاكرة ستبقى تزداد رخصاً، وكثافة، وسهولة في التوسع لمعالجة المشكلات. هذا الافتراض ينكسر بهدوء. فعمليات بناء البنية التحتية للذكاء الاصطناعي تستهلك حصة غير مسبوقة من إمدادات DRAM وHBM العالمية، وقد حذّر كبار مصنّعي الذاكرة من أن القيود مرشحة للتعمق حتى عام 2026. بالنسبة لفرق ذكاء الأعمال في المؤسسات، النتيجة العملية واضحة: الذاكرة العشوائية التي تعتمد عليها منصة التحليلات الخاصة بك أصبحت أغلى ثمناً، وأكثر تنافساً، وأصعب في التوسع عند الطلب.
هذا يغيّر السؤال المهم.
سؤال الأداء التقليدي في ذكاء الأعمال كان: ما مدى سرعة لوحة البيانات عندما تتسع البيانات داخل الذاكرة؟ إنه السؤال الذي تحبه الشركات المُصنِّعة، لأن الإجابة دائماً تقريباً “سريعة جداً”. لكن هذا لم يعد السؤال الذي يقرر ما إذا كانت المنصة ستصمد في الإنتاج. السؤال الحقيقي الآن هو: كيف تتصرف المنصة عندما تتزايد أحجام البيانات، ويتضاعف عدد المستخدمين المتزامنين، وتصبح الذاكرة المورد الذي لا يمكنك ببساطة شراء المزيد منه؟
هذا السؤال له إجابتان مختلفتان جداً في السوق اليوم. يمثّل Qlik Sense المدرسة الناضجة القائمة على الذاكرة — حمّل كل شيء في الذاكرة العشوائية، احتفظ به هناك، ودع المحرك الترابطي يقدّم السرعة من خلال القرب. أما TURBOARD فيمثّل المدرسة الهجينة — تعامل مع الذاكرة كطبقة تسريع لأحمال العمل التي تستفيد أكثر، ووجّه كل شيء آخر إلى التخزين العمودي أو المصادر المباشرة المصممة لهذه المهمة.
كلا الفلسفتين تعمل. السؤال المثير للاهتمام هو أيهما يتقدم في العمر بشكل أفضل مع تغيّر الظروف المحيطة بها. هذا المقال يستعرض ما يحدث فعلاً لكل معمارية مع نمو البيانات وزيادة المستخدمين وتقلّص الذاكرة العشوائية — مستخدماً وثائق Qlik الرسمية ومعمارية TURBOARD المنشورة كدليل.
معماريتان باختصار
Qlik Sense مبني حول محرك QIX الترابطي. عند تحميل أي تطبيق، تُحفظ مجموعة البيانات غير المُجمَّعة بالكامل في الذاكرة العشوائية، إلى جانب الهياكل الترابطية التي تربط كل قيمة بكل قيمة أخرى. تُجاب اختيارات المستخدمين بالمرور عبر هذه الهياكل الموجودة في الذاكرة، وتُخزَّن نتائج الحسابات مؤقتاً في الذاكرة العشوائية بحيث تعود الطلبات المتطابقة اللاحقة فوراً.
صيغة QVD الخاصة بـ Qlik تُسرّع طبقة التحميل بشكل كبير — تشير وثائق Qlik إلى أن قراءات QVD أسرع بعشرة إلى مئة ضعف من القراءات من المصادر الأخرى — لكن نموذج وقت التشغيل لا يزال يتطلب أن تقيم مجموعة البيانات العاملة في الذاكرة الفعلية.
TURBOARD يسلك مساراً مختلفاً. يمكن الوصول إلى البيانات من خلال اتصالات مباشرة مُحسَّنة باستخدام برامج تشغيل قاعدة بيانات مخصصة، أو استيرادها إلى متجر عمودي عالي الأداء مثل MariaDB ColumnStore أو ClickHouse أو Vertica. تُخزَّن نتائج الاستعلامات الأكثر استخداماً مؤقتاً في Redis، متجر بنية البيانات في الذاكرة.
آلية مُحفِّز التخزين المؤقت (cache-trigger) تقرر متى تظل النتائج المخزنة مؤقتاً صالحة ومتى يحتاج المصدر إلى استعلام جديد. تُستخدم الذاكرة بشكل متعمد، لأحمال العمل التي تنتج فيها أكبر قدر من التسريع — وليست المكان الافتراضي لكل البيانات التحليلية.
المخطط أعلاه يوضح كيف تتكامل طبقات TURBOARD معاً. بقية المقال تتفحص ما تفعله كل معمارية مع اشتداد الظروف المحيطة بها.
السيناريو العادل: عندما يفوز النهج القائم على الذاكرة
من المهم أن نقول بوضوح: عندما تتسع مجموعة البيانات بسهولة في الذاكرة العشوائية، ويكون عدد المستخدمين المتزامنين معتدلاً، وتكون البيئة محسّبة بحسب التطبيق، فإن Qlik Sense سريع حقاً. المحرك الترابطي قطعة هندسية ناضجة، وتجربة المستخدم في النقر عبر الفلاتر ومشاهدة عمليات التجميع تُعاد حسابها في أجزاء من الثانية، في يومه الجيد، ممتازة. للنشر على مستوى الأقسام، والتطبيقات التحليلية المركّزة، وأحمال العمل التي يكون فيها نموذج البيانات مستقراً ومفهوماً جيداً، النهج القائم على الذاكرة قوة حقيقية.
هذا هو السيناريو الذي تُبنى حوله معظم العروض التوضيحية للمنتج. وهو أيضاً السيناريو الذي يخبرك بأقل ما يمكن عن كيفية تصرف المنصة بعد عام من الإنتاج، بعد أن نمت البيانات، واتسعت قاعدة المستخدمين، ونُشرت ثلاثة تطبيقات إضافية على نفس الخادم.
سيناريو التوسع: حيث تتباعد المعماريتان
وثائق الدعم الرسمية لـ Qlik تصف نموذج الذاكرة بالتفصيل. يعمل المحرك مقابل عتبتين قابلتين للتهيئة معروفتين باسم Working Set Low و Working Set High، بقيم افتراضية تبلغ 70% و90% من الذاكرة العشوائية الفعلية على التوالي. أسفل العتبة المنخفضة، يحتفظ المحرك بنتائج الحسابات المخزّنة مؤقتاً بقوة، انطلاقاً من مبدأ أن الذاكرة غير المُستخدمة هي ذاكرة مهدورة. عند تجاوز العتبة المنخفضة، يبدأ المحرك في إزاحة النتائج المخزنة مؤقتاً لإفساح المجال للنتائج الجديدة، مرتباً الإزاحة حسب العمر والحجم وزمن الحساب الأصلي. عند تجاوز العتبة العليا، يتوقف التخزين المؤقت عملياً، وقد يُستدعى ملف الترحيل (pagefile) الخاص بنظام التشغيل لإبقاء المحرك حياً. وتشير وثائق Qlik إلى أن استخدام ملف الترحيل قد يخفّض الأداء بشكل كبير.
ما يحدث ميكانيكياً بين هاتين العتبتين أهم من العتبتين نفسهما. كل نتيجة مخزّنة مؤقتاً تُزاح تعني عملية حساب يجب إعادتها من الصفر عند الطلب التالي للمستخدم. ومع تسارع الإزاحة، ينتقل عبء الحساب من الذاكرة إلى وحدة المعالجة المركزية. في بيئة عالية التزامن، حيث يقوم العديد من المستخدمين في الوقت نفسه بتشغيل حسابات لم تعد لها إجابات مخزنة مؤقتاً، تصبح وحدة المعالجة المركزية هي عنق الزجاجة الجديد — وعلى عكس ضغط الذاكرة، فإن ضغط وحدة المعالجة يتجلى مباشرة في صورة تأخير يراه المستخدم: لوحات بيانات تتوقف، فلاتر تستغرق ثوانٍ لتطبيقها، جلسات تنتهي صلاحيتها.
نهج TURBOARD الهجين يوزّع الحمل بشكل مختلف. مجموعة البيانات غير المُجمَّعة لا تحتاج إلى احتلال الذاكرة العشوائية، لأن المتجر العمودي مصمم للإجابة على الاستعلامات التحليلية بكفاءة من القرص — قارئاً فقط الأعمدة التي يلمسها الاستعلام، مستفيداً من ضغط مكثف، ومقدّماً عمليات التجميع بسرعات كانت تتطلب معالجة في الذاكرة قبل عقد من الزمن. التحميل التدريجي يحافظ على المتجر العمودي محدّثاً دون فرض إعادة تحميل كاملة متكررة، مما يعني أن المستخدمين يختبرون بيانات شبه فورية دون تكلفة الذاكرة لاحتجاز مجموعة البيانات كاملة في الذاكرة العشوائية. وذاكرة التخزين المؤقت Redis تُسرِّع بعد ذلك الاستعلامات التي تستفيد أكثر من التسريع — وهي، في أي نشر مؤسسي حقيقي، مجموعة فرعية صغيرة من إجمالي حجم الاستعلامات. القسم التالي يشرح السبب.
البيانات المباشرة: مشكلة Direct Discovery
إجابة Qlik على أحمال العمل التي تتجاوز الذاكرة المتاحة هي Direct Discovery، وهو وضع تُحمَّل فيه حقول الأبعاد إلى الذاكرة بينما تبقى حقول القياسات في قاعدة بيانات المصدر ويتم الاستعلام عنها عند الطلب. النية في التصميم معقولة، لكن القيود الموثّقة كبيرة.
قيود Direct Discovery الموثّقة (وفقاً لمواد المساعدة الرسمية من Qlik):
- اتصال قاعدة بيانات واحد مشترك لجميع مستخدمي التطبيق — قد يُغرق قاعدة بيانات المصدر بالطلبات في ظل التزامن العالي.
- الاستعلامات SQL المولَّدة ليست محسَّنة؛ عمليات الربط (joins) بين الجداول الموجودة في الذاكرة وجداول Direct Discovery قد تنتج عبارات IN ضخمة جداً تُجهد ذاكرة الاستعلام في قواعد البيانات.
- عدة قدرات تحليلية أساسية غير مدعومة، بما في ذلك Set Analysis و Insight Advisor و Dynamic Views.
- لا يوجد تطوير مستقبلي مخطط له لمعالجة هذه القيود، وفقاً لتصريح Qlik الرسمي نفسه.
بالنسبة لـ TURBOARD، الاتصال المباشر ليس حلاً مؤقتاً لضغط الذاكرة. إنه جزء أساسي من المعمارية. برامج تشغيل قاعدة البيانات المخصصة — بدلاً من اتصالات ODBC العامة — توفر وصولاً مباشراً وعالي الأداء لأنظمة المصدر، بما في ذلك منصات البيانات الضخمة مثل Apache Kudu. آلية مُحفِّز التخزين المؤقت تمنع قاعدة بيانات المصدر من التعرض لاستعلام عند كل نقرة من المستخدم: يراقب TURBOARD حقل مُحفِّز محدد (مثل طابع آخر تحديث) ويقدم النتائج المخزّنة مؤقتاً من Redis عندما لم تتغير البيانات الأساسية، ويستعلم من المصدر فقط عندما يشير المُحفِّز إلى توفر بيانات جديدة. تبقى الميزات التحليلية المتقدمة متاحة بالكامل سواء كان أي عنصر يقرأ من ذاكرة التخزين المؤقت، أو من المتجر العمودي، أو من مصدر مباشر. لوحة بيانات واحدة يمكنها أن تجمع الثلاثة دون أي تنازل.
رؤية باريتو وبراءة الاختراع التي تحميها
في أي نشر مؤسسي لذكاء الأعمال، يتبع سلوك المستخدم نمطاً يمكن التنبؤ به. حوالي 80% من المستخدمين يعودون باستمرار إلى نفس لوحات البيانات الأساسية — ملخصات تنفيذية، تقارير أداء شهرية، تجميعات إقليمية. أما النسبة المتبقية البالغة 20% فهم مستخدمون متمرسون يشغّلون استعلامات مخصّصة (ad-hoc) قد لا تُشغَّل مرة أخرى بنفس الصيغة. الدلالة على إدارة الذاكرة مباشرة: ليست كل النتائج المخزّنة مؤقتاً متساوية في القيمة، والنظام الذي يتعامل معها على أنها متكافئة يُهدر أغلى موارده.
نموذج إزاحة Qlik أعمى عن السلوك. تُزال النتائج المخزنة مؤقتاً بناءً على العمر والحجم وزمن الحساب الأصلي — وليس بناءً على عدد مرات طلب المستخدمين الفعليين لها. عندما تمتلئ الذاكرة، لا يستطيع المحرك التمييز بين لوحة البيانات التي يطلع عليها الفريق التنفيذي بأكمله كل صباح، وبين استعلام لمرة واحدة صادف أنه خُزِّن مؤقتاً قبل قليل.
TURBOARD يسلك النهج المعاكس تماماً. في كل مرة يُعرض فيها تقرير، تُزاد درجة شعبيته في Redis Sorted Set — وهو بنية بيانات مصممة بالضبط لهذا النوع من أنماط الوصول المرتّبة. يحافظ النظام على لوحة قيادة مستمرة لأي تقارير تُستخدم فعلاً، ويستخدم هذه اللوحة ليقرر ما يبقى في ذاكرة التخزين المؤقت عندما تكون الذاكرة شحيحة. التقارير الأكثر طلباً محمية في Redis، حيث تعود إلى الأغلبية الكبرى من المستخدمين الذين يعتمدون عليها بدون أي تأخير. أما استعلامات المستخدمين المتمرسين التي تفوّت ذاكرة التخزين المؤقت، فتُوجَّه إلى المتجر العمودي أو المصدر المباشر — وكلاهما مهندس للإجابة على هذه الاستعلامات بسرعة دون إزاحة محتوى مخزن مؤقتاً ذي قيمة عالية.
نظام عرض نتائج بحث سريع مدعوم بالذكاء الاصطناعي مع التكيّف مع عادات المستخدم
هذه الآلية هي موضوع براءة اختراع ممنوحة. تقدّمت بطلب التسجيل شركة E-Kalite (الشركة الأم لـ TURBOARD) في عام 2022، ومُنحت في عام 2025. تغطّي براءة الاختراع طريقة تسريع عرض البيانات في واجهة المستخدم، وتقليل أوقات تحميل المدخلات والمخرجات، وتقليل تكرار الوصول إلى الأجهزة التي تخزّن البيانات وتنقلها — بعبارة أخرى، الجمع بين التسجيل القائم على الاستخدام، والتحديث الذكي لذاكرة التخزين المؤقت، والكشف عن البيانات القديمة المعتمد على المُحفِّز، وهو ما يتيح لـ TURBOARD خدمة أحمال العمل المؤسسية ضمن ميزانيات ذاكرة قد تدفع المعماريات القائمة بالكامل على الذاكرة إلى منطقة ملف الترحيل.
النقطة الاستراتيجية واضحة: عندما تكون الذاكرة وفيرة، التخزين المؤقت الأعمى عن السلوك يكلّفك الكفاءة. وعندما تكون الذاكرة شحيحة، يكلّفك الأداء.
مقارنة جنباً إلى جنب
| السؤال | نهج Qlik Sense | نهج TURBOARD |
|---|---|---|
| أين تعيش البيانات في وقت التشغيل؟ | كاملة في الذاكرة العشوائية | في المتجر العمودي أو المصدر المباشر؛ النتائج مخزّنة مؤقتاً بشكل انتقائي في Redis |
| ماذا يحدث عندما تمتلئ الذاكرة؟ | إزاحة التخزين المؤقت حسب العمر/الحجم، ثم ملف الترحيل | احتفاظ مرتّب حسب السلوك؛ الفائض يُقدَّم من المتجر العمودي أو المصدر المباشر |
| كيف يُدار الاستخدام المتكرر؟ | ذاكرة تخزين مؤقت في الذاكرة، تُزاح بشكل أعمى | ذاكرة تخزين مؤقت Redis، تُحتفظ بها حسب درجة الاستخدام (بموجب براءة اختراع) |
| كيف يُحافظ على حداثة البيانات؟ | إعادة تحميل كاملة أو تدريجية عبر QVD إلى الذاكرة العشوائية | تحميل عمودي تدريجي + مُحفِّزات التخزين المؤقت |
| كيف تُدار الاستعلامات المباشرة؟ | Direct Discovery، بقيود موثّقة | برامج تشغيل مخصصة، مع الاحتفاظ بكامل القدرات التحليلية |
| فلسفة التوسع | تخصيص المزيد من الذاكرة | استخدام الذاكرة بشكل انتقائي، وتوجيه الباقي |
الخلاصة
يبقى Qlik Sense منصة تحليلات قائمة على الذاكرة قوية، وفي الظروف التي صُمِّمت من أجلها — مجموعات بيانات محدودة، تزامن قابل للتنبؤ، تخصيص سخي للذاكرة — تؤدي أداءً جيداً. السؤال الذي حاول هذا المقال الإجابة عليه هو ما يحدث عندما يصبح تحقيق هذه الظروف أصعب. أحجام البيانات لا تتقلّص. توقعات التزامن لا تتراخى. وتكلفة الذاكرة وتوفّرها، للمرة الأولى منذ فترة طويلة، يتحركان في الاتجاه الخطأ.
معمارية TURBOARD رهان على أن العقد القادم في أداء ذكاء الأعمال ستفوز به المنصات التي تستخدم الذاكرة بذكاء بدلاً من استخدامها بوفرة. الوصول الهجين للبيانات، والتخزين العمودي، والاتصال المباشر المخصص، وذاكرة التخزين المؤقت المُسجَّلة ببراءة اختراع والمعتمدة على درجة الاستخدام، كلها تتيح لـ TURBOARD تقديم أداء بمستوى المؤسسات ضمن ميزانيات ذاكرة قد تجد المعماريات القائمة بالكامل على الذاكرة صعوبة في العيش ضمنها.
بالنسبة للمؤسسات التي تواجه تصادم نمو البيانات، وزيادة التزامن، وتشدّد اقتصاديات الأجهزة، فإن هذا الفارق في النهج لم يعد أكاديمياً. إنه الفرق بين منصة تتوسّع مع نمو العمل، ومنصة تتوسّع مع نمو ميزانية المشتريات.
جاهز لرؤية الفرق؟
إذا كنت تقيّم Qlik Sense — أو كنت تستخدمه بالفعل وبدأت تشعر بضغط الذاكرة الذي يصفه هذا المقال — يسعدنا أن نريك كيف تتعامل معمارية TURBOARD الهجينة مع نفس أحمال العمل.
احجز جلسة تعريفية مع فريقنا وشاهد المنصة وهي تعمل ببياناتك الخاصة. لا ضغط — نفضّل أن تجد الحل الأنسب لاحتياجاتك المحددة.
يمكنك أيضاً استكشاف صفحة مقارنة ذكاء الأعمال الشاملة الخاصة بنا لترى كيف نتفوّق عبر المزيد من السيناريوهات المؤسسية.
آخر المدونات
توقف عن بناء لوحات المعلومات، وابدأ في الحصول على الإجابات. جرب مجاناً الحقبة التالية من ذكاء الأعمال مع قدرات الذكاء الاصطناعي التوليدي الرائدة لدينا.