معاملات Couchbase از خصوصیات اسید برای اقدامات محافظت شده در پایگاه داده پشتیبانی می کند.
اتمی تضمین می کند که یک معامله معناشناسی همه یا هیچ چیز را ارائه می دهد-یعنی ، یا تمام اسناد اصلاح شده در یک معامله انجام شده اند ، یا هیچ یک از تغییرات انجام نمی شود. در صورت عدم موفقیت در هنگام اجرای معامله (مانند تصادف مشتری) ، تمام تغییرات آن به عقب برگردانده می شود.
قوام - معاملات Couchbase اطمینان حاصل می کند که بانک اطلاعاتی از یک حالت سازگار به حالت دیگر منتقل می شود و تمام مصنوعات مشتق شده مانند شاخص ها به طور خودکار به روز می شوند (هرچند که به طور غیر همزمان از معامله). توجه داشته باشید که تعریف سنتی از سازگاری مهم نیست زیرا هیچ محدودیت کلیدی خارجی در Couchbase وجود ندارد.
جداسازی - معاملات Couchbase تضمین می کند که تغییرات انجام شده در یک معامله تا زمان انجام معامله قابل مشاهده نیست. این سطح انزوا "خوانده شده" است.
جداسازی ارائه شده به خوانده های معامله ای سخت تر از آن است که خوانده شده انجام شود - این یک نمای اتمی یکنواخت (MAV) است. دیدگاه اتمی یکنواخت تضمین می کند که تمام اثرات یک معامله که قبلاً انجام شده است مشاهده می شود ، یعنی پس از انجام معامله هرگز تا حدی مشاهده نمی شود.
به روزرسانی های از دست رفته همیشه با بررسی در برابر مقدار CAS که مانند یک قفل خوش بینانه رفتار می کند ، جلوگیری می شود.
دوام املاک است که تضمین می کند در صورت بروز خرابی ، تغییرات انجام شده توسط معاملات متعهد از بین نمی رود. معاملات Couchbase دوام قابل تنظیم را برای تحمل سناریوهای مختلف شکست با 3 سطح مختلف فراهم می کند:
اکثریت - قبل از تصدیق نوشتن ، اکثریت ماکت ها را تکرار کنید. این سطح پیش فرض است.
اکثریت و فعال - در اکثر ماکت ها تکرار می شود و قبل از تصدیق نوشتن ، به دیسک اولیه ادامه دهید
PersisttomaJority - قبل از تصدیق نوشتن ، در اکثر ماکت ها به دیسک ادامه دهید.
PersisttomaJority قوی ترین محافظت در برابر شکست ها را فراهم می کند اما کمترین عملکرد در بین سطح دوام است. برای اطلاعات بیشتر ، به سطح دوام مراجعه کنید.
| اتمی سطح بیانیه برای بیانیه های N1QL که در داخل یک معامله اجرا می شوند ارائه شده است. این بدان معناست که اگر بیانیه پرس و جو در حین اجرای به دلایلی مانند یک نقض کلیدی منحصر به فرد انجام شود ، بیانیه کاملاً به عقب برگردانده شده و بقیه معامله ادامه می یابد. به نظر می رسد که این بیانیه بخشی از معامله نیست. هیچ کار دیگری در معامله تحت تأثیر عدم موفقیت این بیانیه نیست. اگر بیانیه پرس و جو موفق شود ، بر اساس نتیجه معامله کلی ، مرتکب می شود یا به عقب برگشته است. |
معاملات توزیع شده: چند گره و چند باکتری
معاملات Couchbase توزیع می شود و در چندین اسناد کار می کند که می توانند در گره های مختلف زندگی کنند. فقط گره هایی که حاوی داده هایی هستند که به روز می شوند تحت تأثیر یک معامله قرار می گیرند.
علاوه بر این ، این اسناد می توانند متعلق به مجموعه های مختلف ، دامنه ها و سطل ها باشند.
عملیات پشتیبانی شده توسط API معاملات
پشتیبانی API های معامله:
درج ، به روزرسانی و حذف عملیات ، در هر تعداد اسناد درج ، به روزرسانی و حذف
ادغام یکپارچه بین ارزش کلیدی (kV) و بیانیه های DML پرس و جو (انتخاب ، درج ، به روزرسانی ، حذف ، upsert ، ادغام) در معاملات
چندین بیانیه با ارزش کلیدی و پرس و جو DML را می توان در یک معامله استفاده کرد.
هنگامی که عبارات DML پرس و جو در یک تراکنش استفاده می شود، معنای request_plus به طور خودکار استفاده می شود تا اطمینان حاصل شود که تمام به روز رسانی های انجام شده (و در صورت انجام در یک تراکنش) قبل از شروع تراکنش برای عبارات پرس و جو در آن قابل مشاهده است.
استفاده از تراکنش ها
برای انتقال 1000 دلار از حساب Beth به حساب Andy با یک تراکنش ACID، یک تراکنش بدهی و اعتبار اولیه را در نظر بگیرید.
مثال جاوا در بالا یک مثال کلاسیک برای انتقال پول بین دو حساب است. به استفاده از تابع لامبدا برای بیان تراکنش توجه کنید.
این برنامه منطق تراکنش را در داخل یک لامبدا، از جمله هر منطق شرطی مورد نیاز، ارائه می‌کند و API تراکنش‌ها وظیفه انجام تراکنش را بر عهده می‌گیرد. اگر API تراکنش‌ها با یک خطای گذرا، مانند تداخل موقت با تراکنش دیگر مواجه شود، می‌تواند آنچه را که تاکنون انجام شده است، برگرداند و لامبدا را دوباره اجرا کند. برنامه نیازی به انجام این تلاش های مجدد و رسیدگی به خطاها ندارد.
| از تراکنش‌ها فقط در اسنادی با حجم کمتر از 10 مگابایت استفاده کنید. |
برای تراکنش‌های سطح برنامه، تراکنش‌ها را از طریق APIهای Couchbase SDK ایجاد و استفاده کنید.
در اینجا مثال دیگری وجود دارد که استفاده از کلید-مقدار و عملیات پرس و جو را ترکیب می کند:
برای اطلاعات بیشتر در مورد تراکنش‌های توزیع‌شده از طریق APIهای SDK، ببینید:
برای موارد استفاده که نیاز به اجرای تغییرات موقت داده‌ها دارند، می‌توانید مستقیماً از ساختارهای تراکنشی در N1QL استفاده کنید. این را می توان با استفاده از cbq، Query Workbench، CLI، یا REST API در سرور Couchbase یا از طریق SDK ها انجام داد.
برای اطلاعات بیشتر در مورد استفاده از بیانیه‌های Query در تراکنش‌ها، به پشتیبانی N1QL برای تراکنش‌های Couchbase مراجعه کنید.
| به شبیه ساز تراکنش پرس و جو نگاهی بیندازید که نحوه عملکرد عبارات پرس و جو در تراکنش ها را نشان می دهد. |
ساختار یک معامله
هر تراکنش یک شروع و یک تعهد یا بازگشت در پایان دارد.
هر تراکنش شامل یک یا چند عملیات KV و به صورت اختیاری یک یا چند عبارت پرس و جو است.
ایجاد تراکنش
تراکنش زمانی شروع می شود که یکی از شرایط زیر صادق باشد:
یک تراکنش از SD K-transactions. run((ctx) در مثال بالا شروع می شود.
دستور BEGIN TRANSACTION اجرا می شود - برای مثال، از Query Workbench.
یک تراکنش پرس و جوی منفرد که به طور ضمنی یک تراکنش را شروع می کند، با استفاده ازtransactions. query(statement) از SDK، با استفاده از Run as TX از Query Workbench یا با استفاده از پارامتر query tximplicit اجرا می شود.
پایان معامله
یک تراکنش زمانی می تواند پایان یابد که یکی از شرایط زیر صادق باشد:
یک عملیات commit - ctx. commit() در مثال بالا اجرا می شود.
یک rollback اجرا می شود - ctx. rollback() یا با اجرای دستور ROLLBACK TRANSACTION.
بازخوانی تراکنش با موفقیت انجام می شود، در این صورت تراکنش به طور ضمنی انجام می شود.
برنامه با مشکلی روبرو می شود که قابل حل نیست، در این صورت تراکنش به طور خودکار برگشت داده می شود.
انقضای تراکنش همچنین منجر به عقبگرد می شود.
Savepoint
Savepoint یک حالت میانی تعریف شده توسط کاربر است که برای مدت تراکنش در دسترس است. در یک تراکنش طولانی مدت، به جای بازگرداندن کل تراکنش در صورت بروز خطا، می توان از نقاط ذخیره برای بازگشت به آن حالت استفاده کرد.
توجه داشته باشید که نقاط ذخیره فقط در زمینه یک تراکنش در دسترس هستند (به عنوان مثال، ctx. query ("SAVEPOINT") در داخل لامبدا) و پس از انجام یک تراکنش حذف می شوند.
معاملات و خدمات Couchbase
کلیه خدمات Couchbase فقط داده های متعهد را مشاهده می کنید. اصلاحات معامله غیر مجاز (به عنوان مثال داده های کثیف) هرگز برای هیچ سرویس Couchbase قابل مشاهده نیست.
شاخص های ارائه شده توسط خدمات شاخص ، جستجو و تحلیلی به طور همزمان با تعهدات انجام شده توسط معاملات به روز نمی شوند و در عوض آنها با قوام نهایی به روز می شوند. از این رو ، یک پرس و جو که بلافاصله پس از انجام معامله انجام می شود ، ممکن است اثرات معامله را مشاهده نکند.
سرویس Query پارامتر سازگاری اسکن تراکنش ، Request_Plus را ارائه می دهد ، که به نمایش داده ها اجازه می دهد تا پس از معامله ، منتظر بماند تا شاخص ها به طور مناسب به روز شوند. این پارامتر request_plus تضمین می کند که نمایش داده شدگان شما بر روی آخرین داده های قابل مشاهده کار می کنند. هنگامی که از یک پرس و جو در یک معامله استفاده می شود ، قوام اسکن معامله به طور پیش فرض روی Request_Plus تنظیم می شود و از این رو تضمین می کند که پرس و جو همه تغییرات متعهد را مشاهده می کند.
توجه داشته باشید که می توانید در بعضی موارد مانند موارد زیر ، سطح قوام اسکن را در Not_Bounded به روز کنید:
اگر پرس و جو شما از کلیدها استفاده می کند.
اگر می دانید که داده های قابل دسترسی یا مصرف شده توسط معامله اخیراً به روز نشده است.
اگر معامله شما به آخرین داده ها اهمیتی نمی دهد ، به عنوان مثال اظهارات را صعود یا درج کنید.
معاملات و تکثیر (XDCR)
تکثیر مرکز داده های متقابل (XDCR) از سازگاری نهایی تغییرات معامله ای پشتیبانی می کند. هیچ تغییری غیرقابل قبول هرگز به خوشه های هدف ارسال نمی شود. پس از انجام ، تغییرات معامله ای یکی یکی در هدف قرار می گیرند. اگر اتصال در هنگام دریافت معامله از بین رفته باشد ، می توان یک معامله جزئی را دریافت کرد.
اسناد اصلاح شده معامله شده فقط در صورت عدم وجود معاملات مربوط به همان اسناد ، می توانند در آن خوشه ها به طور همزمان در یک XDCR دو طرفه انجام نشود ، فقط در خوشه ها تکرار شوند.
همیشه مراحل را برای اطمینان از عدم امنیت ایمن برای اطلاعات در مورد عدم استفاده از یک برنامه معامله ای از یک مرکز داده به مرکز دیگر دنبال کنید.
مکانیک معامله
مثال معامله را برای انتقال وجوه از حساب بث به حساب اندی در نظر بگیرید.
با فرض اینکه 2 سند درگیر در این معامله در دو گره مختلف زندگی می کنند ، در اینجا مراحل سطح بالایی وجود دارد که معامله را دنبال می کند:
هر اجرای منطق معامله در یک برنامه "تلاش" در معامله کلی نامیده می شود.
ورودی های ضبط معامله فعال
مکانیک اول این است که هر یک از این تلاش ها وارد یک سند ابرداده در خوشه Couchbase می شود. به این اسناد ابرداده سوابق معامله فعال یا ATRS گفته می شود. ATR ها به طور خودکار ایجاد و نگهداری می شوند و به راحتی توسط پیشوند آنها _txn قابل تشخیص هستند: Atr-. آنها قابل مشاهده هستند و نباید در خارج اصلاح شوند.
هر ATR حاوی مدخل برای تلاش های متعدد است. هر ورودی ATR برخی از ابرداده ها را ذخیره می کند و به طور مهم ، چه تلاش انجام شده باشد یا نه. به این ترتیب ، ورود به عنوان نقطه واحد حقیقت برای معامله عمل می کند ، که برای ارائه "تعهد اتمی" در هنگام خواندن ضروری است. در مرحله 1 در بالا ، یک ورودی جدید به ATR اضافه می شود.
به طور پیش فرض ، اسناد ابرداده در مجموعه پیش فرض سطل اولین سند جهش یافته در معامله ایجاد می شوند. با این حال ، می توانید از یک مجموعه نامگذاری شده برای ذخیره اسناد ابرداده استفاده کنید. برای جزئیات بیشتر به مجموعه ابرداده های سفارشی مراجعه کنید.
جهش های مرحله ای
مکانیک دوم این است که جهش یک سند در یک معامله ، مستقیماً بدنه سند را تغییر نمی دهد. در عوض ، نسخه پس از اقدامات پس از انجام سند در کنار سند روی صحنه می رود-از نظر فنی در ویژگی های گسترده آن (XATTRS). به این ترتیب ، تمام تغییرات برای تمام قسمت های خوشه Couchbase تا رسیدن به نقطه تعهد نامرئی است.
این تغییرات اسناد مرحله ای به طور مؤثر به عنوان قفل در برابر سایر معاملات که سعی در تغییر سند دارند ، جلوگیری می کند و از درگیری های نوشتن نوشتن جلوگیری می کند.
در مراحل 2 و 3 در تصویر بالا ، شناسه معامله و محتوا برای جهش های اول و دوم در XATTRS اسناد مربوطه روی صحنه می رود.
پاک کردن
مکانیسم های ایمنی برای اطمینان از تغییرات مرحله باقیمانده از یک معامله شکست خورده وجود دارد که نمی تواند معاملات زنده را به طور نامحدود مسدود کند. این موارد شامل یک فرآیند پاکسازی ناهمزمان است که با ایجاد شیء معاملات آغاز می شود و برای معاملات منقضی شده ایجاد شده توسط هر برنامه ، روی همه سطل ها اسکن می شود.
توجه داشته باشید که اگر یک برنامه در حال اجرا نباشد ، این پاکسازی نیز اجرا نمی شود.
فرآیند پاکسازی در پاکسازی ناهمزمان به تفصیل است.
در مراحل 4 و 5 در تصویر بالا ، اسناد "Usera" و "UserB" بدون محاصره هستند ، یعنی از XATTRS خارج شده و با بدنه سند جایگزین شده اند.
متعهد
فقط هنگامی که منطق کاربرد (Lambda) با موفقیت به نتیجه برسد ، این تلاش انجام می شود. این امر ورود به سیستم را به روز می کند ، که می تواند به عنوان سیگنال توسط بازیگران معامله ای در مورد استفاده از نسخه پس از انجام یک سند از XATTRS خود استفاده شود. از این رو به روزرسانی ورود ATR به طور مؤثر یک سوئیچ "تعهد اتمی" برای معامله است.
پس از رسیدن به این نقطه تعهد اتمی ، اسناد فردی مرتکب شده اند (یا "بدون ایستاده"). این یک تعهد در نهایت سازگار برای بازیگران غیر تعامل (از جمله خواندن ارزش کلیدی استاندارد) فراهم می کند. معاملات به محض تغییر ورود ATR به متعهد ، خواندن نسخه پس از تحرک اسناد را آغاز می کند.
در مرحله 4 در تصویر بالا ، تلاش معامله به عنوان "متعهد" در ATR مشخص شده است و لیست شناسه های سند درگیر در معامله به روز می شود.
در مرحله 7 در تصویر بالا ، تلاش معامله به عنوان "تکمیل" مشخص شده و از ATR حذف می شود.
مجوزها
برای اجرای یک عملیات با ارزش کلیدی در یک معامله ، کاربران باید نقش های اداری یا داده های مربوط به RBAC و مجوزهای مربوط به سطل ها ، دامنه ها و مجموعه های مربوطه را داشته باشند.
به همین ترتیب ، برای اجرای یک بیانیه پرس و جو در یک معامله ، کاربران باید نقش های اداری یا پرس و جو و فهرست RBAC و مجوزهای مربوط به سطل ها ، اسکوپ ها و مجموعه های مربوطه را داشته باشند.
برای جزئیات بیشتر به نقش ها مراجعه کنید.
مجموعه ابرداده های سفارشی
به طور پیش فرض ، اسناد ابرداده در مجموعه پیش فرض سطل اولین سند جهش یافته در معامله ایجاد می شوند.
اسناد ابرداده شامل اسناد درگیر در هر معامله ، کلید سند و نام سطل ، دامنه و مجموعه ای است که در آن وجود دارد.
در مواردی که استقرار به یک روش گرانول تر برای سازماندهی و به اشتراک گذاری داده ها در سطل ها ، اسکوپ ها و مجموعه ها نیاز دارد ، می توان از مجموعه ابرداده های سفارشی با مجوزهای مناسب RBAC برای کنترل دید استفاده کرد. در صورت تمایل به حذف مجموعه پیش فرض ، می توانید از یک مجموعه ابرداده سفارشی نیز استفاده کنید.
برای تعریف یک مجموعه ابرداده سفارشی ، از پارامتر پیکربندی زیر استفاده کنید:
هرگونه معاملات ایجاد شده از این شیء معاملات ، ابرداده را در آن مجموعه ایجاد و استفاده می کند.
پاکسازی ناهمزمان که توسط این شیء معاملات آغاز شده است ، فقط در این مجموعه به دنبال معاملات منقضی شده است.
برای اطلاعات بیشتر ، به مجموعه های ابرداده های سفارشی در مستندات API معاملات مراجعه کنید.
پیامدهای هنگام استفاده از معاملات
تعداد نوشتن های مورد نیاز توسط یک به روزرسانی معامله ای بیشتر از تعداد مورد نیاز برای به روزرسانی غیر متعادل است. بنابراین به روزرسانی های معاملاتی ممکن است کمتر از به روزرسانی های غیر متعادل انجام شود.
توجه داشته باشید که داده های موجود در یک سند واحد همیشه به صورت اتمی به روز می شوند (بدون نیاز به معاملات): بنابراین ، هر زمان که عملی باشد ، مدل داده خود را به گونه ای طراحی کنید که یک سند واحد مقادیری را که باید به صورت اتمی به روز شوند ، داشته باشد.
به روزرسانی های غیر متعادل نباید به هیچ سندی که در معامله درگیر است ، در حالی که معامله در حال انجام است ، انجام شود: این مانع از بازنویسی به روزرسانی غیر متعادل می شود.
هنگام استفاده از اظهارات پرس و جو در یک معامله ، توصیه می کنیم تعداد جهش ها را در یک معامله محدود کنید زیرا جدول دلتا با هر جهش افزایش می یابد و منجر به افزایش مصرف می شود. برای مدیریت میزان حافظه مصرف شده توسط جداول دلتا از تنظیم "حافظه-کوتا" در سرویس پرس و جو استفاده کنید.
برای بارهای شبیه به ETL یا به روزرسانی های گسترده که به اسید نیاز دارند ، استفاده از معاملات یک پرس و جو را مستقیماً از طریق میز کار پرس و جو ، CLI یا CBQ در نظر بگیرید. معاملات پرس و جو تک ، که به آنها نیز به عنوان معاملات ضمنی گفته می شود ، نیازی به نگهداری جدول دلتا نیست.
ملاحظات استقرار
اگر با استفاده از یک خوشه گره واحد (به عنوان مثال ، در طول توسعه) ، توجه داشته باشید که تعداد پیش فرض ماکت برای یک سطل تازه ایجاد شده 1 است. اگر در این پیش فرض باقی مانده باشد ، تمام ارزش های با ارزش با دوام می نویسد ، که توسط معاملات استفاده می شود ،با دوام impociationexception شکست می خورد. این تنظیم از طریق GUI یا خط فرمان قابل تغییر است. اگر روی یک سطل که از قبل وجود دارد تغییر یابد ، سرور باید دوباره تعادل یابد.
استفاده از معاملات نیاز به پروتکل زمان شبکه (NTP) برای همگام سازی زمان در تمام گره های خوشه ای دارد. برای جزئیات بیشتر به همگام سازی ساعت با NTP مراجعه کنید.
تنظیمات و پارامترها
معاملات را می توان با استفاده از تعدادی از تنظیمات و پارامترهای سطح درخواست پیکربندی کرد.
پارامترهای پرس و جو در سطح درخواست
پارامترهای سطح درخواست هنگام استفاده از نمایش داده ها در معاملات. برای جزئیات بیشتر به تنظیمات معاملات N1QL مراجعه کنید.
تایمر انقضاء معامله
پیکربندی می کند که یک معامله قبل از بازگشت به چه مدت باید دوام داشته باشد. تایمر انقضا معامله (که قابل تنظیم است) با شروع معامله شروع می شود. مقدار پیش فرض 15 ثانیه است. در این بازه زمانی ، اگر مشکلات همزمانی یا گره وجود داشته باشد ، از ترکیبی از عملیات انتظار و آزمایش مجدد تا زمان رسیدن معامله استفاده می شود. برای اطلاعات بیشتر ، به رسیدگی به خطای معاملات مراجعه کنید.
مشخص می کند که بیانیه DML یک معامله تک است. به طور پیش فرض ، آن را نادرست تنظیم می کند. برای جزئیات بیشتر به tximplicit مراجعه کنید.
حداکثر زمان برای انتظار برای عملکرد KV را قبل از زمان بندی مشخص می کند. مقدار پیش فرض 2. 5 ثانیه است. برای جزئیات بیشتر به KVTimeout مراجعه کنید.
مجموعه ای را که سوابق معامله فعال (ATRS) و سوابق مشتری ذخیره می شود ، مشخص می کند. مجموعه باید موجود باشد. اگر مشخص نشده باشد ، ATR در مجموعه پیش فرض در محدوده پیش فرض در سطل حاوی اولین سند جهش یافته در معامله ذخیره می شود. برای جزئیات بیشتر به AtrCollection مراجعه کنید.
