الإدراج

عدد الفهارس على الجدول هو العامل الأكثر هيمنة على أداء الإدراج (insert performance). فكلما زاد عدد الفهارس على الجدول، صار التنفيذ أبطأ. وعبارة insert هي العملية الوحيدة التي لا يمكنها الاستفادة المباشرة من الفهرسة؛ لأنها لا تحتوي على جملة where.

تتضمن إضافة صف جديد إلى جدول عدة خطوات. أولاً، يجب على قاعدة البيانات أن تجد مكاناً لتخزين الصف. وفي جدول الكومة (heap table) العادي — الذي لا يخضع لأي ترتيب معيّن للصفوف — يمكن لقاعدة البيانات أن تأخذ أي كتلة من الجدول فيها مساحة حرة كافية. وهذه عملية بسيطة وسريعة جداً، تُنفَّذ في معظمها في الذاكرة الرئيسية. وكل ما على قاعدة البيانات فعله بعد ذلك هو إضافة المدخل الجديد إلى كتلة البيانات المعنية.

إذا كانت هناك فهارس على الجدول، وجب على قاعدة البيانات أن تضمن العثور على المدخل الجديد عبر هذه الفهارس أيضاً. ولهذا السبب عليها إضافة المدخل الجديد إلى كل فهرس من فهارس ذلك الجدول دون استثناء. وعليه، فإن عدد الفهارس مضاعِف لكلفة عبارة insert.

إن أعجبك هذا الموضوع، قد يعجبك أيضاً…

… أن تشترك في القوائم البريدية، وتحصل على ملصقات مجانية، وتشتري كتابي، أو تنضم إلى دورة تدريبية.

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

وما إن تُحدَّد العقدة الورقية الصحيحة، حتى تتحقق قاعدة البيانات من وجود مساحة حرة كافية في هذه العقدة. فإن لم تكن كافية، شقّت قاعدة البيانات العقدة الورقية (page split) ووزّعت المدخلات بين العقدة القديمة وعقدة جديدة. وتؤثر هذه العملية أيضاً في المرجع الموجود في عقدة الفرع المقابلة؛ إذ يجب تكراره هو الآخر. وغني عن القول إن عقدة الفرع قد تنفد مساحتها هي أيضاً، فقد يلزم شقّها كذلك. وفي أسوأ الحالات، قد تضطر قاعدة البيانات إلى شقّ جميع العقد حتى العقدة الجذرية. وهذه هي الحالة الوحيدة التي تكسب فيها الشجرة طبقة إضافية وتزداد عمقاً.

فصيانة الفهرس (index maintenance)، في نهاية المطاف، هي الجزء الأغلى في عملية insert. ويظهر ذلك أيضاً في الشكل 8.1أداء الإدراج حسب عدد الفهارس: فزمن التنفيذ لا يكاد يُرى إذا لم يكن للجدول أي فهارس. ومع ذلك، يكفي إضافة فهرس واحد لمضاعفة زمن التنفيذ مئة مرة. وكل فهرس إضافي يزيد التنفيذ إبطاءً.

الشكل 8.1 أداء الإدراج حسب عدد الفهارس

ملاحظة

الفهرس الأول يُحدث الفرق الأكبر.

لتحسين أداء الإدراج، من المهم جداً الإبقاء على عدد الفهارس صغيراً.

نصيحة

استخدم الفهارس عن قصد وباقتصاد، وتجنّب الفهارس المكرّرة كلما أمكن. وهذا مفيد أيضاً لعبارتَي delete وupdate.

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

ومع ذلك، فإن الأداء بلا فهارس جيد إلى حد يجعل من المعقول إسقاط جميع الفهارس مؤقتاً أثناء تحميل كميات كبيرة من البيانات (bulk load) — بشرط ألا تحتاج إليها أي عبارات SQL أخرى في تلك الأثناء. ويمكن أن يطلق هذا تسريعاً هائلاً يظهر في المخطط، وهو في الواقع ممارسة شائعة في مستودعات البيانات.

فكّر في الأمر

كيف سيتغير الشكل 8.1 عند استخدام جدول منظَّم بالفهرس أو فهرس عنقودي؟

هل هناك أي طريقة غير مباشرة يمكن أن تستفيد بها عبارة insert من الفهرسة؟ أي هل يمكن لفهرس إضافي أن يجعل عبارة insert أسرع؟