اتخطّى للمحتوى
تعلّم ماجنتو بالعربي
Englishوظّفنيابدأ الكورس
ابدأ الكورسوظّفنيEnglish

المرحلة 02 · البيانات والواجهةدرس 8 من 218 دقيقة قراءةآخر تحديث:

Lesson 08 / 21

Indexersبالتفصيل.

من أهم مواضيع الأداء في Magento، وبيتسأل في كل إنترفيو تقريبًا. هنفهم يعني إيه indexer، ليه موجود أصلًا، الأنواع، الفرق بين الـ modes، والأوامر العملية — مع الفخاخ اللي بتوقّع الناس.

● Performance Modes CLI MView

الـ Indexer في Magento 2 بيحوّل بيانات متفرّقة زي الأسعار والمخزون وخصائص EAV لجداول جاهزة للقراءة السريعة في الـ storefront. ليه وضعين: Update on Save بيحدّث الـ index مع كل حفظ، و Update by Schedule بيسجّل التغييرات ويعالجها على دفعات بالـ cron عن طريق MView. وأهم أوامره indexer:status و indexer:reindex.

// ليه الموضوع ده مهم الـ indexers هي السبب رقم 1 لبطء المواقع لو متظبطتش صح، وأشهر سؤال في الإنترفيو عن الأداء. لو فهمت الفرق بين Update on Save وUpdate on Schedule بس، تكون فهمت أهم جزء عملي.
01

يعني إيه Indexer ولماذا؟

الفكرة الأساسية: مقايضة بين سرعة الكتابة وسرعة القراءة.

إيه هو

الـ Indexer هو آلية بتحوّل البيانات المعقّدة والمبعثرة (زي الأسعار، المخزون، خصائص المنتجات في نظام EAV) لـ جداول مسطّحة ومحسّنة (index tables) جاهزة للقراءة السريعة.

ليه موجود أصلًا

عشان بنية Magento (خصوصًا EAV) مرنة بس بطيئة في القراءة — سعر منتج واحد ممكن يحتاج حسابات من عدة جداول (tier prices, special prices, rules...). لو حسبنا ده وقت كل زيارة، الموقع هيكون بطيء جدًا. فبنحسبه مرة واحدة مقدّمًا ونخزّن النتيجة.

المقايضة

الفكرة: نتعب مرة في الكتابة، عشان نرتاح كل مرة في القراءة. القراءة بتحصل ملايين المرات (كل زائر)، الكتابة بتحصل نادرًا (لما تعدّل منتج). فمنطقي نأجّل التعب للكتابة.

تشبيه زي فهرس الكتاب. بدل ما تقلّب كل الصفحات كل مرة تدوّر على موضوع (بطيء)، الفهرس محضّر مقدّمًا وبيوصّلك بسرعة. تحضير الفهرس بياخد وقت مرة واحدة، بس بيوفّر وقت في كل بحث بعد كده.
i
الاسم نفسه "index" جاي من نفس فكرة الفهرس/الـ database index — تحضير بنية جاهزة للوصول السريع.
• • •
02

إزاي بيشتغل من جوّه

من البيانات الخام للجدول الجاهز.

الخطوات

الـ indexer بياخد البيانات المصدرية، بيعمل عليها الحسابات المطلوبة، وبيكتب النتيجة في جدول الـ index المخصّص. الـ storefront بيقرا من جدول الـ index الجاهز مباشرة — مش من المصدر المعقّد.

  • المصدر (source): جداول EAV، أسعار، rules، مخزون — مبعثرة ومعقّدة.
  • المعالجة: الـ indexer بيجمّع ويحسب (سعر نهائي، توفّر مخزون...).
  • الوجهة (index table): جدول مسطّح زي catalog_product_index_price.
  • القراءة: الـ storefront بيقرا من الجدول ده مباشرة = سريع.
i
عشان كده لما تعدّل سعر منتج ومتعملش reindex، ممكن السعر القديم يفضل ظاهر — لأن الـ storefront بيقرا من جدول الـ index اللي لسه فيه القيمة القديمة.
• • •
03

الأنواع الأساسية

أهم الـ indexers اللي لازم تعرفها بالاسم.

  • Product Price (catalog_product_price) — بيحسب الأسعار النهائية مع كل القواعد.
  • Product/Category (catalog_category_product) — بيربط المنتجات بالـ categories.
  • Product EAV (catalog_product_attribute) — بيسطّح خصائص المنتجات القابلة للفلترة.
  • Stock (cataloginventory_stock) — حالة المخزون والتوفّر.
  • Catalog Search (catalogsearch_fulltext) — فهرس البحث النصّي.
  • Category Products — أي منتجات في أي category.
  • Price Rules — قواعد الأسعار (cart/catalog rules).
i
مش لازم تحفظهم كلهم بالاسم الدقيق، بس اعرف إن أهمهم Price وStock وCatalog Search لأنهم الأكثر تأثيرًا على الأداء والأكثر عرضة للمشاكل.
ASKليه في indexers كتير مش واحد؟
الإجابة: عشان كل نوع بيانات ليه منطق حساب مختلف وبيتغيّر لأسباب مختلفة. فصلهم بيسمح بإعادة فهرسة الجزء المتأثر بس بدل الكل — تطبيق لمبدأ فصل المسؤوليات.
• • •
04

الـ Modes — الأهم عمليًا

الفرق بين الـ modes هو أكتر حاجة بتفرق في الأداء وبتتسأل في الإنترفيو.

ON SAVEعند الحفظ

الـ index بيتحدّث فورًا كل ما تحفظ تغيير. التغيير بيظهر على طول، بس عملية الحفظ بتبقى بطيئة.

ON SCHEDULEمجدول

التغييرات بتتجمّع، والـ cron بيعمل reindex للمتغيّر بس على فترات. الحفظ سريع، والتحديث بياخد شوية وقت يظهر.

أنهي واحد تختار

Update on Schedule هو الموصى به دايمًا في production. لأنه بيخلّي عمليات الحفظ (وإدارة المنتجات) سريعة، وبيعمل reindex ذكي للمتغيّر فقط في الخلفية.

الفرق الجوهري

الـ On Save بيعمل reindex كامل للجزء المتأثر وقت الحفظ (تعب فوري). الـ On Schedule بيسجّل إيه اتغيّر بس، والـ cron بيعمل reindex جزئي (partial) للمتغيّر فقط.

!
لو الموقع بطيء عند حفظ المنتجات، أو الـ import بياخد وقت رهيب — أول حاجة تشيكها إن الـ indexers على Update on Schedule مش On Save.
i
شرط أساسي: الـ cron لازم يكون شغّال عشان Update on Schedule يشتغل. من غير cron، التغييرات مش هتتحدّث خالص.
• • •
05

MView — السحر ورا Schedule

إزاي Magento بيعرف "إيه اللي اتغيّر" عشان يعمل reindex جزئي.

إيه هو MView

الـ MView (Materialized View) هو الآلية اللي بتتتبّع التغييرات في الـ Update on Schedule. بيستخدم DB triggers بتسجّل أي صف اتغيّر في جدول خاص اسمه changelog.

إزاي بيشتغل

لما تعدّل منتج، الـ trigger بيكتب الـ id بتاعه في جدول الـ _cl (changelog). الـ cron بيقرا الـ changelog، يعرف أنهي entities اتغيّرت، ويعمل reindex ليها بس — مش لكل المنتجات.

تشبيه زي لستة "اللي محتاج تصليح" في ورشة. بدل ما تفحص كل العربيات كل يوم، بتسجّل بس اللي فيها مشكلة، والفني بيروح للّي في اللستة. توفير كبير في المجهود.
i
عشان كده الـ Update on Schedule أكفأ بكتير: مبيعملش reindex للكل، بيعمل بس للـ ids اللي في الـ changelog. ده الفرق بين full reindex و partial reindex.
ASKليه الـ triggers مش كود PHP؟
الإجابة: عشان الـ DB triggers بتشتغل على مستوى قاعدة البيانات نفسها، فبتلقط أي تغيير مهما كان مصدره (admin, API, import, direct SQL). لو كانت PHP، التغييرات اللي بتحصل خارج التطبيق مش هتتسجّل.
• • •
06

الأوامر العملية (CLI)

الأوامر اللي هتستخدمها يوميًا مع الـ indexers.

terminalbash
# عرض حالة كل الـ indexers
bin/magento indexer:status

# reindex للكل
bin/magento indexer:reindex

# reindex لـ indexer واحد بس
bin/magento indexer:reindex catalog_product_price

# عرض الـ mode الحالي لكل indexer
bin/magento indexer:show-mode

# تغيير الكل لـ Update on Schedule (الموصى به)
bin/magento indexer:set-mode schedule

# تغيير لـ Update on Save
bin/magento indexer:set-mode realtime

# تغيير indexer واحد بس
bin/magento indexer:set-mode schedule catalog_product_price

# إعادة تعيين (لو علق في processing)
bin/magento indexer:reset
!
لاحظ التسمية: schedule = Update on Schedule، وrealtime = Update on Save. الأسماء في الـ CLI مختلفة عن أسماء الـ admin شوية.

لما تعمل indexer:status، بتشوف حالات مختلفة:

Ready Reindex required Processing
  • Ready (Valid): الـ index محدّث وسليم. مفيش حاجة مطلوبة.
  • Reindex required (Invalid): فيه بيانات اتغيّرت والـ index محتاج تحديث.
  • Processing: الـ reindex شغّال دلوقتي.
i
لو indexer فضل عالق في Processing لفترة طويلة (بسبب انقطاع مثلًا)، استخدم indexer:reset عشان ترجّعه لـ invalid وتعمله reindex تاني.
• • •
07

الفخاخ وأسئلة الإنترفيو

أكتر الأخطاء والأسئلة المتكررة عن الـ indexers.

  • الـ indexers على realtime في production — بيبطّئ الحفظ والـ import. حوّلهم schedule.
  • الـ cron مش شغّال — الـ schedule mode مش هيشتغل خالص من غيره.
  • reindex كامل في الـ migration — عطّل الـ indexers، انقل الداتا، وبعدين reindex مرة واحدة.
  • تعديل سعر مش ظاهر — الـ index لسه فيه القيمة القديمة، محتاج reindex أو cron يشتغل.
  • جداول changelog بتكبر — لو الـ cron واقف، الـ _cl tables بتتضخّم.
Q1إيه الفرق بين Update on Save و Update on Schedule؟
الإجابة: On Save بيعمل reindex فوري وقت الحفظ (يبطّئ الحفظ). On Schedule بيسجّل المتغيّر في changelog والـ cron بيعمل reindex جزئي في الخلفية (حفظ سريع). Schedule هو الموصى به في production.
Q2إزاي Magento بيعرف إيه اللي اتغيّر في mode الـ schedule؟
الإجابة: عن طريق الـ MView والـ DB triggers اللي بتكتب الـ ids المتغيّرة في جداول الـ changelog (_cl)، والـ cron بيقراها ويعمل reindex ليها بس.
Q3ليه الموقع بطيء وقت حفظ المنتجات؟
الإجابة: على الأرجح الـ indexers على realtime (On Save)، فكل حفظ بيشغّل reindex فوري. الحل تحويلهم لـ schedule.
Q4ليه بنعطّل الـ indexers قبل الـ data migration الكبيرة؟
الإجابة: عشان كل عملية insert/save مبتشغّلش reindex منفصل. بنعطّلهم، ننقل الداتا كلها، وبعدين نعمل reindex واحد في الآخر — أسرع بمراحل.

Indexers بالتفصيل ✓

دلوقتي فاهم الـ indexers من الجذور: ليه موجودة (مقايضة قراءة/كتابة)، إزاي بتشتغل (MView + triggers)، والفرق العملي بين الـ modes اللي بيفرق في الأداء.

الخلاصة اللي تفتكرها: Update on Schedule + cron شغّال = production سليم. ده جوهر الموضوع كله، ولو قلته في الإنترفيو بتوضّح إنك اشتغلت production فعلًا.

// magento 2 backend · indexers deep dive · performance

خلّصت الدرس؟علّمه عشان تتابع تقدّمك في الكورس.

كاتب الدرس

Abdulrahman Masoud

عندك سؤال على الدرس أو محتاج مساعدة في مشروع Magento؟ كلّمني.

وظّفني

أسئلة شائعة

يعني إيه Indexer في Magento 2 وليه موجود؟

الـ Indexer آلية بتحوّل البيانات المعقّدة والمبعثرة، زي الأسعار والمخزون وخصائص المنتجات في الـ EAV، لجداول مسطّحة جاهزة للقراءة السريعة. الفكرة إنك تتعب مرة وقت الكتابة عشان ترتاح في كل قراءة، لأن الـ storefront بيقرا من جدول الـ index الجاهز مباشرة بدل ما يحسب كل حاجة مع كل زيارة.

ما الفرق بين Update on Save و Update by Schedule في Magento 2؟

في Update on Save الـ index بيتحدّث فورًا مع كل حفظ، فالتغيير بيظهر على طول بس الحفظ نفسه بيبقى أبطأ. في Update by Schedule التغييرات بتتسجّل والـ cron بيعمل reindex للمتغيّر بس على فترات في الخلفية، فالحفظ سريع والتحديث بياخد شوية وقت يظهر. في الـ CLI الأول اسمه realtime والتاني schedule.

إزاي Magento بيعرف إيه اللي اتغيّر في Update by Schedule؟

عن طريق الـ MView (Materialized View)، اللي بيستخدم DB triggers بتكتب الـ id بتاع أي صف اتغيّر في جداول changelog بتنتهي بـ _cl. الـ cron بيقرا الـ changelog ويعمل reindex للـ entities دي بس، ولأن الـ triggers شغّالة على مستوى الـ DB بتلقط التغيير مهما كان مصدره: admin أو API أو import أو SQL مباشر.

ليه السعر مش بيتغيّر على الموقع بعد ما عدّلته في Magento 2؟

لأن الـ storefront بيقرا من جدول الـ index زي catalog_product_index_price، واللي ممكن يكون لسه شايل القيمة القديمة. الحل إنك تعمل reindex، أو لو الـ indexers على schedule تتأكد إن الـ cron شغّال، لأن من غيره التغييرات مش هتتحدّث خالص.

إزاي أعمل reindex لـ indexer واحد بس في Magento 2؟

شغّل bin/magento indexer:reindex catalog_product_price مع اسم الـ indexer اللي عايزه، ومن غير اسم هيعمل reindex للكل. تقدر تشوف الحالة بـ indexer:status والـ mode الحالي بـ indexer:show-mode، وتغيّر mode indexer واحد بـ indexer:set-mode schedule catalog_product_price.

إيه معنى Reindex required وإزاي أحل indexer عالق في Processing؟

Reindex required (Invalid) معناها إن فيه بيانات اتغيّرت والـ index محتاج تحديث، وReady معناها إنه محدّث وسليم، وProcessing معناها إن الـ reindex شغّال دلوقتي. لو indexer فضل عالق في Processing فترة طويلة بسبب انقطاع مثلًا، شغّل bin/magento indexer:reset عشان يرجع invalid وبعدين اعمله reindex تاني.

ليه حفظ المنتجات أو الـ import بطيء جدًا في Magento 2؟

على الأرجح الـ indexers على Update on Save (realtime)، فكل حفظ بيشغّل reindex فوري ويبطّأ العملية. أول حاجة تشيكها إنك تحوّلهم لـ schedule بـ bin/magento indexer:set-mode schedule، مع التأكد إن الـ cron شغّال عشان التحديثات تتعمل في الخلفية.

دروس مرتبطة