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

تنظیمات سازگاری نوشتن PostgreSQL و اتصال خاص
در Compose با پایگاه داده های زیادی سروکار داریم که این فرصت را به ما می دهد تا با عملکرد و کاستی های آنها بیشتر آشنا شویم. وقتی یاد می‌گیریم ویژگی‌های پایگاه‌های داده جدید را دوست داشته باشیم، گاهی اوقات به این فکر می‌کنیم که چقدر خوب می‌شد اگر ویژگی‌های مشابه در ابزارهای بالغ‌تری که برای مدت طولانی با آنها کار می‌کردیم وجود داشت. یکی از ویژگی‌های جدیدی که می‌خواستم در PostgreSQL ببینم، سازگاری نوشتن قابل تنظیم در هر اتصال در کل کلاستر بود. و همانطور که مشخص است، ما قبلاً آن را داریم و امروز می خواهیم اطلاعاتی در مورد نحوه استفاده از آن با شما به اشتراک بگذاریم.

چرا به آن نیاز دارم؟

اینکه خوشه چگونه باید رفتار کند به برنامه شما بستگی دارد. به عنوان مثال، یک برنامه پرداخت قبض را در نظر بگیرید. شما به XNUMX% سازگاری در کلستر نیاز دارید، بنابراین باید commit های همزمان را فعال کنید تا پایگاه داده شما منتظر انجام همه تغییرات باشد. با این حال، اگر برنامه شما یک شبکه اجتماعی با رشد سریع است، احتمالاً پاسخ سریع را به سازگاری XNUMX٪ ترجیح می دهید. برای رسیدن به این هدف، می توانید از commit های ناهمزمان در خوشه خود استفاده کنید.

با سازش ملاقات کنید

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

معامله 1: عملکرد

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

Tradeoff 2: ثبات

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

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

رفتار همزمان در یک برنامه صورتحساب معنا دارد که در آن ثبات مزیت آشکاری در مبادله بین ثبات و عملکرد دارد. مهمترین چیز برای چنین برنامه ای داده های معتبر است. اکنون به شبکه اجتماعی فکر کنید که وظیفه اصلی آن حفظ توجه کاربر با پاسخ دادن به درخواست‌ها در سریع‌ترین زمان ممکن است. در این صورت، عملکرد با پرش شبکه کمتر و انتظار کمتر برای commit ها در اولویت خواهد بود. با این حال، موازنه بین عملکرد و ثبات تنها چیزی نیست که باید به آن فکر کنید.

معاوضه 3: سقوط

درک نحوه رفتار یک خوشه در هنگام شکست بسیار مهم است. موقعیتی را در نظر بگیرید که در آن یک یا چند نسخه از کار می افتند. هنگامی که commit ها به صورت ناهمزمان پردازش می شوند، رهبر به عملکرد خود ادامه می دهد، یعنی نوشتن را می پذیرد و پردازش می کند، بدون اینکه منتظر نسخه های از دست رفته باشد. وقتی کپی ها به خوشه برمی گردند، با رهبر می رسند. با replication همزمان، اگر replica ها پاسخ ندهند، رهبر چاره ای نخواهد داشت و همچنان منتظر تایید commit می ماند تا زمانی که replica به خوشه برگردد و بتواند نوشتن را بپذیرد و commit کند.

یک اتصال در هر تراکنش؟

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

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

تضمین کنترل در عمل

به طور پیش فرض، PostgreSQL سازگاری را فراهم می کند. این توسط پارامتر سرور کنترل می شود synchronous_commit. به طور پیش فرض در موقعیت است on، اما سه گزینه دیگر دارد: local, remote_write یا off.

هنگام تنظیم پارامتر روی off تمام commit های همزمان حتی در سیستم محلی متوقف می شوند. پارامتر محلی حالت سنکرون را برای سیستم محلی مشخص می کند، اما نوشتن در رونوشت ها به صورت ناهمزمان انجام می شود. Remote_write حتی فراتر می رود: نوشتن در replica ها به صورت ناهمزمان ساخته می شوند، اما زمانی برگردانده می شوند که replica نوشتن را پذیرفت اما آن را روی دیسک ننوشت.

با در نظر گرفتن گستره گزینه های موجود، رفتاری را انتخاب می کنیم و با در نظر گرفتن آن on - اینها ضبط های همزمان هستند، ما انتخاب می کنیم local برای commit های ناهمزمان از طریق شبکه، در حالی که commit های محلی را همزمان می گذاریم.

اکنون، ما به شما می گوییم که چگونه این را در یک لحظه تنظیم کنید، اما تصور کنید که ما راه اندازی کنیم synchronous_commit в local برای سرور ما تعجب کردیم که آیا امکان تغییر پارامتر وجود دارد یا خیر synchronous_commit در حال پرواز، و معلوم شد که نه تنها ممکن است، بلکه دو راه برای انجام این کار وجود دارد. اولین مورد این است که جلسه اتصال خود را به صورت زیر تنظیم کنید:

SET SESSION synchronous_commit TO ON;  
// Your writes go here

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

روش دوم زمانی خوب است که شما فقط می خواهید مطمئن شوید که برای یک تراکنش تکثیر همزمان دارید. در بسیاری از پایگاه های داده تولید NoSQL مفهوم تراکنش وجود ندارد، اما در PostgreSQL وجود دارد. در این صورت شما یک تراکنش را شروع می کنید و سپس تنظیم می کنید synchronous_commit в on قبل از اجرای ورودی برای معامله COMMIT تراکنش را با استفاده از هر مقدار پارامتر انجام می دهد synchronous_commit، که در آن زمان تنظیم شده بود، اگرچه بهتر است متغیر را از قبل تنظیم کنید تا مطمئن شوید که سایر توسعه دهندگان متوجه می شوند که نوشته ها ناهمزمان نیستند.

BEGIN;  
SET LOCAL synchronous_commit TO ON;  
// Your writes go here
COMMIT;  

قبل از اینکه پایگاه داده به مشتری متصل پاسخ مثبت بدهد، همه تعهدات تراکنش اکنون به عنوان نوشته شده در replica ها تأیید می شوند.

پیکربندی PostgreSQL

قبل از این، ما یک سیستم PostgreSQL را تصور می کردیم synchronous_commit، نصب شده در local. برای اینکه این امر در سمت سرور واقع بینانه باشد، باید دو گزینه پیکربندی سرور را تنظیم کنید. یک پارامتر دیگر synchronous_standby_names زمانی به خود خواهد آمد synchronous_commit در خواهد بود on. تعیین می‌کند که کدام کپی‌ها واجد شرایط commit‌های همزمان هستند، و ما آن را روی *، به این معنی است که همه کپی ها درگیر هستند. این مقادیر معمولاً در پیکربندی می شوند فایل پیکربندی با اضافه کردن:

synchronous_commit = local  
synchronous_standby_names='*'

با تنظیم پارامتر synchronous_commit به معنا local، ما سیستمی ایجاد می کنیم که در آن دیسک های محلی همزمان می مانند، اما commit های مشابه شبکه به طور پیش فرض ناهمزمان هستند. مگر اینکه، البته، همانطور که در بالا نشان داده شده است، تصمیم بگیریم این commit ها را همزمان کنیم.

اگر توسعه را دنبال کرده اید پروژه فرماندار، ممکن است متوجه تغییرات اخیر شده باشید (1, 2) که به کاربران Governor این امکان را می داد که این پارامترها را آزمایش کرده و سازگاری آنها را نظارت کنند.

چند کلمه دیگر...

همین یک هفته پیش، به شما می گفتم که تنظیم دقیق PostgreSQL غیرممکن است. این زمانی بود که کرت، یکی از اعضای تیم پلتفرم Compose، اصرار داشت که چنین فرصتی وجود دارد. او اعتراضات من را آرام کرد و در اسناد PostgreSQL یافت موارد زیر:

این تنظیم را می توان در هر زمان تغییر داد. رفتار هر تراکنش با تنظیمی که در زمان ارتکاب اعمال می شود تعیین می شود. بنابراین، انجام برخی از تراکنش ها به صورت همزمان و برای برخی دیگر به صورت ناهمزمان ممکن و مفید است. مثلا به زور یکی multistatement تراکنش to make به صورت ناهمزمان commit می کند زمانی که مقدار پیش فرض پارامتر مخالف است، تنظیم کنید SET LOCAL synchronous_commit TO OFF در یک معامله

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

منبع: www.habr.com