Get best of the week

Google Cloud Spanner: جيد ، سيئ ، شرير

مرحباً ، هابروفسك. تقليديا ، نواصل تبادل المواد المثيرة للاهتمام تحسبا لإطلاق دورات جديدة. اليوم ، خصيصًا لك ، نشرنا مقالًا حول Google Cloud Spanner ، تم تحديده ليتزامن مع إطلاق دورة AWS للمطورين .



نشر في الأصل على مدونة Lightspeed HQ .

كشركة تقدم العديد من حلول نقاط البيع المستندة إلى السحابة لتجار التجزئة وأصحاب المطاعم وتجار التجزئة عبر الإنترنت في جميع أنحاء العالم ، تستخدم Lightspeed عدة أنواع مختلفة من منصات قواعد البيانات لمجموعة متنوعة من حالات المعاملات والتحليل والبحث. لكل من منصات قواعد البيانات هذه نقاط القوة والضعف الخاصة بها. وبالتالي ، عندما قدمت Google Cloud Spanner في السوق ، وميزات واعدة غير مسبوقة في عالم قواعد البيانات العلائقية ، مثل قابلية التوسع الأفقي غير المحدودة فعليًا واتفاقية مستوى الخدمة 99.999٪ (SLA) ، - لا يمكن أن نفوت فرصة الحصول عليها!

لإلقاء نظرة عامة شاملة على تجربتنا مع Cloud Spanner ، بالإضافة إلى معايير التقييم التي استخدمناها ، سنغطي الموضوعات التالية:

  1. معايير التقييم لدينا
  2. سحابة سبانر باختصار
  3. تصنيفنا
  4. النتائج التي توصلنا إليها



1. معايير التقييم لدينا


قبل الخوض في ميزات Cloud Spanner وأوجه الشبه والاختلاف مع الحلول الأخرى في السوق ، دعنا نتحدث أولاً عن حالات المستخدم الرئيسية التي كانت لدينا في الاعتبار عند التفكير في مكان نشر Cloud Spanner في بنيتنا التحتية:

  • كبديل لقاعدة بيانات SQL التقليدية (السائدة)
  • كيف حل OLTP مع دعم OLAP

ملاحظة: من أجل البساطة وسهولة المقارنة ، تقارن هذه المقالة Cloud Spanner مع MySQL GCP Cloud SQL وعائلة Amazon AWS RDS من الحلول.

استخدام Cloud Spanner كبديل لحل قاعدة بيانات SQL التقليدي


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

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

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

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

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

من ناحية أخرى ، نظرًا لطبيعتها ، يمكن لـ Cloud Spanner التوسع أفقياً بسهولة مع الحد الأدنى من التداخل. DBMS

كامل المواصفات كخدمةيجب تقييمها من زوايا مختلفة. كأساس ، أخذنا DBMS الأكثر شيوعًا في السحابة - لكل من Google و GCP Cloud SQL و Amazon و AWS RDS. في تقييمنا ، ركزنا على الفئات التالية:

  • تعيين الميزات: مدى SQL ، DDL ، DML ؛ مكتبات الاتصال / الموصلات ، ودعم المعاملات ، وما إلى ذلك.
  • دعم التنمية: سهولة التطوير والاختبار.
  • دعم الإدارة: إدارة المثيلات - على سبيل المثال ، رفع / خفض وترقية المثيلات ؛ اتفاقية مستوى الخدمة والنسخ الاحتياطي والاستعادة ؛ الأمن / التحكم في الوصول.

استخدام Cloud Spanner كـ OLTP مع دعم OLAP


على الرغم من أن Google لا تدعي صراحة أن Cloud Spanner مخصص للمعالجة التحليلية ، إلا أنها تشارك بعض السمات مع آليات أخرى ، مثل Apache Impala & Kudu و YugaByte ، والتي تم تصميمها لأحمال عمل OLAP.

حتى لو كانت هناك فرصة ضئيلة فقط أن يتضمن Cloud Spanner محرك HTAP (معالجة مختلطة للمعاملات / تحليلي) قابل للتوسيع أفقياً مع مجموعة قابلة للاستخدام (أكثر أو أقل) من ميزات OLAP ، نعتقد أنها تستحق اهتمامنا.

مع أخذ ذلك في الاعتبار ، قمنا بفحص الفئات التالية:

  • دعم تحميل البيانات والفهارس والتقسيم
  • أداء الاستعلام و DML

2. سحابة المفك باختصار


Google Spanner هو نظام إدارة قواعد بيانات علائقية للكتلة (RDBMS) تستخدمه Google للعديد من خدماتها الخاصة. جعلته Google متاحًا بشكل عام لمستخدمي Google Cloud Platform في أوائل عام 2017.

فيما يلي بعض سمات Cloud Spanner:

  • مجموعة RDBMS قابلة للتطوير عالية الاتساق: تستخدم مزامنة وقت الجهاز لضمان تناسق البيانات.
  • دعم المعاملات عبر الجداول: يمكن أن تمتد المعاملات إلى جداول متعددة - لا تقتصر بالضرورة على جدول واحد (على عكس Apache HBase أو Apache Kudu).
  • : (), . , . , .
  • : . . , , , -.
  • : Cloud Spanner . . . . , , , . , .

«Cloud Spanner . , Cloud Spanner , - , ».


: Apache Tephra Apache HBase ( Apache Phoenix -).

3.


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

قمنا بتصنيف Cloud Spanner كبديل لـ Sharded MySQL


تحتوي Google Cloud SQL و Amazon AWS RDS ، وهما من أكثر أنظمة إدارة قواعد البيانات OLTP شيوعًا في السوق السحابية ، على مجموعة ميزات كبيرة جدًا. ومع ذلك ، لتوسيع قواعد البيانات هذه بما يتجاوز حجم العقدة المفردة ، تحتاج إلى إجراء تقسيم التطبيق. يخلق هذا النهج تعقيدًا إضافيًا لكل من التطبيقات والإدارة. نظرنا في كيفية تناسب Spanner في سيناريو دمج عدة أجزاء في حالة واحدة وأي الميزات (إن وجدت) التي قد يتعين التضحية بها.

دعم SQL و DML و DDL ، وكذلك الموصلات والمكتبات؟


أولاً ، عند البدء بأي قاعدة بيانات ، يجب عليك إنشاء نموذج بيانات. إذا كنت تعتقد أنه يمكنك توصيل JDBC Spanner بأداة SQL المفضلة لديك ، فستجد أنه يمكنك الاستعلام عن بياناتك معه ، ولكن لا يمكنك استخدامه لإنشاء جدول أو تغيير (DDL) أو أي عمليات إدراج / تحديث / حذف ( DML). لا يدعم JDBC الرسمي من Google أيضًا.
"لا تدعم برامج التشغيل حاليًا DML أو DDL."
توثيق البراغي

مع وحدة تحكم GCP ، لا يعد الوضع أفضل - يمكنك إرسال استعلامات SELECT فقط. لحسن الحظ ، هناك مشغل JDBC مع دعم DML و DDL من المجتمع ، بما في ذلك المعاملات github.com/olavloite/spanner-jdbc . على الرغم من أن برنامج التشغيل هذا مفيد للغاية ، إلا أن الافتقار إلى محرك JDBC الخاص بـ Google يثير الدهشة. لحسن الحظ ، تقدم Google دعمًا واسعًا إلى حد ما لمكتبات العملاء (استنادًا إلى gRPC): C # و Go و Java و node.js و PHP و Python و Ruby.

يؤدي الاستخدام الإلزامي تقريبًا لواجهات مستخدم Cloud Spanner (بسبب نقص DDL و DML في JDBC) إلى بعض القيود على المجالات ذات الصلة من التعليمات البرمجية ، مثل تجمعات الاتصال أو أطر ربط قواعد البيانات (مثل Spring MVC). كقاعدة عامة ، عند استخدام JDBC ، يمكنك تحديد تجمع الاتصال المفضل لديك بحرية (على سبيل المثال ، HikariCP و DBCP و C3PO وما إلى ذلك) ، والذي يتم اختباره ويعمل بشكل جيد. في حالة Spanner APIs المخصصة ، يجب أن نعتمد على الأطر / مجموعات / جلسات الربط التي أنشأناها بأنفسنا.

يسمح تصميم المفتاح الأساسي (PC) لـ Cloud Spanner بأن يكون سريعًا جدًا عند الوصول إلى البيانات عبر جهاز الكمبيوتر ، ولكنه يؤدي أيضًا إلى بعض مشكلات الاستعلام.

  • ; . ( / .)
  • UPDATE DELETE WHERE, , DELETE all — , : UPDATE xxx WHERE id IN (SELECT id FROM table1)
  • - , . , .

?


يحتوي Google Cloud Spanner على دعم مضمن للفهارس الثانوية. هذه ميزة لطيفة جدًا ولا توجد دائمًا في التقنيات الأخرى. لا يدعم Apache Kudu حاليًا الفهارس الثانوية على الإطلاق ، ولا يدعم Apache HBase الفهارس مباشرة ، ولكن يمكنه إضافتها من خلال Apache Phoenix.

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

كما ذكر في مراجعة Cloud Spanner ، قد تختلف فهارسه عن فهارس MySQL. لذلك ، يجب توخي الحذر بشكل خاص عند بناء الاستعلامات والتنميط لضمان استخدام الفهرس المناسب عند الحاجة.

التمثيل؟


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

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

دعم التنمية؟


يقدم Cloud Spanner دعمًا لائقًا جدًا للغات البرمجة للعمل مع واجهة برمجة التطبيقات الخاصة بها. توجد المكتبات المدعومة رسميًا في مجالات C # و Go و Java و node.js و PHP و Python و Ruby. الوثائق مفصلة تمامًا ، ولكن ، كما هو الحال مع التقنيات المتقدمة الأخرى ، يكون المجتمع صغيرًا جدًا مقارنة بتقنيات قواعد البيانات الأكثر شيوعًا ، والتي يمكن أن تؤدي إلى زيادة الوقت المنقضي في حل حالات أو مشاكل الاستخدام الأقل شيوعًا.

فماذا عن دعم التنمية المحلية؟


لم نجد طريقة لإنشاء مثيل Cloud Spanner في البيئة المحلية. أقرب صورة حصلنا عليها هي صورة CockroachDB Docker ، وهي متشابهة من حيث المبدأ ، ولكنها في الواقع مختلفة تمامًا. على سبيل المثال ، قد يستخدم CockroachDB PostgreSQL JDBC. نظرًا لأن بيئة التطوير يجب أن تكون قريبة قدر الإمكان من بيئة العمل ، فإن Cloud Spanner ليست مثالية ، حيث تحتاج إلى الاعتماد على مثيل Spanner الكامل. لتوفير التكاليف ، يمكنك اختيار مثيل لمنطقة واحدة.

دعم الإدارة؟


من السهل إنشاء مثيل Cloud Spanner. تحتاج فقط إلى الاختيار بين إنشاء مثيل متعدد المناطق أو مثيل لمنطقة واحدة ، حدد المنطقة (المناطق) وعدد العقد. في أقل من دقيقة ، سيكون المثيل جاهزًا للعمل.

تتوفر العديد من المقاييس الأساسية مباشرة على صفحة Spanner في وحدة تحكم Google. تتوفر طرق عرض أكثر تفصيلاً من خلال Stackdriver ، حيث يمكنك أيضًا تعيين مقاييس العتبة وسياسات التنبيه.

الوصول إلى الموارد؟


يقدم MySQL إعدادات دور / أذونات مستخدم شاملة ومفصلة للغاية. يمكنك بسهولة تكوين الوصول إلى جدول معين ، أو حتى مجرد مجموعة فرعية من أعمدته. يستخدم Cloud Spanner أداة Google Identity & Access Management (IAM) ، والتي تسمح لك بتعيين السياسات والأذونات على مستوى عالٍ جدًا. الخيار الأكثر تفصيلاً هو الدقة على مستوى قاعدة البيانات التي لا تتناسب مع معظم حالات الإنتاج. يفرض عليك هذا التقييد إضافة إجراءات أمان إضافية إلى التعليمات البرمجية أو البنية الأساسية أو كليهما لمنع الاستخدام غير المصرح به لموارد Spanner.

النسخ الاحتياطية؟


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

أداء الاستعلام؟


استخدمنا Yahoo! لتنزيل البيانات واختبار الاستعلامات. معيار الخدمة السحابية. يوضح الجدول أدناه حجم عمل YCSB B بنسبة قراءة 95٪ ونسبة كتابة 5٪.



* تم إجراء اختبار الحمل على المحرك الحسابي n1-standard-32 (CE) (32 vCPU ، 120 جيجابايت من الذاكرة) ، ولم يكن مثيل الاختبار اختناقًا في الاختبارات.
** الحد الأقصى لعدد سلاسل العمليات في مثيل واحد من YCSB هو 400. في المجموع ، يجب تشغيل ست حالات متوازية من اختبارات YCSB للحصول على إجمالي 2400 سلسلة.

بالنظر إلى نتائج الاختبار ، ولا سيما الجمع بين حمل المعالج و TPS ، نرى بوضوح أن Cloud Spanner يتطور بشكل جيد. يتم تعويض الحمل الكبير الذي تم إنشاؤه بواسطة عدد كبير من الخيوط من خلال العدد الكبير من العقد في مجموعة Cloud Spanner. على الرغم من أن التأخير يبدو مرتفعًا إلى حد ما ، خاصة عند العمل مع 2400 سلسلة ، فقد يكون من الضروري إعادة الاختبار باستخدام 6 مثيلات أصغر من المحرك الحسابي للحصول على أرقام أكثر دقة. سيقوم كل مثيل بتشغيل اختبار YCSB واحد بدلاً من مثيل CE كبير واحد مع 6 اختبارات موازية. وبالتالي ، سيكون من الأسهل التمييز بين تأخيرات طلب Cloud Spanner والتأخيرات المضافة بواسطة اتصال الشبكة بين Cloud Spanner ومثيل CE الذي يتم تشغيل الاختبار عليه.

كيف يتعامل Cloud Spanner مع OLAP؟


التقسيم؟


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

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

تحميل البيانات؟


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

  • فرز البيانات حسب المفتاح الأساسي.
  • قسّمها على 10 * عدد عُقد الأقسام الفردية.
  • إنشاء مجموعة من مهام العمل التي تقوم بتحميل البيانات بالتوازي.

باستخدام تنزيل البيانات هذا ، يتم استخدام جميع عقد Cloud Spanner.

استخدمنا عبء العمل A YCSB لإنشاء مجموعة بيانات من 10M صف.



* تم إجراء اختبار الحمل على المحرك الحسابي n1-standard-32 (32 vCPU ، 120 جيجابايت من الذاكرة) ، ولم يكن مثيل الاختبار اختناقًا في الاختبارات.
** لا يُنصح بتكوين عقدة واحدة لأي حمل إنتاج.

كما ذكر أعلاه ، يقوم Cloud Spanner تلقائيًا بمعالجة التجزئة وفقًا لحملها ، لذلك تتحسن النتائج بعد عدة تكرار متتالية للاختبار. النتائج المعروضة هنا هي أفضل النتائج التي تلقيناها. بالنظر إلى الأرقام أعلاه ، يمكننا أن نرى كيف يتطور Cloud Spanner (جيدًا) مع زيادة في عدد العقد في المجموعة. الأرقام التي تبرز هي متوسط ​​تأخيرات منخفضة للغاية تتناقض مع نتائج أعباء العمل المختلطة (95 ٪ للقراءة و 5 ٪ للكتابة) ، كما هو موضح في القسم أعلاه.

تحجيم؟


إن زيادة وتقليل عدد عقد Cloud Spanner هي مهمة بنقرة واحدة. إذا كنت ترغب في تحميل البيانات بسرعة ، يمكنك التفكير في تعزيز المثيل إلى أقصى حد (في حالتنا ، كانت 25 عقدة في منطقة US-EAST) ، ثم تقليل عدد العقد المناسبة للتحميل العادي ، بعد كل البيانات في قاعدة البيانات مع مراعاة الحد من 2 TB / العقدة.

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



تمكنا من تقليل المقياس من 25 إلى حالتين ، لكننا علقنا في عقدتين.

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

أداء استعلام OLAP؟


في البداية ، خططنا لتخصيص وقت كبير لتقييمنا لـ Spanner لهذا الجزء. بعد عدة SELECT COUNTs ، أدركنا على الفور أن الاختبار سيكون قصيرًا وأن Spanner لن يكون محرك OLAP. بغض النظر عن عدد العقد في المجموعة ، استغرق التحديد البسيط لعدد الصفوف في جدول مكون من 10 ملايين صف 55 إلى 60 ثانية. بالإضافة إلى ذلك ، فشل أي طلب يتطلب المزيد من الذاكرة لتخزين النتائج الوسيطة مع وجود خطأ OOM.

SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.

يمكن العثور على بعض الأرقام لطلبات TPC-H في مقال Todd Lipcon Nosql-kudu-spanner-slides.html ، الشريحتين 42 و 43. هذه الأرقام تتوافق مع نتائجنا (للأسف).



4. النتائج التي توصلنا إليها


نظرًا للحالة الحالية لميزات Cloud Spanner ، من الصعب تخيلها كبديل بسيط لحل OLTP الحالي ، خاصة عندما تتجاوز احتياجاتك ذلك. يجب قضاء قدر كبير من الوقت في بناء حل يأخذ في الاعتبار عيوب Cloud Spanner.

عندما بدأنا في تقييم Cloud Spanner ، توقعنا أن تكون ميزات الإدارة الخاصة به على الأقل أو ليست بعيدة جدًا عن حلول Google SQL الأخرى. لكننا فوجئنا بالنقص الكامل للنسخ الاحتياطية والتحكم المحدود للغاية في الوصول إلى الموارد. ناهيك عن نقص وجهات النظر ، وعدم وجود بيئة تطوير محلية ، وتسلسلات غير مدعومة ، JDBC بدون دعم DML و DDL ، وما إلى ذلك.

إذن ، أين يذهب الشخص الذي يحتاج إلى توسيع قاعدة بيانات المعاملات؟ يبدو أنه لا يوجد حل واحد في السوق مناسب لجميع حالات الاستخدام. هناك العديد من الحلول المغلقة والمفتوحة المصدر (بعضها مذكور في هذه المقالة) ، لكل منها نقاط القوة والضعف الخاصة به ، ولكن لا يقدم أي منها SaaS مع SLA بنسبة 99.999٪ ودرجة عالية من الاتساق. إذا كان هدف اتفاقية مستوى الخدمة المرتفع هو هدفك الأساسي ولا تميل إلى إنشاء الحل الخاص بك لبيئات سحابية متعددة ، فقد يكون Cloud Spanner هو الحل الذي تبحث عنه. ولكن يجب أن تكون على دراية بكل قيودها.

في الإنصاف ، تجدر الإشارة إلى أن Cloud Spanner لم يتم إصداره للجمهور فقط في ربيع عام 2017 ، لذلك فمن المعقول توقع أن بعض أوجه القصور الحالية قد تختفي في نهاية المطاف (آمل) ، وعندما يحدث ذلك ، يمكن أن تغير اللعبة. بعد كل شيء ، Cloud Spanner ليس مجرد مشروع تابع لجهة خارجية لـ Google. تستخدمه Google كأساس لمنتجات Google الأخرى. وعندما استبدلت Google مؤخرًا Megastore في Google Cloud Storage بـ Cloud Spanner ، سمحت Google Cloud Storage بأن تكون متسقة بشكل صارم لقوائم الكائنات على مستوى العالم (والتي لا تزال لا تنطبق على Amazon S3 ).

لذا ، لا يزال هناك أمل ... نأمل.

هذا كل شئ. مثل مؤلف المقالة ، ما زلنا نأمل ، ولكن ما رأيك في هذا؟ اكتب في التعليقات:

الجميع مدعو لزيارة ندوتنا المجانية على الإنترنت ، وفي إطارها سنتحدث بالتفصيل عن دورة OTUS AWS للمطورين .

More articles:


All Articles