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