قاعدة البيانات في الغيوم: لمن ولماذا - رأي المتخصصين في بيانات البلشون

ويعتقد أن المستقبل هو ل DB كخدمة. هل يستحق كل هذا العناء للجميع إطلاق DBA والانتقال إلى السحابة العامة أو السعي لإنشاء سحابة خاصة على Docker مع Kubernetes؟ شارك ثلاثة خبراء من Data Egret - Alexei Lesovsky و Viktor Yegorov و Andrey Salnikov - على قناة #RuPostgres المباشرة وجهات نظرهم بشأن نوع المشاريع السحابية التي تناسبهم.

كان وسيط النقاش وسيط المناقشة نيكولاي ساموخفالوف ، مؤسس Postgres.ai والمؤسس المشارك لمجتمع RuPostgres.org.



تحت قص - نسخة من المحادثة.

- اليوم سنتحدث عن بوستجرس في الغيوم. وسأبدأ بسؤال صعب: هل صحيح أن لديك أكثر من نصف العملاء الموجودين بالفعل في السحب؟

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

ولكن قبل الحديث عن السحب ، دعونا نحدد المصطلحات. ماذا نعني بـ "السحب": Amazon ، Google Cloud ، DB كخدمة؟

- يمكنني التمييز بين Postgres في السحابة ، التي يتم إعدادها على مثيل Amazon EC2 (أو تناظرية من Google) ، حيث يمكنك ، بشكل تقريبي ، تسجيل الدخول عبر ssh وتصحيح التكوين ، و Postgres تحت السيطرة (باللغة الإنجليزية "مُدار") ، عند الوصول المباشر على مستوى الملف أو لا ssh ، ولكن هناك فقط القدرة على الاتصال وتنفيذ استعلامات SQL. ينبغي من حيث المبدأ النظر فيها بشكل منفصل. وسؤالي الأول كان حول Postgres المدارة.

أليكسي: هؤلاء العملاء أقل بكثير من النصف.

فيكتور: حسنًا ، في الحالة الأولى - ما هي المزايا المهمة التي لدينا من السحابة؟ ما هو معنى السحابة؟

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

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

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

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

الحمل العام لأنظمة المحاكاة الافتراضية المعتادة التي يمكن نشرها في المنزل (KVM ، Xen) ، قمت بقياسها منذ خمس سنوات ، ثم كانت حوالي 7-8٪. علاوة على ذلك ، يعتمد على إعدادات الجهاز الظاهري وعبء العمل. على سبيل المثال ، كان هناك قدر أكبر بكثير من النفقات العامة على Redis و Postgres مقارنة بـ Unicorn ، التي تخدم Rails backends.

ربما الآن الأرقام مختلفة.

- حتى 5-7 ٪ هو النفقات العامة مقبولة مقارنة بالإيجابيات التي تحدث عنها فيكتور.

وكيف يمكنك تغيير تكوين العملاء: هل هناك أي تحرك نحو القواعد المدارة؟



أليكسي: رقم الاتجاه هو العكس. يفتقر الأشخاص الذين يعملون مع أشياء مثل RDS إلى المرونة في الإدارة والإدارة. نتيجة لذلك ، نحصل على نفس الموقف "مثل الحيوانات الأليفة" ، ولكن في حالات EC2.

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

- هل تستخدم Amazon RDS لهذا الغرض؟

أليكسي: عملائنا ، على العكس من ذلك ، يرفضون RDS. السبب ، كما قلت ، هو عدم وجود مرونة في الإدارة.

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

لا يمكنك حل العديد من المشاكل بنفسك - فقط بمساعدة الدعم.

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

أليكسي: OpenSCG هو ، بالطبع ، فريق من المحترفين. لكن شراء مثل هذا الفريق لا يغلق 100 ٪ من الحالات المحتملة. هناك مشاكل تدعم الوجوه لأول مرة. هذا يحدث أيضا معنا.

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

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



أندرو: أود أن أضيف حول مقارنة حالات RDS و EC2.
كان لدينا عميل مع الإنتاج على RDS. طلب المشورة. يقع Dev-circuit في Microsoft Azure ، على ما يبدو ، كان Azure يعتبر في البداية الخدمة السحابية الرئيسية.

قمت بسحب قاعدة دارة التطوير من Azure إلى Amazon في EC2 لتقترب من الإنتاج ، وتقترب مشكلات التنبؤ من قاعدة بيانات المنتج.

على الرغم من أن خادم EC2 كان بسيطًا في مثيلات RDS ، وكان حمل الاختبار أعلى من المنتج ، إلا أنه في دائرة التطوير بعد الإعداد ، كانت النتائج أفضل بكثير من مثيله في Amazon على مثيل RDS الخاص بالإنتاج.

لدي شكوك أنه بسبب نقص خبرة PostgreSQL داخل شركة العميل ، تم استخدام RDS مع التكوين الافتراضي. نحن تحريف جميع الإعدادات.

نتيجة لذلك ، كان العميل معجبًا جدًا. التفت إلى الإدارة مع اقتراح بدلاً من RDS لاتخاذ وتكوين مثيلات بسيطة.

- بالمناسبة ، كيف تم قياسها ، أيهما أفضل ، أيهما أسوأ؟

أندرو: نظر العميل إلى مقاييس تطبيقه ، ومدى سرعة تنزيل البيانات ومعالجتها.

- نحن الآن ننتقد RDS ، لكن له مزايا هائلة - فهو يزيل الكثير من الصداع المرتبط بالنشر والنسخ الاحتياطي والتكرار. هل توافق

أندرو: نعم. وعلى الأرجح ، كان السبب الرئيسي وراء بقاء العميل في RDS هو بالتحديد نقص الخبرة في PostgreSQL. يحصلون على كل ما يحتاجونه مع RDS ، فهم يدفعون أكثر مقابل الحالات.

- بالإضافة إلى Amazon RDS ، هناك postgres المدارة المستندة إلى مجموعة النظراء. هل واجهتك ، على سبيل المثال ، خدمة ياندكس؟

أندريه: صادفت أجهزتهم الافتراضية ولم يعجبني حقًا - محركات NVMe ليست صادقة جدًا هناك. في الواقع ، هناك محركات متصلة عبر الشبكة.

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

أندريه: لقد علقوا علي في Yandex Cloud بأنهم صادقون في NVMe في DB كخدمة ، لكنني لم أواجه هذه الخدمة حتى الآن. على ما يبدو ، هناك بنية مختلفة قليلاً على مستوى توفير الموارد.

إنهم يعملون بجد على خدمة DB كخدمة ، حيث يستخدمونها في خدماتهم. هناك فقط نقاط دخول مختلفة للعملاء الخارجيين والاستخدام الداخلي.

- وما رأيك ، هل هناك أي احتمالات ل Postgres الروسية في السحابة؟ سوف تقلع أو لا تقلع؟

أندرو:

Yandex لديها فريق ممتاز ، من ذوي الخبرة ، مع خبرة جيدة. أعتقد أنهم سوف تقلع.

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

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

صحيح أن Yandex Cloud لا تزال في البداية ، ولا يتم تقديم الكثير من الوظائف في الوقت الحالي.

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



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

- وماذا تفعل ، هل هناك تأثير مماثل في منطقة الأمازون؟ هل هناك أي طرق لتحديد أنك "مضغوط"؟ pgbench لدفع؟

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

- أشعر أنك لا تحب حقا Postgres المدارة. هل يرجع ذلك إلى حقيقة أن RDS يأخذ عملك؟

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

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

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

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

- أنت تريد أن تقول أن تعريف الفهارس غير المستخدمة يعتمد على قطعة من الحديد؟ أو بعض الأشياء الأخرى الشائعة؟

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

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

- سؤال آخر من الجمهور: ماذا عن إعدادات النواة؟

فيكتور: في EC2 ، مثل هذه الأشياء قابلة للتخصيص.

- هناك حلول جديدة لفئة "Postgres المدارة" من موردين معروفين ، إلى جانب Amazon و Google المعتاد. على سبيل المثال ، أعلنت Nutanix و SAP في عام 2018 عن إنشاء حلول تستند إلى Postgres. ألا تعتقد أن كل هؤلاء الرجال يقودوننا إلى ظهور بعض القرارات التي من شأنها أن تفعل الشيء نفسه ، ولكن فقط على قطعة من الحديد الخاص بك؟ بحيث يمكنك النقر فوق الزر ونشر Postgres الجديدة ، حيث تم تكوين النسخ الاحتياطية والنسخ المتماثل بالفعل.

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

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

أليكسي: اتضح أنه لم تتم إدارته تمامًا.

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

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

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

Victor: لقد بدأنا في الحديث عن حقيقة أن لدينا طبقة إضافية من البنية التحتية التي يجب إدارتها - لتنظيم Kubernetes هذه.

لا أوافق على أنه سيعمل دائمًا بطريقة سحرية بنقرة زر واحدة بالطريقة التي نريدها. من الضروري الحفاظ على المتخصصين المعنيين.

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

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

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

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

من الأسهل كثيرًا الاتصال والرؤية مباشرة ، واختبار بعض فرضياتك والتصرف بها بشكل أكبر.

- هل لديك أي أمثلة نشطة من حيث يتم استخدام Kubernetes بالفعل وتعيش بوستجرس فيه؟

أليكسي: لسوء الحظ ، أنا لا. ولكن أود حقا أن. أنا حقا أحب Kubernetes ، أنا قريب من مفهومه وفلسفته.

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

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

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

, , . — , , . .

– , ?

: , . , . - , . , , Kubernetes. Kubernetes . CNCF . , .

– - kubernetes_ru. github, Kubernetes: . Postgres, .

, , , . , Kubernetes – , . - IT.

– , Amazon Aurora PostgreSQL Serverless ? , , . , . .. .

:

. .

, . , , . : , . , - . .

– . . , , .

: . , . , , – . , , , , .

أي . – , , 70% . . .

, , « », .

– . , , DBA : - , - — , ?

: , , , – DBA, SQL-developer. Oracle SQL-developer, , , , . , Oracle. . DBA , - .

DBA — - «» , .

Kubernetes. , . . , Kubernetes . , volume . أي , . , .

– ?

: .

, . , , . , Postgres ( ). Postgres - . أي (, ), .

, .

, , . . . .

– ?

: - . , , .

, Cassandra. . أي — , Kubernetes.

, , . , , .

أي . DBA, , – . , , - – .

– ?

: . , . , , , Kubernetes . , , , , - - Kubernetes ( ).

: Kubernetes. – patroni. Zalando Kubernetes. , , ( – , Amazon , ). , – . , – . – - Kubernetes.

– RDS. EC2 Postgres . patroni ( https://github.com/zalando/patroni ), .

: , , - high availability.

– . — , ?

: , - .
Zalando DBA, patroni. أي , Kubernetes , DBA .

– . DBA, DBA «» «».

: , . . , , .

– - Kubernetes? ?

: - , . Kubernetes – , . Kubernetes - . . DBA. Kubernetes (, Kubernetes , , ).

- , , - - -.

: ( Kubernetes ), - . , — — . - , , , , , , .

:

. Kubernetes , . , . .

, — . , Postgres- , , . .

: …

– .. : - — dev environment, production – Kubernetes. ...

: latency , , . .

– , . .
, HighLoad++ .

PS .