Get best of the week

التخزين المؤقت. الجزء 2: 60 يومًا قبل الإصدار

مرحبا! لقد كتبت لك بالفعل حول كيفية تعزيز المبادرات في الشركة. بتعبير أدق ، كيف ينجح هذا (أحيانًا) ، وما هي الصعوبات التي قد تنشأ: أشعل النار بأثر رجعي. كيف تحول حل عصامي إلى أن تكون أكثر برودة من دفع واحد و كيف اخترنا نظام التخزين المؤقت. الجزء الأول .

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

يجب أن أقول - أعتقد أنه للوصول بالمشروع إلى مثل هذه اللحظة الحادة - إنه خطأ بعيد جدًا عن lshaya من أي بطولة من خلال إطالة المشروع من هذه المشكلة ...
لكني لا أخفي هذه التجربة وأشاركها طواعية - لأنني أعتبر:

  • مناطق المشكلة بالتحديد هي نقاط النمو
  • أكبر المشاكل "تصل" بالتحديد من حيث لا تتوقع

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

لذا ، يبدو أن المقدمة كافية ، إذا كنت مستعدًا - مرحبًا بك في القط.



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

الصعوبة الرئيسية هي فقط للتحويل وإرسال. يسمى:

  1. أنت بحاجة إلى توفير البيانات في شكل json ، والذي يزن 100 كيلوبايت لكل منها ، وبعضها يطفو على السطح حتى 10 ميجابايت (ابحث عن مدى توفر ومعايير تسليم البضائع إلى المتاجر)
  2. هناك json بهيكل يحتوي على مرفقات متكررة من أي مستوى من التداخل (على سبيل المثال ، قائمة داخل عنصر قائمة ، حيث توجد عناصر قائمة مرة أخرى ، وما إلى ذلك)
  3. البيان النهائي غير معتمد ويتغير باستمرار (على سبيل المثال ، يتم استبدال العمل مع السلع بواسطة النماذج بنهج عندما نعمل باستخدام نماذج الألوان). باستمرار - هذا عدة مرات في الأسبوع ، بمعدل ذروة مرتين في اليوم لمدة أسبوع.

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

وبالتحديد ، اكتشفوا كيفية تثبيت نماذج الويب وكائناتها بسرعة على جانب الخادم.

تم تعيين شخص واحد من الفريق لدور "صفعة نموذجية" احترافية ، وباستخدام مكونات الويب المُعدّة ، قدم عرضًا توضيحيًا لواجهة المستخدم بشكل أسرع من تصحيح المحللين لرسومات واجهة المستخدم هذه.

ولكن من أجل تغيير مخطط التحولات ، نشأ التعقيد هنا.

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

أعرب محللون عن القاعدة في المخططات، التي، على الرغم من أنها رسمت في شيء منفصل عن الرمز (شيء من برنامج Visio / draw.io / gliffy)، ولكن كان هناك ذلكعلى غرار المربعات والسهام في أنظمة ETL (على سبيل المثال ، Pentaho Kettle ، التي تم استخدامها في ذلك الوقت لتزويد البيانات إلى موقع Sportmaster الإلكتروني). الآن ، إذا لم يكن لدينا استعلام SQL ، ولكن مخطط ETL! ثم يتم التعبير عن العبارة والحل بشكل طوبولوجي متطابق ، مما يعني أن تحرير الشفرة قد يستغرق وقتًا طويلاً مثل تحرير العبارة!

ولكن مع أنظمة ETL ، هناك صعوبة أخرى. نفس Pentaho Kettle - رائع عندما تحتاج إلى إنشاء فهرس جديد في ElasticSearch ، لكتابة جميع البيانات الملتصقة من عدة مصادر (ملاحظة: في الواقع ، Pentaho Kettle لا تعمل بشكل جيد للغاية ، لأنها لا تستخدم جافا سكريبت في التحويلات المتعلقة بفصول جافا التي يصل المستهلك من خلالها إلى البيانات - ولهذا السبب ، يمكنك كتابة شيء لا يمكن تحويله إلى كائنات البوجو الضرورية ، ولكن هذا موضوع منفصل ، بعيدًا عن المسار الرئيسي للمقالة).

ولكن ماذا تفعل عندما يقوم المستخدم بتصحيح حقل واحد في مستند واحد في لوحة المشرف؟ لتسليم هذا التغيير إلى موقع ويب سبورتجرماسترز ، لا تقم بإنشاء فهرس جديد لملء جميع المستندات من هذا النوع ، بما في ذلك الفهرس المحدث!

كنت أرغب في ذلك عندما يتم تغيير كائن واحد في بيانات الإدخال ، ثم إرسال تحديث إلى موقع ElasticSearch فقط لمستند الإخراج المقابل.

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

لم يؤد البحث عن المنتجات المعبأة لحل هذه المشكلة إلى أي شيء. غير موجود.
وعندما يئسوا من العثور عليهم ، اكتشفوا ذلك ، ولكن كيف يجب أن يعمل في الداخل ، وكيف يمكن القيام بذلك؟

نشأت الفكرة على الفور.

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

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

وبالتالي ، كان لحلنا نقطة قوية فيما يتعلق بجميع الصعوبات التمهيدية:

  1. يجب توفير البيانات في شكل json -> نحن نعمل مع كائنات pojo (كائن جافا قديم عادي ، إذا لم يجد شخص ما الأوقات التي كان فيها هذا التصنيف قيد الاستخدام) ، والتي يسهل تجاوزها في json
  2. هناك json مع هيكل يحتوي على تكرارات متكررة من أي مستوى من التعشيش -> مرة أخرى ، pojo (الشيء الرئيسي هو أنه لا توجد حلقات ، ولكن كم عدد مستويات التعشيش ليست مهمة ، من السهل معالجتها في java من خلال العودية)
  3. البيان الختامي يتغير باستمرار -> ممتاز ، لأننا نغير مخطط التحول بشكل أسرع مما يرغب المحللون (في الرسوم البيانية) في رغبات التجارب

من اللحظات المحفوفة بالمخاطر ، واحدة فقط - نكتب الحل من الصفر ، بمفردنا.

في الواقع ، لم تكن الفخاخ قادمة.

لحظة خاصة N1. فخ. "مستقر بشكل جيد"


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

هنا في نهج المنتج ، عند العمل مع تدفق إمدادات القيمة ، يتم توجيه تحذير بشكل لا لبس فيه إلى جميع المتفائلين: هناك مانع -> المهمة لا تعمل ، الفترة.

ولكن بعد ذلك ، لم يثر مثل هذا الاعتماد حتى الشك. في الواقع ، كنا نشعر بالبهجة من النجاح مع معالج دلتا النموذجي - نظام لمعالجة البيانات على الدلتا (تنفيذ نموذج رياضي عندما يتم حساب التغييرات في بيانات المخرجات باستخدام مخطط التحويل كاستجابة للتغيير في بيانات الإدخال).

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

لذا ، يجب أن يتم التحويل 15 دقيقة وليس ثانية أطول. المدخل الرئيسي هو جدول يحتوي على 5.5 مليون سجل. في مرحلة التطوير ، لم يتم ملء الجدول بعد. بتعبير أدق ، تمتلئ بمجموعة بيانات اختبار صغيرة بحجم 10 آلاف صف.

حسنًا ، لنبدأ. في التنفيذ الأول ، عمل معالج Delta على HashMap كمخزن مفتاح القيمة (دعني أذكرك ، نحن بحاجة إلى قراءة وكتابة الكائنات كثيرًا بمفتاح). بالطبع ، في أحجام الإنتاج ، لن تتناسب جميع الكائنات الوسيطة في الذاكرة - لذلك ، بدلاً من HashMap ، ننتقل إلى Hazelcast.

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

وهكذا ، فإننا نطلق معالج دلتا للتحول المستهدف. يعمل على الفور تقريبا. هذا أمر مفهوم - البيانات هي 10 آلاف فقط بدلاً من 5.5 مليون ، لذلك نضرب الوقت المقاس في 550 ، ونحصل على النتيجة: شيء حوالي دقيقتين. غرامة! في الواقع - انتصار!

كان هذا في بداية عمل المشروع - فقط عندما تحتاج إلى تحديد البنية ، وتأكيد الفرضيات (إجراء الاختبارات التي تؤكدها) ، ودمج الحل التجريبي بشكل عمودي.

نظرًا لأن الاختبارات أظهرت نتيجة ممتازة - أي أننا أكدنا جميع الفرضيات ، وسرعان ما حولنا الطيار - وضع "هيكل عظمي" متكامل رأسيًا للحصول على جزء صغير من الوظائف. وبدأوا الترميز الرئيسي - ملء "الهيكل العظمي باللحوم".

ما تشارك بنجاح وبقوة. حتى ذلك اليوم الجميل ، عندما تم تحميل مجموعة كاملة من البيانات إلى المتجر الرئيسي .

شغّل الاختبار على هذه المجموعة.

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

لكن الاختبار لم ينجح بعد ساعة. وحتى بعد ساعتين كان هناك أمل في أنه سيعمل ، وسنبحث عما يجب تشديده. كانت بقايا الأمل حتى بعد 5 ساعات. ولكن ، بعد 10 ساعات ، عندما عادوا إلى المنزل ، لكن الاختبار لم ينجح بعد - لم يعد هناك أمل.

كانت المشكلة أنه في اليوم التالي ، عندما وصلوا إلى المكتب ، استمر الاختبار في العمل بجد. ونتيجة لذلك ، تدحرجت لمدة 30 ساعة ، ولم تنتظر ، وأوقفت.
نكبة!

تم ترجمة المشكلة بسرعة كافية.

Hazelcast - عند العمل على كمية صغيرة من البيانات - قام بالفعل بتمرير كل شيء في الذاكرة. ولكن عندما كان مطلوبا لتفريغ البيانات على القرص - انخفض الأداء آلاف المرات.

البرمجة ستكون مهنة مملة ولا طعم لها ، إن لم يكن للسلطات والالتزام بتسليم المنتج النهائي. لذا ، نحن ، بعد يوم واحد ، بعد أن تلقينا مجموعة كاملة من البيانات - نحتاج إلى الذهاب إلى السلطات مع تقرير حول كيفية اجتياز الاختبار على أحجام الإنتاج.

هذا اختيار جاد وصعب للغاية:

  1. قل "كما هي" = التخلي عن المشروع
  2. قل "كما أريد" = للمخاطرة ، ربما ، من غير المعروف ما إذا كان بإمكاننا إصلاح المشكلة

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

وبالتالي ، فإن التخلي عن خليقتك الحبيبة أمر صعب للغاية.
هذه هي سمة جميع الناس - نحن نحب ما بذلنا من جهد كبير فيه. لذلك ، من الصعب سماع النقد - يجب أن تبذل جهودًا واعية لإدراك التعليقات بشكل ملائم.

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

في ذلك الاجتماع مع الرؤساء ، أشار مديرنا إلى أن "الاختبار أظهر أن النظام يعمل بثبات عند أحجام الإنتاج ، وأنه لا ينهار". في الواقع ، عمل النظام بشكل مستقر. 60 يوما

للافراج .

لحظة خاصة N2. ليس فخًا ، لكن ليس اكتشافًا. "الاقل هو الاكثر"


للعثور على بديل لـ Hazelcast مع دور مستودع بيانات Key-Value ، قمنا بتجميع قائمة بجميع المرشحين - حصلنا على قائمة من 31 منتجًا. هذا هو كل ما تمكنت من البحث عنه ومعرفة أصدقائي. علاوة على ذلك ، أعطت Google بعض الخيارات الفاحشة تمامًا ، مثل ورقة مصطلح الطالب.

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

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

نحتاج إلى نظام يحفظ المفتاح _fast_ المفتاح إلى كائن على القرص ويقرأ المفتاح بسرعة.

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

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

قام RocksDB ، الذي تم تثبيته في دور تخزين القيمة الرئيسية - بجلب مؤشر الاختبار المستهدف إلى مستوى 5 ساعات. كانت بعيدة عن 15 دقيقة ، ولكن الشيء الرئيسي تم القيام به. كان الشيء الرئيسي هو فهم ما كان يحدث ، لفهم أن الكتابة على القرص كانت في أسرع وقت ممكن ، وأسرع من المستحيل. على SSD ، في الاختبارات المحسنة ، ضغط RocksDB على 400 ميجا بايت / ثانية ، وكان ذلك كافيًا لمهمتنا. التأخير - في مكان ما في بلدنا ، في رمز ملزم.

في موقعنا الرمز، وهو ما يعني أننا يمكن التعامل معها. لنفككها ، ولكن يمكننا التعامل معها.

لحظة خاصة N3. الدعم. "الحساب النظري"


لدينا خوارزمية ومدخلات. نأخذ نطاق بيانات الإدخال ، ونحسب عدد الإجراءات التي يجب أن يقوم بها النظام ، وكيف يتم التعبير عن هذه الإجراءات في تكاليف وقت التشغيل لـ JVM (تعيين قيمة لمتغير ، وإدخال طريقة ، وإنشاء كائن ، ونسخ مجموعة من وحدات البايت ، وما إلى ذلك) ، بالإضافة إلى عدد المكالمات التي ينبغي عقد RocksDB.

وفقًا للحسابات ، اتضح أنه يجب أن يجتمعوا لمدة دقيقتين (تقريبًا ، كما أظهر اختبار HashMap في البداية ، ولكن هذه مجرد مصادفة - لقد تغيرت الخوارزمية منذ ذلك الحين).

ومع ذلك ، يستمر الاختبار لمدة 5 ساعات.

والآن قبل الإفراج عن 30 يومًا.

هذا تاريخ خاص - الآن سيكون من المستحيل الانهيار - لن يكون لدينا الوقت للتبديل إلى خيار النسخ الاحتياطي.
بالطبع ، في هذا اليوم يتم استدعاء مدير المشروع إلى السلطات. السؤال هو نفسه - هل لديك وقت ، فهل كل شيء على ما يرام؟



إليك أفضل طريقة لوصف هذا الموقف - صورة غلاف موسعة لهذه المقالة. أي أن الرؤساء يظهرون ذلك الجزء من الصورة الذي يظهر في العنوان. لكن في الحقيقة - هكذا.

على الرغم من أننا بالطبع لم نكن مضحكين على الإطلاق. وقول "كل شيء رائع!" - هذا ممكن فقط لشخص لديه مهارة قوية للغاية في إتقان الذات.
احترام كبير للمدير ، للاعتقاد ، والثقة بالمطورين.

حقا ، كود متاح حقا - يظهر 5 ساعات. حساب نظري - يظهر دقيقتين. كيف يمكن تصديق ذلك؟

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

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

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

على سبيل المثال ، التسلسل. استخدم لأول مرة java.io. ولكن إذا قمنا بربط Cryo ، فإننا في حالتنا نحصل على زيادة 2.5 أضعاف في سرعة التسلسل وانخفاضًا بمقدار 3 أضعاف في كمية البيانات المتسلسلة (مما يعني أن IO أصغر 3 مرات ، والذي يأكل الموارد الرئيسية فقط). ولكن ، بمزيد من التفصيل ، هذا موضوع لمقال تقني منفصل.

لكن النقطة الأساسية ، أو "حيث اختبأ الفيل" - سأحاول أن أصف في فقرة واحدة.

نقطة خاصة 4. استقبال لإيجاد حل. "المشكلة = الحل"


عندما نحصل على / نضعها بالمفتاح - في الحسابات التي تم إجراؤها كعملية واحدة ، يؤثر على الإدخال / الإخراج في حجم يساوي مفتاح + قيمة الكائن (في شكل متسلسل ، بالطبع).
ولكن ماذا لو كان الكائن نفسه الذي نسميه get / set هو خريطة ، والتي نحصل عليها أيضًا عن طريق get / set من القرص. كم سيتم القيام IO في هذه الحالة؟

في حساباتنا ، لم تؤخذ هذه الميزة في الاعتبار. أي أنه تم اعتباره 1 IO للمفتاح + قيمة الكائن. لكن في الواقع؟

على سبيل المثال ، في تخزين Key-Value ، بواسطة المفتاح 1 ، يوجد كائن obj-1 بنوع Map ، حيث يجب تخزين كائن obj-2 معين تحت مفتاح key-2. هنا اعتقدنا أن العملية ستتطلب إدخال / إخراج لـ key-2 + obj-2. ولكن في الواقع ، تحتاج إلى التفكير في الهدف 1 والتعامل معه وإرساله إلى IO: key-1 + obj-1. وإذا كانت خريطة تحتوي على 1000 كائن ، فسيكون استهلاك الإدخال والإخراج حوالي 1000 مرة أكثر. وإذا كانت 10000 قطعة ، إذن ... هكذا حصلوا على "الصابورة".

عادة ما يكون الحل واضحًا عند تحديد المشكلة.

في حالتنا ، أصبح هذا هيكلًا خاصًا للتلاعب داخل الخريطة المتداخلة. أي أن مفتاح القيمة هذا ، الذي يقبل get / set مفتاحين في وقت واحد ، والذي يجب تطبيقه بالتسلسل: key-1 ، key-2 - أي بالنسبة للمستوى الأول وللواحد المتداخل. كيفية تنفيذ مثل هذا الهيكل - سأخبرك بالتفصيل بسرور ، ولكن مرة أخرى ، في مقالة فنية منفصلة.
هنا ، من هذه الحلقة ، أشدد على هذه الميزة وأروج لها: مشكلة تفصيلية للغاية هي حل جيد.

إكمال


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

والأهم من ذلك - الآن بعد أن قيل كل شيء عن العملية ، عن اللحظات النفسية ، عن اللحظات التنظيمية. الآن لدينا فكرة عن المهام وتحت أي ظروف تم إنشاء النظام. الآن - يمكنك ويجب أن تخبر عن النظام من الناحية التقنية - أي نوع من النموذج الرياضي هذا ، وما هي الحيل في الكود الذي ذهبنا إليه ، وما هي الحلول المبتكرة التي فكرنا فيها.

حول هذا في المقالة التالية.

في هذه الأثناء ، كود جديد سعيد!

More articles:


All Articles