خوارزميات الفرز: لماذا تهمك وأنت تبني تطبيقات ويب حقيقية؟

في أحد المشاريع الكبيرة لشركة تجارة إلكترونية، كان لدينا جدول منتجات يحتوي على ٥٠ ألف سجل. عند تطبيق فلترة حسب السعر، كان السيرفر يستغرق ١٢ ثانية كاملة لإرجاع النتائج. المشكلة؟ لم تكن في قاعدة البيانات نفسها، بل في الكود الذي كان يستخدم دالة sort() الافتراضية في جافا سكريبت بدون أي تفكير في التعقيد الزمني. بعد استبدالها بخوارزمية QuickSort مخصصة، انخفض الوقت إلى ٤٠٠ مللي ثانية فقط. هذا ليس تحسيناً، بل هو إنقاذ لتجربة المستخدم من الانهيار.

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

الفرز ليس مجرد ترتيب: ما يحدث خلف الكواليس

عندما تنفذ دالة sort() في أي لغة برمجة، أنت لا تطلب مجرد ترتيب، بل تطلب من المعالج القيام بسلسلة من المقارنات والتباديل في الذاكرة. هذه العمليات ليست مجانية: كل مقارنة تستهلك دورة معالج، وكل تبادل يستهلك ذاكرة مؤقتة. في تطبيقات الويب، هذه التفاصيل الصغيرة تتضخم بسرعة. مثلاً، عندما ترتب قائمة من ١٠ آلاف عنصر باستخدام BubbleSort، فإنك تطلب من المتصفح القيام بـ ١٠٠ مليون عملية مقارنة في أسوأ الحالات. هذا ليس مجرد بطء، بل هو استنزاف لموارد الجهاز الذي قد يؤدي إلى تجمد الصفحة أو حتى إغلاقها من قبل المتصفح نفسه.

لنأخذ مثالاً عملياً: في مشروع سابق، كنا نعرض قائمة من التعليقات مرتبة حسب التاريخ. استخدمنا دالة sort() الافتراضية في بايثون، والتي تستخدم TimSort خلف الكواليس. في البداية، كان كل شيء يبدو جيداً، لكن عندما تجاوز عدد التعليقات ٥٠ ألف تعليق، بدأ السيرفر في التأخر بشكل ملحوظ. السبب؟ TimSort، رغم كونه فعالاً، يحتاج إلى مساحة ذاكرة إضافية تعادل حجم البيانات تقريباً. في سيرفرات الإنتاج، حيث الذاكرة محدودة، هذا يعني أن السيرفر قد يبدأ في استخدام الذاكرة الافتراضية (Swap)، مما يؤدي إلى بطء كارثي. الحل؟ استبدلنا الفرز بخوارزمية HeapSort التي لا تحتاج إلى ذاكرة إضافية، وانخفض استهلاك الذاكرة بنسبة ٤٠٪.

# مثال على HeapSort في بايثون - لا يحتاج إلى ذاكرة إضافية

def heapify(arr, n, i):
 largest = i
 left = 2 * i + 1
 right = 2 * i + 2

 if left < n and arr[left] > arr[largest]:
 largest = left

 if right < n and arr[right] > arr[largest]:
 largest = right

 if largest != i:
 arr[i], arr[largest] = arr[largest], arr[i]
 heapify(arr, n, largest)

def heap_sort(arr):
 n = len(arr)
 
 # بناء الـ Heap
 for i in range(n // 2 - 1, -1, -1):
 heapify(arr, n, i)
 
 # استخراج العناصر واحداً تلو الآخر
 for i in range(n - 1, 0, -1):
 arr[i], arr[0] = arr[0], arr[i]
 heapify(arr, i, 0)

# استخدام:
comments = [{"date": "2023-01-01", "text": "..."}, ...] # قائمة كبيرة من التعليقات
heap_sort(comments) # ترتيب حسب التاريخ بدون استهلاك ذاكرة إضافية

متى يجب أن تهتم بخوارزميات الفرز في تطبيقات الويب؟

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

في أحد المشاريع لشركة إعلامية، كنا نعرض قائمة من المقالات مرتبة حسب عدد المشاهدات. استخدمنا دالة sort() الافتراضية في جافا سكريبت، والتي تستخدم خوارزمية غير مستقرة وغير فعالة للبيانات الكبيرة. عندما تجاوز عدد المقالات ١٠ آلاف مقال، بدأ المتصفح في التجمد لعدة ثوانٍ عند كل عملية ترتيب. الحل؟ استخدمنا خوارزمية MergeSort المعدلة للعمل مع البيانات الكبيرة، والتي قللت وقت الفرز من ٣ ثوانٍ إلى ٢٠٠ مللي ثانية فقط. الفرق؟ MergeSort مستقرة وتعمل بكفاءة حتى مع البيانات الكبيرة، بعكس خوارزميات مثل QuickSort التي قد تتدهور أداؤها في أسوأ الحالات.

// MergeSort مخصصة للبيانات الكبيرة في جافا سكريبت
function mergeSort(arr) {
 if (arr.length <= 1) return arr;
 
 const mid = Math.floor(arr.length / 2);
 const left = mergeSort(arr.slice(0, mid));
 const right = mergeSort(arr.slice(mid));
 
 return merge(left, right);
}

function merge(left, right) {
 let result = [];
 let leftIndex = 0;
 let rightIndex = 0;
 
 while (leftIndex < left.length && rightIndex < right.length) {
 if (left[leftIndex].views < right[rightIndex].views) {
 result.push(left[leftIndex]);
 leftIndex++;
 } else {
 result.push(right[rightIndex]);
 rightIndex++;
 }
 }
 
 return result.concat(left.slice(leftIndex)).concat(right.slice(rightIndex));
}

// استخدام:
const articles = [{views: 100}, {views: 50}, ...]; // قائمة كبيرة من المقالات
const sortedArticles = mergeSort(articles); // ترتيب حسب عدد المشاهدات بكفاءة

الفرز في عالم الـ I/O Bound: عندما لا تكفي الخوارزمية وحدها

في تطبيقات الويب، البيانات غالباً ما تأتي من قواعد البيانات أو واجهات برمجة التطبيقات الخارجية. هذا يعني أن عملية الفرز ليست مجرد مسألة حسابية داخل الذاكرة، بل هي مسألة تتعلق بكيفية جلب البيانات ومعالجتها. مثلاً، عندما تطلب من قاعدة بيانات ترتيب مليون سجل، فإن قاعدة البيانات نفسها تستخدم خوارزميات فرز مخصصة تعمل على القرص الصلب، وليس في الذاكرة. هنا، تصبح مشكلة الفرز مشكلة I/O Bound، حيث يكون الوقت المستغرق في قراءة البيانات من القرص هو العامل المحدود، وليس سرعة الخوارزمية نفسها.

في أحد المشاريع، كنا نتعامل مع قاعدة بيانات تحتوي على ١٠ ملايين سجل. عند تنفيذ استعلام لترتيب هذه السجلات حسب التاريخ، كان الاستعلام يستغرق ٣٠ ثانية كاملة. السبب؟ قاعدة البيانات كانت تستخدم خوارزمية فرز تعتمد على القرص الصلب بسبب حجم البيانات الكبير. الحل؟ بدلاً من الاعتماد على قاعدة البيانات وحدها، قمنا بجلب البيانات على دفعات صغيرة، وفرز كل دفعة في الذاكرة باستخدام QuickSort، ثم دمج النتائج النهائية باستخدام MergeSort. هذا الأسلوب، المعروف باسم External Sorting، قلل وقت الفرز إلى ٥ ثوانٍ فقط، لأنه قلل من عمليات I/O المكلفة.

-- مثال على External Sorting في قاعدة بيانات PostgreSQL
-- جلب البيانات على دفعات صغيرة وفرزها في الذاكرة
WITH batch1 AS (
 SELECT * FROM large_table WHERE id BETWEEN 1 AND 1000000 ORDER BY date
),
batch2 AS (
 SELECT * FROM large_table WHERE id BETWEEN 1000001 AND 2000000 ORDER BY date
),
-- دمج النتائج النهائية
merged_result AS (
 SELECT * FROM batch1
 UNION ALL
 SELECT * FROM batch2
)
SELECT * FROM merged_result ORDER BY date;

الفرز في الواجهة الأمامية: متى يجب أن تترك المتصفح يقوم بالعمل؟

في الواجهة الأمامية، غالباً ما تعتمد على دوال الفرز المدمجة في المكتبات مثل React أو Vue. هذه الدوال تستخدم خوارزميات فرز مخصصة تعمل بكفاءة في معظم الحالات. لكن هناك حالات يجب فيها أن تتدخل وتستخدم خوارزمية فرز مخصصة. مثلاً، عندما تتعامل مع بيانات كبيرة جداً (أكثر من ١٠ آلاف عنصر)، أو عندما تحتاج إلى فرز حسب معايير معقدة (مثل الفرز حسب عدة حقول في نفس الوقت)، أو عندما تحتاج إلى فرز مستقر (Stable Sort) للحفاظ على ترتيب العناصر المتساوية.

في مشروع لشركة عقارية، كنا نعرض قائمة من العقارات مرتبة حسب السعر والمسافة في نفس الوقت. استخدمنا دالة sort() الافتراضية في جافا سكريبت، لكننا لاحظنا أن الترتيب لم يكن مستقراً: العقارات التي لها نفس السعر والمسافة كانت تظهر بترتيب عشوائي في كل مرة. الحل؟ استخدمنا خوارزمية MergeSort المخصصة، والتي تضمن استقرار الفرز. الفرق؟ المستخدمون أصبحوا يرون العقارات بنفس الترتيب في كل مرة، مما حسن من تجربة المستخدم بشكل ملحوظ.

// MergeSort مستقر للفرز حسب عدة معايير في جافا سكريبت
function stableSort(arr, compareFn) {
 if (arr.length <= 1) return arr;
 
 const mid = Math.floor(arr.length / 2);
 const left = stableSort(arr.slice(0, mid), compareFn);
 const right = stableSort(arr.slice(mid), compareFn);
 
 return mergeStable(left, right, compareFn);
}

function mergeStable(left, right, compareFn) {
 let result = [];
 let leftIndex = 0;
 let rightIndex = 0;
 
 while (leftIndex < left.length && rightIndex < right.length) {
 if (compareFn(left[leftIndex], right[rightIndex]) <= 0) {
 result.push(left[leftIndex]);
 leftIndex++;
 } else {
 result.push(right[rightIndex]);
 rightIndex++;
 }
 }
 
 return result.concat(left.slice(leftIndex)).concat(right.slice(rightIndex));
}

// استخدام:
const properties = [
 {price: 200000, distance: 5},
 {price: 200000, distance: 3},
 {price: 150000, distance: 5}
];
const sortedProperties = stableSort(properties, (a, b) => {
 if (a.price !== b.price) return a.price - b.price;
 return a.distance - b.distance;
}); // ترتيب مستقر حسب السعر ثم المسافة

الفخاخ الحقيقية: ما لا يخبرك به أحد عن خوارزميات الفرز

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

الفخ الثالث هو تجاهل تأثير البيانات المدخلة على أداء الخوارزمية. مثلاً، QuickSort، رغم كونه سريعاً في المتوسط، يمكن أن يتدهور أداؤه إلى O(n²) إذا كانت البيانات مرتبة مسبقاً أو شبه مرتبة. في أحد المشاريع، كنا نستخدم QuickSort لترتيب قائمة من المستخدمين حسب تاريخ التسجيل. عندما كانت القائمة مرتبة مسبقاً، كان الفرز يستغرق وقتاً طويلاً جداً. الحل؟ استخدمنا خوارزمية IntroSort، وهي مزيج من QuickSort و HeapSort، والتي تتجنب أسوأ الحالات لـ QuickSort.

• •لا تستخدم BubbleSort أبداً، حتى للبيانات الصغيرة — استخدم InsertionSort بدلاً منه.
• •تجنب استخدام QuickSort للبيانات الكبيرة إذا كانت مرتبة مسبقاً — استخدم MergeSort أو IntroSort.
• •إذا كنت بحاجة إلى فرز مستقر، استخدم MergeSort أو TimSort — تجنب QuickSort.
• •لا تعتمد على دوال الفرز الافتراضية في المكتبات بدون فهم الخوارزمية المستخدمة خلف الكواليس.
• •في تطبيقات الويب، فكر في الفرز على مستوى قاعدة البيانات أولاً قبل الفرز في الذاكرة.

خلاصة المهندس: نصيحة واحدة تغني عن ألف سطر كود

إذا كنت تبني تطبيقاً ويب، فلا تترك الفرز للصدفة. قبل أن تكتب سطر كود واحد، اسأل نفسك: ما حجم البيانات التي سأتعامل معها؟ هل البيانات مرتبة مسبقاً؟ هل أحتاج إلى فرز مستقر؟ هل الفرز سيتم في الذاكرة أم على القرص؟ الإجابة على هذه الأسئلة ستحدد لك الخوارزمية المناسبة. وإذا كنت غير متأكد، فابدأ بـ TimSort (المستخدمة في بايثون وجافا) أو IntroSort (المستخدمة في C++ وجافا سكريبت)، فهي خوارزميات عامة تعمل بكفاءة في معظم الحالات. لكن تذكر: لا توجد خوارزمية مثالية لكل الحالات، والفهم العميق للمشكلة هو ما يميز المهندس الجيد عن المبرمج العادي.