أنت لست جوجل

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

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

كما أشار جو هيلرستين في محاضرته حول قواعد البيانات لطلاب المرحلة الجامعية الأولى (في الدقيقة 54):

الحقيقة هي أن هناك حوالي 5 شركات في العالم تقوم بمثل هذه المهام الطموحة. أما بالنسبة لأي شخص آخر ... فهم ينفقون موارد لا تصدق لتوفير نظام متسامح مع الأخطاء لا يحتاجون إليه حقًا. كان لدى الناس نوع من "google" في الألفية الجديدة: "سنفعل كل شيء تمامًا مثل Google ، لأننا ندير أيضًا أكبر خدمة لمعالجة البيانات في العالم ..." [من المفارقات أن يهز رأسه وينتظر الضحك من الجمهور]

كم عدد الطوابق في مبنى مركز البيانات الخاص بك؟ قررت Google البقاء في الرابعة ، على الأقل في مركز البيانات المعين هذا الواقع في Mays County ، أوكلاهوما.

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

MapReduce / Hadoop هو مثال بسيط للغاية. حتى أتباع Cargo Cult أدركوا بالفعل أن الطائرات لن تحل كل مشاكلهم. ومع ذلك ، فإن استخدام MapReduce يسمح لك بإجراء تعميم مهم: إذا كنت تستخدم التكنولوجيا التي تم إنشاؤها لشركة كبيرة ، ولكن في نفس الوقت تحل المشاكل الصغيرة ، فقد تتصرف دون تفكير. ومع ذلك ، فمن المرجح أنك تسترشد بالأفكار الصوفية التي تقلد العمالقة مثل Google و Amazon ، وستصل إلى نفس المستويات.

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

إطار رائع: UNPHAT

في المرة التالية التي تطرح فيها على Google تقنية جديدة رائعة (لإعادة) تشكيل نظامك ، أحثك ​​على التوقف واستخدام إطار عمل UNPHAT فقط:

1. لا تحاول حتى التفكير في الحلول الممكنة قبل فهم مشكلة (فهم) . هدفك الرئيسي هو "حل" المشكلة من حيث المشكلة ، وليس من حيث الحلول.
2. قائمة (ترقيم) العديد من الحلول الممكنة. لا حاجة لتوجيه إصبعك على الفور إلى الخيار المفضل لديك.
3. النظر في حل منفصل ، ثم قراءة الوثائق (ورقة) ، إن وجدت.
4. حدد السياق التاريخي الذي تم فيه إنشاء هذا الحل.
5. تطابق المزايا مع العيوب. تحليل ما كان على صناع القرار التضحية لتحقيق هدفهم.
6. فكر (فكر) ! تفكر بهدوء وهدوء في مدى ملائمة هذا الحل لتلبية احتياجاتك. ما الذي تحتاجه بالضبط لتغير رأيك؟ على سبيل المثال ، كم يجب أن تكون البيانات أقل ، بحيث تفضل عدم استخدام Hadoop؟

أنت لست أمازون

استخدام UNPHAT سهل. أذكر محادثتي الأخيرة مع شركة قررت على عجل استخدام كاساندرا في عملية مكثفة لقراءة البيانات التي تم تنزيلها في الليل.

نظرًا لأنني كنت معتادًا بالفعل على توثيق Dynamo وكنت أعلم أن Cassandra هو نظام مشتق ، فقد فهمت أن التركيز الرئيسي في قواعد البيانات هذه على القدرة على التسجيل (تحتاج Amazon إلى جعل الإجراء "add to cart" أبدًا لم تفشل). أنا أقدر أيضًا أن المطورين ضحوا بتكامل البيانات - وفي الواقع ، كل ميزة متأصلة في RDBMS التقليدية. ولكن بعد كل شيء ، الشركة التي تحدثت معها ، لم تكن القدرة على التسجيل أولوية. بصراحة ، كان المشروع يعني إنشاء سجل واحد كبير في اليوم.

الأمازون تبيع الكثير من كل شيء. إذا توقفت الوظيفة "add to basket" فجأة عن العمل ، فإنها ستخسر الكثير من المال. هل لديك مشكلة في نفس الترتيب؟

قررت هذه الشركة استخدام Cassandra لأنه استغرق عدة دقائق لإكمال استعلام PostgreSQL المعني ، وقرروا أن هذه كانت قيودًا تقنية على جزء من أجهزتهم. بعد توضيح بضع نقاط ، أدركنا أن الجدول يتكون من حوالي 50 مليون صف من 80 بايت لكل منهما. سوف يستغرق الأمر حوالي 5 ثوانٍ لقراءته من SSD إذا كان عليك المرور فيه تمامًا. هذا بطيء ، لكنه لا يزال أمرين من حجم أسرع من سرعة تنفيذ الاستعلام في ذلك الوقت.

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

أنت لست ينكدين

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

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

الشمس ، كونها كائنًا ضخمًا للغاية ، وهذا فقط 6 أوامر أثقل من الأرض.

ربما اتخذ المطورون قرارًا متعمدًا ، بناءً على الاحتياجات المتوقعة وفهمًا جيدًا لهدف كافكا. لكنني أعتقد أنهم كانوا مدفوعين إلى حد كبير بحماس المجتمع (المبرر عادة) لكافكا ولم يتساءلوا أبدًا عما إذا كانت هذه هي الأداة التي يحتاجون إليها حقًا. فقط تخيل ... 10 أوامر!

هل تحدثت؟ أنت لست أمازون

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

بحلول الوقت الذي قررت فيه أمازون التحول إلى بنية الخدمات الموجهة الخدمية (SOA) ، كان لديهم حوالي 7800 موظف ومبيعاتهم تجاوزت 3 مليارات دولار .

تتسع قاعة الحفلات الموسيقية بيل غراهام في سان فرانسيسكو لـ 7000 شخص. كان لدى أمازون حوالي 7800 موظف عندما تحولوا إلى الخدمية.

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

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

حتى جوجل ليست جوجل.

يمكن أن تكون أمثلة استخدام الأنظمة لمعالجة تدفقات البيانات المحملة بدرجة عالية (Hadoop أو Spark) محيرة حقًا. في كثير من الأحيان ، تكون قواعد بيانات إدارة قواعد البيانات (DBMS) التقليدية أكثر ملاءمة للتحميل ، وأحيانًا يكون حجم البيانات ضئيلًا للغاية حتى أن الذاكرة المتوفرة ستكون كافية لهم. هل تعلم أنه يمكنك شراء 1 تيرابايت من ذاكرة الوصول العشوائي في مكان ما مقابل 10،000 دولار؟ حتى إذا كان لديك مليار مستخدم ، فلا يزال بإمكانك تزويد كل منهم بسعة 1 كيلوبايت من ذاكرة الوصول العشوائي.

ربما لن يكون هذا كافيًا للتحميل ، لأنك ستحتاج إلى القراءة والكتابة على القرص. ولكن هل تحتاج حقًا إلى عدة آلاف من الأقراص للقراءة والكتابة؟ هنا هو مقدار البيانات التي لديك في الواقع؟ تم إنشاء GFS و MapReduce لحل مشاكل الحوسبة عبر الإنترنت ... على سبيل المثال ، لإعادة حساب فهرس البحث عبر الإنترنت .

أسعار محركات الأقراص الثابتة الآن أقل بكثير مما كانت عليه في عام 2003 عندما تم نشر وثائق GFS.

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

ربما كنت ترغب في النظر في قابلية التوسع مقدما. هل قمت بالفعل بجميع الحسابات اللازمة؟ هل تتراكم البيانات بشكل أسرع من انخفاض أسعار SSD؟ كم مرة يجب أن ينمو عملك حتى لا تتلاءم جميع البيانات المتاحة على جهاز واحد؟ اعتبارًا من عام 2016 ، كان Stack Exchange يقوم بمعالجة 200 مليون استعلام يوميًا مع دعم لخوادم SQL الأربعة فقط : الخادم الرئيسي لـ Stack Overflow ، والآخر لكل شيء آخر ، ونسختين.

مرة أخرى ، يمكنك اللجوء إلى UNPHAT وتقرر استخدام Hadoop أو Spark. وربما يكون القرار صحيحا. الشيء الرئيسي هو أنك تستخدم حقًا التكنولوجيا المناسبة لحل مشكلتك . بالمناسبة ، هذا معروف في Google: عندما قرروا أن MapReduce غير مناسب للفهرسة ، توقفوا عن استخدامه.

أول الأشياء أولا ، فهم المشكلة

قد لا تكون رسالتي شيئًا جديدًا ، لكن قد تكون بهذا الشكل هي التي سترد عليك أو ربما سيكون من السهل عليك أن تتذكر UNPHAT وتطبيقها في الحياة. إذا لم يكن الأمر كذلك ، فيمكنك مشاهدة ريتش هيكي وهو يتحدث في Hammock Driven Development ، أو كتاب Paul ، How to Solve it ، أو Hamming ’s Art of Doing Science and Engineering . لأن الشيء الرئيسي الذي نطلبه جميعًا هو التفكير!

وفهم حقًا المشكلة التي تحاول حلها. في كلمات بول ملهمة:

"من الغباء الإجابة على سؤال لا تفهمه. من المحزن السعي لتحقيق هدف لا ترغب في تحقيقه. "

الترجمة الروسية

ترجمة: الكسندر تريجوبوف
حرره أليكسي إيفانوف (ponchiknews)
المجتمع: ponchiknews
الشكل: فريق محتوى LucidChart