بناء أسرع تحليلات مواقع الويب في العالم (2021)

على مدار أكثر من عام ، كنا نكافح لمواكبة نمو بيانات التحليلات الخاصة بنا. نما Fathom بسرعة الضوء ، مع تخلي المزيد والمزيد من الأشخاص عن Google Analytics ، كان استيعابنا للبيانات ينفجر.

في آذار (مارس) 2021 ، نقلنا جميع بيانات التحليلات الخاصة بنا إلى قاعدة بيانات أحلامنا.

على مدار أكثر من عام ، كنا نكافح لمواكبة نمو بيانات التحليلات الخاصة بنا. نما Fathom بسرعة الضوء ، مع تخلي المزيد والمزيد من الأشخاص عن Google Analytics ، وتزايد استيعابنا للبيانات. كانت شعبيتنا رائعة بالنسبة للأعمال وخصوصية المستخدم ، ولكنها ليست جيدة لأداء لوحة المعلومات. ما كان لدينا لم ينجح معنا.

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

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

الإصدار 2

بالنسبة للإصدار 2 ، أعدنا بناء Fathom Analytics بالكامل وانتقلنا إلى Laravel Vapor. احتفظنا بهيكل قاعدة بيانات مماثل ، لكننا انتقلنا إلى MySQL المُدارة. كان الجانب الإيجابي أنني عدت إلى منطقة الراحة الخاصة بي (حيث كانت لدي خبرة) ، ولكن الجانب السلبي هو أننا لم نفعل أي شيء لتحسين بنية قاعدة البيانات الخاصة بنا. هل سارت الأمور بشكل أسرع؟ طبعا. لقد قمنا بزيادة وحدة المعالجة المركزية وذاكرة الوصول العشوائي ، وكان أداء الاستعلامات أفضل ، ولكنه لم يكن حلاً مستدامًا للوحة التحكم أو المحفظة. مشاكل مع MySQL

قبل سرد أسباب التخلي عن MySQL ، أريد أن أوضح بصوت عالٍ وواضح أنني أعلم أن MySQL لم يتم تصميمه لحالة الاستخدام التحليلي واسعة النطاق هذه. بعد توضيح ذلك ، إليك الأسباب الرئيسية التي دفعتنا للتخلي عن RDS لـ MySQL:

أداء سيء

على الرغم من أننا احتفظنا بجداول الملخصات فقط (يتم تجميع البيانات بالساعة) ، كانت قاعدة البيانات الخاصة بنا تكافح من أجل تنفيذ SUM و GROUP BY. وكان الأمر أسوأ مع البيانات الأساسية العالية. من الأمثلة على ذلك العميل الذي حصل على 11.000.000 مشاهدة فريدة للصفحة في يوم واحد. قد يستغرق MySQL 7 دقائق لمعالجة استعلام SUM / GROUP لهم ، وستنتهي مهلة استعلامات لوحة المعلومات. للتغلب على هذا القيد ، كان عليّ إنشاء وظيفة cron مخصصة تحسب مسبقًا بيانات لوحة القيادة. كنا بحاجة إلى مزيد من المرونة

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

مع RDS ، كان علينا التفكير في IOPS. بعد تجربة مرهقة مع أحد مواقع الويب الفيروسية ، بدأنا في الإفراط في توفير IOPS لـ RDS. وهي باهظة الثمن. إذا لم تكن معتادًا على IOPS ، فإن أسهل طريقة لشرحها هي أنك تحتاج إلى توفير قدر معين من التخزين ، والذي يأتي مع كمية ثابتة من IOPS ، والتي تملي الحد الأقصى للقراءة / الكتابة في الثانية في قاعدة البيانات الخاصة بك. وإذا حصلت على موقع ينتشر بسرعة كبيرة ولم يكن لديك IOPS المناسب للتعامل معه ، مرحبًا بك في backlog town ، قم بتعبئة الموقع.

للتأكد من قدرتنا على التعامل مع تدفقات حركة المرور ، دفعنا 2000 غيغابايت من مساحة تخزين قاعدة البيانات. أعطانا هذا 6000 IOPS ، وهو أمر جيد معنا. لذلك كنا ندفع 500 دولارًا إضافيًا شهريًا للتخزين الذي لم نكن بحاجة إليه ، فقط في حالة وجود موقع فيروسي آخر لإدارته. وفي وقت كتابة هذا التقرير ، ما زلنا ندفع مقابل ذلك لأن AWS لا تسمح لك بخفض سعة التخزين لديك بسهولة. (نعم ، أنا مالح حيال ذلك.) حد الاتصال

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

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