Google Cloud Spanner: خوب، بد و زشت

سلام، ساکنین خابروفسک. طبق معمول، پیش از شروع دوره های جدید، مطالب جالب را به اشتراک می گذاریم. امروز، به‌ویژه برای شما، همزمان با شروع دوره، مقاله‌ای درباره Google Cloud Spanner منتشر کرده‌ایم. "AWS برای توسعه دهندگان".

در ابتدا منتشر شد وبلاگ Lightspeed HQ.

Lightspeed به عنوان شرکتی که انواع راه‌حل‌های POS مبتنی بر ابر را به خرده‌فروشان، رستوران‌داران و فروشندگان آنلاین در سراسر جهان ارائه می‌کند، از چندین نوع مختلف از پلتفرم‌های پایگاه داده برای انواع موارد استفاده تراکنش، تحلیلی و جستجو استفاده می‌کند. هر یک از این پلتفرم‌های پایگاه داده نقاط قوت و ضعف خاص خود را دارند. از این رو، زمانی که Google Cloud Spanner را به بازار معرفی کرد - ویژگی‌های امیدوارکننده‌ای که در دنیای پایگاه‌های داده رابطه‌ای دیده نشده است، مانند مقیاس‌پذیری افقی تقریباً نامحدود و توافق‌نامه سطح خدمات 99,999٪ (SLA). - ما نمی‌توانستیم این فرصت را از دست بدهیم تا بتوانیم آن را در دست بگیریم!

برای ارائه یک نمای کلی از تجربه خود با Cloud Spanner و همچنین معیارهای ارزیابی که استفاده کردیم، موضوعات زیر را پوشش خواهیم داد:

1. معیارهای ارزیابی ما
2. Cloud Spanner به طور خلاصه
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 می‌تواند با افزودن خواننده‌های slave به صورت افقی برای عملیات خواندن مقیاس‌بندی کند، اما نمی‌تواند برای نوشتن مقیاس افقی انجام دهد.

از سوی دیگر، Cloud Spanner به دلیل ماهیت خود می تواند به راحتی با کمترین مداخله به صورت افقی مقیاس شود.

کاملا برجسته DBMS به عنوان یک سرویس باید از زوایای مختلف ارزیابی شود. به عنوان پایه، ما محبوب ترین DBMS در فضای ابری را انتخاب کردیم - برای Google، GCP Cloud SQL و برای آمازون، AWS RDS. در ارزیابی خود ما روی دسته بندی های زیر تمرکز کردیم:

• نگاشت ویژگی: وسعت SQL، DDL، DML. کتابخانه های اتصال / اتصال دهنده ها، پشتیبانی تراکنش ها و غیره.
• پشتیبانی توسعه: توسعه و آزمایش آسان.
• پشتیبانی مدیریت: مدیریت نمونه - به عنوان مثال، افزایش/کاهش مقیاس و ارتقاء نمونه ها. SLA، پشتیبان گیری و بازیابی؛ امنیت/کنترل دسترسی

استفاده از Cloud Spanner به عنوان یک راه حل OLTP با قابلیت OLAP

در حالی که گوگل به صراحت ادعا نمی کند که Cloud Spanner برای پردازش تحلیلی طراحی شده است، اما برخی ویژگی ها را با موتورهای دیگری مانند Apache Impala & Kudu و YugaByte که برای بارهای کاری OLAP طراحی شده اند، به اشتراک می گذارد.

حتی اگر شانس کمی وجود داشته باشد که Cloud Spanner یک موتور HTAP (پردازش تراکنش/تحلیل هیبریدی) با یک مجموعه ویژگی (کم و بیش) قابل استفاده (کم و بیش) قابل استفاده را شامل شود، ما فکر می کنیم که ارزش توجه ما را دارد.

با در نظر گرفتن این موضوع، دسته بندی های زیر را بررسی کردیم:

• بارگذاری داده ها، فهرست ها و پشتیبانی از پارتیشن بندی
• عملکرد پرس و جو و DML

2. Cloud Spanner به طور خلاصه

Google Spanner یک سیستم مدیریت پایگاه داده رابطه ای خوشه ای (RDBMS) است که گوگل برای چندین سرویس خود استفاده می کند. گوگل در اوایل سال 2017 آن را به طور کلی در دسترس کاربران پلتفرم Google Cloud قرار داد.

در اینجا برخی از ویژگی های Cloud Spanner آورده شده است:

• خوشه مقیاس پذیر RDBMS بسیار سازگار: از همگام سازی زمان سخت افزاری برای اطمینان از سازگاری داده ها استفاده می کند.
• پشتیبانی از تراکنش های متقاطع: تراکنش ها می توانند چندین جدول را دربر گیرند - لزوماً محدود به یک جدول نیست (برخلاف Apache HBase یا Apache Kudu).
• جداول مبتنی بر کلید اصلی: همه جداول باید دارای یک کلید اولیه اعلام شده (PC) باشند که می تواند از چندین ستون در جدول تشکیل شده باشد. داده‌های جدولی به ترتیب رایانه شخصی ذخیره می‌شوند و برای جستجوی رایانه شخصی بسیار کارآمد و سریع هستند. مانند سایر سیستم‌های مبتنی بر رایانه شخصی، پیاده‌سازی باید با موارد استفاده از پیش طراحی‌شده برای دستیابی به مدل‌سازی شود بهترین عملکرد.
• میزهای راه راه: جداول می توانند وابستگی فیزیکی به یکدیگر داشته باشند. ردیف‌های جدول فرزند را می‌توان با ردیف‌های جدول والد مطابقت داد. این رویکرد جستجوی روابطی را که می‌توان در طول فاز مدل‌سازی داده‌ها شناسایی کرد، مانند مکان‌یابی مشترک مشتریان و صورت‌حساب‌های آنها، سرعت می‌بخشد.
• شاخص ها: Cloud Spanner از نمایه های ثانویه پشتیبانی می کند. ایندکس از ستون های نمایه شده و تمام ستون های PC تشکیل شده است. در صورت تمایل، نمایه می تواند شامل سایر ستون های غیر نمایه شده نیز باشد. ایندکس را می توان با جدول والد برای سرعت بخشیدن به پرس و جوها در هم آمیخت. چندین محدودیت برای نمایه ها اعمال می شود، مانند حداکثر تعداد ستون های اضافی ذخیره شده در فهرست. همچنین، پرس و جو از طریق نمایه ها ممکن است مانند سایر RDBMS ها ساده نباشد.

«Cloud Spanner فقط در موارد نادر یک فهرست را به طور خودکار انتخاب می کند. به ویژه، Cloud Spanner به طور خودکار یک نمایه ثانویه را انتخاب نمی کند اگر پرس و جو ستون هایی را درخواست کند که در آن ذخیره نشده اند. فهرست مطالب '.

• توافقنامه سطح خدمات (SLA): استقرار در یک منطقه با SLA 99,99%؛ استقرار چند منطقه ای با 99,999٪ SLA. در حالی که SLA به خودی خود فقط یک توافق است و هیچ تضمینی ندارد، من معتقدم که افراد در گوگل داده های سختی برای ارائه چنین ادعایی قوی دارند. (برای مرجع، 99,999٪ به معنای 26,3 ثانیه در دسترس نبودن خدمات در ماه است.)
• بیشتر: https://cloud.google.com/spanner/

توجه: پروژه Apache Tephra پشتیبانی تراکنش های پیشرفته ای را به Apache HBase اضافه می کند (هم اکنون در Apache Phoenix به عنوان بتا اجرا شده است).

3. ارزیابی ما

بنابراین، همه ما ادعاهای گوگل را در مورد مزایای Cloud Spanner خوانده‌ایم - مقیاس افقی تقریباً نامحدود با حفظ ثبات بالا و SLA بسیار بالا. اگرچه در هر صورت تحقق این الزامات بسیار دشوار است، اما هدف ما رد آنها نبود. در عوض، بیایید روی چیزهای دیگری که اکثر کاربران پایگاه داده به آن اهمیت می دهند تمرکز کنیم: برابری و قابلیت استفاده.

ما Cloud Spanner را به عنوان جایگزینی برای MySQL Sharded ارزیابی کردیم

Google Cloud SQL و Amazon AWS RDS، دو تا از محبوب‌ترین DBMS‌های OLTP در بازار ابری، دارای مجموعه‌ای از ویژگی‌ها هستند. با این حال، برای مقیاس‌بندی این پایگاه‌های داده فراتر از اندازه یک گره، باید پارتیشن بندی برنامه را انجام دهید. این رویکرد پیچیدگی بیشتری هم برای برنامه ها و هم برای مدیریت ایجاد می کند. ما بررسی کردیم که چگونه Spanner در سناریوی ترکیب چند خرده در یک نمونه واحد قرار می‌گیرد و چه ویژگی‌هایی (در صورت وجود) ممکن است نیاز به قربانی کردن داشته باشند.

پشتیبانی از SQL، DML و DDL، و همچنین اتصال دهنده ها و کتابخانه ها؟

ابتدا، هنگام شروع با هر پایگاه داده، باید یک مدل داده ایجاد کنید. اگر فکر می کنید می توانید JDBC Spanner را به ابزار SQL مورد علاقه خود متصل کنید، متوجه خواهید شد که می توانید داده های خود را با آن پرس و جو کنید، اما نمی توانید از آن برای ایجاد جدول یا تغییر (DDL) یا هر درج/به روز رسانی/حذف استفاده کنید. عملیات (DML). JDBC رسمی گوگل از هیچ یک از اینها پشتیبانی نمی کند.

"درایورها در حال حاضر از بیانیه های DML یا DDL پشتیبانی نمی کنند."
مستندات آچار

وضعیت با کنسول GCP بهتر نیست - شما فقط می توانید پرس و جوهای SELECT را ارسال کنید. خوشبختانه یک درایور JDBC با پشتیبانی از DML و DDL از جامعه، از جمله تراکنش‌ها، وجود دارد github.com/olavloite/spanner-jdbc. در حالی که این درایور بسیار مفید است، فقدان درایور JDBC خود گوگل تعجب آور است. خوشبختانه، گوگل پشتیبانی نسبتاً گسترده ای را برای کتابخانه های مشتری (بر اساس gRPC) ارائه می دهد: C#، Go، Java، node.js، PHP، Python و Ruby.

استفاده تقریباً اجباری از APIهای سفارشی Cloud Spanner (به دلیل فقدان DDL و DML در JDBC) منجر به برخی محدودیت‌ها برای مناطق کد مرتبط مانند استخرهای اتصال یا چارچوب‌های اتصال پایگاه داده (مانند Spring MVC) می‌شود. به طور معمول، هنگام استفاده از JDBC، شما آزاد هستید که استخر اتصال مورد علاقه خود را انتخاب کنید (به عنوان مثال HikariCP، DBCP، C3PO، و غیره) که تست شده و به خوبی کار می کند. در مورد Spanner API های سفارشی، ما باید به چارچوب ها / استخرهای الزام آور / جلساتی که خودمان ایجاد کرده ایم تکیه کنیم.

طراحی محوری کلید اصلی (PC) به Cloud Spanner امکان می دهد هنگام دسترسی به داده ها از طریق رایانه شخصی بسیار سریع باشد، اما برخی از مسائل مربوط به پرس و جو را نیز معرفی می کند.

• شما نمی توانید مقدار کلید اصلی را به روز کنید. ابتدا باید ورودی را از رایانه اصلی حذف کنید و آن را با مقدار جدید دوباره وارد کنید. (این شبیه به سایر موتورهای پایگاه داده/ذخیره سازی کامپیوتر گرا است.)
• هر دستور UPDATE و DELETE باید PC را در WHERE مشخص کند، بنابراین نمی‌تواند خالی باشد DELETE همه عبارت‌ها - همیشه باید یک درخواست فرعی وجود داشته باشد، برای مثال: UPDATE xxx WHERE IN (انتخاب شناسه از جدول 1)
• عدم وجود گزینه افزایش خودکار یا هر چیز مشابهی که توالی فیلد PC را تعیین می کند. برای این کار، مقدار مربوطه باید در سمت برنامه ایجاد شود.

شاخص های ثانویه؟

Google Cloud Spanner از نمایه های ثانویه پشتیبانی داخلی دارد. این یک ویژگی بسیار خوب است که همیشه در سایر فناوری ها وجود ندارد. Apache Kudu در حال حاضر به هیچ وجه از نمایه های ثانویه پشتیبانی نمی کند و Apache HBase مستقیماً از ایندکس ها پشتیبانی نمی کند، اما می تواند آنها را از طریق Apache Phoenix اضافه کند.

ایندکس ها در Kudu و HBase را می توان به عنوان یک جدول جداگانه با ترکیب متفاوتی از کلیدهای اصلی مدل کرد، اما اتمی بودن عملیات انجام شده بر روی جدول والد و جداول شاخص مرتبط باید در سطح برنامه انجام شود و اجرای صحیح آن بی اهمیت نیست.

همانطور که در بررسی Cloud Spanner ذکر شد، نمایه های آن ممکن است با نمایه های MySQL متفاوت باشد. بنابراین، هنگام ساخت پرس‌و‌جوها و نمایه‌سازی باید دقت ویژه‌ای داشت تا اطمینان حاصل شود که شاخص مناسب در جایی که نیاز است استفاده می‌شود.

نمایندگی؟

یک شی بسیار محبوب و مفید در پایگاه داده views است. آنها می توانند برای تعداد زیادی از موارد استفاده مفید باشند. دو مورد علاقه من لایه انتزاعی منطقی و لایه امنیتی هستند. متأسفانه، Cloud Spanner از view ها پشتیبانی نمی کند. با این حال، این فقط تا حدی ما را محدود می کند زیرا هیچ جزئیاتی برای مجوزهای دسترسی در سطح ستون وجود ندارد که در آن نماها ممکن است راه حل مناسبی باشند.

به مستندات Cloud Spanner برای بخشی از جزئیات سهمیه ها و محدودیت ها مراجعه کنید (آچار/سهمیه)، به ویژه یکی وجود دارد که می تواند برای برخی از برنامه ها مشکل ساز باشد: Cloud Spanner خارج از جعبه دارای محدودیت حداکثر 100 پایگاه داده در هر نمونه است. بدیهی است که این می تواند یک گلوگاه بزرگ برای پایگاه داده ای باشد که به اندازه بیش از 100 پایگاه داده طراحی شده است. خوشبختانه، پس از صحبت با نماینده فنی گوگل، متوجه شدیم که این محدودیت تقریباً به هر مقداری از طریق پشتیبانی Google قابل افزایش است.

پشتیبانی توسعه؟

Cloud Spanner برای کار با API خود از زبان برنامه نویسی بسیار مناسب پشتیبانی می کند. کتابخانه های رسمی پشتیبانی شده در زمینه های C#، Go، Java، node.js، PHP، Python و Ruby هستند. مستندات کاملاً دقیق هستند، اما مانند سایر فناوری‌های پیشرفته، جامعه در مقایسه با محبوب‌ترین فناوری‌های پایگاه داده بسیار کوچک است، که می‌تواند منجر به صرف زمان بیشتر برای حل موارد یا مشکلات کمتر رایج شود.

پس حمایت از توسعه محلی چطور؟

ما راهی برای ایجاد یک نمونه Cloud Spanner در محل پیدا نکرده‌ایم. نزدیک ترین چیزی که به آن رسیدیم یک تصویر داکر بود. سوسک، که در اصل مشابه است، اما در عمل بسیار متفاوت است. به عنوان مثال، CockroachDB می تواند از PostgreSQL JDBC استفاده کند. از آنجایی که محیط توسعه باید تا حد امکان به محیط تولید نزدیک باشد، Cloud Spanner ایده آل نیست زیرا باید بر یک نمونه کامل Spanner تکیه کند. برای صرفه جویی در هزینه ها، می توانید یک نمونه تک منطقه ای را انتخاب کنید.

پشتیبانی اداره؟

ایجاد یک نمونه Cloud Spanner بسیار ساده است. شما فقط باید بین ایجاد یک نمونه چند منطقه ای یا تک منطقه ای یکی را انتخاب کنید، منطقه(ها) و تعداد گره ها را مشخص کنید. در کمتر از یک دقیقه، نمونه شما راه اندازی می شود.

چندین معیار ابتدایی مستقیماً از صفحه Spanner در Google Console قابل دسترسی هستند. نماهای دقیق تر از طریق Stackdriver در دسترس هستند، جایی که می توانید آستانه های متریک و خط مشی های هشدار را نیز تنظیم کنید.

دسترسی به منابع؟

MySQL تنظیمات گسترده و بسیار دقیقی را برای مجوزها/نقش های کاربر ارائه می دهد. شما به راحتی می توانید دسترسی به یک جدول خاص یا حتی زیر مجموعه ای از ستون های آن را پیکربندی کنید. Cloud Spanner از ابزار Google's Identity & Access Management (IAM) استفاده می کند که فقط به شما امکان می دهد خط مشی ها و مجوزها را در سطح بسیار بالایی تنظیم کنید. گرانول ترین گزینه رزولوشن در سطح پایگاه داده است که در اکثر موارد استفاده تولیدی نمی گنجد. این محدودیت شما را مجبور می کند تا اقدامات امنیتی بیشتری را به کد، زیرساخت یا هر دو اضافه کنید تا از استفاده غیرمجاز از منابع Spanner جلوگیری کنید.

پشتیبان گیری؟

به بیان ساده، هیچ نسخه پشتیبان در Cloud Spanner وجود ندارد. اگرچه الزامات بالای SLA Google می تواند تضمین کند که شما هیچ داده ای را به دلیل خرابی سخت افزار یا پایگاه داده، خطاهای انسانی، نقص برنامه و غیره از دست نمی دهید. همه ما این قانون را می دانیم: در دسترس بودن بالا جایگزین استراتژی پشتیبان گیری صدا نیست. در حال حاضر، تنها راه پشتیبان‌گیری از داده‌ها، پخش برنامه‌ای آن‌ها از یک پایگاه داده به یک محیط ذخیره‌سازی جداگانه است.

عملکرد پرس و جو؟

ما از یاهو برای بارگیری داده ها و آزمایش کوئری ها استفاده کردیم. معیار سرویس ابری جدول زیر حجم کاری YCSB B را با نسبت خواندن 95% به 5% نوشتن نشان می دهد.

* تست بار روی موتور محاسباتی n1-استاندارد-32 (CE) (32 vCPU، 120 گیگابایت حافظه) اجرا شد و نمونه آزمایش هرگز گلوگاهی در آزمایش ها نبود.
** حداکثر تعداد رشته‌ها در یک نمونه YCSB 400 است. در مجموع شش نمونه موازی از آزمون‌های YCSB باید اجرا می‌شد تا در مجموع 2400 رشته به دست آید.

با نگاهی به نتایج معیار، به‌ویژه ترکیب بار CPU و TPS، به وضوح می‌توانیم متوجه شویم که Cloud Spanner بسیار خوب مقیاس می‌شود. بار سنگین ایجاد شده توسط تعداد زیاد نخ ها با تعداد زیاد گره ها در خوشه Cloud Spanner جبران می شود. در حالی که تأخیر بسیار زیاد به نظر می رسد، به خصوص در هنگام اجرا با 2400 رشته، آزمایش مجدد با 6 نمونه کوچکتر از موتور محاسباتی ممکن است برای بدست آوردن اعداد دقیق تر لازم باشد. هر نمونه یک تست YCSB را به جای یک نمونه CE بزرگ با 6 تست موازی اجرا می کند. به این ترتیب، تشخیص تأخیر درخواست Cloud Spanner و تأخیر اضافه شده توسط اتصال شبکه بین Cloud Spanner و نمونه CE که آزمایش را انجام می دهد آسان تر خواهد بود.

Cloud Spanner به عنوان یک OLAP چگونه عمل می کند؟

پارتیشن بندی؟

تقسیم داده‌ها به بخش‌های مستقل از لحاظ فیزیکی و/یا منطقی، به نام پارتیشن، یک مفهوم بسیار محبوب است که در اکثر موتورهای OLAP یافت می‌شود. پارتیشن ها می توانند به طور قابل توجهی عملکرد پرس و جو و قابلیت نگهداری پایگاه داده را بهبود بخشند. عمیق‌تر رفتن به پارتیشن‌بندی یک مقاله جداگانه خواهد بود، بنابراین بیایید فقط به اهمیت داشتن یک طرح پارتیشن‌بندی و تقسیم‌بندی فرعی اشاره کنیم. توانایی تجزیه داده ها به پارتیشن ها و حتی بیشتر به پارتیشن های فرعی کلید عملکرد پرس و جوی تحلیلی است.

Cloud Spanner از پارتیشن‌ها پشتیبانی نمی‌کند. این داده ها را در داخل به اصطلاح تقسیم می کند انشعاب-ها بر اساس محدوده کلید اولیه. پارتیشن بندی به طور خودکار برای متعادل کردن بار در یک Cloud Spanner Cluster انجام می شود. یکی از ویژگی های بسیار مفید Cloud Spanner تقسیم بار پایه جدول والد است (جدولی که با جدول دیگری در هم آمیخته نیست). آچار به طور خودکار تشخیص می دهد که آیا حاوی آن است یا خیر انشعاب داده هایی که بیشتر از داده های دیگر خوانده می شوند انشعاب-ah، و ممکن است در مورد جدایی بیشتر تصمیم بگیرد. به این ترتیب، گره های بیشتری را می توان در یک درخواست درگیر کرد، که همچنین به طور موثری توان عملیاتی را افزایش می دهد.

در حال بارگیری داده ها؟

روش Cloud Spanner برای داده های انبوه مانند بارگذاری معمولی است. برای دستیابی به حداکثر عملکرد، باید برخی از دستورالعمل ها را دنبال کنید، از جمله:

• داده های خود را بر اساس کلید اصلی مرتب کنید.
• آنها را بر 10 تقسیم کنید*تعداد گره ها بخش های جداگانه
• مجموعه ای از وظایف کاری ایجاد کنید که داده ها را به صورت موازی بارگذاری می کند.

این بارگیری داده از تمام گره های Cloud Spanner استفاده می کند.

ما از بار کاری YCSB A برای تولید مجموعه داده ای از 10 میلیون ردیف استفاده کردیم.

* تست بار روی موتور محاسباتی n1-standard-32 (32 vCPU، 120 گیگابایت حافظه) اجرا شد و نمونه آزمایش هرگز در آزمایش‌ها گلوگاه نبود.
** راه اندازی تک گره برای هر حجم کاری تولیدی توصیه نمی شود.

همانطور که در بالا ذکر شد، Cloud Spanner به طور خودکار تقسیم ها را بر اساس بار آنها پردازش می کند، بنابراین نتایج پس از چندین تکرار متوالی تست بهبود می یابد. نتایج ارائه شده در اینجا بهترین نتایجی است که به دست آوردیم. با نگاهی به اعداد بالا، می‌توانیم ببینیم که چگونه Cloud Spanner با افزایش تعداد گره‌ها در خوشه مقیاس می‌شود (به خوبی). اعداد برجسته، تأخیرهای متوسط ​​بسیار پایین است که با نتایج مربوط به بارهای کاری ترکیبی (95% خواندن و 5% نوشتن) همانطور که در بخش بالا توضیح داده شد، در تضاد است.

مقیاس بندی؟

افزایش و کاهش تعداد گره های Cloud Spanner یک کار با یک کلیک است. اگر می‌خواهید داده‌ها را سریع بارگیری کنید، ممکن است نمونه خود را به حداکثر افزایش دهید (در مورد ما 25 گره در منطقه US-EAST بود) و سپس تعداد گره‌های واجد شرایط برای بارگذاری معمولی خود را پس از وارد شدن تمام داده‌ها کاهش دهید. پایگاه داده، با اشاره به محدودیت 2 ترابایت/گره.

حتی با یک پایگاه داده بسیار کوچکتر این محدودیت را به ما یادآوری شد. پس از چندین بار آزمایش بارگذاری، پایگاه داده ما حدود 155 گیگابایت حجم داشت و هنگامی که به نمونه 1 گره کوچک شد، خطای زیر را دریافت کردیم:

ما توانستیم از 25 به 2 مورد کاهش دهیم، اما در دو گره گیر کردیم.

افزایش و کاهش تعداد گره ها در یک کلاستر Cloud Spanner را می توان با استفاده از REST API خودکار کرد. این می تواند به ویژه برای کاهش بار سیستم در ساعات شلوغ کاری مفید باشد.

عملکرد پرس و جوهای OLAP؟

ما در ابتدا برنامه ریزی کردیم که زمان قابل توجهی را برای ارزیابی خود از Spanner در این بخش صرف کنیم. پس از چندین SELECT COUNT، بلافاصله متوجه شدیم که آزمایش کوتاه خواهد بود و Spanner موتور مناسبی برای OLAP نخواهد بود. صرف نظر از تعداد گره ها در خوشه، انتخاب ساده تعداد ردیف ها در جدول ردیف 10M بین 55 تا 60 ثانیه طول کشید. علاوه بر این، هر درخواستی که برای ذخیره نتایج میانی به حافظه بیشتری نیاز داشت با خطای OOM ناموفق بود.

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

برخی از اعداد برای پرس و جوهای TPC-H را می توان در مقاله تاد لیپکن یافت Nosql-kudu-spanner-slides.html، اسلایدهای 42 و 43. این اعداد با نتایج خود ما مطابقت دارند (متاسفانه).

4. نتیجه گیری ما

با توجه به وضعیت فعلی ویژگی‌های Cloud Spanner، تصور اینکه جایگزینی ساده برای راه‌حل OLTP موجود شما باشد، دشوار است، به خصوص زمانی که نیازهای شما بیشتر از آن باشد. زمان قابل توجهی باید برای ایجاد راه حلی در مورد کاستی های Cloud Spanner صرف شود.

وقتی شروع به ارزیابی Cloud Spanner کردیم، انتظار داشتیم ویژگی‌های مدیریتی آن با سایر راه‌حل‌های Google SQL همتراز باشد، یا حداقل خیلی دور از آن نباشد. اما ما از کمبود کامل پشتیبان گیری و کنترل بسیار محدود بر دسترسی به منابع شگفت زده شدیم. ناگفته نماند بدون نما، محیط توسعه محلی، توالی های پشتیبانی نشده، JDBC بدون پشتیبانی از DML و DDL و غیره.

پس کسی که نیاز به مقیاس‌بندی پایگاه داده تراکنشی دارد کجا می‌رود؟ به نظر نمی رسد راه حل واحدی در بازار وجود داشته باشد که مناسب همه موارد استفاده باشد. راه حل های متن باز و بسته زیادی وجود دارد (که در این مقاله به برخی از آنها اشاره شده است) که هر کدام نقاط قوت و ضعف خاص خود را دارند، اما هیچ یک از آنها SaaS را با SLA 99,999% و سازگاری بالا ارائه نمی دهند. اگر SLA بالا هدف اصلی شماست و تمایلی به ساخت یک راه حل سفارشی چند ابری ندارید، Cloud Spanner ممکن است راه حلی باشد که به دنبال آن هستید. اما باید از تمام محدودیت های آن آگاه باشید.

اگر منصف باشیم، Cloud Spanner تنها در بهار 2017 برای عموم منتشر شد، بنابراین منطقی است که انتظار داشته باشیم برخی از کاستی های فعلی آن در نهایت برطرف شوند (امیدوارم)، و زمانی که این کار را انجام دهند، می تواند یک تغییر دهنده بازی باشد. به هر حال، Cloud Spanner فقط یک پروژه جانبی برای گوگل نیست. گوگل از آن به عنوان پایه ای برای سایر محصولات گوگل استفاده می کند. و هنگامی که Google اخیراً Megastore را در Google Cloud Storage با Cloud Spanner جایگزین کرد، به Google Cloud Storage اجازه داد تا برای فهرست‌های اشیاء در مقیاس جهانی بسیار سازگار باشد (که هنوز برای آن صدق نمی‌کند. آمازون S3).

پس هنوز امیدی هست... امیدواریم.

همین. ما نیز مانند نویسنده مقاله امیدواریم، اما نظر شما در مورد این چیست؟ در نظرات بنویسید

از همه دعوت می کنیم از ما دیدن کنند وبینار رایگان که در آن ما با جزئیات در مورد دوره به شما خواهیم گفت "AWS برای توسعه دهندگان" از OTUS

منبع: www.habr.com