برنامه نویسی

CitusDB چقدر ACID است؟ (در مقایسه با YugabyteDB)

چه فرقی با هم دارند اشتراک گذاری روی پایگاه های داده یکپارچهمانند پسوند CitusDB برای PostgreSQL، و SQL توزیع شده? هر دو در حال توزیع ردیف های جدول و ورودی های فهرست هستند اما توزیع می کنند SQL به معنای بیش از آن: توزیع کردن تراکنش های SQL و حفظ آنها اسید خواص

  • به اشتراک گذاری پایگاه های داده یکپارچه از تراکنش‌های محلی استفاده می‌کند، با یک هماهنگ‌کننده در بالای آن که از commit دو مرحله‌ای برای انجام تمام خرده‌ها و تشخیص وجود تراکنش‌های مشکوک استفاده می‌کند.
  • پایگاه های داده SQL توزیع شده تراکنش های جهانی را اجرا کنید، به طوری که برنامه ها بتوانند آن را به عنوان یک پایگاه داده منطقی ببینند تا مقیاس پذیری افقی برای برنامه های OLTP فراهم شود.

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

یک مثال معمولی انتقال حساب بانکی است. اگر 100 دلار از حساب A به حساب B منتقل کنید، تراکنش پایگاه داده که انتقال را انجام می دهد، دو حساب را یکی پس از دیگری به روز می کند تا 100 دلار به B اضافه کند و 100 دلار به B برداشت می کند. ممکن است مبلغ کل همه حساب ها به طور موقت از بین برود. 100 دلار وقتی توسط تراکنشی که انتقال را انجام می دهد پرس و جو می شود، اما همه تراکنش های دیگر هرگز نباید این حالت میانی را ببینند.

برای مثال، استفاده خواهم کرد pgbench در YugabyteDB. من به سادگی جدول پیش فرض را مقداردهی اولیه می کنم که شامل عبارت است pgbench_accounts جدول:

pgbench -i
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این 100000 حساب با موجودی صفر ایجاد می کند:

select count(*),min(abalance),max(abalance),sum(abalance) 
 from pgbench_accounts;
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

من یک اسکریپت سفارشی برای انجام یک انتقال ساده بین دو حساب تصادفی ایجاد می کنم:

cat > /tmp/pgbench-acid.sql <<'SQL'
\set aid1 random(1, 100000 * :scale)
\set aid2 random(1, 100000 * :scale)
\set delta random(-5000, 5000)
BEGIN;
UPDATE pgbench_accounts SET abalance = abalance + :delta WHERE aid = :aid1;
UPDATE pgbench_accounts SET abalance = abalance - :delta WHERE aid = :aid2;
END;
SQL
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

SQL توزیع شده YugabyteDB

من این را در پس زمینه به مدت 5 دقیقه از 10 اتصال اجرا می کنم:

pgbench -f /tmp/pgbench-acid.sql -T 300 -c 10 &
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

اکنون از psql من کل موجودی حساب را هر 100 میلی ثانیه استعلام می کنم:

select count(*),min(abalance),max(abalance),sum(abalance) 
 from pgbench_accounts;
\watch 0.1
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

به دلیل ACID بودن همه تراکنش ها، مبلغ کل هرگز تغییر نمی کند زیرا همه نقل و انتقالات از یک حساب به حساب دیگر انجام می شود:
YugabyteDB که در آن مقدار کل همیشه صفر است
این تراکنش های توزیع شده، با خواندن و نوشتن در همه گره ها هستند:
عملیات راد و نوشتن در تمام گره های YugabyteDB

PostgreSQL با CitusDB

بیایید همین کار را روی CitusDB اجرا کنیم. من یک خوشه 3 گره را شروع می کنم:

git clone https://github.com/citusdata/docker.git citusdata-docker
cd citusdata-docker
docker-compose up -d --scale worker=3 
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مقداردهی اولیه می کنم pgbench جداول:

pgbench -i
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

من توزیع می کنم pgbench_accounts جدول:

docker exec -it citusdata-docker_master psql -c '
 select create_distributed_table('pgbench_accounts', 'aid');
'
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

من همان اسکریپت را در پس زمینه اجرا می کنم:

pgbench -f /tmp/pgbench-acid.sql -T 300 -c 10 &
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

و مقدار کل را هر 100 میلی ثانیه جستجو کنید:

select count(*),min(abalance),max(abalance),sum(abalance) 
 from pgbench_accounts;
\watch 0.1
وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مبلغ کل گاهی منفی و گاهی مثبت است زیرا تراکنش های جاری مبالغ تصادفی را انتقال می دهند. پرس و جو توزیع شده برخی از حالت های میانی را می بیند.
CitusDB مقادیر متفاوت از صفر را نشان می دهد

این اسید نیست، سازگاری نهایی است. در برخی موارد، زمانی که دیگر تراکنش‌های جاری وجود نداشته باشد، خرده‌ها همگام‌سازی می‌شوند.

توجه داشته باشید که این مثال فقط در مورد آتومیسیتی و منحل کردن اسید این سیonsistency در مورد محدودیت های یکپارچگی است و CitusDB اجازه کلیدهای خارجی متقاطع یا حتی شاخص های جهانی را نمی دهد. این تفاوت دیگری با Distributed SQL است (این پست قبلی در مورد آن را ببینید). این Dپایداری در مورد ماندگاری است. این CitusDB محافظت نمی شود. برای محافظت از هر قطعه، باید چندین پایگاه داده آماده به کار با commit همزمان اضافه کنید. این پیچیدگی را برای بیش از تعداد انگشت شماری از خرده ها افزایش می دهد (الگوهای Patroni می توانند به طراحی صحیح این پیچیدگی کمک کنند). خوشه YugabyteDB در بالا دارای تکثیر داخلی در کنار توزیع است و یک خوشه Replication Factor 3 بود که می تواند به گره های بیشتری مقیاس شود زیرا جداول در واقع به خرده های کوچکتری توزیع می شوند که می توانند به صورت آنلاین حرکت کنند.

موارد استفاده CitusDB

رفتار از در نهایت سازگار می خواند برای پرس و جوهای چندشارد انتظار می رود و برای موارد استفاده CitusDB که برای آن طراحی شده است قابل قبول است (به زمان استفاده از Citus مراجعه کنید):

  • تجزیه و تحلیل زمان واقعی: جداول معمولاً به موقع تقسیم می شوند و دریافت داده ها به یک قطعه می رسد. سپس، پرس و جوها سازگار خواهند بود.
  • برنامه چند مستاجر: برای چند مستأجر از پیش تعریف شده، جداول به ازای هر مستاجر تقسیم می شود و معاملات در یک مستاجر خواهد بود و ثابت خواهد بود.

موارد استفاده YugabyteDB

SQL توزیع شده پایگاه های داده (Google Spanner، CockroachDB، TiDB، YugabyteDB) ویژگی های ACID را برای تراکنش های متقاطع تضمین می کنند و سپس برای همه برنامه های OLTP که شامل تراکنش‌های چند تکه‌ای می‌شود و امکان اشتراک‌گذاری مجدد خودکار در هنگام کوچک‌سازی را فراهم می‌کند.

در میان آنها، تنها یکی که است سازگار با PostgreSQL وقتی صحبت از تراکنش ها می شود، YugabyteDB است زیرا بقیه ویژگی ها و رفتار مشابهی ندارند. YugabyteDB از تمام سطوح جداسازی PostgreSQL، با رفتاری یکسان، برای تمام تراکنش های توزیع شده پشتیبانی می کند.

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا