مشاجره پایگاه داده چیست و چرا باید مراقبت کنید؟

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

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

اما اول ، ما باید درک کنیم که آنها چیست.

مشاجره پایگاه داده چیست؟

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

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

معاملات اسیدی و سطح انزوا

پردازش معاملات نیاز به دقت دارد. اسید مخفف مخفف است که به معنای اتمی ، قوام ، انزوا و دوام است - چهار ویژگی که به ما امکان می دهد اعتبار داده ها را در یک پایگاه داده حتی در صورت بروز خطا ، خرابی دستگاه و غیره تضمین کنیم. به طور خاص ، معاملات باید داشته باشند:

• Atomicity - معاملات ممکن است چندین مرحله داشته باشند (برای مثال ، مانده حساب را بررسی کنید ، 50 دلار به تعادل اضافه کنید ، تأیید شماره مانده نهایی را برگردانید). اتمی بیان می کند که یک معامله باید به عنوان یک واحد واحد رفتار شود ، به گونه ای که یا تمام مراحل به اتمام رسیده است (تعهد معامله) یا هیچ یک از آنها (معاملات معامله) نیستند.
• قوام - پایگاه داده باید قبل و بعد از هر معامله سازگار باشد. به عبارت دیگر ، نباید هیچ نکته ای (حتی یک موقت) وجود داشته باشد که داده های موجود در پایگاه داده نادرست باشد.
• جداسازی - معاملات به طور مستقل از یکدیگر پردازش می شوند تا زمانی که مرتکب نشوند. سیستم های مختلف پایگاه داده می توانند این کار را متفاوت انجام دهند (ما در یک لحظه به آن رسیدیم) ، اما این به طور کلی به نوعی قفل نیاز دارد ، یعنی یک ردیف پایگاه داده در ابتدای پردازش معامله "قفل شده" است و باز نمی شود و اجازه می دهداز سایر معاملات تا اولین معامله یا مرتکب یا سقط جنین می شود.
• دوام - تغییرات مرتبط با معامله ای که مرتکب شده است باید حتی در صورت بروز چیزی مانند تصادف سخت افزاری ادامه یابد.

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

چرا مشاجره پایگاه داده اتفاق می افتد

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

برای نشان دادن این موضوع ، یک مثال ساده را تصور کنیم: دو معامله ، همه در یک حساب بانکی یکسان عمل می کنند ، و بنابراین هر دو سعی در به روزرسانی همان ردیف در پایگاه داده ما دارند:

• مانده پرس و جو ، سپرده 50 دلار و به روزرسانی مانده
• تعادل پرس و جو ، 40 دلار برداشت و تعادل را به روز کنید

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

در حالی که این یک مثال ساده است ، اما نشان می دهد که وقتی بسیاری از معاملات سعی می کنند همزمان با همان داده ها عمل کنند ، چگونه می توان تأخیرها را ظهور کرد.

نمونه هایی از مشاجره پایگاه داده

بیایید به یک سناریوی واقع بینانه تر نگاه کنیم تا بیشتر نشان دهد که چگونه بحث و گفتگو اتفاق می افتد:

مثال: تصور کنید که ما یک سایت پخش ویدیویی ساخته ایم. در پایگاه داده ما ، ما یک جدول به نام فیلم با ستونی به نام Views داریم و هر بار که یک فیلم مشاهده می شود ، معامله ای به پایگاه داده ارسال می شود تا 1 را به مقدار آن فیلم در فیلم ها اضافه کند.

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

تشخیص مشاجره پایگاه داده

حالا که می فهمیم چه مشاجره ای دارد ، چگونه می توانیم بگوییم چه اتفاقی می افتد؟متأسفانه ، پاسخ کلی به این سؤال دشوار است ، زیرا بر اساس سیستم پایگاه داده ای که استفاده می کنید بسیار متفاوت است. در اینجا ، ما به روش های مختلفی برای تشخیص مشاجره هنگام استفاده از CockroachDB به طور خاص نگاه خواهیم کرد - ممکن است متوجه شوید که رویکردهای مشابه در سایر پایگاه داده ها نیز اعمال می شود.

بررسی پیام های عملکرد و خطا. اگر متوجه کاهش عملکرد برنامه و خطاهای مکرر مانند SQLState هستید: 40001 ، retry_write_too_old و retry_serializable ، اینها نشانه هایی هستند که احتمالاً شما یک مسئله مشاجره دارید.

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

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

با نمودار مشاجره بیانیه SQL مشورت کنید. داشبورد SQL کنسول DB CockroachDB حاوی یک نمودار بحث و گفتگو است که تعداد نمایش داده های ایجاد شده در طول زمان را نشان می دهد:

با نمودار راه اندازی مجدد معامله مشورت کنید. به همین ترتیب ، صفحه معاملات در کنسول DB شامل یک نمودار راه اندازی مجدد است که می تواند مفید باشد - سنبله در راه اندازی مجدد نشان می دهد که می تواند یک مسئله مشاجره وجود داشته باشد.

بهترین روشها برای جلوگیری از مشاجره در سوسکید

بنابراین اکنون که یک مشکل مشاجره را شناسایی کرده اید ، چگونه می توانید آن را برطرف کنید؟و مهمتر از همه ، چگونه می توانید در آینده از مشکلات مشاجره جلوگیری کنید؟

باز هم ، پاسخ این سؤالات بسته به فناوری انتخابی پایگاه داده شما تا حدودی متفاوت خواهد بود. در اینجا ، ما برخی از راه حل های پیشنهادی را برای کاربران CockroachDB ارائه خواهیم داد:

• معاملات بزرگ را در کارهای کوچکتر تجزیه کنید.
• از Select برای به روزرسانی در معاملات که در حال خواندن یک ردیف هستند و سپس متعاقباً همان ردیف را به روز کنید ، استفاده کنید.
• هنگام تعویض مقادیر در یک ردیف ، از upsert (به جای انتخاب ، درج یا به روزرسانی) استفاده کنید و مقادیر همه ستون های موجود در ردیف را به روز کنید.
• عادی سازی داده ها را افزایش دهید (اگرچه این امر معاملات تجاری دارد و همیشه بهترین گزینه نخواهد بود).

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

عملکرد پایگاه داده خود را بهبود بخشید!

دستور العمل های جدید تنظیم عملکرد ما به شما کمک می کند تا تنگناها را تشخیص داده و عملکرد سریع و سریع از پایگاه داده خود بدست آورید.