🔵 عنوان مقاله
Postgres, MongoDB, and What “Cannot Scale” Really Means

🟢 خلاصه مقاله:
در دنیای پایگاه‌های داده، مقوله مقیاس‌پذیری همواره یکی از چالش‌های مهم توسعه‌دهندگان و مدیران فناوری اطلاعات بوده است. در این میان، چندین سیستم محبوب مانند PostgreSQL و MongoDB نقش مهمی در استراتژی‌های داده‌ای شرکت‌ها ایفا می‌کنند. اما مفهومی که اغلب درباره آن صحبت می‌شود، یعنی «نتوانستن در مقیاس بزرگ» یا همان «Cannot Scale»، موضوعی است که باید به دقت بررسی شود تا حقیقت پشت آن مشخص گردد.

در خبر اخیر منتشر شده در نشریه «ذا ریجستر»، صحبت‌هایی از مدیرعامل شرکت MongoDB نقل شده است که ادعا می‌کند «PostgreSQL نمی‌تواند به راحتی در مقیاس بزرگ عمل کند». این دیدگاه، بازتاب دهنده نگرانی‌های رایج درباره محدودیت‌های سیستم‌های رابطه‌ای در مقایسه با سامانه‌های NoSQL است. ولی آیا واقعاً این ادعا درست است؟ یا شاید تعریفی نادرست از توانایی‌های هر سیستم است که در اینجا مطرح شده است؟

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

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

در نهایت، درک صحیح از محدودیت‌ها و قابلیت‌های هر سیستم، کلید موفقیت در طراحی زیرساخت‌های داده‌ای است. هر دو نوع پایگاه داده، یعنی PostgreSQL و MongoDB، ابزارهای قدرتمندی هستند که در مواقع مناسب، می‌توانند نیازهای مختلف سازمان‌ها را برآورده کنند، بدون اینکه به عبارتی «نمی‌توانند در مقیاس بزرگ» خرده‌ای وارد باشد.

#پایگاه_داده #مقیاس_پذیری #PostgreSQL #MongoDB

🟣لینک مقاله:
https://postgresweekly.com/link/178321/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
pgEdge shows off its new Postgres MCP server

🟢 خلاصه مقاله:
شرکت pgEdge به تازگی از سرور جدید خود با نام Postgres MCP رونمایی کرده است. این سرور قدرتمند امکان اتصال ابزارهای هوشمند مانند Claude Code به هر پایگاه داده پستگرس را فراهم می‌کند، تا کاربران بتوانند به راحتی با طرحواره‌ها، معیارها و داده‌های مختلف کار کنند. این فناوری نوآورانه به توسعه‌دهندگان و مدیران دیتابایک‌ها این امکان را می‌دهد که فرآیند مدیریت، تحلیل و بهره‌برداری از داده‌های خود را ساده‌تر و سریع‌تر انجام دهند. سرور MCP جدید، با طراحی مدرن و قابلیت‌های گسترده، نویدبخش پیشرفت‌های چشمگیری در حوزه مدیریت دیتابیک است و می‌تواند نقش مهمی در بهبود بهره‌وری و توسعه سیستم‌های پایگاه داده ایفا کند.

#پایگاه_دیتا #توسعه_فناوری #مدیریت_دیتابیس #پستگرس

🟣لینک مقاله:
https://postgresweekly.com/link/178677/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Microsoft Unveiled its VS Code 'IDE for Postgres'

🟢 خلاصه مقاله:
در ماه مه گذشته، شرکت مایکروسافت نسخه آزمایشی افزونه جدیدی برای ویرایشگر VS Code رونمایی کرد که مخصوص مدیریت پایگاه‌های داده پستگرس طراحی شده است. این افزونه امکانات متعددی را فراهم می‌کند، از جمله امکان مدیریت اشیاء دیتابیس، استفاده از فناوری IntelliSense برای ساخت کوئری‌ها و همچنین ادغام با سیستم هوشمند Copilot. این ابزار جدید، قابلیت‌های قدرتمندی را در اختیار توسعه‌دهندگان قرار می‌دهد تا بتوانند به راحتی و با سرعت بیشتری عملیات مربوط به پایگاه‌ داده‌های پستگرس را انجام دهند، بدون نیاز به ابزارهای جداگانه یا محیط‌های پیچیده.

این پیش‌نمایش نشان می‌دهد که مایکروسافت قصد دارد ابزارهای توسعه پایگاه داده‌ها را برای کاربران VS Code بیش از پیش یکپارچه و کاربرپسند کند، و توسعه‌دهندگان را در انجام وظایف مربوط به دیتابیس‌ها یاری دهد. با امکاناتی نظیر مدیریت اشیاء و کوئری‌نویسی هوشمند، این افزونه می‌تواند به طور چشمگیری فرآیندهای توسعه و نگهداری پایگاه‌های داده را تسهیل کند و بهره‌وری کلی را افزایش دهد.

#مایکروسافت #پستگرس #VSCode #توسعه‌دهندگان

🟣لینک مقاله:
https://postgresweekly.com/link/178689/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

بعضی وقتا گلوگاه performance دیتابیس از query یا infra نیست، از primary key میاد.

اUUID چون randomه، هر insert رو می‌فرسته یه جای متفاوت از B-treeی که برای ایندکس ها ساخته شده و ممکنه باعث شه درخت دوباره ساخت بشه؛ نتیجه‌اش cache miss، page split و write cost بالاتره. زیر بار دیتابیس زود به سقف CPU می‌رسه.

در مقابل، bigint auto-increment همیشه آخر index می‌نویسه و رفتار دیتابیس قابل پیش‌بینی میشه. تو تست‌های واقعی، فقط با عوض کردن UUID به bigserial، throughput چند برابر بهتر شده بدون اینکه data model یا business logic تغییر کنه.
اprimary key تصادفی یعنی مالیات دائمی روی هر write

راه بهتر اینه که primary key داخلی bigint باشه و یه public UUID برای بیرون سیستم داشته باشی. اگه client-generated id لازم داری، می‌تونی از time-orderd مثله Snowflake استفاده کنی تا keyها تقریبا ترتیبی باشن و توی سیستم های توزیع شده هم یکتا باشن و هم index اذیت نشه.

<Go Talk | گو تاک/>

🔵 عنوان مقاله
Multigres: Vitess for Postgres

🟢 خلاصه مقاله:
ویتس یک سیستم خوشه‌بندی محبوب است که عمدتاً برای افزایش مقیاس‌پذیری و تقسیم‌بندی داده‌ها در MySQL استفاده می‌شود. این سیستم توانسته است نیازهای شرکت‌ها و توسعه‌دهندگان را برای مدیریت حجم بزرگ داده‌ها و بهبود عملکرد پایگاه‌های داده برآورده کند. امسال، تیم Supabase یکی از بنیان‌گذاران و طراحان اصلی ویتس، آقای سوگو سوجومارانه، را برای توسعه نسخه‌ای مخصوص پایگاه داده PostgreSQL استخدام کرد. این پروژه در حال حاضر در مراحل اولیه قرار دارد و تیم توسعه در حال کار بر روی آن است تا بتواند امکانات و قابلیت‌های مشابه ویتس در محیط PostgreSQL را فراهم کند.

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

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

#پایگاه_داده #PostgreSQL #پروژه_بازمتن #توسعه

🟣لینک مقاله:
https://postgresweekly.com/link/178690/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

راهنمای کامل انواع Lock در Redis

از سری آموزش Redis رسیدیم 🔥
این بار یک پست جامع و کامل درباره تمامی Redis Locks منتشر می‌کنم.
چون هر کدام از این Redis Lock نیاز به سناریوی واقعی، کد ، تست دارن و این کار خیلی زمان‌بره، اول یک نمای کلی دقیق از همه‌شون می‌دم و بعد به‌مرور برای هر کدام یک پست جداگانه + پروژه واقعی + کد کامل منتشر می‌کنم.
لیست کامل ۱۲ نوع قفل مهم Redis که در این سری پوشش داده می‌شن:

1- Simple Lock
2- Safe Simple Lock
3- Redlock
4- Reentrant Lock
5- Read-Write Lock
6- Semaphore Lock
7- Fair Lock
8- Fencing Token Lock
9- Striped / Sharded Lock
10- Multi-Resource Lock
11- Auto-Renewal / Watchdog Lock
12- Leased Lock

لینک مقاله در Medium:
https://lnkd.in/dqWcJixP

👉Amirhossein Jafari
Devops EngineerDevops Engineer


آخر هفته گذشته روی راه‌اندازی Redis در Kubernetes کار می‌کردم و عملاً دوباره تفاوت مودهای مختلف Redis را بررسی کردم؛ از Standalone و Replication تا Sentinel و در نهایت Redis Cluster. چیزی که خیلی واضح مشخص می‌شه اینه که اگر مود اشتباه انتخاب بشه، حتی با infrastructure قوی هم خیلی سریع به مشکل performance یا availability می‌خوریم. Redis Cluster تنها مدلی هست که هم write scalability دارد و هم high availability واقعی، ولی در عوض کمی پیچیدگی بیشتری در اجرا و سمت کلاینت داره.
پیاده‌سازی Redis Cluster روی Kubernetes با StatefulSet و Headless Service، وقتی درست انجام شود، نتیجه‌اش کاملاً قابل مشاهده است: توزیع بهتر load، latency پایدارتر زیر فشار، و حذف single point of failure. توی تست‌هایی که داشتم، پخش شدن writeها روی چند master تأثیر مستقیم روی throughput داشت، مخصوصاً در workloadهای write-heavy. در نهایت، Redis فقط یک cache سریع نیست؛ معماری‌ای که براش انتخاب می‌کنیم مستقیماً روی رفتار سیستم در مقیاس و موقع failure اثر میذاره.

🔵 عنوان مقاله
PostgREST 14: A RESTful API for Postgres Databases

🟢 خلاصه مقاله:
در سال ۲۰۲۵، سال پرکاری برای سرورهای وب مستقل بود که به طور مستقیم، بانک اطلاعاتی پستگرس شما را به یک رابط برنامه‌نویسی تحت وب RESTful تبدیل می‌کنند. در این سال، نسخه‌های ۱۳ و ۱۴ این ابزار قدرتمند و محبوب عرضه شدند، هر کدام با قابلیت‌ها و بهبودهای خاص خودشان که کار توسعه‌دهندگان را بسیار راحت‌تر و کارآمدتر کرده است.

این پروژه، که PostgREST نام دارد، به توسعه‌دهندگان اجازه می‌دهد تا بدون نیاز به نوشتن کدهای پیچیده، به سرعت و با سهولت، از بانک اطلاعاتی پستگرس خود در قالب APIهای استاندارد استفاده کنند. نسخه‌های جدید علاوه بر بهبودهای عملکرد، امکانات تازه‌ای ارائه می‌دهند که توسعه و مدیریت APIها را ساده‌تر و انعطاف‌پذیرتر می‌سازند.

در مجموع، سال ۲۰۲۵ نشان داد که ابزارهای متن‌باز و مخصوص مدیریت بانک‌های اطلاعاتی، همچنان در حال توسعه و ارتقاء هستند و آینده‌ای روشن در انتظار آن‌ها است، چیزی که به توسعه‌دهندگان این امکان را می‌دهد تا در پروژه‌هایشان بهره‌وری بیشتری داشته باشند.

#پستگرس #API #وبسرویس #توسعه

🟣لینک مقاله:
https://postgresweekly.com/link/178696/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

مروری بر مفاهیم Vector Database

در ارائه اخیرم برای شرکت آپ، یک مخزن GitHub طراحی کردم تا اصول و الگوریتم‌های پایه‌ای vector databases را به شکل عملی نشان دهد. هدف این پروژه، آشنایی با حوزه‌های semantic search، vector similarity metrics و سیستم‌های بازیابی مبتنی بر بردار است و در عین حال فرصتی برای یادگیری عملی فراهم می‌کند.

ویژگی‌های کلیدی این repository شامل:
Neural network ساده با TensorFlow برای درک نحوه تولید بردارهای embedding
پیاده‌سازی یک vector database from scratch با cosine similarity برای فهم الگوریتم‌های جستجوی برداری
تحلیل داخلی Milvus internals برای بررسی معماری و بهینه‌سازی‌های عملکردی
نمونه عملی semantic search روی جملات با Milvus، شامل نحوه indexing و query بردارها
سرور MNIST FastAPI با PyTorch که تصویر عدد کاربر را دریافت کرده و نزدیک‌ترین بردارهای برچسب‌دار (nearest neighbor search) را پیش‌بینی می‌کند

این پروژه برای من علاوه بر یک تمرین عملی، فرصتی بود تا دانش خودم در زمینه vector-based retrieval systems را با دیگران به اشتراک بگذارم.

https://github.com/ap-incubator/vector-database

<Mohammad Nasr/

🔵 عنوان مقاله
Which Indexes Could Be Corrupted After an OS Upgrade?

🟢 خلاصه مقاله:
وقتی سیستم‌عامل شما به‌روزرسانی می‌شود، ممکن است تاثیراتی بر روی پایگاه‌های داده شما داشته باشد. یکی از این اثرات مهم، تغییر در نحوه تعریف و تنظیمات مقایسه‌کننده‌ها (collations) است که در بانک‌های اطلاعاتی مانند Postgres مورد استفاده قرار می‌گیرند. این به‌روزرسانی‌های سیستم‌عامل می‌تواند وابسته‌های نرم‌افزاری را بروزرسانی کرده و در نتیجه، ساختار و عملکرد برخی شاخص‌ها را مختل کند.

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

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

#پایگاه_داده #آسیب_پذیری #به‌روزرسانی_سیستم #شاخص‌ها

🟣لینک مقاله:
https://postgresweekly.com/link/178675/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

شرکت Microsoft قصد دارد تا پایان سال ۲۰۳۰ تمام کدهای نوشته‌شده به زبان‌های C و C++ را با Rust جایگزین کند.

👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0

سلام . در بخش‌های قبلی، نحوه ایجاد کلیدها در پایگاه‌داده Redis و همچنین تعیین قواعد نام‌گذاری برای آن‌ها را بررسی کردیم. در این بخش، تمرکز ما بر روی استفاده از دستور Keys و الگوهای تطبیق است که به شما امکان می‌دهد کلیدهای مورد نظر خود را بر اساس الگوهای خاصی جستجو کنید.
دستور Keys و الگوهای تطبیق :
دستور Keys در Redis به شما این امکان را می‌دهد تا کلیدهایی که با یک الگوی خاص مطابقت دارند را پیدا کنید. این الگوها می‌توانند شبیه به عبارات منظم (Regular Expressions) در زبان‌های برنامه‌نویسی مانند پایتون باشند. برای استفاده از این دستور، ابتدا باید الگوی مورد نظر خود را تعریف کنید. این الگو می‌تواند شامل کاراکترهای خاصی مانند ?، * و [] باشد که هر کدام معنای خاصی دارند. ادامه مطلب :
12- https://lnkd.in/db5vktZE
ذخیره داده ها : زمانی که شما سرور Redis را خاموش می‌کنید، دو گزینه اصلی دارید:
1. ذخیره داده‌ها (shutdown save): این گزینه باعث می‌شود که تمام داده‌های موجود در حافظه (RAM) سرور، بر روی دیسک ذخیره شوند. این کار تضمین می‌کند که پس از راه‌اندازی مجدد سرور، داده‌ها از دست نروند.
2. عدم ذخیره داده‌ها (shutdown nosave): این گزینه باعث می‌شود که داده‌های موجود در حافظه سرور ذخیره نشوند. در نتیجه، پس از راه‌اندازی مجدد سرور، داده‌های جدیدی که از آخرین ذخیره‌سازی ایجاد شده‌اند، از دست خواهند رفت.ادامه مطلب :
13- https://lnkd.in/dMHxVpMD

در این بخش به بررسی نحوه تغییر نام کلیدها در پایگاه‌داده Redis با استفاده از دستور RENAME می‌پردازیم. این دستور به شما امکان می‌دهد تا نام یک کلید موجود را تغییر دهید و در صورت نیاز، مقادیر آن را به کلید جدید منتقل کنید. همچنین، به برخی از نکات مهم در استفاده از این دستور نیز اشاره خواهیم کرد. ادامه مطلب :
14-https://lnkd.in/defRQbwa

❌ایا اینترنت شما هم ضعیفه؟❌

اره = 🕊

نه = 👾

در بلاگ Redis مقایسه‌ای عملی بین Redis Cloud و Amazon ElastiCache ارائه شده که برای انتخاب راه‌حل مناسب Redis در معماری‌های مدرن بسیار مفیده — مخصوصاً اگر پروژه‌تون تو AWS اجرا میشه.

🔑 ۱) مدل شبکه و اتصال
• ا**ElastiCache** فقط داخل VPC خصوصی AWS کار می‌کنه و اگر سرویس‌های خارج از اون VPC (حتی تو حساب یا اکانت دیگه) نیاز به دسترسی دارن، باید مسیر شبکه‌سازی پیچیده‌ای مثل Transit Gateway یا VPC Peering بسازید.
• ا**Redis Cloud** چند گزینه اتصال داره: VPC peering، AWS PrivateLink، Transit Gateway، حتی Public TLS endpoint با کنترل CIDR — که دسترسی امن بیرون از AWS یا بین حساب‌ها رو ساده‌تر می‌کنه.

⚡️ ۲) هزینه و بهره‌وری منابع
•ا ElastiCache (بر اساس Valkey/Redis) نیاز به رزرو حداقل ظرفیت، سربار حافظه، و replicaهای متعدد برای HA داره که در عمل باعث مصرف بیشتر منابع و هزینه بالاتر میشه.
•ا Redis Cloud معمولاً کارایی بهتری در حافظه و مقیاس داره (بدون رزرو غیرضروری و با مدل‌های multi-tenant) و کل هزینه‌ی مالکیت (TCO) رو پایین‌تر نگه می‌داره.

🛡 ۳) در دسترس‌بودن و مقاومت به خطا
• ElastiCache دارای HA پایه‌ای با replicaهاست، اما persistence اون فقط snapshot محور بوده که ممکنه تا یک ساعت داده‌های جدید رو تحت پوشش نده.
• Redis Cloud علاوه بر snapshot، از AOF بهره می‌بره و می‌تونه failover سریع‌تر و حفظ داده بهتر ارائه بده — گرچه هزینه‌ها به‌صورت AWS traffic still اعمال می‌شن.

📌 جمع‌بندی سریع:

* اگر فقط داخل یک VPC AWS هستید و نمی‌خواهید شبکه پیچیده بسازید، ElastiCache گزینه‌ی ساده‌تریه.
* اگر قرار سیستم شما چند VPC، چند حساب، دسترسی بیرونی، یا رشد سریع داشته باشه، Redis Cloud انعطاف‌پذیری و امکانات بیشتری ارائه می‌ده.

دیتابیسهای قدرتمند بساز بدون کد نوشتن! NocoDB ابزار اوپن سورس جایگزین Airtable

با رابط spreadsheet-like راحت، میتونی دیتابیس هارو بسازی ، ویوهای متنوع (گرید، کانبان، گالری، فرم، تقویم)، فیلتر/سورت پیشرفته، فرمولا، لینک/لوکآپ، کنترل دسترسی دقیق و ادغام با Slack، Discord، AWS S3 و کلی ابزار دیگه!

github.com/nocodb/nocodb‎

<POURYA/>

یه اشتباه رایجی که توی کار کردن با دیتابیس MySQL وجود داره اینه که فکر میکنیم دیتا مستقیم روی دیسک ذخیره میشه و از دیسک خونده میشه، اما واقعیت اینه که MySQL یه الگوریتم جالبی برای بهینه کردن پرفورمنس داره تا بتونه پردازش کوئری ها رو به خوبی هندل کنه.

توی این مقاله خیلی ساده flow اجرای یه کوئری رو توضیح دادم که MySQL دقیقا پشت صحنه چه فرآیندی رو انجام میده تا هم پرفورمنس رو حفظ کنه و هم نتیجه رو به کاربر برگردونه. میتونید مقاله رو توی لینک زیر بخونید:

https://farshadth.medium.com/how-mysql-works-behind-the-scenes-72746950cd65

<Farshad Tofighi/>

وقتی SQL Server بیش‌ازحد به حافظه‌اش اعتماد می‌کنه.

خیلی وقت‌ها مشکل از خود کوئری نیست،
از Execution Plan قدیمیه که دیگه با دیتای فعلی هم‌خوانی نداره.

سناریوی رایج:

Batch Update با TOP
لوپ یا Job طولانی
دیتایی که وسط کار شدیداً تغییر می‌کنه
کوئری بی‌خطا تموم میشه، ولی هنوز دیتا باقی مونده!

علتش؟ SQL Server یه Plan می‌سازه، Cache
می‌کنه و میگه:
«دفعه بعد هم اوضاع همینه»
در حالی که نیست.
اینجاست که این خط نجات‌دهنده میاد وسط:
OPTION (RECOMPILE)

چی کار می‌کنه؟
هر بار Compile جدید، تخمین دقیق‌تر، Join درست‌تر، Memory Grant واقعی، پایان دادن به رفتارهای «عجیب ولی بی‌خطا»

جمع‌بندی:

ء Recompile یعنی «تصمیم‌گیری با وضعیت امروز دیتا، نه خاطرات دیروز»

| <Sajjad Zibafar/>

وضعیت اینترنت ایران طبق رادار های کلود فلیر
احتمال قطع دسترسی اینترنت با این وضعیت خیلی زیاده...
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0

🔵 عنوان مقاله
Kafka is Fast, I'll Use Postgres

🟢 خلاصه مقاله:
کافکا سریع است، پس من از پستگرس استفاده می‌کنم.
در حالی که از یک پست دیگر درباره جایگزینی پستگرس به جای ری‌دیس برای کشینگ الهام گرفته شده بود، نویسنده تصمیم گرفت بررسی کند آیا پستگرس واقعاً قدرتمند است و می‌تواند در مواردی که معمولاً کافکا انتخاب می‌شود، عملکرد مناسبی داشته باشد.
در این مقاله، او به مقایسه قابلیت‌های پستگرس و کافکا پرداخته و بررسی می‌کند که آیا پستگرس به عنوان جایگزینی سریع و کارآمد، می‌تواند نیازهای جریان داده، پیام‌رسانی و پردازش رویداد را برآورده سازد یا خیر.
نتیجه‌گیری نشان می‌دهد که در برخی موارد، پستگرس می‌تواند گزینه‌ای گزینه‌پذیر بر جای کافکا باشد، به‌ویژه زمانی که سادگی، هزینه و سازگاری با زیرساخت‌های موجود اهمیت دارد. این مقاله دیدگاه جدیدی در انتخاب ابزارهای مدیریت داده‌ها و جریان‌های اطلاعاتی ارائه می‌دهد.
#پستگرس #کافکا #مدیریت_دیتا #تکنولوژی

🟣لینک مقاله:
https://postgresweekly.com/link/178913/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Postgres in the Time of Monster Hardware

🟢 خلاصه مقاله:
در دنیای امروز، تصور کنید که پردازشگر مورد استفاده در سیستم‌های کاری شما چقدر قدرتمند است. ممکن است باور نکنید، اما تصور داشتن پردازنده‌ای مانند AMD EPYC با ۱۹۲ هسته در هر سوکت و رم ۱۰ ترابایتی، کاملاً در دسترس است. این نوع از سخت‌افزارهای مدرن، قابلیت‌هایی بی‌نظیر را فراهم می‌کند و قدرت پردازش فوق‌العاده‌ای را در اختیار ما قرار می‌دهد. چنین امکاناتی، ما را به سؤال‌هایی درباره روش‌های امروزی برای توسعه و مقیاس‌بندی سرورهای پایگاه داده و بهره‌برداری بهینه از این سخت‌افزارهای عظیم، وا می‌دارد.

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

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

#پایگاه_داده #مقیاس‌پذیری #تکنولوژی_مدرن #سخت‌افزار

🟣لینک مقاله:
https://postgresweekly.com/link/178922/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Benchmarking Postgres 17 vs 18

🟢 خلاصه مقاله:
در این مقاله، نویسنده به بررسی و مقایسه دقیق عملکرد نسخه‌های مختلف پایگاه داده PostgreSQL، یعنی نسخه‌های ۱۷ و ۱۸، پرداخته است. او با اجرای مجموعه‌ای گسترده از آزمون‌ها در حدود ۹۶ ترکیب متفاوت، تلاش کرده است تا تفاوت‌های عملکرد این دو نسخه را ارزیابی کند. نتایج این آزمایش‌ها نشان می‌دهد که نسخه ۱۸ پایگاه داده PostgreSQL، در کنار بهبودهای عملکردی قابل توجه، مزایای بیشتری نسبت به نسخه قبلی خود دارد.

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

در پایان، می‌توان نتیجه گرفت که PostgreSQL ۱۸ نسبت به نسخه‌های پیشین خود، پیشرفت قابل توجهی دارد و بهره‌مندی از دیسک‌های داخلی و انجام تنظیمات دقیق، ارزش ادامه‌دار بودن این بهبودها را دوچندان می‌سازد.

#پایگاه_داده #PostgreSQL #بهبود_عملکرد #تست_پرفورمنس

🟣لینک مقاله:
https://postgresweekly.com/link/178918/web

➖➖➖➖➖➖➖➖
👑 @Database_Academy