- خیلی از نوآوریها و بهینگیهای پایگاهداده چه در سطح قابلیتهای کاربردی، چه در سطح بهینهسازیهای الگوریتمی و محاسباتی طی ۳۰ سال گذشته اول توی PostgreSQL اومد. مثلا Multiversion Concurrency Control (MVCC) (کنترل همزمانی چند نسخهای) یا مثلا GiST (Generalized Search Tree) مفاهیمی بودند که بقیه از PostgreSQL الهام گرفتن. یا برخی بهینگیهای Query Optimizer.
- خیلی از نوآوریها و بهینگیهای پایگاهداده چه در سطح قابلیتهای کاربردی، چه در سطح بهینهسازیهای الگوریتمی و محاسباتی طی ۳۰ سال گذشته اول توی PostgreSQL اومد. مثلا Multiversion Concurrency Control (MVCC) (کنترل همزمانی چند نسخهای) یا مثلا GiST (Generalized Search Tree) مفاهیمی بودند که بقیه از PostgreSQL الهام گرفتن. یا برخی بهینگیهای Query Optimizer.
- از اونجایی که محصول رایگان و کدباز است، طبیعتا انتظار بلوغ ابزارها، خصوصا توی لایهی مدیریت رو نمیشه ازش داشت و مثلا همین Citus یا Barman یا ابزارهای جانبی متعددی کنارش ارائه میشن که شاید توی محصولات گرون و اینترپرایز مثل Oracle یا SQL Server همراه با خود محصول و با پشتیبانی رسمی ارائه میشن.
- خصوصا وقتی پای خرید لایسنس و استفاده قانونی از محصول به میون بیاد، دانش PostgreSQL لازم میشه.
- 🗿 تجربه شخصی: من حدود ۲۰ ساله به صورت تخصصی در کنار هر فعالیتی که توی حوزه نرمافزار داشتم، در زمینه دیتابیس فعال بودم، از تدریس، مشاوره، طراحی تا نگهداری و بهینهسازی دیتابیسهایی از چند ده گیگابایت تا چندصد ترابایت. خلاصه میتونم بگم زمان و انرژی نگهداری PostgreSQL در فضای غیر ابری (On-premise) نسبتا بیشتر از محصولاتی مثل Oracle یا SQL Server است (هرچقدر هم ساختار و دیتا بزرگتر، زمان و انرژی بیشتری لازمه). ولی از نظر معماری و مفاهیم آکادمیک دیتابیس، وقتی به query planner / optimizer نگاه تخصصی و علمی داشته باشیم، 💎 فوقالعاده است. اما توی محیط واقعی، خصوصا وقتی دیتابیس بزرگه، تعداد کاربر و کوئریهای همزمان زیاده، و یا شرایط بدی پیش بیاد، عموما ایرادیابی و مدیریت Oracle یا SQL Server به مراتب سریعتر و بیدردسرتر است. ولی اگر روزی پای خرید لایسنس به میون بیاد، بعیده حتی سازمانهای بزرگ هم قادر به حفظ محصولاتی باشن که الان بدون یک ریال هزینه لایسنس استفاده میکنن. اگر مهاجرت کرده باشید، یا پلنش رو داشته باشید، موضوع لایسنس خیلی ملموستره.
من PostgreSQL رو خیلی بعدتر از بقیه پلتفرمها شروع کردم (از نسخه ۹.۱، حدودا سال ۲۰۱۲) و تمام این سالها شاهد نوآوریهایی بودم که بخش زیادیش کاربرد تخصصی داشت و مثلا ابزارهای بکاپگیریش تا همین نسخه ۱۷ حتی با SQL Server 2005 شاید قابل مقایسه نباشه! (البته به جز Object Restore که دلیلش هم تفاوت مکانیزمشونه) هر پروژهای، هر تیمی، هر سازمانی، هر محصولی، هر بودجهای و دهها از این «هر» ها باعث میشن تا انتخاب بهینه تغییر کنه. نمیشه به همه گفت MySQL یا PostgreSQL یا ... استفاده کنید. بلکه بخشی از مهندسی، انتخاب ابزار مناسب و متناسب است. و سعی کنیم توی بازیهای بچهگانهی این بهتر است یا اون نیوفتیم. بدون شک، PostgreSQL یکی از بازیگرهای اصلی حوزه دیتابیس است و برای سناریوهای مختلفی میتونه گزینه خیلی خوبی باشه. فقط یادمون باشه، مثلا تنوع ایندکسهاش بیشتر از SQL Server است، یا پیادهسازی HA با مکانیزمهای اوراکلی مثل اکتیو دیتاگارد یا RAC فرق داره، حتی روشهای ذخیرهسازی یا ایراد یابیش، ابزارهای مونیتورینگ و... پس صرف اینکه بخش عمده دستورات SQL توی همشون مشابهه توی تلهی توهم بلد بودن نیوفتیم و تیم و محصول رو به مشکل نندازیم. حتی چون مثل Microsoft یا Oracle ساختار یادگیری آزمونمحور و Certificateی نداره، انتخاب کتاب خوب هم گاها نیاز به تورق و چک کردن چند تا کتاب داره تا بتونین گزینه بهتر رو انتخاب کنید.
منتظر کارتقرمزهای 🟥 بعدی باشید... 😉
خوشحال میشم تجربیات، نظر یا پرسشهاتون رو طرح کنید و گپ بزنیم 💬