هل من المنطقي فهارس الصور النقطية "المزيفة"؟

Question

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

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

الآن، يمكنني بالتأكيد إنشاء وصيانة فهرس الصور النقطية الخاص بي واستخدامه للبحث عن معرفات الصفوف التي تشير إلى جدول الحقائق.ومع ذلك، أظن أن هذا سيؤدي إلى إبطال الغرض الكامل من الفهرس، لأن قاعدة البيانات ستظل تبحث عن معرفات الصفوف في B-Tree.هل يمكن لشخص يتمتع بخلفية نظرية أكثر عمقًا أو خبرة أكبر أن يخبرني إذا كنت لا أزال أكتسب أي شيء، مثل عدم الاضطرار إلى القيام بعمليات وصل بطيئة على جداول الأبعاد؟

وسأكون ممتنًا أيضًا للحصول على تلميحات حول ما يجب علي تقييمه إذا لم تكن الإجابة واضحة.

Answer 1

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

لست متأكدًا من أعلى رأسي إذا كانت MySQL تفعل ذلك، لكن Postgresql يفعل ذلك بالتأكيد.IIRC بعض المتغيرات (Greenplum، على ما أعتقد) تدعم أيضًا فهارس الصور النقطية بشكل مباشر وكان هناك بعض الحديث عن دمجها في محرك قاعدة البيانات الرئيسي.لا أذكر إذا كان هذا قد تم القيام به بعد.

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

Answer 2

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

في عام منذ كنت سوف يكون البحث من خلال مؤشر B-شجرة على أي حال فإنك لن تكسب شيئا إذا تجربتي هو أي دليل.

وهكذا، لا.

وإذا كان التطبيق الخاص بك هو OLAP بطبيعتها في الطبيعة، وكان لديك عدد صغير من الأبعاد التي بطبيعة الحال المجموعة إلى نطاقات أمر، وكنت حقا بحاجة الى تغيير asymptotics من مشكلتك، قد تنظر في بناء "الجدول مبلغ" مثل هيكل ثم يمكنك الاستعلام لأي إجابة الهرمية مع 2 ^ عمليات التطوير، ويمكنك أن استهلاك إذا كنت تفعل عدد من الاستفسارات ذات الصلة.

ومثال على ذلك في 2D مع الإحداثيات x و y، حيث كنت مهتما في مجموع أكثر من مجموعة من (X1، Y1) إلى (X2، Y2).

ومخزنة بشكل منفصل كنت قد لتلخيص عدد من مداخل تتناسب مع المنطقة.

وباستخدام sumtable، لكل وظيفة (س، ص) لا تخزن قيمة هذا الموقف، ولكن بدلا من تخزين مجموع المنطقة من (0،0) إلى (س، ص).

وبعد ذلك يمكنك الرد على أي استفسار عن طريق طرح مجموعة:

ومبلغ (X2، Y2) - مبلغ (X1، Y2) - مبلغ (X2، Y1) + مبلغ (X1، Y1)

وكمية ثابتة من النفقات العامة (حسنا، لوغاريتمي في حجم مجموعة البيانات، على افتراض أن يكون لديك فهرس على x و y وتخزينها في SQL)

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