🔵 عنوان مقاله
What You Can Expect From PGConf.dev

🟢 خلاصه مقاله:
در ادامه برنامه‌های پیش روی کنفرانس PGConf.dev، شما می‌توانید انتظار چه مواردی را داشته باشید؟ ملانی پلاگمن در این باره با کلر جیوردانو گفتگو کرده است تا جزئیات و برنامه‌های مهم این رویداد مهم در ماه مه آینده در ونکوور، کانادا را با شما به اشتراک بگذارد. این کنفرانس فرصت بی‌نظیری است برای توسعه‌دهندگان و فعالان حوزه فناوری برای آشنایی با جدیدترین دستاوردها، به‌اشتراک‌گذاری تجربیات، و برقراری ارتباط با متخصصان برجسته در صنعت. حضور در چنین رویدادی نه تنها امکان یادگیری مهارت‌های جدید را فراهم می‌آورد، بلکه راه‌های تازه‌ای برای گسترش شبکه حرفه‌ای شما باز می‌کند و نقش مؤثری در پیشرفت شخصی و حرفه‌ای‌تان دارد. در نهایت، این کنفرانس برآن است تا با برگزاری جلسات، کارگاه‌ها و گفتگوهای آموزشی غنی، آینده فناوری و توسعه نرم‌افزار را شکل دهد و فرصت ارزشمندی برای شرکت‌کنندگان فراهم آورد.

#کنفرانس_توسعه #فناوری #شبکه_سازى #رشد_حرفه‌ای

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🥇 اگر عاشق تکنولوژی‌های روز دنیا هستی، اینجا هر روز تازه‌ترین و مهم‌ترین مطالب درباره:👇

🛰 فضا و اکتشافات فضایی و تکنولوژی های مرتبط فضای
⚡️ برق و انرژی‌های نو
🔌 دنیای الکترونیک و گجت‌های هوشمند و انواع پهپاد ها
🚗 خودروهای برقی و آینده حمل‌ونقل

همه چیز به‌صورت کوتاه، خلاصه و کاملاً قابل‌فهم👇👇

🥈 @futurepulse_persian

🔵 عنوان مقاله
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/