آخرین نسخه «بهترین پایگاه داده رابطه‌ای منبع باز جهان»، تا چند هفته دیگر منتشر می‌شود (اگر همه چیز طبق برنامه پیش برود). این از برنامه معمول انتشار یک نسخه جدید با تعداد زیادی ویژگی جدید یک بار در سال پیروی می کند، و صادقانه بگویم، این قابل توجه است. به همین دلیل من یکی از اعضای فعال جامعه PostgreSQL شدم.
به نظر من، بر خلاف نسخه های قبلی، PostgreSQL 12 حاوی یک یا دو ویژگی انقلابی (مانند پارتیشن بندی یا موازی سازی پرس و جو) نیست. یک بار به شوخی گفتم که ویژگی اصلی PostgreSQL 12 ثبات بیشتر است. آیا این همان چیزی نیست که هنگام مدیریت داده های حیاتی کسب و کار خود به آن نیاز دارید؟
اما PostgreSQL 12 به همین جا ختم نمی شود: با ویژگی ها و بهبودهای جدید، برنامه ها عملکرد بهتری خواهند داشت. و تنها کاری که باید انجام دهید این است که ارتقا دهید!
(خب، شاید نمایه ها را دوباره بسازید، اما در این نسخه آنقدرها هم که قبلاً ترسناک بودیم نیست.)
ارتقاء PostgreSQL و لذت بردن از پیشرفت های قابل توجه بدون سر و صداهای غیر ضروری، عالی خواهد بود. چند سال پیش، یک ارتقاء از PostgreSQL 9.4 به PostgreSQL 10 را بررسی کردم و دیدم که چگونه برنامه به لطف موازی سازی پرس و جو بهبود یافته در PostgreSQL 10 سرعت می گیرد. و مهمتر از همه، تقریباً هیچ چیزی از من لازم نیست (فقط یک پارامتر پیکربندی را تنظیم کنید. max_parallel_workers).
موافقم، زمانی که برنامه‌ها بلافاصله پس از ارتقا بهتر کار می‌کنند، راحت است. و ما بسیار تلاش می کنیم تا کاربران را راضی کنیم، زیرا PostgreSQL تعداد بیشتری از آنها دارد.
بنابراین چگونه یک ارتقای ساده به PostgreSQL 12 می تواند شما را خوشحال کند؟ الان بهت میگم
پیشرفت های عمده نمایه سازی
بدون نمایه سازی، پایگاه داده دور از دسترس نخواهد بود. دیگر چگونه می توانید به سرعت اطلاعات را پیدا کنید؟ سیستم نمایه سازی بنیادی PostgreSQL نامیده می شود . این نوع شاخص برای سیستم های ذخیره سازی بهینه شده است.
ما به سادگی از اپراتور استفاده می کنیم CREATE INDEX ON some_table (some_column)، و PostgreSQL کارهای زیادی برای به روز نگه داشتن ایندکس انجام می دهد در حالی که ما دائماً مقادیر را درج، به روز رسانی و حذف می کنیم. همه چیز خود به خود کار می کند، گویی با جادو.
اما ایندکس های PostgreSQL یک مشکل دارند - آنها و فضای اضافی دیسک را اشغال می کند و عملکرد بازیابی و به روز رسانی داده ها را کاهش می دهد. منظور من از "نفخ" حفظ بی اثر ساختار شاخص است. این ممکن است - یا ممکن است - مربوط به انبوه زباله هایی باشد که حذف می کند (با تشکر از پیتر گاگان برای اطلاعات))). نفخ شاخص به ویژه در حجم کاری که شاخص به طور فعال در حال تغییر است قابل توجه است.
PostgreSQL 12 عملکرد شاخص های B-tree را تا حد زیادی بهبود می بخشد و آزمایشات با معیارهایی مانند TPC-C نشان داده است که اکنون به طور متوسط 40٪ فضای کمتری استفاده می شود. اکنون ما زمان کمتری را نه تنها برای حفظ شاخص های درخت B (یعنی عملیات نوشتن)، بلکه برای بازیابی داده ها صرف می کنیم، زیرا ایندکس ها بسیار کوچکتر هستند.
برنامه هایی که به طور فعال جداول خود را به روز می کنند - معمولاً برنامه های OLTP () - از دیسک استفاده می کند و درخواست ها را بسیار کارآمدتر پردازش می کند. هرچه فضای دیسک بیشتر باشد، پایگاه داده بدون ارتقای زیرساخت فضای بیشتری برای رشد دارد.
برخی از استراتژی‌های ارتقا نیازمند بازسازی شاخص‌های B-tree برای استفاده از این مزایا هستند (مثلاً به طور خودکار ایندکس ها را بازسازی نمی کند). در نسخه‌های قبلی PostgreSQL، بازسازی نمایه‌های بزرگ روی جداول منجر به خرابی قابل توجهی می‌شد، زیرا نمی‌توان در این فاصله تغییراتی ایجاد کرد. اما PostgreSQL 12 یک ویژگی جالب دیگر دارد: اکنون می توانید فهرست ها را به موازات دستور بازسازی کنید. برای جلوگیری از توقف کامل
بهبودهای دیگری در زیرساخت نمایه سازی در PostgreSQL 12 وجود دارد. چیز دیگری که در آن جادو وجود داشت - ، با نام مستعار WAL (گزارش پیش‌نویس). ثبت پیش‌نویس هر تراکنش در PostgreSQL را در صورت شکست و تکرار ثبت می‌کند. برنامه ها از آن برای بایگانی و . البته، ثبت پیش‌نویس روی دیسک نوشته می‌شود، که می‌تواند بر عملکرد تأثیر بگذارد.
PostgreSQL 12 سربار رکوردهای WAL را که توسط شاخص‌های GiST، GIN و SP-GiST در طول ساخت فهرست ایجاد می‌شوند، کاهش داده است. این چندین مزیت ملموس را به همراه دارد: رکوردهای WAL فضای دیسک کمتری را اشغال می‌کنند و داده‌ها سریعتر پخش می‌شوند، مانند هنگام بازیابی فاجعه یا بازیابی لحظه به لحظه. اگر از چنین شاخص هایی در برنامه های خود استفاده می کنید (مثلاً برنامه های جغرافیایی مبتنی بر PostGIS از شاخص GiST زیاد استفاده می کنند)، این یکی دیگر از ویژگی هایی است که بدون هیچ تلاشی از جانب شما تجربه را به میزان قابل توجهی بهبود می بخشد.
پارتیشن بندی - بزرگتر، بهتر، سریعتر
PostgreSQL 10 معرفی شد . در PostgreSQL 11 استفاده از آن بسیار ساده تر شده است. در PostgreSQL 12 می توانید مقیاس بخش ها را تغییر دهید.
در PostgreSQL 12، عملکرد سیستم پارتیشن بندی به طور قابل توجهی بهتر شده است، به خصوص اگر هزاران پارتیشن در جدول وجود داشته باشد. به عنوان مثال، اگر یک پرس و جو فقط بر چند پارتیشن در یک جدول با هزاران مورد تأثیر بگذارد، بسیار سریعتر اجرا می شود. عملکرد فقط برای این نوع پرس و جوها بهبود نمی یابد. همچنین متوجه خواهید شد که عملیات INSERT در جداول با پارتیشن های متعدد چقدر سریعتر است.
ضبط داده ها با استفاده از - به هر حال، این یک راه عالی است و در اینجا یک مثال است - جداول پارتیشن بندی شده در PostgreSQL 12 نیز کارآمدتر شده اند. با COPY همه چیز از قبل سریع بود، اما در PostgreSQL 12 کاملاً پرواز می کند.
به لطف این مزایا، PostgreSQL به شما اجازه می دهد تا مجموعه داده های بزرگتری را ذخیره کنید و بازیابی آنها را آسان تر کنید. و هیچ تلاشی از طرف شما نیست. اگر برنامه دارای پارتیشن های زیادی مانند ثبت داده های سری زمانی باشد، یک ارتقاء ساده عملکرد آن را به میزان قابل توجهی بهبود می بخشد.
در حالی که این دقیقاً یک بهبود "ارتقا و لذت بردن" نیست، PostgreSQL 12 به شما امکان می دهد کلیدهای خارجی ایجاد کنید که به جداول پارتیشن بندی شده ارجاع می دهند و کار کردن با پارتیشن بندی را لذت بخش می کند.
با پرس و جوها خیلی بهتر شد
وقتی که (با نام مستعار CTE، مستعار WITH پرس و جو)، من نمی توانستم صبر کنم تا مقاله ای در مورد آن بنویسم . این یکی از ویژگی هایی است که سرعت برنامه را افزایش می دهد. البته مگر اینکه از CTE استفاده کنید.
من اغلب متوجه می شوم که افراد تازه کار SQL عاشق استفاده از CTE هستند؛ اگر آنها را به روش خاصی بنویسید، واقعاً احساس می شود که در حال نوشتن یک برنامه ضروری هستید. من شخصاً دوست داشتم این سؤالات را بازنویسی کنم تا به اطراف بپردازم بدون CTE و افزایش بهره وری. حالا همه چیز فرق کرده است.
PostgreSQL 12 به شما امکان می دهد نوع خاصی از CTE را بدون عوارض جانبی وارد کنید (SELECT) که فقط یک بار در انتهای درخواست استفاده می شود. اگر من پرس و جوهای CTE را که بازنویسی کردم پیگیری کنم، اکثر آنها در این دسته قرار می گیرند. این به توسعه دهندگان کمک می کند تا کدهای واضح بنویسند که اکنون نیز به سرعت اجرا می شود.
علاوه بر این، PostgreSQL 12 خود اجرای SQL را بدون نیاز به انجام کاری بهینه می کند. و اگرچه من احتمالاً اکنون نیازی به بهینه سازی چنین پرس و جوهایی ندارم، بسیار خوب است که PostgreSQL به کار بر روی بهینه سازی پرس و جو ادامه می دهد.
Just-in-Time (JIT) - اکنون پیش فرض
در سیستم های PostgreSQL 12 با پشتیبانی کامپایل JIT به طور پیش فرض فعال است. اول از همه، شما پشتیبانی می شوید برای برخی از عملیات داخلی، و دوم، پرس و جو با عبارات (ساده ترین مثال x + y) در لیست های انتخابی (که بعد از SELECT دارید)، جمع ها، عبارات با بندهای WHERE و موارد دیگر می توانند از JIT برای بهبود عملکرد استفاده کنند.
از آنجایی که JIT به طور پیش‌فرض در PostgreSQL 12 فعال است، عملکرد خود به خود بهبود می‌یابد، اما من توصیه می‌کنم این برنامه را در PostgreSQL 11 که JIT معرفی کرد، آزمایش کنید تا عملکرد پرس‌وجو را اندازه‌گیری کنید و ببینید آیا نیاز به تنظیم چیزی دارید یا خیر.
بقیه ویژگی های جدید PostgreSQL 12 چطور؟
PostgreSQL 12 دارای تعداد زیادی ویژگی جدید جالب است، از توانایی بررسی داده های JSON با استفاده از عبارات مسیر استاندارد SQL/JSON تا احراز هویت چند عاملی با یک پارامتر. clientcert=verify-full، ستون ها و موارد دیگر ایجاد کرد. برای یک پست جداگانه کافی است.
مانند PostgreSQL 10، PostgreSQL 12 عملکرد کلی را بلافاصله پس از ارتقاء بهبود می بخشد. مطمئناً شما می توانید مسیر خود را داشته باشید - قبل از فعال کردن بهبودها، برنامه را در شرایط مشابه در سیستم تولید آزمایش کنید، همانطور که من با PostgreSQL 10 انجام دادم. حتی اگر PostgreSQL 12 در حال حاضر پایدارتر از آنچه انتظار داشتم، در آزمایش تنبلی نکنید. برنامه ها را به طور کامل، قبل از عرضه به تولید.
منبع: www.habr.com