در مورد معاملات

این صفحه تراکنش ها در Cloud Spaer را توضیح می دهد و شامل کد نمونه برای اجرای تراکنش ها می شود.

معرفی

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

Spaer از این حالت های تراکنش پشتیبانی می کند:

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

فقط خواندنی . این نوع تراکنش ثبات تضمینی را در چندین خواندن ارائه می کند، اما اجازه نوشتن را نمی دهد. به طور پیش فرض، تراکنش های فقط خواندنی با مُهر زمانی منتخب سیستم اجرا می شوند که ثبات خارجی را تضمین می کند، اما همچنین می توان آن ها را برای خواندن در مهر زمانی در گذشته پیکربندی کرد. تراکنش های فقط خواندنی نیازی به تعهد ندارند و قفل نمی شوند. علاوه بر این، تراکنش های فقط خواندنی ممکن است قبل از اجرا منتظر بمانند تا نوشته های در حال پیشرفت کامل شوند.

DML پارتیشن بندی شدهاین نوع تراکنش یک عبارت زبان دستکاری داده ها (DML) را به صورت پارتیشن بندی شده DML اجرا می کند. DML پارتیشن بندی شده برای به روز رسانی و حذف انبوه، به ویژه پاکسازی دوره ای و پر کردن مجدد طراحی شده است.

این صفحه خصوصیات کلی و معنایی تراکنش ها در Spaer را شرح می دهد و رابط های تراکنش خواندنی، خواندنی، فقط خواندنی و پارتیشن بندی شده DML در Spaer را معرفی می کند.

خواندن و نوشتن معاملات

در اینجا سناریوهایی وجود دارد که در آنها باید از تراکنش خواندن و نوشتن قفل استفاده کنید:

• اگر نوشتنی انجام می دهید که به نتیجه یک یا چند خواندن بستگی دارد، باید آن نوشتن و خواندن (های) را در همان تراکنش خواندن و نوشتن انجام دهید.
  • مثال: دو برابر موجودی حساب بانکی A. خواندن موجودی A باید در همان تراکنش با نوشتن باشد تا موجودی را با مقدار دو برابر شده جایگزین کند.
  • مثال: انتقال 200 دلار از حساب A به حساب B. هر دو نوشتن (یکی برای کاهش A 200 دلار و یکی برای افزایش B به میزان 200 دلار) و خواندن مانده حساب اولیه باید در یک تراکنش باشد.
  • مثال: اگر موجودی فعلی A بیشتر از 500 دلار باشد، 200 دلار از حساب بانکی A به حساب بانکی B منتقل کنید. تراکنش شما باید حاوی خواندن موجودی A و یک بیانیه شرطی باشد که حاوی نوشته ها باشد.

  در اینجا سناریویی وجود دارد که در آن نباید از تراکنش خواندن و نوشتن قفل شده استفاده کنید:

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

  خواص

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

  چرا از معامله خواندن نوشتن استفاده می کنیم؟معاملات خواندن-خواص اسید پایگاه داده های رابطه ای را ارائه می دهد (در واقع ، معاملات خواندن Spaer ضمانت های قوی تری نسبت به اسید سنتی ارائه می دهد ؛ به بخش معناشناسی در زیر مراجعه کنید.).

  انزوا

  موارد زیر خصوصیات جداسازی برای معاملات خواندن و فقط خواندنی است.

  معاملاتی که می خوانند و می نویسند

  در اینجا خصوصیات انزوا که پس از انجام موفقیت آمیز معامله ای که شامل یک سری از خواندن (یا پرس و جو) است ، دریافت می کنید و می نویسد:

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

  برخی از درایورهای مشتری Spaer حاوی منطق امتحان مجدد معامله برای ماسک خطاهای گذرا هستند که آنها با اجرای مجدد معامله و اعتبار دادن به داده های تحت نظارت مشتری انجام می دهند.

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

  معاملاتی که فقط خوانده می شوند

  ضمانت های یک تراکنش خواندن و نوشتن که فقط خوانده می شود مشابه است: همه خواندن های درون آن تراکنش داده ها را از همان مهر زمانی برمی گردانند، حتی برای عدم وجود ردیف. یک تفاوت این است که اگر داده ها را می خوانید و بعداً تراکنش خواندن و نوشتن را بدون نوشتن انجام می دهید، هیچ تضمینی وجود ندارد که داده ها پس از خواندن و قبل از commit در پایگاه داده تغییر نکرده باشند. اگر می خواهید بدانید که آیا داده ها از زمانی که آخرین خوانده اید تغییر کرده است یا نه، بهترین روش این است که آن را دوباره بخوانید (چه در یک تراکنش خواندن-نوشتن، یا با استفاده از خواندن قوی.) همچنین، برای کارایی، اگر از قبل می دانید کهشما فقط می خوانید و نمی نویسید، باید از تراکنش فقط خواندنی به جای تراکنش خواندن-نوشتن استفاده کنید.

  اتمی، قوام، دوام

  علاوه بر ویژگی Isolation، Spaer Atomicity (اگر هر یک از نوشته های موجود در commit تراکنش، همه آنها متعهد می شوند)، Consistency (پایگاه داده پس از تراکنش در وضعیت ثابتی باقی می ماند) و Durability (داده های متعهد متعهد می مانند) را ارائه می کند.

  مزایای این خواص

  به دلیل این ویژگی ها، به عنوان یک توسعه دهنده اپلیکیشن، می توانید روی درستی هر تراکنش به تنهایی تمرکز کنید، بدون اینکه نگران نحوه محافظت از اجرای آن در برابر سایر تراکنش هایی باشید که ممکن است همزمان اجرا شوند.

  رابط

  کتابخانه های کلاینت Spaer رابطی را برای اجرای بدنه ای از کار در زمینه تراکنش خواندن-نوشتن، با تلاش های مجدد برای لغو تراکنش فراهم می کند. در اینجا کمی زمینه برای توضیح این نکته وجود دارد: یک تراکنش Spaer ممکن است قبل از انجام چندین بار امتحان شود. به عنوان مثال، اگر دو تراکنش به طور همزمان روی داده ها کار کنند که ممکن است باعث بن بست شود، Spaer یکی از آنها را لغو می کند تا تراکنش دیگر بتواند پیشرفت کند.(به ندرت، رویدادهای گذرا در Spaer ممکن است منجر به لغو برخی از تراکنش ها شود.) از آنجایی که تراکنش ها اتمی هستند، تراکنش لغو شده هیچ اثر قابل مشاهده ای روی پایگاه داده ندارد. بنابراین، تراکنش ها باید با امتحان مجدد آنها تا زمانی که موفق شوند، اجرا شوند.

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

  مثال

  فرض کنید یک ستون MarketingBudget را به جدول آلبوم ها که در صفحه طرحواره و مدل داده نشان داده شده است اضافه کرده اید:

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

  موارد زیر نحوه اجرای یک معامله خواندن-نوشتن را نشان می دهد:

  node. js

  پیتون

  مفاهیم

  قابلیت سریال و قوام خارجی

  Spaer "سریال قابلیت" را فراهم می کند ، به این معنی که تمام معاملات به نظر می رسد که به صورت سریال اجرا می شوند ، حتی اگر برخی از خواندن ها ، می نویسد و سایر عملیات معاملات مجزا به طور موازی رخ داده است. Spaer متعهد به تعهدات متعهد است که منعکس کننده سفارش معاملات متعهد برای اجرای این ملک است. در حقیقت ، Spaer ضمانت قوی تری نسبت به سریال سازی به نام قوام خارجی ارائه می دهد: معاملات به ترتیب متعهد می شوند که در زمان های متعهد آنها منعکس می شود ، و این زمان های متعهد زمان واقعی را منعکس می کند تا بتوانید آنها را با ساعت خود مقایسه کنید. در معامله می خواند ، هر آنچه را که قبل از انجام معامله انجام شده است ، مشاهده می کنید و می نویسد توسط هر آنچه پس از انجام معامله آغاز می شود ، مشاهده می شود.

  به عنوان مثال ، اجرای دو معامله را که در نمودار زیر نشان داده شده است در نظر بگیرید:

  تراکنش TXN1 به رنگ آبی برخی از داده های A را می خواند ، نوشتن را به A می نویسد ، سپس با موفقیت مرتکب می شود. معاملات TXN2 به رنگ سبز پس از TXN1 شروع می شود ، برخی از داده های B را می خواند ، سپس داده ها را می خواند. از آنجا که TXN2 مقدار A بعد از TXN1 را می خواند ، نوشتن خود را به A انجام داد ، Txn2 اثر نوشتن Txn1 را به A می بیند ، حتی اگر TXN2 قبل از اتمام TXN1 شروع شود.

  حتی اگر همپوشانی در زمان وجود داشته باشد که در آن TXN1 و TXN2 در حال اجرا هستند ، اما متعهد Timestamps C1 و C2 به یک سفارش معامله خطی احترام می گذارند ، به این معنی که به نظر می رسد تمام اثرات خوانده شده و نوشتن TXN1 در یک نقطه واحد رخ داده استزمان (C1) ، و به نظر می رسد که تمام اثرات خوانده شده و نوشته های TXN2 در یک نقطه از زمان (C2) رخ داده است. علاوه بر این ، C1خوانده شده پیشوند تاریخ تعهد را مشاهده کنید. اگر یک خواندن اثر TXN2 را مشاهده کند ، تأثیر TXN1 را نیز می بیند. تمام معاملات که با موفقیت انجام می دهند این ملک را دارند.

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

  ضمانت ها را بخوانید و بنویسید

  اگر تماس برای انجام معامله انجام نشود ، خواندن و نوشتن تضمین می کند که شما به چه خطایی بستگی دارید که تماس تعهد اساسی با چه خطایی انجام نشود.

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

  لغو عملیات معامله

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

  با این حال ، حتی اگر شما سعی در لغو خواندن داشته باشید ، Spaer تضمین نمی کند که خواندن در واقع لغو شده است. پس از درخواست لغو خواندن ، که خوانده شده هنوز هم می تواند با دلایل دیگری با موفقیت تکمیل یا شکست بخورد (به عنوان مثال سقط). علاوه بر این ، آن Read Conveled ممکن است برخی از نتایج را به شما بازگرداند ، و نتایج احتمالاً ناقص به عنوان بخشی از تعهد معامله تأیید می شود.

  توجه داشته باشید که برخلاف خواندن ، لغو عملیات تعهد معامله منجر به سقط جنین معامله می شود (مگر اینکه معامله قبلاً با دلیل دیگری مرتکب شده یا شکست خورده باشد).

  کارایی

  قفل

  Spaer به چندین مشتری اجازه می دهد تا همزمان با همان پایگاه داده ارتباط برقرار کنند. به منظور اطمینان از قوام چندین معاملات همزمان ، Spaer از ترکیبی از قفل های مشترک و قفل های اختصاصی برای کنترل دسترسی به داده ها استفاده می کند. هنگامی که شما به عنوان بخشی از معامله ، خواندن را انجام می دهید ، Spaer قفل های خوانده شده را به دست می آورد ، که به خوانده های دیگر اجازه می دهد تا تا زمان آماده شدن معامله شما به داده ها دسترسی پیدا کنند. هنگامی که معامله شما در حال انجام است و می نویسد ، معاملات برای ارتقاء به یک قفل اختصاصی تلاش می کند. این قفل های جدید خواندن را روی داده ها مسدود می کند ، منتظر است تا قفل های خواندن مشترک موجود را پاک کند ، سپس قفل اختصاصی را برای دسترسی اختصاصی به داده ها قرار می دهد.

  یادداشت های مربوط به قفل ها:

  • قفل ها در دانه بندی ردیف و ستون گرفته می شوند. اگر تراکنش T1 ستون "A" از Foo "را قفل کرده است ، و Transaction T2 می خواهد ستون" B "از ردیف" foo "را بنویسد ، هیچ درگیری وجود ندارد.
  • به یک مورد داده می نویسد که داده های نوشته شده را نیز نمی خواند (با نام مستعار "کور می نویسد") با سایر نویسندگان نابینا همان مورد مغایرت ندارید (زمان متعهد هر نوشتن ، ترتیب مورد استفاده را تعیین می کندپایگاه داده). نتیجه این امر این است که اگر اطلاعاتی را که می نویسید ، فقط باید Spaer فقط باید به یک قفل اختصاصی ارتقا یابد. در غیر این صورت Spaer از یک قفل مشترک به نام Writer Shared Lock استفاده می کند.
  • هنگام انجام جستجوهای ردیف در یک معامله خواندن نوشتن ، از شاخص های ثانویه برای محدود کردن ردیف های اسکن شده در محدوده کوچکتر استفاده کنید. این امر باعث می شود که Spaer تعداد کمتری از ردیف ها را در جدول قفل کند و امکان تغییر همزمان در ردیف های خارج از محدوده را فراهم می کند.

  از قفل ها نباید برای اطمینان از دسترسی انحصاری به یک منبع خارج از Spaer استفاده شود. معاملات را می توان به دلایل مختلف توسط Spaer مانند ، به عنوان مثال ، هنگام اجازه دادن به داده ها به منابع محاسباتی نمونه ، سقط کرد. اگر معامله ای انجام شود ، چه صریحاً توسط کد برنامه و چه به طور ضمنی توسط کد مشتری مانند درایور Spaer JDBC ، فقط تضمین می شود که قفل ها در طی تلاش که در واقع انجام شده است ، نگه داشته شده است.

  می توانید از ابزار Introspection Lock Statistics برای بررسی درگیری های قفل در پایگاه داده خود استفاده کنید.

  تشخیص بن بست

  Spaer هنگامی که معاملات متعدد ممکن است بن بست باشد ، تشخیص می دهد و همه به جز یکی از معاملات برای سقط جنین را مجبور می کند. به عنوان مثال ، سناریوی زیر را در نظر بگیرید: Transaction TXN1 قفل را در رکورد A نگه می دارد و منتظر قفل در رکورد B است ، و TXN2 یک قفل را در رکورد B نگه می دارد و منتظر قفل در ضبط است. تنها راه پیشرفت در این شرایط ، سقط جنین یکی از معاملات است ، بنابراین قفل خود را آزاد می کند و به معامله دیگر اجازه می دهد تا ادامه یابد.

  Spaer از الگوریتم استاندارد "Wound-Wait" برای رسیدگی به تشخیص بن بست استفاده می کند. در زیر کاپوت ، Spaer سن هر معامله ای را که درخواست قفل های متناقض می کند ، پیگیری می کند. همچنین به معاملات قدیمی تر اجازه می دهد تا معاملات جوان تر را سقط کند (جایی که "قدیمی تر" به معنای این است که زودتر خواندن ، پرس و جو ، یا تعهد زودتر اتفاق افتاده است).

  Spaer با اولویت به معاملات قدیمی ، تضمین می کند که هر معامله در نهایت فرصتی برای دستیابی به قفل ها دارد ، پس از آنکه به اندازه کافی پیر می شود تا اولویت بالاتری نسبت به سایر معاملات داشته باشد. به عنوان مثال ، معامله ای که یک قفل مشترک را به دست می آورد ، می تواند توسط یک معامله قدیمی که به یک قفل مشترک به یک نویسنده نیاز دارد ، سقط کرد.

  اعدام توزیع شده

  Spaer می تواند معاملات را بر روی داده هایی انجام دهد که چندین سرور را شامل می شود. این قدرت در مقایسه با معاملات تک سرور با هزینه عملکرد همراه است.

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

  کارآمدترین معاملات در Spaer فقط شامل خواندن ها و نوشتن هایی است که باید به صورت اتمی اعمال شود. معاملات سریعترین هنگام خواندن و نوشتن داده های دسترسی در همان قسمت از فضای کلیدی است.

  معاملات فقط خواندنی

  علاوه بر قفل کردن معاملات خواندن ، Spaer معاملات فقط خواندنی را ارائه می دهد.

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

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

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

  خواص

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

  رابط

  Spaer یک رابط کاربری برای اجرای یک بدنه کار در زمینه معامله فقط خواندنی ، با ترمیم های مربوط به معاملات معامله فراهم می کند.

  مثال

  موارد زیر نحوه استفاده از یک معامله فقط خواندنی را برای دریافت داده های مداوم برای دو خواندن در همان زمان بندی نشان می دهد: