Get best of the week

ماذا يحدث لشعبية MySQL و PostgreSQL؟ مناقشة Mitap

في 24 أبريل ، استضفنا خريطة MySQL @ Scale عبر الإنترنت حول مشكلات قابلية التوسع MySQL . شارك متحدثون من Avito و Badoo و ECOMMPAY: Andrey Aksenov (مؤلف أبو الهول ، زعيم البنية التحتية للبحث) ، Evgeny Kuzovlev (CIO ECOMMPAY) ، Vladimir Fedorkov (خبير MySQL / DBA في ECOMMPAY) و Nikolai Korolev (خبير MySQL / DBA في Badoo).

خرج Mitap منذ فترة طويلة ، لذلك قررنا نشره في أجزاء ، والبدء من النهاية - بمناقشة مثيرة للاهتمام للغاية في رأينا حول شعبية MySQL و PostgreSQL ، أسباب شعبية PostgreSQL ، ORM ، عدم تطابق المعاوقة ، مؤشرات كسورية ، الغضب ، الرفض ، المساومة وإعداد الفراغ التلقائي ومشاكل أخرى لاختيار DBMS من قبل مطوري سجل الزوار على NodeJS. انتباه! لا توجد مفردات خاضعة للرقابة للغاية ، وقد تم استبدال عدد من التعميمات غير الصحيحة ، وأية مصادفات عشوائية وليست بأي حال من الأحوال مسيئة.

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

واتضح أن Postgres متقدم (قليلاً) على MySQL ، وبالنسبة لي كانت في الأساس نوعًا من القصة الجديدة ، لأنه يبدو أن النسبة يجب أن تكون مختلفة. وهناك استطلاعات أجريت في مؤتمرات HighLoad ، تم نشرها. ليس لدي مقارنة منتظمة منتظمة من عام لآخر ، لكنها أظهرت بوضوح أن Postgres في مرحلة ما حول عدد الإجابات على سؤال "ما هي قاعدة بياناتك الرئيسية" قد تفوقت وتجاوزت MySQL.

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

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

بادئ ذي بدء ، ما رأيك ، في روسيا ، في العالم ، هو إعادة التوازن بين MySQL و Postgres ، وإذا كان الأمر كذلك ، فما هي أسبابها ، وكم من الأسباب التي أشرت إليها منطقية ومعقولة ، وربما هناك أسباب أخرى أسباب؟

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

في وقت سابق ، بشروط ، قبل حوالي ثماني سنوات ، لكي تعمل Postgres من أجلك فقط ، كان من الضروري الرقص كثيرًا باستخدام الدف الذي لا تحزنه الأم الآن. وقمت بوضع MySQL خارج الصندوق وعملت من أجلك. ربما ليس ثمانية ، وربما قبل 10-12 سنة. في الواقع ، تم تقليل هذا التعقيد في Postgres بشكل كبير ، ونقطة هذا الدخول هي التشغيل والتطوير ، وتمت مقارنتها مع MySQL بطريقة أو بأخرى.

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

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

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

فلاديمير فيدوركوف: يبدو يعني (فيما يتعلق بالمهندسين - تقريبا. ع ).

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

أليكسي ريباك: لا ، لقد دخلت للتو في ورقة رابحة.

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

في الوقت نفسه ، أنا غاضب بشدة لأنه في MySQL ليس لدي الفرصة ... أريد ، ولكن هنا لدي مؤشر B-tree وهذا كل شيء. وعلى الرغم من كسر! لا أعلم ، لا يمكنني البناء فقط ...

أليكسي ريباك: هناك فهارس تجزئة.

يفجيني كوزوفليف: نعم. ولكن ، دعنا نقارن عدد الفهارس التي لدينا في MySQL وعدد الفهارس التي لدينا في Postgres. هذا لا يضاهى. في الوقت نفسه ، يمكن قول الشيء نفسه عن محركات الطاولة. في MySQL لدينا محرك طاولة ، لا أريد ، ستذهب ، ستأخذ بعض TokuDB ، وسوف تستمتع في واحد بالمائة من الحالات وفي 99 ٪ من الحالات لا تفهم لماذا أخذتها ...

Andrey Aksyonov: تشويه بالكسور.

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

أندريه أكسيونوف: لماذا لم يتجذر؟ لقد تأصل InnoDB.

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

إيفجيني كوزوفليف: تعلم ، علم النفس البشري ، أن إمكانية الاختيار في بعض الأحيان تكون أكثر أهمية من الاختيار نفسه. MySQL يعطيها.

Alexei Rybak: لا يختار الأشخاص MySQL مقابل Postgres ، نظرًا لوجود محركات مختلفة. أعتقد أن هذا هو آخر ...

فلاديمير فيدوركوف: لأنه عندما يختار الناس MySQL ضد Postgres ، إذا كان هناك شخص على الأقل في الشركة وراء Postgres ، فسيتم اختياره لأنه دين.

أليكسي ريباك: MySQL هو أيضًا دين.

فلاديمير فيدوركوف: لا ، على الإطلاق.

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

Alexei Rybak: اسمع ، لا أصدق ذلك ، سامحني. أخبرني ، دعونا على وجه التحديد ...

Andrey Aksyonov: تعال على وجه التحديد. انظر ، 1995 ...

Alexey Rybak:الشركات التي أطلقت أصلاً منتجات الويب المصممة لنفس الرجال ... يا إلهي ، خرجت من رأسي! اتصل للتو ... الآن ، هنا هو الذي سيهزم الجميع ...

أندريه أكسيونوف: سيفوز مونغو.

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

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

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

أندري أكسيونوف: أكرر مرة أخرى. براعم على الجانبين ؛ Postgres على معلمات معينة ، من ناحية ، والمطورين على معلمات معينة ، من ناحية أخرى. مرة أخرى ، 1995. أنت مطور. تجلس في B ... ( أتيراو ) ، تكسب 15 دولارًا ، وهذا عام. وتكتب ج ***** ( لا قيمة لها) سجل الزوار في بيرل. ثم تحصل على عملية الاختيار - قاعدة البيانات التي تختارها. والمثير للدهشة أن كلا من MySQL و Postgres موجودان بالفعل. وإذا لم تكن كذلك ، فستظهر في عام 1996. ولكن أنت ، *** (أنثى من عائلة الكلاب) ، مطور دفتر الزوار على Perl in B ... ( Syzran )! لديك مهمة بهذا الحجم ، يمكنك حلها.

المعيار الوحيد الذي يمكنك التفكير فيه هو عدد طلبات "لكل دائرة" في الثانية التي ستلبيها. و "على دائرة" الطلبات في الثانية في هذه اللحظة ، تستهلك Postgres أقل أربع مرات ونصف. فقط هكذا ، فقط لأنك. بعد ذلك ، تبدو: حسنًا ، نعم ، ولكن في معاملات Postgres ، وفي MySQL 3.23 MyISAM. ولكن لنكون صادقين ، فإن المعاملات الخاصة بدفتر الزوار الخاص بي هي **** لي (على الإطلاق)لا حاجة. اختر MySQL بقوة.

الآن مر القليل من الوقت ، 25 سنة. من حيث المبدأ ، ما زلت تعيش في B ... ( Tuymazy ) ، لا تكتب بلغة Perl ، ولكن في NodeJS ، تم فهرسة راتبك ، لأنه مجرد تضخم بالدولار ، والآن أصبح 15 دولارًا ، مضروبًا في التضخم ، - 45 ، وهذا شهر. لديك نفس المشاكل ، بالإضافة إلى 100500 حزمة في NodeJS. وتحتاج حزم NodeJS 100500 هذه إلى تخزين حالتها بالكامل في مكان ما ، وطلبات معقدة حول مدير الحزم ، وما إلى ذلك.

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

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

أليكسي ريباك: اسمع ، لكنني لا أفهم أين الأفضل؟ ما هو الأفضل؟ أفهم أنهم متساوون في شيء ما ، لكن ما هو أفضل ، لا أفهم.

أندري أكسيونوف: كلاهما أسوأ.

أليكسي ريباك: ثان مونغو؟

أندري أكسيونوف:بالطبع ، من علامات الاقتباس ، "Mongo". ولكن هذا موضوع لمحادثة منفصلة كاملة ، وموضوع محادثات منفصل كامل يسمى "أين المستقبل المشرق".

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

أليكسي ريباك: / dev / null! الكتابة إلى / dev / null ، الأصدقاء ، dev / null هو مقياس ويب.

أندري أكسيونوف: نعم. حسنًا ، حسنًا ، يمكنك أيضًا تشغيل / dev / null من حيث المبدأ على الأداء ، يمكننا.

أليكسي ريباك: حسنًا يا أصدقاء. الجميع على الأرجح متعب للغاية. نحن نتحدث منذ أكثر من ساعتين.

أندري أكسيونوف: لكن الأسئلة المثيرة للاهتمام لم تثر.

نيكولاي كوروليف:بدأ للتو.

أليكسي ريباك: بجدية؟ هل تريد الاستمرار؟

أندري أكسيونوف: لم أسكب ويسكي أيضًا.

أليكسي ريباك: لكن هذا سؤال كبير لماذا لم تفعل.

أندريه أكسيونوف: لم

أقم بالتحضير بالطبع ... فلاديمير فيدوركوف: لذلك قالوا أن البث ، البث ، لا شيء مستحيل ، لا يمكنك أن تقسم ، لا يمكنك أن تكون ممتلئًا.

أليكسي ريباك: آه! اصحاب! كل من كان يشاهد البث شكرا جزيلا لوجودك معنا. نبدأ الجزء غير الرسمي ، حيث يتم إيقاف تشغيله ... الآن ... أزيل البث المباشر. شكرا لكم جميعا ، شكرا لضيوفنا - فلاديمير ، أندري ، يوجين ، نيكولاي. بث قبالة ، وداعا ، أراك لاحقا.

(نهاية التسجيل)

يمكن الاطلاع على السجل الكامل للميتاب على يوتيوب:



في المستقبل القريب ، سننشر أيضًا أجزاء أخرى حول البنية التحتية وأنماط التحمل / التسامح مع الخطأ وحالة النظام البيئي MySQL.

إذا كنت تحب هذا التنسيق ، فسيكون هناك يوم الجمعة هذا تجمع آخر مخصص للبنية التحتية للحاويات ، فلا تزال هناك أماكن لذلك . المشاركون: يفغيني بوتابوف (الرئيس التنفيذي لشركة ITSumma) ، وديمتري ستولياروف (CTO Flant) ، ودينيس رمشوكوف (المعروف أيضًا باسم Eric Oldmann ، COO argotech.io ، سابقًا - RAO UES of Russia) ، Andrey Fedorovsky (CTO News360.com) و إيفان كروجلوف (مهندس أنظمة ، سابق - Booking.com). دعونا نتحدث عن أدوات ومشاكل وآفاق الحاويات و Kubernetes في البنية التحتية الحديثة.

لدينا أيضًا مجموعة Facebook المذكورة "إدارة وتطوير مشاريع تكنولوجيا المعلومات الكبيرة" ، وقناة feedmeto مع منشورات مثيرة للاهتمام من مدونات التكنولوجيا (غالبًا ما تكون أجنبية) للشركات ، وقناة المؤلف rybakalexey حول إدارة التطوير في شركات الأغذية.

More articles:


All Articles