یکی از اولین قربانی‌های پیدایش LLMها مثل ChatGPT یا Claudi رفیق قدیمی و وفادار برنامه‌نویس‌ها بود، یعنی Stackoverflow.

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

حداقل تا الان LLMها چیزی فراتر از یک auto complete خیلی خیلی بزرگ نیستن. درک و شعور به معنی رایج ندارن که خودشون استنتاج و تحلیل کنند. مگه اینکه آینده مدل‌هایی مثل o1 یا دستیابی به AGI شرایط رو تغییر بده!

به دو دلیل سعی کنیم از stackoverflow و google بیشتر استفاده کنیم:

۱: پویایی بیشتر، فرصت یادگیری و پرهیز از copy/paste که باعث میشه کم‌سوادتر بشیم و باسوادتر به نظر بیاییم!

۲: محیط زیست! هر یک سوال از ChatGPT مقدار زیادی کربن و گرما ایجاد می‌کن

🔅 چند هفته پیش نوشتم که تیم VS Code در حال پیاده‌سازی ECMAScript modules است، نتیجه ۲ سال توسعه مداوم و برنامه‌ریزی شده به اتمام رسید.

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

شاید در نگاه اول بگیم «خب به ما چه؟» ولی نکته اصلی درس چگونگی «مدیریت تغییرات» و نگاه همیشگی به تغییرات و روزآمدی زیرساخت‌های نرم‌افزار در کنار تغییرات فانکشنال است...

نظرتون چیه؟

✨ نکات ادمینی برای مهاجرت به PostgreSQL ویژه SQL Server DBA ها

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

بخش ۷ فلش‌کارت‌های قرمزمون، ویژه Failover، Disaster Recovery و Backup است. و به‌صورت روزانه کامل می‌شن ✍️

#MSSQL_to_PGSQL

- خیلی از نوآوری‌ها و بهینگی‌های پایگاه‌داده چه در سطح قابلیت‌های کاربردی، چه در سطح بهینه‌سازی‌های الگوریتمی و محاسباتی طی ۳۰ سال گذشته اول توی 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ی نداره، انتخاب کتاب خوب هم گاها نیاز به تورق و چک کردن چند تا کتاب داره تا بتونین گزینه بهتر رو انتخاب کنید.

منتظر کارت‌قرمزهای 🟥 بعدی باشید... 😉
خوشحال می‌شم تجربیات، نظر یا پرسش‌هاتون رو طرح کنید و گپ بزنیم 💬

🚀 🎉 و 17 PostgreSQL منتشر شد

توی این فلش‌کارت قرمزها در مورد PostgreSQL نوشته‌ام و خواهم نوشت، در مورد قابلیت‌های اختصاصی نسخه ۱۷ هم علاوه بر فلش‌کارت‌های عمومی، به صورت اختصاصی می‌نویسم (خصوصا که دیگه برای برخی کارهای ساده مثل بکاپ incremental نیازی به Barman نیست!)

حالا بیایم یکم سابقه‌اش رو مرور کنیم:

- خالق PostgreSQL استاد دانشگاه MIT و برنده جایزه تورینگ، آقای مایکل استون‌بریکر (Michael Stonebraker) است که اگر نقشش رو در حوزه DBMSها از خلق PostgreSQL تا کمک به توسعه Oracle و SQL Server و... بررسی کنیم، می‌تونیم بگیم یکی از هیولاهای این حوزه است.

- مایکل‌استونبریکر نقش خیلی مهمی در توسعه Object-Relational Databases و Columnar Storage داشته.

- شرکت‌هایی مثل Apple، Cisco، Netflix، ,Instagram, Spotify, Airbnb, Uber, Ayvens ازش استفاده می‌کنن. مایکروسافت سال ۲۰۱۹ Citus Data که مقیاس‌پذیری افقی و پردازش توزیع‌شده رو برای PostgreSQL فراهم می‌کنه خرید.

🧵