المطوّرون بحاجة إلى الفهرسة
مشكلات أداء SQL قديمة قِدَم لغة SQL نفسها—بل قد يقول بعضهم إن SQL بطيء بطبيعته. ورغم أن ذلك ربما كان صحيحاً في الأيام الأولى لـSQL، فإنه ليس صحيحاً على الإطلاق اليوم. ومع ذلك، لا تزال مشكلات أداء SQL شائعة. فكيف يحدث ذلك؟
لغة SQL هي ربما أنجح لغة برمجة من الجيل الرابع (fourth-generation programming language — 4GL). وميزتها الأساسية هي القدرة على الفصل بين «ماذا» و*«كيف»*. فعبارة SQL وصف مباشر لما هو مطلوب دون تعليمات حول كيفية إنجازه. تأمّل المثال التالي:
SELECT date_of_birth
FROM employees
WHERE last_name = 'WINAND'
تُقرأ استعلامات SQL كجملة إنجليزية تشرح البيانات المطلوبة. وكتابة عبارات SQL لا تتطلب عموماً أي معرفة بالعمل الداخلي لقاعدة بيانات (database) أو نظام التخزين (مثل الأقراص والملفات وغيرها). فلا حاجة لإخبار قاعدة البيانات بالملفات التي يجب فتحها أو بكيفية العثور على الصفوف المطلوبة. وكثير من المطوّرين لديهم سنوات من الخبرة في SQL، ومع ذلك يعرفون القليل جداً عمّا يجري من معالجة داخل قاعدة البيانات.
فصل الاهتمامات—ما هو مطلوب مقابل كيفية الحصول عليه—يعمل ببراعة ملحوظة في SQL، لكنه لا يزال غير مثالي. فتصل عملية التجريد إلى حدودها عندما يتعلق الأمر بالأداء: فمؤلف عبارة SQL، بحكم التعريف، لا يهمه كيف تنفّذ قاعدة البيانات العبارة. وبالتالي فهو غير مسؤول عن التنفيذ البطيء. غير أن التجربة تثبت العكس؛ أي أن المؤلف يجب أن يعرف قليلاً عن قاعدة البيانات لمنع مشكلات الأداء.
ويتّضح أن الشيء الوحيد الذي يحتاج المطوّرون إلى تعلّمه هو الفهرسة. فالفهرسة في قاعدة البيانات مهمة تطويرية في واقع الأمر؛ لأن أهم معلومة للفهرسة السليمة ليست إعدادات نظام التخزين ولا تجهيز العتاد، بل كيفية استعلام التطبيق للبيانات. وهذه المعرفة—بمسار الوصول—ليست متاحة بسهولة لمديري قواعد البيانات (database administrators — DBAs) ولا للمستشارين الخارجيين. إذ يلزم وقت طويل لجمع هذه المعلومات عبر الهندسة العكسية للتطبيق؛ أما التطوير فيملك هذه المعلومات أصلاً.
يغطي هذا الكتاب كل ما يحتاج المطوّرون معرفته عن الفهارس—ولا شيء أكثر. وبعبارة أدق، يغطي الكتاب النوع الأهم من الفهارس فقط: فهرس شجرة B (B-tree index).
إن أعجبك هذا الموضوع، قد يعجبك أيضاً…
… أن تشترك في القوائم البريدية، وتحصل على ملصقات مجانية، وتشتري كتابي، أو تنضم إلى دورة تدريبية.
يعمل فهرس شجرة B بالطريقة نفسها تقريباً في قواعد بيانات كثيرة. ويستخدم الكتاب أساساً مصطلحات قاعدة بيانات Oracle®، لكنه يشير إلى المصطلحات المقابلة في قواعد البيانات الأخرى حيث يكون ذلك مناسباً. كما تقدّم الملاحظات الجانبية مزيداً من المعلومات عن MySQL وPostgreSQL وSQL Server®.
بُنيت بنية الكتاب خصيصاً للمطوّرين؛ فمعظم الفصول تقابل جزءاً معيناً من عبارة SQL.
الفصل الأول هو الوحيد الذي لا يغطي SQL تحديداً؛ فهو يتناول البنية الأساسية للفهرس. وفهم بنية الفهرس ضروري لمتابعة الفصول اللاحقة—لا تتجاوز هذا الفصل!
ورغم أن الفصل قصير نسبياً—نحو ثماني صفحات فقط—فإنك بعد إتمامه ستكون قد فهمت بالفعل ظاهرة الفهارس البطيئة.
هنا نستفرغ كل جهدنا. يشرح هذا الفصل جميع جوانب عبارة where، من عمليات البحث البسيطة جداً بعمود واحد إلى العبارات المعقدة للنطاقات والحالات الخاصة مثل LIKE.
ويشكّل هذا الفصل متن الكتاب الرئيسي. فحين تتعلم استخدام هذه التقنيات، ستكتب SQL أسرع بكثير.
الفصل الثالث - الأداء وقابلية التوسع
هذا الفصل استطراد قصير حول قياسات الأداء وقابلية توسع قاعدة البيانات. اعرف لماذا ليست إضافة العتاد أفضل حل للاستعلامات البطيئة.
عودة إلى SQL: ستجد هنا شرحاً لكيفية استخدام الفهارس لإجراء ضمّ (join) سريع للجداول.
هل تساءلت يوماً إن كان هناك أي فرق بين اختيار عمود واحد أو جميع الأعمدة؟ إليك الإجابة—مع حيلة تحقق أداءً أفضل.
الفصل السادس - الترتيب والتجميع
حتى order by وgroup by يمكن أن يستخدما الفهارس.
الفصل السابع - النتائج الجزئية
يشرح هذا الفصل كيفية الاستفادة من التنفيذ «المتدفق» (pipelined) إذا لم تكن بحاجة إلى مجموعة النتائج كاملة.
الفصل الثامن - الإدراج والحذف والتحديث
كيف تؤثر الفهارس في أداء الكتابة؟ الفهارس ليست مجانية—استخدمها بحكمة!
سؤال قاعدة البيانات عن كيفية تنفيذها لعبارة ما.
يسرد بعض الخرافات الشائعة ويشرح الحقيقة. وسيُوسَّع مع نمو الكتاب.
جميع عبارات create وinsert لجداول الكتاب.
نصيحة
شرائح محاضرتي «الفهارس: المنقذ المهجور للأداء»