بررسی: YugabyteDB به PostgreSQL افتخار می کند

YugabyteDB 2.13 یک نسخه بسیار مقیاس پذیر و توزیع شده از PostgreSQL است که ایده های قانع کننده ای از Google Cloud Spanner و Amazon Aurora را ترکیب می کند و به عنوان یک پایگاه داده سازگار با Cassandra نیز عمل می کند.

وقتی YugaByteDB 1.0 را در سال ۲۰۱۸ بررسی کردم، تراکنش‌های ACID توزیع شده، استقرار چند منطقه‌ای و پشتیبانی از Cassandra و Redis API را ترکیب کرد. در آن زمان، پشتیبانی PostgreSQL “در راه بود”، به معنای ناقص و به سختی آزمایش شده بود. به سرعت به ماه می ۲۰۲۲ بروید و قطار Postgres به ایستگاه راه پیدا کرد.

YugaByteDB 1.0 در بالای یک فورک پیشرفته از فروشگاه ارزش کلید RocksDB ساخته شده است. از یک موتور ذخیره‌سازی کلید به سند با ساختار log استفاده می‌کرد، یک لایه API قابل اتصال داشت، از Raft برای اجماع خوشه‌ای استفاده می‌کرد، و از مهرهای زمانی ساعت منطقی ترکیبی (HLC) و همگام‌سازی ساعت پروتکل زمان شبکه (NTP) برای همگام‌سازی زمان گره استفاده می‌کرد. فقط عملکرد اصلی YugaByteDB 1.0 منبع باز بود. من یک نسخه سازمانی را بررسی کردم که شامل قطعات اختصاصی، مانند لایه ارکستراسیون YugaWare بود.

در حال حاضر، در YugabyteDB 2.13، پشتیبانی PostgreSQL کاملاً پیشرفته است (اما به طور کامل انجام نشده است). این محصول اکنون کاملاًمنبع باز (Apache 2.0) است، اگرچه شرکت ها می توانند (و انجام می دهند) یک قرارداد پشتیبانی برای پلتفرم Yugabyte مبتنی بر Kubernetes بخرند، و هر کسی می تواند خوشه های پولی را در Yugabyte Cloud ایجاد کند که اجرا می شوند. در خدمات وب آمازون (AWS) یا Google Cloud Platform (GCP). هرکسی همچنین می‌تواند یک «خوشه» یک گره دو CPU رایگان در Yugabyte Cloud برای اهداف اکتشافی ایجاد کند. در این مرحله بیش از یک میلیون خوشه YugabyteDB مستقر شده است.

YugabyteDB مستقیماً با سایر پایگاه‌های داده تراکنشی SQL توزیع‌شده، مانند Google Cloud Spanner، Amazon رقابت می‌کند. شفق قطبی و CockroachDB. همچنین تا حدی کمتر با پایگاه‌های داده تراکنشی سنتی مانند Oracle Database، SQL Server و IBM DB2 رقابت می‌کند، زیرا افراد بارگذاری پایگاه داده خود را به ابر منتقل می‌کنند و معماری برنامه‌های کاربردی خود را به میکروسرویس‌ها تغییر می‌دهند.

معماری YugabyteDB

سال بعد از اینکه بررسی خود را در مورد YugabyteDB 1.0 نوشتم، Karthik Ranganathan، یکی از بنیانگذاران و CTO Yugabyte، مجموعه ای از مقالات فنی در مورد سفر این شرکت به سمت پیاده سازی نسخه توزیع شده PostgreSQL نوشت. یکی از جالب ترین آنها “۶ چالش فنی ایجاد پایگاه داده SQL توزیع شده.”

به طور خلاصه، تیم مهندسی Yugabyte به Google Cloud Spanner و Amazon Aurora نگاه کردند و به این نتیجه رسیدند که می‌خواهند یک رویکرد ترکیبی اتخاذ کنند و مقیاس‌پذیری افقی و توزیع جغرافیایی Spanner و لایه جستجوی سازگاری PostgreSQL Amazon Aurora را تقلید کنند. . آنها سازگاری PostgreSQL و نه MySQL را انتخاب کردند، تا حدی به دلیل محبوبیت روزافزون PostgreSQL و تا حدی به این دلیل که PostgreSQL مجوز مجاز تری دارد. (و بله، این واقعیت که Oracle مالک MySQL است، وارد محاسبات شد.)

Yugabyte الگوریتم اجماع خوشه Raft را به جای Paxos انتخاب کرد، با مکانیزم اجاره رهبر که به پایگاه داده اجازه می دهد از رهبر رایانه لوحی بدون نیاز به رفت و برگشت استفاده کند، و یک ساعت یکنواخت را به جای ساعت بیدرنگ انتخاب کرد. (Spanner از TrueTime استفاده می‌کند که به ساعت‌های اتمی و GPS نیاز دارد.) Yugabyte تصمیم گرفت از ساعت‌های منطقی ترکیبی (HLC) استفاده کند، که مشکل همگام‌سازی را با ترکیب ساعت‌های فیزیکی که با استفاده از NTP با ساعت‌های Lamport که روابط علی را دنبال می‌کنند، حل می‌کند. p>

Yugabyte در ابتدا سعی کرد PostgreSQL API را بازنویسی کند. پس از پنج ماه آنها از آن صرف نظر کردند و از کد لایه پرس و جو PostgreSQL دوباره استفاده کردند. این مشکلات خاص خود را داشت، اما شرکت در نهایت به آن رسید.

YugabyteDB از دو لایه منطقی تشکیل شده است که هر یک از آنها یک سرویس توزیع شده است که بر روی چندین گره (یا pods در مورد Kubernetes) اجرا می شود. Yugabyte Query Layer (YQL) لایه بالایی YugabyteDB را تشکیل می دهد که برنامه ها با استفاده از درایورهای مشتری با آن تعامل دارند.

DocDB، یک فروشگاه اسناد توزیع شده، با کارایی بالا و الهام گرفته از Google Spanner، به عنوان لایه پایین عمل می کند. در اینجا جداول کاربر به طور ضمنی به عنوان چند قطعه مدیریت می شوند که تبلت نامیده می شود. این معماری چهار مزیت را به همراه دارد: اشتراک گذاری شفاف جداول، تکرار داده های خرد، تراکنش های بین خرده ها (معروف به تراکنش های توزیع شده)، و ماندگاری ردیف ها مبتنی بر سند. جزئیات نحوه عملکرد این روش برای موارد مختلف در این مقاله (لایه ذخیره سازی YugabyteDB).

Yugabyte SQL (YSQL) همانطور که در نمودار زیر نشان داده شده است در بالای DocDB قرار دارد. جزئیات چشمگیر نحوه عملکرد این روش در مقاله دوم (لایه جستجوی YugabyteDB). کافی است بگوییم که تلاش قابل توجهی برای پیاده سازی مدیریت کاتالوگ سیستم، مدیریت جدول کاربر، مسیر خواندن و نوشتن IO و نگاشت جداول SQL به یک فروشگاه اسناد انجام شده است.

لایه YSQL YugabyteDB یک پارتیشن بندی غیر ضروری از لایه پرس و جو PostgreSQL است که برای مقیاس پذیری و انعطاف پذیری و همچنین سازگاری طراحی شده است.

چیزهای جدید در YugabyteDB 2.13

خلاصه کوتاهی از پیشرفت‌ها در YugabyteDB 2.13 این است که عملکرد پایگاه داده بهبود یافته، تجربه توسعه‌دهنده بهتر و امنیت و انطباق گسترده را ارائه می‌دهد. این مناطق به یک دسته از پیشرفت‌های مجزا تقسیم می‌شوند.

1. نماهای مادی یک مجموعه داده از پیش محاسبه‌شده را ایجاد و ذخیره می‌کنند که از مشخصات پرس‌وجو به‌منظور کاهش زمان‌های پرس‌وجو در آینده با کاهش دسترسی به داده‌ها و محاسبات پرس و جو پیچیده می‌شود.
2. با حفظ ابرداده مربوط به تراکنش‌ها در همان منطقه، YugabyteDB تأخیر بین شبکه‌ای را حذف می‌کند و عملکرد تراکنش‌های محلی را بهبود می‌بخشد.
3. اپراتورها می‌توانند اطمینان حاصل کنند که پشتیبان‌گیری از داده‌ها در همان مناطق ابری باقی می‌ماند تا هزینه‌های انتقال داده‌های ذخیره‌سازی ابری کاهش یابد و به سازمان‌ها کمک شود تا از مقررات پیچیده داده‌ها، مانند GDPR پیروی کنند.
4. YugabyteDB Cloud Shell به توسعه دهندگان اجازه می دهد با استفاده از هر مرورگر مدرن به YugabyteDB متصل شوند. (من از این به شدت در آزمایشم استفاده کردم.)
5. پشتیبانی از ابزارهای MyBatis و Dapper ORM.
6. توسعه‌دهندگان به گردش‌های کاری توسعه کاملاً خودکار، یکپارچه و بومی ابری دسترسی دارند که می‌توانند با YugabyteDB با استفاده از محیط‌های توسعه‌دهنده مبتنی بر ابر، Gitpod و Codespaces GitHub از پیش پیکربندی شوند.
7. اعتبارنامه امنیتی نوع ۱ SOC 2.
8. مدیریت کلید با HashiCorp Vault.
9. نظارت با Imperva Cloud Data Protection.

بهبودهای بیشتری در اینجا فهرست شده است و اینجا.

تست یوگا بایت TPC-C و Jepsen

در فوریه ۲۰۲۲، Yugabyte یک اجرا کرد معیار پردازش تراکنش موفق TPC-C با ۱۰۰۰۰۰ انبار، با استفاده از خوشه ای از ۶۳ نمونه هر c5d.12xlarge (48 vCPU، ۹۶ گیگابایت رم). خروجی ۶۳۰ هزار عملیات در ثانیه با تأخیر سمت مشتری برای سفارش‌های جدید ~۵۴ میلی‌ثانیه بود. این یک نمایش چشمگیر از بزرگ شدن است. اما برای مقایسه، CockroachDB می تواند ۱.۶۸ میلیون tpmC را با ۱۴۰۰۰۰ انبار پردازش کند< /a>، با استفاده از یک خوشه از ۸۱ گره هر کدام c5d.9xlarge (36 vCPU، ۷۲ گیگابایت RAM)، که حتی چشمگیرتر است.

Yugabyte همچنین آزمایش Jepsen را انجام داده است. کایل کینگزبری، مغز پشت آزمایش‌های جپسن، به‌طور بدنامی در مورد نتایج خود دلسرد است. در سال ۲۰۱۹ Yugabyte پست کرد که “YSQL تست های رسمی Jepsen را نسبتاً آسان گذراند.” کایل در توییتر پاسخ داد که نه، این کار را نکرده است : در تغییرات طرحواره غیرمعامله مسائل حل نشده وجود داشت. پست وبلاگ مربوط به انتشار YugabyteDB 2.0 در اواخر همان سال دارای ویرایشی است که مشکل را تصدیق می کند و مشکل در YugabyteDB 2.1.3 در ماه مه ۲۰۲۰ حل شد. بنابراین در این مرحله به نظر می رسد که YugabyteDB در واقع دارای گواهی Jepsen است.

ایجاد یک خوشه ابر Yugabyte

سه گزینه استقرار اساسی برای YugabyteDB وجود دارد که در مستندات به عنوان Yugabyte Core (متن باز؛ نصب از tarball، نمودار Helm، یا تصویر Docker)، Yugabyte Anywhere (اشتراک، مبتنی بر Kubernetes) و Yugabyte Managed ( ابر). این سه گزینه اینجا مقایسه شده‌اند.

من روی Yugabyte Managed تمرکز کردم، زیرا تمام ویژگی‌ها را دارد و به حداقل تنظیمات نیاز دارد. من در ابتدا یک “خوشه” همیشه رایگان و یک گره ایجاد کردم، با توجه به اجرای یک آموزش در پوسته ابری جدید YugabyteDB.

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

ایجاد یک خوشه YugabyteDB رایگان برای همیشه. این خوشه دارای یک گره با دو vCPU، چهار گیگابایت رم و ۱۰ گیگابایت فضای دیسک است.

ایجاد یک خوشه سه گره پولی در Yugabyte Cloud. همه گزینه‌ها برای سلف‌سرویس برای کاربر باز هستند، با این تفاوت که اگر می‌خواهید یک خوشه چند منطقه‌ای داشته باشید، باید یک بلیط ارسال کنید و VPC‌ها را در همه مناطق درخواستی داشته باشید. شما می توانید از میان انتشار پایدار یا انتشار لبه تحت تنظیمات پیشرفته انتخاب کنید. اگر می خواهید از نسخه لبه در تولید استفاده کنید، باید برای تایید با پشتیبانی تماس بگیرید. vCPUهای من در هر گره به ۱۶ یا کمتر محدود شده است. من تصور می کنم که فعال کردن گره های بزرگتر نیاز به یک درخواست پشتیبانی دارد. قیمت ها در GCP و AWS و در همه مناطق یکسان است. تحمل خطا قیمت را سه برابر می کند.

تمرین SQL Yugabyte

به‌جز یک استثنای کوچک که یک هشدار بتا ایجاد کرد، همه چیز در خط فرمان آموزش Yugabyte SQL فقط کار کرد. این شامل یک شاخص GIN (شاخص معکوس عمومی) برای دسترسی سریع به عناصر داخل یک JSONB یا فیلد متنی است. وقتی متوجه شدم که Yugabyte هنوز از فهرست‌های GiST (درخت جستجوی تعمیم‌یافته) پشتیبانی نمی‌کند، ناامید شدم.

ایجاد دو جدول با PostgreSQL DDL تقریباً استاندارد. جداول شامل برخی از محدودیت‌های نسبتاً پیچیده است، از جمله کلیدهای خارجی و یک محدودیت چک با یک عبارت منظم. به استفاده از شاخص‌های هش برای داده‌های نامرتب، و همچنین شاخص‌های صعودی و نزولی معمولی توجه کنید.

درج داده ها در جداول جدید. به استفاده از مقادیر “skills” در قسمت other_info JSONB در جدول emp توجه کنید. بعداً نشان خواهیم داد که از یک شاخص GIN برای پرس و جو کردن آنها استفاده می کنیم.

این عبارت SELECT از یک خود پیوستن برای یافتن همه کارمندانی که حقوق بالاتری نسبت به مدیران خود دارند استفاده می‌کند.

این یک جستجوی تحلیلی نسبتاً پیشرفته است که از توابع LAG، COALESCE و WINDOW برای تعیین فاصله تاریخ استخدام بین کارکنان در هر بخش استفاده می‌کند.

در اینجا ما یک نمایه متنی GIN در یک فیلد JSONB ایجاد می‌کنیم و از آن برای انجام جستجوی سریع با استفاده از اسکن فهرست به جای انجام یک اسکن کامل جدول استفاده می‌کنیم.

شاخص‌های GIN برای هر فیلد نوشتاری، نه فقط فیلدهای JSONB، قابل اعمال هستند. در اینجا ما یک شاخص GIN را با تابع ()to_tsvector ترکیب می کنیم. سپس عبارت SELECT از اسکن فهرست برای یافتن نتایج متن مورد نظر استفاده می کند. تابع to_tsvector() یک سند متنی را به نشانه‌ها تجزیه می‌کند، نشانه‌ها را به واژگان کاهش می‌دهد و یک tsvector برمی‌گرداند که واژگان را همراه با موقعیت‌هایشان در سند فهرست می‌کند، همانطور که در مستندات PostgreSQL توضیح داده شده است.

YSQL از دستورات آماده شده و رویه های ذخیره شده پشتیبانی می کند. این رویه ذخیره شده بخشی از کمیسیون را از یک کارمند به کارمند دیگر به طور ایمن منتقل می کند.

در اینجا ما تریگرها و تراکنش‌ها و همچنین تابع ()pg_ sleep را نشان می‌دهیم.

در اینجا یک جدول ایجاد می‌کنیم، یک نمایه ایجاد می‌کنیم، جدول را تجزیه و تحلیل می‌کنیم، از جدول برای سه مقدار اول که برابر با پنج است، جست‌وجو می‌کنیم و نشان می‌دهیم که پرس و جو از یک اسکن فقط شاخص استفاده می‌کند.

این داشبورد معیارهای خوشه Yugabyte Cloud را نشان می‌دهد که ما برای نمایش جستجوهای SQL استفاده می‌کردیم. تأخیر بالا مربوط به پرس و جوهای DDL بود که جداول و نمایه ها را ایجاد می کردند. استفاده از CPU کم ماند.

• YugabyteDB 2.13

  < meta content="4.5" itemprop="ratingValue"/>
  بیشتر بیاموزید

  در یوگا بایت

  YugabyteDB یک پایگاه داده توزیع شده سازگار با PostgreSQL بسیار توانا است که از اکثر ویژگی های PostgreSQL از جمله رویه های ذخیره شده، مکان نماها و راه اندازی ها پشتیبانی می کند. همچنین یک پایگاه داده توزیع شده سازگار با Cassandra بسیار توانا است.

  مزایا

  • پایگاه داده سازگار PostgreSQL و Cassandra توزیع شده
  • در دسترس به عنوان منبع باز
  • در دسترس به عنوان یک سرویس
  • بیشتر ویژگی های PostgreSQL پشتیبانی می شوند
  • مقیاس پذیری بالا

  معایب

  • شاخص‌های GiST (برای پرس و جوهای مکانی) هنوز پشتیبانی نمی‌شوند
  • مقیاس‌پذیری به خوبی CockroachDB نیست

YugabyteDB 2.13

YugabyteDB یک پایگاه داده توزیع شده سازگار با PostgreSQL بسیار توانا است که از اکثر ویژگی های PostgreSQL از جمله رویه های ذخیره شده، مکان نماها و راه اندازی ها پشتیبانی می کند. همچنین یک پایگاه داده توزیع شده سازگار با Cassandra بسیار توانا است.

• پایگاه داده سازگار PostgreSQL و Cassandra توزیع شده
• در دسترس به عنوان منبع باز
• در دسترس به عنوان یک سرویس
• بیشتر ویژگی های PostgreSQL پشتیبانی می شوند
• مقیاس پذیری بالا

• شاخص‌های GiST (برای پرس و جوهای مکانی) هنوز پشتیبانی نمی‌شوند
• مقیاس‌پذیری به خوبی CockroachDB نیست

• پایگاه داده
• پایگاه‌های داده رابطه‌ای< /a>
• پایگاه‌های داده NoSQL< /a>
• توسعه نرم افزار< /a>
• رایانش ابری< /a>