المنشور طويل على المعتاد ولكن كل كلمة فيه غاية بالأهمية.

المنشور طويل على المعتاد ولكن كل كلمة فيه غاية بالأهمية.

حاجة زي ال indexing مش بتلاقي حد يتكلم عليها بشكل عميق غير قلة من الناس.

خذ مثال قواعد البيانات. بدل ما نبحث عن البيانات عن طريق قراءة كل ال rows في الجدول، ال index بيخلينا نوصل للمعلومة مباشرة. يعني زي (فهرس) الكتاب.

طريقة بناء الـ index والأداء المتوقع منه يعتمد على الخوارزمية اللي تختارها.

حاجة زي Hash Indexing. بتعتمد على hash functions عشان تخزن البيانات في مواقع محددة (Buckets) تجعل عملية البحث سريعة جدًا. غالبًا O(1) إذا ما كان فيه قيم مكررة تنتج عن خوارزمية الهاش (collisions). النوع ذا مش مناسب للبحث عن range query أو ترتيب البيانات. لأن الترتيب مش جزء من تصميمه. بمعنى لو كنت تحتاج تبحث عن داتا ضمن range معين، زي تواريخ محددة، هذا النوع ما الحل الأنسب لوضعك.

نوع زي ال B-Tree (Balanced Tree). أكثر شيوع في traditional database. بيوفر أداء متوازن لكل من reading, writing, deleting. مهمة النوع ذا يتأكد أن ال Tree تظل balanced عشان جميع العمليات سريعة مهما كان حجم البيانات. وبيستخدم خوارزمية binary search في عملية البحث. الخوارزمية ذي تعطي أداء بمعدل O(log n). بمعنى إن كل خطوة أثناء البحث تقسم البيانات إلى نصفين. وهذا يقلل التعقيد بشكل كبير. خاصة البيانات تكون مرتبة داخل الـ B-Tree.

النوع ذا مناسب لما يكون عندك بيانات تحتاج ترتيب مستمر أو تبحث عن range value.

نجي لواحد من الأنواع الأكثر حداثة LSM Tree (Log-Structured Merge Tree). النوع ذا مصمم عشان الأنظمة اللي تتعامل مع عمليات كتابة كثيفة مثل Distributed Database System زي Cassandra أو RocksDB. الفكرة إن البيانات ما تنكتب مباشرة على الـ hard disk، بيتم تخزينها في الـ memory. ولما تمتلئ الـ memory، بتنتقل البيانات بشكل تدريجي إلى الـ SSTable (ملفات مخزنة على القرص) بطريقة منظمة. هذا الأسلوب يقلل عدد مرات الكتابة للقرص ويحسن أداء الكتابة بشكل كبير. وبالمقابل ممكن يكون أبطأ في عمليات القراءة مقارنة بالـ B-Tree، لأنه يحتاج يدمج البيانات من عدة مواقع أثناء عملية القراءة للحصول على النتيجة النهائية.

في عندنا نوعين من ال indexing.

الـ Clustered Index يحدد طريقة تخزين البيانات الفعلية في القرص physical data، يعني لو عندك جدول بترتيب معين (مثل أرقام الموظفين). هذا النوع يحافظ على الترتيب بشكل مباشر. والجدول في ال database يقدر يحتوي على Clustered Index واحد فقط لأنه يتحكم في ترتيب البيانات بشكل فيزيائي.

ال Non-Clustered Index مجرد دليل إضافي. يعني البيانات بتبقى مخزنة بشكل مستقل، والـ index يوفر ال references اللي يساعدنا أنه نوصل لها. النوع ذا ممكن يكون مفيد لما نحتاج نبحث عن بيانات متعددة. لأنه بيعطينا حرية أنه نضيف أكثر من index لنفس الجدول.

لو فهمت شوية الحاجات ذي بتوضح لك لو كنت تبني نظام يعتمد على نطاقات مثل تاريخ العمليات المالية، الـ B-Tree غالبًا يكون الحل المثالي. أما لو كنت تعالج كميات هائلة من البيانات بسرعة (زي كتابة سجلات الآلاف من العمليات في الثانية زي ال logging system)، فالـ LSM Tree يتفوق. بالنسبة للـ Hash Indexing، خيار ممتاز لو نحتاج البحث المباشر دون ترتيب.

دائما الأهم التوازن بين الأداء والاحتياجات. أحيانًا اختيار النوع الخطأ ممكن يعقد الأمور أكثر مما يحلها. الحل مش مجرد إضافة index، بل التأكد أنك تستخدم النوع اللي يخدم طبيعة مشروعك بأفضل طريقة.