أهلاً بكم! اسمي جولوف نيكولاي. عملت سابقًا في Avito وقمت بإدارة منصة البيانات لمدة ست سنوات، أي أنني عملت على جميع قواعد البيانات: التحليلية (Vertica، ClickHouse)، والتدفق وOLTP (Redis، Tarantool، VoltDB، MongoDB، PostgreSQL). خلال هذا الوقت، تعاملت مع عدد كبير من قواعد البيانات - مختلفة جدًا وغير عادية، ومع حالات استخدامها غير القياسية.
أنا أعمل حاليًا في ManyChat. في جوهرها، هذه شركة ناشئة - جديدة وطموحة وسريعة النمو. وعندما انضممت إلى الشركة لأول مرة، نشأ سؤال كلاسيكي: "ما الذي يجب على الشركات الناشئة الشابة أن تأخذه الآن من سوق نظم إدارة قواعد البيانات وقواعد البيانات؟"
في هذه المقالة، بناءً على تقريري في ، سأجيب على هذا السؤال. نسخة الفيديو من التقرير متاحة على .
قواعد البيانات المعروفة 2020
إنه عام 2020، نظرت حولي ورأيت ثلاثة أنواع من قواعد البيانات.
النوع الأول - قواعد بيانات OLTP الكلاسيكية: PostgreSQL، SQL Server، أوراكل، MySQL. لقد تمت كتابتها منذ وقت طويل، ولكنها لا تزال ذات صلة لأنها مألوفة جدًا لمجتمع المطورين.
النوع الثاني هو قواعد من "الصفر". لقد حاولوا الابتعاد عن الأنماط الكلاسيكية من خلال التخلي عن SQL والهياكل التقليدية وACID، وذلك عن طريق إضافة تجزئة مدمجة وميزات جذابة أخرى. على سبيل المثال، هذا هو Cassandra أو MongoDB أو Redis أو Tarantool. أرادت كل هذه الحلول أن تقدم للسوق شيئًا جديدًا بشكل أساسي واحتلت مكانتها لأنها كانت ملائمة للغاية لمهام معينة. سأشير إلى قواعد البيانات هذه بالمصطلح الشامل NOSQL.
لقد انتهت "الأصفار"، واعتدنا على قواعد بيانات NOSQL، واتخذ العالم، من وجهة نظري، الخطوة التالية - إلى قواعد البيانات المدارة. تحتوي قواعد البيانات هذه على نفس جوهر قواعد بيانات OLTP الكلاسيكية أو قواعد بيانات NoSQL الجديدة. لكن ليس لديهم حاجة إلى DBA وDevOps ويعملون على الأجهزة المُدارة في السحابة. بالنسبة للمطور، هذه "مجرد قاعدة" تعمل في مكان ما، ولكن لا أحد يهتم بكيفية تثبيتها على الخادم، ومن قام بتكوين الخادم ومن يقوم بتحديثه.
أمثلة على قواعد البيانات هذه:
- AWS RDS عبارة عن برنامج مُجمَّع مُدار لـ PostgreSQL/MySQL.
- DynamoDB هو نظير AWS لقاعدة بيانات مستندة إلى المستندات، على غرار Redis وMongoDB.
- Amazon Redshift عبارة عن قاعدة بيانات تحليلية مُدارة.
هذه قواعد بيانات قديمة بشكل أساسي، ولكنها نشأت في بيئة مُدارة، دون الحاجة إلى العمل مع الأجهزة.
ملحوظة. تم أخذ الأمثلة لبيئة AWS، ولكن نظائرها موجودة أيضًا في Microsoft Azure أو Google Cloud أو Yandex.Cloud.
ما الجديد في هذا؟ في عام 2020، لا شيء من هذا.
مفهوم بدون خادم
الجديد حقًا في السوق في عام 2020 هو الحلول بدون خادم أو بدون خادم.
سأحاول شرح ما يعنيه هذا باستخدام مثال الخدمة العادية أو تطبيق الواجهة الخلفية.
لنشر تطبيق خلفي عادي، نقوم بشراء أو استئجار خادم، ونسخ الكود عليه، ونشر نقطة النهاية في الخارج، والدفع بانتظام مقابل خدمات الإيجار والكهرباء ومركز البيانات. هذا هو المخطط القياسي.
هل هناك أي طريقة أخرى؟ مع الخدمات بدون خادم يمكنك ذلك.
ما هو محور هذا النهج: لا يوجد خادم، ولا يوجد حتى استئجار مثيل افتراضي في السحابة. لنشر الخدمة، انسخ الكود (الوظائف) إلى المستودع وانشره إلى نقطة النهاية. ثم نقوم ببساطة بالدفع مقابل كل استدعاء لهذه الوظيفة، متجاهلين تمامًا الأجهزة التي يتم تنفيذها فيها.
وسأحاول توضيح هذا النهج بالصور.
النشر الكلاسيكي. لدينا خدمة مع حمولة معينة. نطرح حالتين: الخوادم الفعلية أو المثيلات في AWS. يتم إرسال الطلبات الخارجية إلى هذه الحالات ومعالجتها هناك.
كما ترون في الصورة، لا يتم التخلص من الخوادم بالتساوي. أحدهما مستخدم بنسبة 100%، وهناك طلبان، والآخر بنسبة 50% فقط - خامل جزئيًا. إذا لم تصل ثلاثة طلبات، ولكن 30، فلن يتمكن النظام بأكمله من التعامل مع الحمل وسيبدأ في التباطؤ.
النشر بدون خادم. في بيئة بدون خادم، لا تحتوي هذه الخدمة على مثيلات أو خوادم. هناك مجموعة معينة من الموارد الساخنة - حاويات Docker صغيرة مُجهزة مع رمز الوظيفة المنشور. يتلقى النظام طلبات خارجية ولكل منها، يقوم الإطار بدون خادم برفع حاوية صغيرة تحتوي على رمز: يعالج هذا الطلب المحدد ويقتل الحاوية.
طلب واحد - حاوية واحدة مرفوعة، 1000 طلب - 1000 حاوية. والنشر على خوادم الأجهزة هو بالفعل عمل موفر السحابة. إنه مخفي تمامًا بواسطة إطار العمل بدون خادم. في هذا المفهوم نحن ندفع مقابل كل مكالمة. على سبيل المثال، جاءت مكالمة واحدة يوميًا - لقد دفعنا مقابل مكالمة واحدة، وجاء مليون في الدقيقة - لقد دفعنا مقابل مليون. أو في ثانية، يحدث هذا أيضًا.
يعد مفهوم نشر وظيفة بدون خادم مناسبًا لخدمة عديمة الحالة. وإذا كنت بحاجة إلى خدمة Statefull (حالة)، فإننا نضيف قاعدة بيانات إلى الخدمة. في هذه الحالة، عندما يتعلق الأمر بالعمل مع الحالة، فإن كل وظيفة Statefull تكتب وتقرأ ببساطة من قاعدة البيانات. علاوة على ذلك، من قاعدة بيانات لأي من الأنواع الثلاثة الموضحة في بداية المقال.
ما هو القيد المشترك لجميع قواعد البيانات هذه؟ هذه هي تكاليف السحابة أو خادم الأجهزة المستخدمة باستمرار (أو عدة خوادم). لا يهم ما إذا كنا نستخدم قاعدة بيانات كلاسيكية أو مُدارة، وسواء كان لدينا Devops ومسؤول أم لا، فإننا لا نزال ندفع مقابل استئجار الأجهزة والكهرباء ومركز البيانات على مدار الساعة طوال أيام الأسبوع. إذا كانت لدينا قاعدة كلاسيكية، فإننا ندفع ثمن السيد والعبد. إذا كانت قاعدة بيانات مجزأة عالية التحميل، فإننا ندفع مقابل 24 أو 7 أو 10 خادمًا، وندفع باستمرار.
كان يُنظر سابقًا إلى وجود خوادم محجوزة بشكل دائم في هيكل التكلفة على أنه شر لا بد منه. تواجه قواعد البيانات التقليدية أيضًا صعوبات أخرى، مثل القيود المفروضة على عدد الاتصالات، وقيود القياس، والإجماع الموزع جغرافيًا - يمكن حلها بطريقة ما في قواعد بيانات معينة، ولكن ليس كلها مرة واحدة وليس بشكل مثالي.
قاعدة بيانات بدون خادم - النظرية
سؤال 2020: هل من الممكن جعل قاعدة البيانات بدون خادم أيضًا؟ لقد سمع الجميع عن الواجهة الخلفية بدون خادم... فلنحاول جعل قاعدة البيانات بدون خادم؟
يبدو هذا غريبًا، لأن قاعدة البيانات عبارة عن خدمة كاملة الحالة، وليست مناسبة جدًا للبنية التحتية بدون خادم. في الوقت نفسه، فإن حالة قاعدة البيانات كبيرة جدًا: غيغابايت، تيرابايت، وفي قواعد البيانات التحليلية حتى بيتابايت. ليس من السهل رفعها في حاويات Docker خفيفة الوزن.
من ناحية أخرى، تحتوي جميع قواعد البيانات الحديثة تقريبًا على قدر كبير من المنطق والمكونات: المعاملات، وتنسيق التكامل، والإجراءات، والتبعيات العلائقية، والكثير من المنطق. بالنسبة إلى الكثير من منطق قاعدة البيانات، تكون الحالة الصغيرة كافية. يتم استخدام الجيجابايت والتيرابايت مباشرة بواسطة جزء صغير فقط من منطق قاعدة البيانات المتضمن في تنفيذ الاستعلامات مباشرة.
وبناءً على ذلك، فإن الفكرة هي: إذا كان جزء من المنطق يسمح بالتنفيذ عديم الحالة، فلماذا لا يتم تقسيم القاعدة إلى أجزاء ذات حالة وعديمة الحالة.
بدون خادم لحلول OLAP
دعونا نرى كيف قد يبدو تقسيم قاعدة البيانات إلى أجزاء ذات حالة وعديمة الحالة باستخدام أمثلة عملية.
على سبيل المثال، لدينا قاعدة بيانات تحليلية: البيانات الخارجية (الأسطوانة الحمراء على اليسار)، وعملية ETL التي تقوم بتحميل البيانات إلى قاعدة البيانات، ومحلل يرسل استعلامات SQL إلى قاعدة البيانات. هذا هو مخطط تشغيل مستودع البيانات الكلاسيكي.
في هذا المخطط، يتم تنفيذ ETL بشكل مشروط مرة واحدة. ثم تحتاج إلى الدفع باستمرار مقابل الخوادم التي تعمل عليها قاعدة البيانات ببيانات مليئة بـ ETL، بحيث يكون هناك شيء لإرسال الاستعلامات إليه.
دعونا نلقي نظرة على النهج البديل المطبق في AWS Athena Serverless. لا توجد أجهزة مخصصة بشكل دائم يتم تخزين البيانات التي تم تنزيلها عليها. بدلا من هذا:
- يرسل المستخدم استعلام SQL إلى أثينا. يقوم مُحسِّن Athena بتحليل استعلام SQL ويبحث في مخزن بيانات التعريف (بيانات التعريف) عن البيانات المحددة اللازمة لتنفيذ الاستعلام.
- يقوم المحسن، استنادا إلى البيانات المجمعة، بتنزيل البيانات الضرورية من مصادر خارجية إلى وحدة تخزين مؤقتة (قاعدة بيانات مؤقتة).
- يتم تنفيذ استعلام SQL من المستخدم في وحدة تخزين مؤقتة ويتم إرجاع النتيجة إلى المستخدم.
- يتم مسح التخزين المؤقت وتحرير الموارد.
في هذه البنية، نحن ندفع فقط مقابل عملية تنفيذ الطلب. لا طلبات - لا تكاليف.
يعد هذا أسلوبًا عمليًا ويتم تنفيذه ليس فقط في Athena Serverless، ولكن أيضًا في Redshift Spectrum (في AWS).
يوضح مثال Athena أن قاعدة البيانات بدون خادم تعمل على استعلامات حقيقية تحتوي على عشرات ومئات التيرابايت من البيانات. ستتطلب مئات التيرابايت مئات الخوادم، لكن لا يتعين علينا أن ندفع مقابلها - فنحن ندفع مقابل الطلبات. سرعة كل طلب منخفضة (جدًا) مقارنة بقواعد البيانات التحليلية المتخصصة مثل Vertica، ولكننا لا ندفع مقابل فترات التوقف.
تنطبق قاعدة البيانات هذه على الاستعلامات التحليلية المخصصة النادرة. على سبيل المثال، عندما نقرر بشكل عفوي اختبار فرضية ما على كمية هائلة من البيانات. أثينا مثالية لهذه الحالات. بالنسبة للطلبات المنتظمة، يعد هذا النظام مكلفًا. في هذه الحالة، قم بتخزين البيانات في بعض الحلول المتخصصة.
بدون خادم لحلول OLTP
نظر المثال السابق إلى مهام OLAP (التحليلية). الآن دعونا نلقي نظرة على مهام OLTP.
لنتخيل PostgreSQL أو MySQL قابلة للتطوير. لنقم بإنشاء نسخة مُدارة عادية من PostgreSQL أو MySQL بأقل قدر من الموارد. عندما يتلقى المثيل المزيد من التحميل، سنقوم بتوصيل النسخ المتماثلة الإضافية التي سنقوم بتوزيع جزء من حمل القراءة عليها. إذا لم تكن هناك طلبات أو تحميل، نقوم بإيقاف النسخ المتماثلة. المثيل الأول هو السيد، والباقي عبارة عن نسخ متماثلة.
يتم تنفيذ هذه الفكرة في قاعدة بيانات تسمى Aurora Serverless AWS. المبدأ بسيط: يتم قبول الطلبات الواردة من التطبيقات الخارجية بواسطة أسطول الوكيل. نظرًا لزيادة الحمل، فإنه يخصص موارد الحوسبة من الحد الأدنى من المثيلات التي تم تسخينها مسبقًا - ويتم الاتصال في أسرع وقت ممكن. يحدث تعطيل المثيلات بنفس الطريقة.
يوجد داخل Aurora مفهوم وحدة قدرة Aurora، ACU. هذا (مشروط) مثيل (الخادم). يمكن أن تكون كل وحدة ACU محددة سيدًا أو عبدًا. تحتوي كل وحدة سعة على ذاكرة الوصول العشوائي (RAM) الخاصة بها والمعالج والحد الأدنى من القرص. وفقا لذلك، واحد هو سيد، والباقي تتم قراءة النسخ المتماثلة فقط.
يعد عدد وحدات سعة Aurora قيد التشغيل بمثابة معلمة قابلة للتكوين. يمكن أن يكون الحد الأدنى للكمية واحدًا أو صفرًا (في هذه الحالة، لا تعمل قاعدة البيانات في حالة عدم وجود طلبات).
عندما تتلقى القاعدة الطلبات، يقوم أسطول الوكيل برفع وحدات سعة Aurora، مما يزيد من موارد أداء النظام. تتيح القدرة على زيادة الموارد وتقليلها للنظام "التوفيق بين" الموارد: عرض وحدات ACU الفردية تلقائيًا (استبدالها بوحدات جديدة) ونشر جميع التحديثات الحالية على الموارد المسحوبة.
يمكن لقاعدة Aurora Serverless قياس حمل القراءة. لكن الوثائق لا تقول ذلك بشكل مباشر. قد يبدو الأمر وكأنهم يستطيعون رفع سيد متعدد. لا يوجد سحر.
قاعدة البيانات هذه مناسبة تمامًا لتجنب إنفاق مبالغ ضخمة على الأنظمة ذات الوصول غير المتوقع. على سبيل المثال، عند إنشاء مواقع MVP أو مواقع بطاقات العمل التسويقية، لا نتوقع عادةً تحميلًا ثابتًا. وبناءً على ذلك، إذا لم يكن هناك وصول، فإننا لا ندفع مقابل المثيلات. عند حدوث تحميل غير متوقع، على سبيل المثال بعد مؤتمر أو حملة إعلانية، تزور حشود من الأشخاص الموقع ويزداد التحميل بشكل كبير، يأخذ Aurora Serverless هذا الحمل تلقائيًا ويربط الموارد المفقودة (ACU) بسرعة. ثم يمر المؤتمر، وينسى الجميع النموذج الأولي، وتظل الخوادم (ACU) مظلمة، وتنخفض التكاليف إلى الصفر - وهو أمر مريح.
هذا الحل غير مناسب للتحميل العالي المستقر لأنه لا يقيس حمل الكتابة. تحدث كل هذه الاتصالات وقطع الاتصال بالموارد عند ما يسمى "نقطة القياس" - وهي نقطة زمنية لا تكون فيها قاعدة البيانات مدعومة بمعاملة أو جداول مؤقتة. على سبيل المثال، في غضون أسبوع، قد لا تحدث نقطة القياس، وتعمل القاعدة على نفس الموارد ولا يمكنها ببساطة التوسع أو الانكماش.
لا يوجد سحر - إنه PostgreSQL عادي. لكن عملية إضافة الأجهزة وفصلها تتم بشكل آلي جزئيًا.
بدون خادم حسب التصميم
Aurora Serverless هي قاعدة بيانات قديمة تمت إعادة كتابتها للسحابة للاستفادة من بعض مزايا Serverless. والآن سأخبرك عن القاعدة، التي تمت كتابتها في الأصل للسحابة، للنهج بدون خادم - التصميم بدون خادم. تم تطويره على الفور دون افتراض أنه سيتم تشغيله على خوادم فعلية.
هذه القاعدة تسمى ندفة الثلج. لديها ثلاث كتل رئيسية.
الأول هو كتلة البيانات الوصفية. هذه خدمة سريعة في الذاكرة تعمل على حل المشكلات المتعلقة بالأمان وبيانات التعريف والمعاملات وتحسين الاستعلام (كما هو موضح في الرسم التوضيحي الموجود على اليسار).
الكتلة الثانية عبارة عن مجموعة من مجموعات الحوسبة الافتراضية لإجراء العمليات الحسابية (يوجد في الرسم التوضيحي مجموعة من الدوائر الزرقاء).
الكتلة الثالثة هي نظام تخزين البيانات القائم على S3. S3 عبارة عن مخزن كائنات بلا أبعاد في AWS، وهو يشبه إلى حد ما Dropbox بدون أبعاد للأعمال.
دعونا نرى كيف يعمل Snowflake، على افتراض بداية باردة. أي أن هناك قاعدة بيانات، ويتم تحميل البيانات فيها، ولا توجد استعلامات قيد التشغيل. وبناء على ذلك، إذا لم تكن هناك طلبات إلى قاعدة البيانات، فقد قمنا برفع خدمة البيانات الوصفية السريعة في الذاكرة (الكتلة الأولى). ولدينا تخزين S3، حيث يتم تخزين بيانات الجدول، مقسمة إلى ما يسمى بالأقسام الدقيقة. للتبسيط: إذا كان الجدول يحتوي على معاملات، فإن الأقسام الدقيقة هي أيام المعاملات. كل يوم عبارة عن قسم صغير منفصل وملف منفصل. وعندما تعمل قاعدة البيانات في هذا الوضع، فإنك تدفع فقط مقابل المساحة التي تشغلها البيانات. علاوة على ذلك، فإن معدل المقعد منخفض جدًا (خاصة مع مراعاة الضغط الكبير). تعمل خدمة البيانات الوصفية أيضًا بشكل مستمر، ولكنك لا تحتاج إلى الكثير من الموارد لتحسين الاستعلامات، ويمكن اعتبار الخدمة بمثابة برامج تجريبية.
لنتخيل الآن أن مستخدمًا جاء إلى قاعدة البيانات الخاصة بنا وأرسل استعلام SQL. يتم إرسال استعلام SQL على الفور إلى خدمة بيانات التعريف للمعالجة. وبناء على ذلك، عند تلقي الطلب، تقوم هذه الخدمة بتحليل الطلب والبيانات المتاحة وأذونات المستخدم، وإذا كان كل شيء على ما يرام، تضع خطة لمعالجة الطلب.
بعد ذلك، تبدأ الخدمة في إطلاق مجموعة الحوسبة. مجموعة الحوسبة هي مجموعة من الخوادم التي تقوم بإجراء العمليات الحسابية. أي أن هذه مجموعة يمكن أن تحتوي على خادم واحد، وخادمين، و1، و2، و4، و8 - أي عدد تريده. يمكنك طرح طلب ويبدأ تشغيل هذه المجموعة على الفور. يستغرق حقا ثواني.
بعد ذلك، بعد بدء المجموعة، يبدأ نسخ الأقسام الدقيقة اللازمة لمعالجة طلبك إلى المجموعة من S3. أي لنتخيل أنه لتنفيذ استعلام SQL، فأنت بحاجة إلى قسمين من جدول واحد وواحد من الجدول الثاني. في هذه الحالة، سيتم نسخ الأقسام الثلاثة الضرورية فقط إلى المجموعة، وليس كافة الجداول بالكامل. لهذا السبب، وبالتحديد لأن كل شيء يقع داخل مركز بيانات واحد ومتصل بقنوات سريعة جدًا، فإن عملية النقل بأكملها تحدث بسرعة كبيرة: في ثوانٍ، ونادرًا جدًا في دقائق، إلا إذا كنا نتحدث عن بعض الطلبات الهائلة . وفقًا لذلك، يتم نسخ الأقسام الدقيقة إلى مجموعة الحوسبة، وعند الانتهاء، يتم تنفيذ استعلام SQL على مجموعة الحوسبة هذه. يمكن أن تكون نتيجة هذا الطلب سطرًا واحدًا أو عدة أسطر أو جدولًا - يتم إرسالها خارجيًا إلى المستخدم حتى يتمكن من تنزيلها أو عرضها في أداة ذكاء الأعمال الخاصة به أو استخدامها بطريقة أخرى.
لا يستطيع كل استعلام SQL قراءة التجميعات من البيانات التي تم تحميلها مسبقًا فحسب، بل يمكنه أيضًا تحميل/إنشاء بيانات جديدة في قاعدة البيانات. أي أنه يمكن أن يكون استعلامًا، على سبيل المثال، يقوم بإدراج سجلات جديدة في جدول آخر، مما يؤدي إلى ظهور قسم جديد في مجموعة الحوسبة، والذي بدوره يتم حفظه تلقائيًا في وحدة تخزين S3 واحدة.
السيناريو الموصوف أعلاه، من وصول المستخدم إلى رفع المجموعة، وتحميل البيانات، وتنفيذ الاستعلامات، والحصول على النتائج، يتم دفعه بمعدل دقائق استخدام مجموعة الحوسبة الافتراضية المرتفعة، والمستودع الافتراضي. يختلف السعر اعتمادًا على منطقة AWS وحجم المجموعة، ولكنه في المتوسط يبلغ بضعة دولارات في الساعة. إن تكلفة مجموعة مكونة من أربع آلات تبلغ ضعف تكلفة مجموعة مكونة من جهازين، كما أن تكلفة مجموعة مكونة من ثماني آلات لا تزال مضاعفة التكلفة. تتوفر خيارات من 16 إلى 32 ماكينة، اعتمادًا على مدى تعقيد الطلبات. لكنك تدفع فقط مقابل تلك الدقائق التي تكون فيها المجموعة قيد التشغيل فعليًا، لأنه عندما لا تكون هناك طلبات، فإنك ترفع يديك نوعًا ما، وبعد 5-10 دقائق من الانتظار (معلمة قابلة للتكوين) ستنفجر من تلقاء نفسها، تحرير الموارد وتصبح حرة.
السيناريو الواقعي تمامًا هو أنه عندما ترسل طلبًا، تنبثق المجموعة، نسبيًا، في دقيقة واحدة، يتم احتساب دقيقة أخرى، ثم خمس دقائق لإغلاقها، وينتهي بك الأمر بالدفع مقابل سبع دقائق من تشغيل هذه المجموعة، و وليس لأشهر وسنوات.
تم وصف السيناريو الأول باستخدام Snowflake في إعداد المستخدم الفردي. الآن دعونا نتخيل أن هناك العديد من المستخدمين، وهو أقرب إلى السيناريو الحقيقي.
لنفترض أن لدينا الكثير من المحللين وتقارير Tableau التي تمطر قاعدة بياناتنا باستمرار بعدد كبير من استعلامات SQL التحليلية البسيطة.
بالإضافة إلى ذلك، لنفترض أن لدينا علماء بيانات مبتكرين يحاولون القيام بأشياء هائلة باستخدام البيانات، والعمل بعشرات التيرابايت، وتحليل مليارات وتريليونات صفوف البيانات.
بالنسبة لنوعي عبء العمل الموصوفين أعلاه، يسمح لك Snowflake برفع العديد من مجموعات الحوسبة المستقلة ذات السعات المختلفة. علاوة على ذلك، تعمل مجموعات الحوسبة هذه بشكل مستقل، ولكن مع بيانات متسقة مشتركة.
بالنسبة لعدد كبير من الاستعلامات الخفيفة، يمكنك رفع 2-3 مجموعات صغيرة، ما يقرب من جهازين لكل منهما. يمكن تنفيذ هذا السلوك، من بين أمور أخرى، باستخدام الإعدادات التلقائية. لذلك تقول: "ندفة الثلج، ارفع عنقودًا صغيرًا. إذا زاد الحمل عليه فوق معلمة معينة، ارفع ثانية مماثلة، ثالثة. عندما يبدأ الحمل في الانخفاض، قم بإطفاء الفائض. لذا، بغض النظر عن عدد المحللين الذين يأتون ويبدأون في النظر في التقارير، فإن كل شخص لديه ما يكفي من الموارد.
وفي الوقت نفسه، إذا كان المحللون نائمين ولم ينظر أحد إلى التقارير، فقد تصبح المجموعات مظلمة تمامًا، وتتوقف عن دفع ثمنها.
في الوقت نفسه، بالنسبة للاستعلامات الثقيلة (من علماء البيانات)، يمكنك رفع مجموعة واحدة كبيرة جدًا لـ 32 جهازًا. سيتم أيضًا الدفع لهذه المجموعة فقط مقابل تلك الدقائق والساعات التي يتم فيها تشغيل طلبك العملاق هناك.
تتيح لك الفرصة الموضحة أعلاه تقسيم ليس فقط نوعين من عبء العمل، بل أيضًا المزيد من أنواع عبء العمل إلى مجموعات (ETL، المراقبة، تحقيق التقرير،...).
دعونا نلخص ندفة الثلج. تجمع القاعدة بين فكرة جميلة وتنفيذ عملي. في ManyChat، نستخدم Snowflake لتحليل جميع البيانات المتوفرة لدينا. ليس لدينا ثلاث مجموعات، كما في المثال، ولكن من 5 إلى 9، بأحجام مختلفة. لدينا 16 آلة تقليدية، وآلتان، وأيضًا آلة واحدة صغيرة جدًا لبعض المهام. لقد نجحوا في توزيع الحمل ويسمحون لنا بتوفير الكثير.
تقوم قاعدة البيانات بتحجيم حمل القراءة والكتابة بنجاح. وهذا فرق كبير واختراق كبير مقارنة بنفس "أورورا" التي كانت تحمل عبء القراءة فقط. يتيح لك Snowflake توسيع نطاق عبء العمل في الكتابة باستخدام مجموعات الحوسبة هذه. وهذا يعني، كما ذكرت، أننا نستخدم عدة مجموعات في ManyChat، وتستخدم المجموعات الصغيرة والصغيرة جدًا بشكل أساسي لـ ETL، لتحميل البيانات. ويعيش المحللون بالفعل في مجموعات متوسطة، والتي لا تتأثر على الإطلاق بحمل ETL، لذا فهم يعملون بسرعة كبيرة.
وبناءً على ذلك، فإن قاعدة البيانات مناسبة تمامًا لمهام OLAP. ومع ذلك، لسوء الحظ، لا ينطبق هذا حتى الآن على أحمال عمل OLTP. أولاً، قاعدة البيانات هذه عمودية، مع كل ما يترتب على ذلك من عواقب. ثانيًا، النهج نفسه، عند كل طلب، إذا لزم الأمر، تقوم برفع مجموعة حوسبة وإغراقها بالبيانات، لسوء الحظ، ليس بالسرعة الكافية بعد لتحميل OLTP. يعد انتظار ثوانٍ لمهام OLAP أمرًا طبيعيًا، ولكنه غير مقبول بالنسبة لمهام OLTP؛ قد يكون 100 مللي ثانية أفضل، أو 10 مللي ثانية سيكون أفضل.
مجموع
يمكن إنشاء قاعدة بيانات بدون خادم عن طريق تقسيم قاعدة البيانات إلى أجزاء عديمة الحالة وأجزاء ذات حالة. ربما لاحظت أنه في جميع الأمثلة المذكورة أعلاه، الجزء الخاص بالحالة هو، نسبيًا، تخزين الأقسام الصغيرة في S3، والحالة عديمة الجنسية هي المُحسِّن، الذي يعمل مع البيانات الوصفية، ويتعامل مع مشكلات الأمان التي يمكن أن تثار كخدمات عديمة الحالة خفيفة الوزن ومستقلة.
يمكن أيضًا اعتبار تنفيذ استعلامات SQL بمثابة خدمات خفيفة يمكن أن تظهر في وضع بدون خادم، مثل مجموعات الحوسبة Snowflake، وتنزيل البيانات الضرورية فقط، وتنفيذ الاستعلام و"الخروج".
قواعد البيانات على مستوى الإنتاج بدون خادم متاحة بالفعل للاستخدام، وهي تعمل. قواعد البيانات التي لا تحتوي على خادم جاهزة بالفعل للتعامل مع مهام OLAP. لسوء الحظ، بالنسبة لمهام OLTP يتم استخدامها... مع الفروق الدقيقة، نظرًا لوجود قيود. من ناحية، هذا ناقص. ولكن، من ناحية أخرى، هذه فرصة. ربما يجد أحد القراء طريقة لجعل قاعدة بيانات OLTP بدون خادم تمامًا، دون قيود Aurora.
أتمنى أن تجدها مثيرة للاهتمام. بدون خادم هو المستقبل 🙂
المصدر: www.habr.com