كيف يجد مدير التكنولوجيا الاستعلامات البطيئة ويصلحها قبل تصعيد المالية

NeonEdge هي منصة ألعاب موجهة للعملات المشفرة مقرها في تالين بإستونيا، مبنية حول ألعاب crash يمكن إثبات عدالتها مع دعم متعدد السلاسل عبر ETH و Tron و Polygon و SOL. تخدم المنصة حوالي خمسة عشر ألف مستخدم نشط شهريًا وتشغل حوالي $5M في الأسبوع من إجمالي إيرادات الألعاب. إنه متجر نحيف وطموح من الناحية التقنية - يدير مهندسان كامل البنية الأساسية للبيانات - و Priya Desai، مدير التكنولوجيا ورئيس البيانات، هي الشخص الذي يتصل به المنتج والمالية عندما يتحرك أي شيء أبطأ من المتوقع.

المنتجات المستخدمة: تحليلات أداء الاستعلام, مراقب البنية الأساسية, تحسين التكاليف

20 دقيقة | وقت التحقيق الكامل

3 | استعلامات مشكلة محددة من البداية الباردة

12x | متوسط التسريع بعد نشر التحسينات

---

التحدي

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

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

كانت المشكلة الهيكلية أن مكدس بيانات NeonEdge قد نما بشكل عضوي. القرارات الهندسية المبكرة كانت منطقية لكن لم تتم مراجعتها مع نمو المنصة. لم يقرر أحد بقصد تخطي الفهارس أو كتابة فحص جدول في تقرير أساسي؛ فقط حدثت تدريجياً.

"نحن فريق بيانات من شخصين يدير البنية الأساسية لخمسة عشر ألف مستخدم و $5 مليون في الأسبوع من GGR. أحتاج الاختناق على شاشتي في 20 دقيقة، وإلا جلست المشكلة حتى فترة الشروع التالية."

— Priya Desai, مدير التكنولوجيا, NeonEdge

---

الحل

فتحت Priya Gaming Mind AI ووصفت الأعراض بعبارات بسيطة. اتصل Gaming Mind ببيانات telemetry لـ NeonEdge وبدأ بأكثر سؤال تشخيص مباشر: أي استعلامات تستهلك الوقت الأساسي الأكثر تنفيذاً عبر المكدس الآن.

إليك كيف تطورت التحقيق:

---

Priya: "التقارير بطيئة في جميع الأنحاء. أين يجب أن أنظر أولاً؟"

الترتيب	اسم الاستعلام	متوسط وقت التنفيذ	وقت P99	التشغيلات/اليوم	الداعي	% من إجمالي وقت الاستعلام
1	تقرير مصالحة GGR	41.2 ثانية	68.4 ثانية	4	المالية	24%
2	تقرير نشاط اللاعب	31.0 ثانية	54.1 ثانية	8	المنتج	22%
3	تقرير مجموعة اللاعب	28.3 ثانية	47.6 ثانية	6	المنتج / CRM	12%
4	إسناد إيرادات الشريك	5.8 ثانية	11.2 ثانية	12	التسويق	4%
5	ملخص المستخدم النشط اليومي	5.1 ثانية	9.7 ثانية	24	العمليات	4%

⚠️ Gaming Mind flags: أفضل 3 استعلامات تحتفظ بـ 58% من إجمالي وقت تنفيذ الاستعلام. إصلاح أفضل 3 سيقلل من إجمالي وقت الاستعلام المتوقع بنسبة 58% دون لمس أي شيء آخر.

أنتجت Gaming Mind لوحة ترتيب كمون مغطيًا آخر سبعة أيام من تنفيذ الاستعلام. كانت أفضل ثلاثة استعلامات بطيئة بوضوح الأسوأ، وكانت نقطة بداية Priya واضحة.

---

Priya: "أخبرني عن الأبطأ."

الاستعلام: تقرير مصالحة GGR

المرحلة	العملية	الصفوف الممسوحة	الصفوف الناتجة	وقت المرحلة	الوقت المركب
1	مسح جدول كامل — transaction_ledger	84,200,000	84,200,000	28.4 ثانية	28.4 ثانية
2	Filter: سجلات هذا الأسبوع	84,200,000	312,400	6.1 ثانية	34.5 ثانية
3	Join: metadata السلسلة	312,400	312,400	2.8 ثانية	37.3 ثانية
4	Aggregate: GGR بالسلسلة + نوع اللعبة	312,400	48	1.9 ثانية	39.2 ثانية
5	صيغة الإخراج	48	48	2.0 ثانية	41.2 ثانية

⚠️ Gaming Mind flags: تقرير مصالحة GGR يقوم بمسح جدول كامل عبر 18 شهرًا من تاريخ المعاملات للإجابة على سؤال يحتاج فقط إلى الأسبوع الحالي. السبب الجذري: فقدان محمول WHERE التاريخ قبل مسح الجدول.

كان أسوأ استعلام هو تقرير مصالحة GGR. قام Gaming Mind بتقسيم خطة التنفيذ مرحلة تلو الأخرى: كان المسح الكامل يعالج 18 شهرًا من تاريخ المعاملات في كل مرة. السبب الجذري كان قرار تصميم من 18 شهرًا لم يعد أحد يراجعه.

---

Priya: "والثاني؟"

الاستعلام: تقرير نشاط اللاعب

المرحلة	العملية	صفوف الإدخال	صفوف الإخراج	وقت المرحلة	الوقت المركب
1	Scan: player_sessions	2,100,000	2,100,000	4.2 ثانية	4.2 ثانية
2	Join: game_events (واسع، قبل المرشح)	2,100,000	18,700,000	12.8 ثانية	17.0 ثانية
3	Join: wallet_activity	18,700,000	18,700,000	7.1 ثانية	24.1 ثانية
4	Filter: مقطع اللاعب + نطاق التاريخ	18,700,000	480,000	4.6 ثانية	28.7 ثانية
5	Aggregate + صيغة	480,000	920	2.3 ثانية	31.0 ثانية

⚠️ Gaming Mind flags: يتسع الانضمام قبل المرشح - ينتج عن مجموعة نتائج وسيطة أكبر بـ 3 أضعاف من الضروري. سيقلل عكس خطوتين في تسلسل الانضمام من استهلاك الذاكرة بحوالي ثلثي المبلغ.

الاستعلام الثاني كان يتسع قبل تصفيته - معالجة مجموعة نتائج وسيطة واسعة جداً. كان الحل واضحاً: تطبيق أضيق مرشح أولاً.

---

Priya: "والثالث؟"

الاستعلام: تقرير مجموعة اللاعب

العمود	يوجد فهرس فردي	جزء من فهرس مركب	Cardinality	الوقت الذي تم قضاؤه في حل التقاطع
chain_identifier	نعم	لا	منخفض (4 قيم)	—
registration_date	نعم	لا	عالي (540 يوم)	—
game_category	نعم	لا	متوسط (12 قيمة)	—
chain_identifier + registration_date + game_category	لا	لا	—	~19 ثانية لكل تنفيذ

⚠️ Gaming Mind flags: الأعمدة الثلاثة كل منها فهرس فردي لكن أبداً كمركب. إضافة فهرس مركب واحد سيسرع هذا الاستعلام و 13 استعلام آخر عبر المنصة.

كان الاستعلام الثالث يعاني من فجوة فهرس. ثلاثة أعمدة كانت تظهر معاً في كل نسخة من الاستعلام - معرف السلسلة وتاريخ التسجيل وفئة اللعبة - كل منها فهرس فردي لكن أبداً كمركب.

---

النتائج

التحقيق اكتمل في 20 دقيقة من البداية الباردة

لم يكن لـ Priya لوحات معلومات مبنية مسبقاً. سحبت Gaming Mind telemetry، وصنفت المذنبين، وأنتجت قائمة إصلاح في محادثة واحدة.

تم تحديد ثلاثة أسباب جذرية عبر ثلاثة أنواع مشكلة مختلفة

كان لكل استعلام بطء سبب منفصل هيكلياً — مسح تاريخي غير مصفي، ترتيب انضمام دون الأمثل، وفهرس مركب مفقود.

12x تسريع متوسط بعد نشر الإصلاحات

بعد جميع الإصلاحات، انخفض متوسط وقت توليد التقرير من 45 ثانية إلى ثلاث ثوان و 42 ثانية — تحسن اثني عشر أضعاف.

"استغرقت Gaming Mind 20 دقيقة. كنت أتوقع قضاء فترة ما بعد الظهر في الملفات."

— Priya Desai, مدير التكنولوجيا, NeonEdge