بحثي كان يستغرق دهراً: كيف أنقذتني ‘جداول التجزئة’ (Hash Tables) من جحيم البحث الخطي؟

“يا أبو عمر، بدنا نكبس الزر ونستنى القهوة تجهز؟”

في بداية مسيرتي البرمجية، قبل سنوات طويلة، كنت أعمل على نظام إدارة محتوى لموقع إخباري فلسطيني. كان النظام بسيطاً في بدايته، لكن مع مرور الوقت، تراكمت آلاف المقالات والأخبار في قاعدة البيانات. كانت إحدى أهم الميزات هي البحث عن مقال باستخدام عنوانه أو جزء منه. في البداية، كان كل شيء يعمل “زي الحلاوة”.

لكن مع وصول عدد المقالات إلى 50 ألف مقال، بدأت الكارثة. كل عملية بحث كانت تستغرق ما بين 5 إلى 10 ثوانٍ. تخيل أنك محرر صحفي وتحتاج للبحث عن عشرات المقالات في الساعة! الوضع كان لا يطاق. أتذكر اتصال مدير التحرير بي وهو يقول بنبرة مازحة لكنها مليئة بالجدية: “يا أبو عمر، شو هالنظام هاد؟ بدنا نكبس زر البحث ونروح نعمل قهوة ونرجع؟”.

بصراحة، كان معه حق. كانت “شغلة بتجلط”. قضيت ليلتين أبحث في الكود، وأحاول تحسين الاستعلامات، لكن المشكلة كانت أعمق من ذلك. المشكلة كانت في صميم طريقة تخزين البيانات والبحث فيها. كنت، ببساطة، أستخدم قائمة (Array) وأقوم بالمرور على كل عنصر فيها واحداً تلو الآخر للبحث عن المقال المطلوب. هذا ما يعرف بالبحث الخطي (Linear Search). وعندما أدركت حجم المشكلة الحقيقية، عرفت أن الحل لن يكون ترقيعاً بسيطاً، بل تغييراً جذرياً في هيكل البيانات نفسه. وهنا، دخلت “جداول التجزئة” أو الـ Hash Tables إلى حياتي، وغيرت كل شيء.

ما هو جحيم البحث الخطي (Linear Search)؟

قبل أن نغوص في الحل، دعنا نفهم المشكلة جيداً. تخيل أن لديك خزانة كتب ضخمة وغير منظمة، وبها 10,000 كتاب. وطلبت منك البحث عن كتاب “مئة عام من العزلة”. ماذا ستفعل؟

على الأغلب، ستبدأ من الرف الأول، وتتفحص الكتب كتاباً كتاباً حتى تجد ما تبحث عنه. في أفضل الأحوال، قد يكون الكتاب هو أول كتاب تقع عليه عينك. وفي أسوأ الأحوال، قد يكون آخر كتاب في الخزانة كلها. هذا بالضبط هو البحث الخطي.

في عالم البرمجة، عندما تخزن بياناتك في مصفوفة (Array) أو قائمة (List) وتريد البحث عن عنصر معين، فإن الطريقة الافتراضية هي المرور على العناصر من الأول إلى الأخير. هذا يعني أنه إذا كان لديك n من العناصر، فقد تحتاج إلى n خطوة في أسوأ الحالات للعثور على عنصرك. نسمي هذا التعقيد الزمني O(n). كلما زاد حجم البيانات (n)، زاد وقت البحث بشكل خطي. وهذا هو الجحيم الذي كنت أعيش فيه.

المنقذ: ما هي جداول التجزئة (Hash Tables)؟

الآن، تخيل نفس خزانة الكتب، لكن هذه المرة قمنا بتنظيمها بطريقة عبقرية. قسمنا الخزانة إلى 28 قسماً، كل قسم مخصص لحرف من حروف الأبجدية. عندما تريد البحث عن كتاب “مئة عام من العزلة”، لن تبحث في كل الخزانة. ستذهب مباشرة إلى قسم حرف “الميم” وتبحث هناك فقط. لقد قلصت نطاق بحثك بشكل هائل!

هذه هي الفكرة الأساسية وراء جداول التجزئة. إنها هيكل بيانات يسمح لك بتخزين واسترجاع البيانات بسرعة فائقة، تقترب من الوقت الثابت O(1) في المتوسط. هذا يعني أن وقت البحث لا يعتمد على حجم البيانات. سواء كان لديك 100 عنصر أو 100 مليون عنصر، فإن وقت الوصول يبقى سريعاً بشكل مذهل.

كيف تعمل هذه الأعجوبة؟

تعتمد جداول التجزئة على مكونين رئيسيين:

1. دالة التجزئة (Hash Function): هي معادلة سحرية تأخذ المدخل الخاص بك (والذي نسميه “مفتاح” أو Key)، مثل عنوان المقال، وتحوله إلى رقم صحيح فريد يسمى “الهاش” أو “التجزئة” (Hash). هذا الرقم يمثل “فهرساً” (Index) لمكان تخزين بياناتك.
2. المصفوفة (Array): هي حاوية التخزين الفعلية. نستخدم الفهرس الذي حصلنا عليه من دالة التجزئة لتحديد مكان تخزين القيمة (Value) المرتبطة بالمفتاح.

دعنا نأخذ مثالاً بسيطاً. لنفترض أننا نريد تخزين أرقام هواتف أصدقائنا. المفتاح هو اسم الصديق، والقيمة هي رقم هاتفه.

• للإضافة (Insert): نريد إضافة رقم “أحمد”: "0599123456".
  1. نمرر المفتاح “أحمد” إلى دالة التجزئة.
  2. الدالة تقوم بعمليات حسابية وتعطينا ناتجاً، وليكن الرقم 4.
  3. نذهب إلى الخانة رقم 4 في مصفوفتنا ونخزن فيها رقم هاتف أحمد.
• للبحث (Search): نريد البحث عن رقم “أحمد”.
  1. نمرر المفتاح “أحمد” إلى نفس دالة التجزئة.
  2. لأن الدالة حتمية (Deterministic)، ستعطينا نفس الناتج دائماً لنفس المدخل، وهو الرقم 4.
  3. نذهب مباشرة إلى الخانة رقم 4 في المصفوفة ونجد رقم أحمد هناك. لا حاجة للمرور على أي خانة أخرى!

لاحظ السرعة؟ لم نضطر للبحث في كل القائمة. ذهبنا مباشرة إلى المكان الصحيح. هذا هو سحر الـ O(1).

الفيل في الغرفة: ماذا عن التصادمات (Collisions)؟

قد يسأل سائل ذكي: “يا أبو عمر، ماذا لو أعطت دالة التجزئة نفس الفهرس لمفتاحين مختلفين؟”. مثلاً، ماذا لو أدخلنا “أحمد” فأعطتنا الفهرس 4، ثم أدخلنا “سارة” وأعطتنا أيضاً الفهرس 4؟

هذا سؤال ممتاز، وهذه الظاهرة تسمى “التصادم” (Collision). وهي أمر وارد وطبيعي في جداول التجزئة. المبرمجون الأذكياء الذين صمموا هذا الهيكل فكروا في حلول لهذه المشكلة، وأشهرها هو:

تقنية السلاسل المنفصلة (Separate Chaining)

الفكرة بسيطة جداً. بدلاً من تخزين قيمة واحدة فقط في كل خانة من خانات المصفوفة، نجعل كل خانة عبارة عن “سلة” (Bucket) يمكنها استيعاب أكثر من عنصر. هذه السلة تكون عادة عبارة عن قائمة متصلة (Linked List) أو مصفوفة ديناميكية.

فعندما يحدث تصادم في الفهرس 4 بين “أحمد” و”سارة”:

1. نذهب إلى الخانة رقم 4.
2. نجد أن “أحمد” موجود هناك بالفعل.
3. ببساطة، نضيف “سارة” إلى نفس السلة (القائمة المتصلة) في الخانة 4.

عند البحث عن “سارة”، ستقودنا دالة التجزئة إلى الفهرس 4. عندها، سنمر على العناصر القليلة الموجودة في تلك السلة الصغيرة (أحمد ثم سارة) حتى نجدها. طالما أن دالة التجزئة جيدة وتوزع المفاتيح بشكل متساوٍ، فإن هذه السلاسل ستبقى قصيرة جداً، وسيبقى الأداء قريباً جداً من O(1).

مثال عملي بالكود (باستخدام Python)

أفضل طريقة للفهم هي رؤية الكود. لحسن الحظ، معظم لغات البرمجة الحديثة توفر لنا جداول تجزئة جاهزة للاستخدام. في بايثون، تسمى “القاموس” (Dictionary)، وفي جافاسكريبت تسمى (Object) أو (Map).

لنر كيف حللت مشكلة البحث في المقالات باستخدام قاموس بايثون:

# الطريقة القديمة: البحث الخطي O(n) - بطيئة جداً
# articles_list = [
#    {"id": 1, "title": "عنوان المقال الأول", "content": "..."},
#    {"id": 2, "title": "عنوان المقال الثاني", "content": "..."},
#    ... 50,000 مقال آخر
# ]
# 
# def find_article_by_id_linear(article_id):
#     for article in articles_list:
#         if article["id"] == article_id:
#             return article # قد نمر على 50 ألف عنصر لنجده
#     return None

# الطريقة الجديدة: استخدام جدول التجزئة (قاموس بايثون) O(1) - سريعة جداً

# أولاً، نقوم ببناء القاموس مرة واحدة
# المفتاح هو ID المقال، والقيمة هي المقال نفسه
articles_hash_table = {}
# for article in articles_list:
#     articles_hash_table[article["id"]] = article

# مثال: لنفترض أن القاموس تم بناؤه بهذا الشكل
articles_hash_table = {
    1: {"id": 1, "title": "عنوان المقال الأول", "content": "..."},
    2: {"id": 2, "title": "عنوان المقال الثاني", "content": "..."},
    # ... 50,000 مقال آخر
    48753: {"id": 48753, "title": "مقال عن الذكاء الاصطناعي", "content": "..."}
}


def find_article_by_id_hash(article_id):
    # بحث فوري ومباشر!
    return articles_hash_table.get(article_id)

# الآن، قارن سرعة الاستدعاء
# search_id = 48753
# slow_result = find_article_by_id_linear(search_id) # بطيء جداً
# fast_result = find_article_by_id_hash(search_id)   # فوري!

print(find_article_by_id_hash(2))
# المخرجات: {'id': 2, 'title': 'عنوان المقال الثاني', 'content': '...'}

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

نصائح أبو عمر العملية

“يا خال، المعرفة النظرية مهمة، لكن الخبرة العملية هي اللي بتعلّم الصح.”

من خلال سنوات من التعامل مع هياكل البيانات، إليك بعض النصائح العملية من الآخر:

• متى تستخدم جداول التجزئة؟ استخدمها عندما تحتاج إلى عمليات إضافة، حذف، وبحث سريعة جداً بناءً على مفتاح فريد. الأمثلة تشمل: تخزين بيانات المستخدمين حسب رقمهم الوطني، بناء ذاكرة تخزين مؤقت (Cache)، عد تكرار الكلمات في نص، وغيرها الكثير.
• متى لا تستخدمها؟ تجنبها عندما تحتاج إلى بيانات مرتبة. جداول التجزئة لا تحافظ على ترتيب الإدخال (في معظم اللغات التقليدية). إذا كنت بحاجة للبحث عن “كل المستخدمين الذين أعمارهم أكبر من 30” أو “الحصول على أول 10 مقالات تم إدخالها”، فهياكل بيانات أخرى مثل الأشجار المتوازنة (Balanced Trees) أو حتى مصفوفة مرتبة قد تكون خياراً أفضل.
• لا تخترع العجلة: كل لغات البرمجة الحديثة (Python, Java, C#, JavaScript, Go, Rust) لديها تطبيقات ممتازة ومحسّنة لجداول التجزئة. استخدمها! لا تحاول بناء جدول التجزئة الخاص بك من الصفر في بيئة الإنتاج إلا إذا كان لديك سبب قوي جداً لذلك.
• فهم “عامل الحمولة” (Load Factor): هو نسبة عدد العناصر إلى حجم المصفوفة الداخلية. إذا أصبح هذا العامل مرتفعاً جداً (مثلاً، 0.8)، تزداد احتمالية التصادمات ويقل الأداء. معظم التطبيقات الجيدة لجداول التجزئة تقوم تلقائياً بزيادة حجم المصفوفة الداخلية (Resizing) عندما يتجاوز عامل الحمولة حداً معيناً للحفاظ على الأداء العالي.

الخلاصة يا جماعة الخير 🏁

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

في المرة القادمة التي تجد فيها نفسك تكتب حلقة for للبحث عن عنصر في قائمة كبيرة، توقف للحظة واسأل نفسك: “هل يمكن لجدول التجزئة أن ينقذني من هذا الجحيم؟”. في معظم الأحيان، ستكون الإجابة “نعم”، وستشكرني لاحقاً. تعلم هياكل البيانات الأساسية ليس ترفاً، بل هو أقوى سلاح في ترسانة أي مبرمج ناجح.