🔵 عنوان مقاله
How Darkhorse Emergency Tamed Complex PostgreSQL Schemas

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

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

بازجویی دوباره از مدیرعامل تلگرام در فرانسه

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

▪️این پرونده مربوط به بازداشت دورف در سال ۲۰۲۴ در فرانسه است؛ موضوع اصلی، نقش احتمالی تلگرام در انتشار محتوای غیرقانونی و ضعف در نظارت بر آن‌هاست.

▪️تیم حقوقی او با انتشار بیانیه‌ای تأکید کرده‌اند:

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

‌

مقاله خیلی جذابیه. نکات بسیار ارزشمندی رو میگه. نکات مهمی رو در مورد استفاده از PostgreSQL میگه وقتی که شما همزمان Write-Heavy و Read-Heavy هستی.
مقاله ایده های جالب و متفاوتی رو ارائه میکنه:
داشتن جداولی با حداکثر ۱۰۰ هزار رکورد برای داشتن index scanهای سریع و جلوگیری از کاهش عملکرد PostgreSQL
استفاده از index-only scans و مکانیزمی شبیه loose index scan برای کم کردن io operations
داشتن استراتژی compaction و VACUUM Analyze برای جلوگیری از عملکرد read queries با بزرگ شدن جدول دیتابیس
استفاده از دستور COPY به جای Insert برای batch insertهای زیاد و سنگین
استفاده از golang string type به جای byte slice برای transfer داده که عملکرد تقریبا ۲ برابر بهتری داشته!
Lessons from scaling PostgreSQL queues to 100k events per second
https://www.rudderstack.com/blog/scaling-postgres-queue/

<Hossein Nazari/>

نسخه 11.14 تلگرام منتشر شد

جستجوی پست‌ها
حالا می‌تونی پستای کانال‌های عمومی رو مستقیم سرچ کنی (فعلاً فقط برای پریمیومی‌ها)

آلبوم استوری
استوری‌هاتو می‌تونی تو آلبوم بچینی، مثل خاطره سفر یا معرفی محصول تو کانال‌ها

مجموعه هدیه‌ها
هدایاتو دسته‌بندی کن! مثلا نایاب‌ها، موضوعی‌ها و هرچی دلت خواست

امتیاز پروفایل
با خرید هدیه و پیام پولی، امتیاز می‌گیری و اعتبارت تو تلگرام بالا میره

هدایای خاص برای پریمیومی‌ها
هدایای خفن و محدود فقط برای کاربرای پریمیوم میاد

مینی‌اپ جدید BotFather
ربات‌سازی راحت‌تر از همیشه شده؛ مستقیم از مینی‌اپ جدید مدیریت کن

🐧 ویرایشگر کد Zed :
امکان غیرفعال‌سازی هوش مصنوعی 

🔹اZed چیست؟
اZed یک ویرایشگر کد مدرن و متن‌باز است که ویژگی‌های منحصر‌به‌فردی ارائه می‌دهد: 
✅ سبک و سریع (حتی روی سیستم‌های ضعیف) 
✅ پشتیبانی از چندین زبان برنامه‌نویسی 
✅ امکانات پیشرفته مانند دیباگر داخلی و Git Integration 

🔹 ویژگی جدید:
غیرفعال‌سازی هوش مصنوعی در آخرین آپدیت + امکان خاموش کردن کامل قابلیت‌های هوش مصنوعی اضافه شده است. 

🔸 مزایای این قابلیت:
- حفظ حریم خصوصی
(عدم ارسال کدها به سرورهای خارجی) 
- کاهش مصرف منابع سیستم 
- تمرکز بیشتر روی کدنویسی بدون مزاحمت پیشنهادات AI 
- امکان استفاده از مدل‌های محلی به جای سرویس ابری 

🔹 نحوه غیرفعال‌سازی:
- باز کردن تنظیمات (Ctrl+, یا Cmd+,) 
- جستجوی "AI" 
- غیرفعال کردن گزینه‌های مربوطه 

🔹 مقایسه با سایر ویرایشگرها:
- سرعت: Zed > VS Code > JetBrains 
- هوش مصنوعی: Zed (انعطاف‌پذیر) - VS Code (وابسته به افزونه) - JetBrains (پولی) 
- متن‌باز بودن: Zed و VS Code متن‌باز هستند 

🔹 دانلود:
🌐 وبسایت رسمی: zed.dev 
📥 برای ویندوز، مک و لینوکس در دسترس است.

👤 نویسنده: امیرحسین قاسم‌زاده
📚 منبع: zed.dev
➖➖➖➖➖➖➖➖
https://t.iss.one/addlist/QtXiQlynEJwzODBk

خلاصه‌ای مفید و مختصر از مقاله «Scalability Challenge: How to Remove Duplicates in a Large Data Set (~100M)» از Pankaj Tanwar
🎯 ۱. مسئله واقعی
فرض کن دنبال ارسال push notification به کاربران موبایل هستیم و نباید چندبار به یک دستگاه واحد برای یک کمپین، پیام ارسال شود. تگ دستگاه‌ها توسط push token مشخص می‌شود که بین ۳۲ بایت تا ۴ کیلوبایت حجم دارد و ممکن است یک شناسه بین چند پروفایل کاربر مشترک باشد (مثلاً در زمان نصب مجدد اپ). در نتیجه باید میان ~۱۰۰ میلیون توکن، موارد تکراری حذف شود. اگر بخواهیم همه را در حافظه نگه داریم، حدود ۲۵ گیگابایت رم نیاز است!

🔧 ۲. راه‌حل: استفاده از Bloom Filter
Pankaj پیشنهاد می‌دهد از Bloom Filter استفاده کنیم:

با استفاده از یک آرایه‌ی بیت و تعدادی تابع hash، هر توکن به یک یا چند بیت نگاشت می‌شود.

برای بررسی تکراری بودن، فقط درستی بیت‌ها را چک می‌کنیم؛ در صورت همه “on”، احتمال duplicate بالا است.

با این روش، حافظه لازم برای ۱۰۰ میلیون توکن و خطای احتمالی کمتر از ۰.۱٪ تا حداکثر خطا تنظیم‌شده، به حدود ۱۷۱ مگابایت کاهش می‌یابد (در مقایسه با ۲۵ GB قبلی)

✅ چرا این روش مفید است؟
حافظه بسیار پایین در مقابل دو نسخه نگهداری (25GB → 171MB)

زمان پاسخ سریع: فقط چند عملیات hash و خواندن بیت

پیاده‌سازی ساده و مقیاس‌پذیر ، به‌ویژه برای جریان بلادرنگ (streaming)

🔍 نکات فنی اضافی
Bloom Filter احتمال false positive (تشخیص اشتباه تکراری) دارد، اما هیچ false negative ندارد؛ یعنی اگر فیلتر اعلام کند تکراری نیست، قطعاً نیست.

انتخاب اندازه بیت‌مپ (m) و تعداد hash functionها (k) باید بر اساس n (تعداد ورودی) و نرخ خطای مورد قبول تنظیم شود.

هش‌های سریع و کارآمد مثل MurmurHash یا FNV بهتر از SHA یا MD5 هستند

در ادامه یک خلاصه‌ی کاربردی و دقیق از مقاله‌ی Gunnar Morling با عنوان «Postgres Replication Slots: Confirmed Flush LSN vs. Restart LSN»:

---

موضوع مقاله

در PostgreSQL، replication slots نقش حیاتی در نگهداری و مدیریت WAL (Write-Ahead Log) دارند تا مصرف‌کنندگان (مانند replicas یا ابزارهای CDC مثل Debezium) بتوانند بعد از قطع ارتباط، با اطمینان ادامه دهند. برای این منظور، دو شاخص LSN مهم وجود دارد: confirmed_flush_lsn و restart_lsn. دانستن تفاوت این دو برای عیب‌یابی replication و بهینه‌سازی نگهداری WAL ضروری است

---

اهمیت درک تفاوت آنها

* اگر confirmed_flush_lsn پیشرفت کرده اما restart_lsn همچنان ایستا باشد، به این معنی است که هنوز WAL قدیمی برای complete decoding مورد نیاز است.
* تعداد WALی که باید نگه‌داشته شوند برابر است با فاصله‌ی بین این دو LSN — این فاصلۀ WAL مصرفی در سیستم را تعیین می‌کند.
* اگر این فاصله بسیار بزرگ شود، ممکن است disk overflow (WAL bloat) رخ دهد و یا replication slot منسوخ شود.

---

نکته کلیدی از جامعه PostgreSQL

یکی از کاربران در StackOverflow توضیح داده:

ا> restart_lsn نمی‌تواند پیش رود تا تراکنش‌های باز که از آن شروع شده‌اند، کامل شوند؛ در حالی که confirmed_flush_lsn با هر تراکنش commitشده پیش می‌رود. ([Database Administrators Stack Exchange][3])

---

جمع‌بندی مفید

ا* `confirmed_flush_lsn`: نشان‌دهنده پیشرفت واقعی مصرف‌کننده (چه را دریافت کرده‌ایم).
ا* `restart_lsn`: نشان‌دهنده حداقل WALی که برای ادامه decoding نیاز داریم.
ا* فاصله بین این دو LSN نشانگر حجم WAL مورد نیاز است که باید حفظ شود تا سیستم replication به درستی کار کند.
ا* در تولید، مانیتور کردن این شاخص‌ها و تنظیماتی مثل max_slot_wal_keep_size به جلوگیری از بروز مشکلات ناشی از نگهداری بیش از حد WAL کمک می‌کند.

درود! مقاله‌ای تحت عنوان «Postgres HA Full-Sync» در سایت Multigres پیدا نکردم، اما در معرفی پروژه Multigres بخش‌های مرتبط با High Availability (HA) و سینک کامل (full sync) به‌وضوح وجود داشت. در ادامه خلاصه‌ای کاربردی و جامع در اختیار داری:

---

## معرفی Multigres

Multigres یک پروژه‌ای‌ست به‌منظور ساخت نسخه‌ای مشابه با Vitess برای PostgreSQL، اما کاملاً سازگار با اکوسیستم Postgres. این معماری با هدف افزایش مقیاس‌پذیری، HA و توزیع جهانی طراحی شده است و همچنان به عملکرد استاندارد PostgreSQL وفادار است.([Supabase][1], [multigres.com][2])

---
ویژگی‌های برجسته مرتبط با HA و Full Sync

* High Availability (اHA):

* پشتیبانی از failover خودکار و ترفیع خودکار replica در صورت خرابی، بنابراین سیستم همیشه آنلاین باقی می‌ماند

* اHorizontal Sharding:

* امکان تقسیم دیتابیس به بخش‌های جداگانه روی سرورهای مختلف با مدیریت خودکار—این قابلیت به افزایش مقیاس‌پذیری کمک می‌کند.([multigres.com][2])

* اConnection Pooling و Query Routing:

* لایه‌های اتصال و هدایت پرس‌و‌جوها به سمت shardها یا replicaهای مناسب، بهینه‌سازی عملکرد و کارایی را در پی دارد.([multigres.com][2])

* اCloud-Native Architecture:

* طراحی شده برای اجرا در محیط‌های Kubernetes با قابلیت‌هایی مانند backup خودکار و مدیریت کلاستر در مناطق جغرافیایی مختلف.([multigres.com][2])

---

در مورد "Full Sync"

در محتوای فراخوان‌شده اشاره مستقیمی به مفهوم full-sync replication نشده است. اما با توجه به اطلاعات اشاره شده، Multigres احتمالاً از تکنیک‌هایی مانند:

* اFailover خودکار و مراکز هماهنگ شده
* سینک دوباره داده‌ها بین replica و shards پس از قطعی
* رفتار مبتنی بر مدل‌های مشابه دو فازی (Two-Phase Synchronization) مانند آنچه در پادکست پروژه ذکر شد([Postgres FM][3])

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

🎯 آمادگی کامل IELTS با تدریس خصوصی و آنلاین

👑به دنبال نمره بالا در آیلتس هستی؟

🟢با استاد Mansourian، مدرس با تجربه مهارت‌های
🩵Speaking
🩵Writing
🩵Reading
🩵Listening

رو به بهترین شکل تقویت کن.

📌 کلاس‌ها به صورت آنلاین، خصوصی و روزانه برگزار میشه.

📈 پیشرفت سریع + برنامه‌ریزی دقیق برای رسیدن به هدفت.

💬 همین الان فالو کن و مسیر موفقیتت رو شروع کن!

👇پیج استاد توی انستاگرام 👇

https://www.instagram.com/english_razi_ielts

👌🏾Soheib Kiani


۲۰ تکنیک پیشرفته برنامهریزی منابع و مدیریت Performance در دیتابیسهای توزیعشده

Backend High Load
هر یک از این موارد، دانشی عمیق و عملی برای مهندس backend پیشرفته محسوب میشه:

Dynamic Partitioning
ایجاد پارتیشنهای پویا بر اساس زمان یا متریک خاص برای مدیریت حجم اطلاعات (مثلاً زمانبندی حذف خودکار دیتاهای منقضی)

Directory-based Sharding
استفاده از دیتابیس lookup برای نگاشت داده به shardهای مختلف، مناسب برای کنترل رشد داده به تفکیک ویژگی خاص

Range-based Sharding
تقسیم دادهها بر اساس بازه (مثلاً تاریخ یا ID)، به ویژه برای دیتاهای زمانمحور و تحلیلی

Hash-based Sharding
توزیع داده بر اساس هش یک کلید (key)، مناسب جهت پخش یکنواخت بار

Vertical Partitioning
تقسیم جداول بر اساس ستونهای پرمصرف یا کمتر مصرفشده و ذخیره هر بخش روی سرورهای مجزا برای افزایش بهرهوری

Replication (Master-Slave, Multi-Master)
تکثیر دادهها روی چندین node برای دسترسی بالا، redundancy و عملکرد بهتر خواندن؛ شامل Replication همزمان/غیرهمزمان

Change Data Capture (CDC) Replication
ایجاد همگامسازی بلادرنگ دادههای تغییر یافته، برای replication و ETLهای مقیاسپذیر

Data Consistency Models
انتخاب بین eventual consistency، strong consistency برای trade-off سرعت و دقت در سیستمهای توزیعشده

Multi-level Caching
بهرهگیری همزمان از cacheهای local (مثلاً memory app)، shared (مثلاً Redis/Memcached) و edge (CDN) برای حداکثر سرعت و کاهش بار دیتابیس

Cache Invalidation Strategies
استفاده از مکانیزمهایی مثل TTL، event-based، یا manual invalidation برای جلوگیری از stale data و اختلاف دیتا

Consistent Hashing for Distributed Cache
برای جلوگیری از hotspot و توزیع منصفانه کلیدها در cacheهای توزیعشده

Cache Replication
راهاندازی cache master-slave یا cluster برای افزایش دسترسی، توازن بار، و تحمل خرابی (Redis Sentinel, Cluster Mode)

Sharded Cache Architectures
تفکیک و توزیع کلیدهای cache روی چند سرور به شکلی که قابلیت گسترش و توازن بار داشته باشد

Cache Stampede Protection
پیادهسازی سیاستهایی مثل lock یا request coalescing برای جلوگیری از هجوم همزمان درخواستها هنگام miss شدن cache

Read/Write Splitting
هدایت درخواستهای خواندن به replicaها و نوشتن به master (در replication)، برای بهرهوری بیشتر از منابع

Vertical & Horizontal Scalability
استفاده درست از scale-up (افزایش منابع سرور) و scale-out (افزودن node جدید و sharding) وابسته به نیاز پروژه

Automated Partition Rebalancing
جابجایی یا تقسیم خودکار دادهها بین shardها با تغییر توزیع بار، کاهش hotspot و جلوگیری از ترافیک غیرمتعادل

Dynamic Resource Allocation
اختصاص خودکار منابع (مثل CPU, Memory) به shardها و cacheها مبتنی بر مانیتورینگ و نیاز لحظهای

Hybrid Partitioning Strategies
ترکیب partitioning افقی و عمودی برای استفاده بهینه و شخصیسازی تقسیم دیتا در سناریوهای خاص

Advanced Monitoring & Performance Tuning
رهگیری دقیق متریکهایی مثل hit ratio, latency, eviction rate و تنظیمات fine-tune (مثلاً policyهای eviction cache یا تنظیمات replication lag)

Kilo combines the best features of AI coding tools into one. Batteries included.
یه ابزار اوپن سورس که میتونید به کمکش از هوش مصنوعی حین کد زدن استفاده کنید یه جورایی رقیب cursor و cline محسوب میشه.

#AI #Tools #Coding #VSCode #IDE #Editor #GPT #Kilo


https://kilocode.ai

🤨 دارک مود؛ ناجی چشم‌ها یا یه توهم مدرن...؟!

خیلیا فکر می‌کنن دارک مود برای چشم سالم‌تره، اما تحقیقات علمی چی میگن؟ بررسی مطالعات جدید نشون میده که دارک مود هم مزایا داره، هم معایب!

مزایای علمی دارک مود :

▪️کاهش نور آبی : نور آبی زیاد، ریتم خواب رو مختل می‌کنه، و دارک مود می‌تونه به خواب بهتر کمک کنه.

▪️کاهش مصرف باتری : روی نمایشگرهای OLED، رنگ‌های تیره مصرف انرژی کمتری دارن.

▪️کاهش خیرگی در محیط‌های کم‌نور : وقتی نور اطراف کم باشه، دارک مود فشار کمتری به چشم وارد می‌کنه.

معایب علمی دارک مود :

▪️کاهش خوانایی متن در روز: چشم انسان به خوندن متن تیره روی پس‌زمینه روشن عادت داره، و دارک مود توی نور زیاد باعث خستگی چشم میشه.

▪️برخی تحقیقات نشون میدن که چشم توی حالت دارک مود بیشتر مجبور به تطبیق و تمرکز میشه، که می‌تونه خستگی ایجاد کنه.

▪️برخلاف تصور عموم، تغییر تم به تنهایی تأثیر زیادی روی کاهش خشکی و خستگی چشم نداره، بلکه میزان پلک زدن و استراحت دادن به چشم مهم‌تره.

چرا بسیاری از تیم‌ها ORM را کنار می‌گذارند و سراغ SQL خام می‌روند؟
اخیرا در مدیوم با تعداد زیادی از مقاله‌ها مواجه می‌شوم که یک پیام مشترک دارند:
«ما ORM را کنار گذاشتیم و به SQL خام مهاجرت کردیم — و دیگر برنمی‌گردیم.»

نکته جالب اینجاست که این تصمیم‌ها معمولاً از سر عشق به SQL گرفته نشده‌اند، بلکه از دل دردسرهای ORM زاده شده‌اند.
در چند مقاله‌ی اخیر که مطالعه کردم، تیم‌های مختلفی با تکنولوژی‌های مختلف (از Java + Postgres گرفته تا Go + SQLAlchemy) تجربه‌ی مهاجرت از ORM را به اشتراک گذاشته‌اند — نه فقط برای بهبود سرعت، بلکه برای بازگشت به شفافیت، کنترل و عقلانیت.

مشکل کجا بود؟ چرا ORM جوابگو نبود؟
اگرچه ORM در شروع پروژه‌ها خیلی مفید است (خصوصاً برای CRUDهای سریع و MVPها)، اما با رشد سیستم، مشکلاتی کم‌کم خود را نشان می‌دهند:

* معضل N+1 Query
کوئری‌هایی که ساده به نظر می‌رسند، در باطن ده‌ها یا صدها درخواست اضافه تولید می‌کنند.

* کدهای پیچیده اما غیرشفاف
برای کوئری‌های پیچیده‌تر مثل Window Function، CTE یا Join چندجدولی، باید به انواع annotationها، chainهای مبهم، یا زبان‌های خاص ORM (مثل JPQL) متوسل شد — که در نهایت باز هم می‌رسیم به نوشتن SQL، فقط با دردسر بیشتر.

* ضعف در دیباگ و پروفایلینگ
در ORM، به‌سختی می‌شود فهمید دقیقاً چه کوئری‌ای به دیتابیس رفته. این یعنی دیباگِ کندی‌ها تقریباً کورکورانه است.

* ناسازگاری با مدل واقعی داده‌ها
دیتابیس با row و index و join کار می‌کند؛ ORM با کلاس و رابطه شی‌گرایانه. این تطبیق، به‌ویژه در سیستم‌های پیچیده، منجر به کدهایی می‌شود که بیشتر شبیه «جنگیدن با ORM» هستند.

چرا SQL خام یک تفاوت واقعی ایجاد کرد؟
بعد از مهاجرت، همه تیم‌ها روی این دستاوردها تأکید داشتند:

* کنترل کامل
می‌دانیم چه کوئری نوشته‌ایم، چه زمانی اجرا می‌شود، و چگونه می‌توان آن را بهینه کرد.

* شفافیت
کوئری واضح است، بدون «جادوی مخفی». این یعنی همه تیم — از جونیور تا لید — متوجه می‌شود چه اتفاقی می‌افتد.

* هماهنگی بیشتر با منطق دامنه
به‌جای تعریف business logic در repository و annotation، همه‌چیز در لایه‌های مشخص خدماتی و use-case محور قرار می‌گیرد.

* استفاده کامل از قدرت دیتابیس
ویژگی‌هایی مثل Window Function، CTE، JSONB و Partial Index که در ORM اغلب یا پشتیبانی نمی‌شوند یا با پیچیدگی زیاد ممکن‌اند، در SQL خام به‌راحتی قابل استفاده‌اند.

نگهداری و مقیاس‌پذیری چطور مدیریت شد؟
برای جلوگیری از بی‌نظمی، تیم‌ها:

* کوئری‌ها را در فایل‌های جدا و نسخه‌دار نگه داشتند
* از template و query loaderهای سبک استفاده کردند
* روی هر کوئری تست (یا حداقل EXPLAIN) نوشتند
* قواعد ساده ولی سخت‌گیرانه‌ای برای امنیت (مثل پارامترگذاری) اعمال کردند

در نتیجه، برخلاف تصور اولیه، نگهداشت SQL خام هم قابل مدیریت و حتی لذت‌بخش شد.

کی باید ORM را کنار گذاشت؟
تجربه‌ی مشترک تیم‌ها نشان می‌دهد:

* برای پروژه‌های کوچک، MVPها یا پنل‌های ادمین، ORM عالی است.
* اما در پروژه‌های داده‌محور، با ترافیک بالا، کوئری‌های پیچیده و نیاز به کنترل عملکرد، ORM به‌جای کمک، تبدیل به مانع می‌شود.

جمع‌بندی
بسیاری از ما با ORMها بزرگ شده‌ایم اما آیا هنوز ORM بهترین ابزار ماست؟ یا فقط آسان‌ترین است؟
در دنیایی که عملکرد، شفافیت و کنترل ارزش بیشتری از سرعت اولیه دارند، شاید وقت آن است که دوباره به SQL خام یا ترکیب آن با ORm فکر کنیم — این بار با بلوغ بیشتر و ابزارهای بهتر.

<Mojtaba Banaie/>

🤖 علاقه‌مند به دنیای هوش مصنوعی هستی؟

🏖 دنبال می‌کنی که چطور AI داره دنیا رو متحول می‌کنه؟

🍻پس جای درستی اومدی!

🎯 در کانال ما هر روز:

🔍 جدیدترین اخبار و دستاوردهای دنیای AI

🧠 تحلیل‌ تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدل‌های زبانی

💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد

🛠 معرفی ابزارها، دوره‌ها و منابع یادگیری

📈 بررسی ترندها و آینده‌ فناوری‌های مرتبط با هوش مصنوعی

🍄همه‌ی این‌ها به زبان ساده، خلاصه و قابل فهم برای همه علاقه‌مندان — از مبتدی تا حرفه‌ای!
👇👇👇👇👇👇

https://t.iss.one/ai_labdon

🔵 عنوان مقاله
VectorChord 0.5: Scalable, Fast, and Disk-Friendly Vector Search

🟢 خلاصه مقاله:
این پروژه یک افزونه متن‌باز جست‌وجوی برداری برای PostgreSQL است که با مجوزهای AGPLv3 یا ELv2 عرضه می‌شود. مهم‌ترین ویژگی آن سازگاری با انواع داده و نحو پرس‌وجوی pgvector است، بنابراین می‌تواند در بسیاری از سامانه‌های موجود به‌صورت جایگزین کم‌دردسر (drop-in) به کار رود. سازندگان وعده افزایش قابل‌توجه کارایی نسبت به pgvector داده‌اند؛ بدین معنا که اجرای پرس‌وجوهای شباهت برداری با تأخیر کمتر و توان عملیاتی بالاتر ممکن می‌شود، هرچند میزان بهبود به سناریو و بار کاری وابسته است. تکیه بر PostgreSQL مزیت استقرار ساده در زیرساخت فعلی و حذف نیاز به سرویس جداگانه را حفظ می‌کند. دوگانه‌مجوز بودن نیز انعطاف برای استفاده متن‌باز و مسیرهای استفاده تجاری را فراهم می‌سازد. این دست ابزار معمولاً برای جست‌وجوی معنایی، RAG، سامانه‌های توصیه‌گر و پردازش چندرسانه‌ای کاربرد دارد. کد منبع و اطلاعات بیشتر از طریق مخزن GitHub در دسترس است.

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Indexing JSONB in Postgres

🟢 خلاصه مقاله:
اJSONB در PostgreSQL برای داده‌های نیمه‌ساخت‌یافته بسیار کاربردی است، اما سرعت بازیابی به انتخاب شاخص درست بستگی دارد. برای پرس‌وجوهای مبتنی بر وجود کلید معمولاً GIN بهترین گزینه است؛

ا jsonb_ops دامنهٔ وسیع‌تری از عملگرها را پشتیبانی می‌کند، در حالی‌که jsonb_path_ops برای شمول بهینه‌تر و کوچک‌تر است.

اگر مرتب روی یک مقدار اسکالر داخل JSONB فیلتر یا مرتب‌سازی می‌کنید (مثل data->>'sku')، شاخص B-tree روی یک عبارت یا ستون تولیدشده معمولاً سبک‌تر و سریع‌تر است. برای داده‌های سنگینِ نوشتاری، هزینهٔ نگهداری GIN را در نظر بگیرید و در صورت امکان از شاخص‌های جزئی و بیان‌محور استفاده کنید. در کل، شاخص را مطابق الگوی واقعی پرس‌وجو بسازید و نتیجه را با بنچمارک روی بار کاری خودتان تأیید کنید.

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Indexing JSONB in Postgres

🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چگونه با بهره‌گیری درست از قابلیت‌های ایندکس در پستگرس، بازیابی داده از JSONB را سریع و بهینه کنیم. هسته پیام این است که انتخاب نوع ایندکس باید بر اساس الگوی پرس‌وجو باشد: برای جست‌وجوهای شامل‌بودن و وجود کلید، GIN گزینه اصلی است (نسخه پیش‌فرض برای عملگرهای متنوع و jsonb_path_ops برای ایندکس کوچکتر و سریع‌ترِ خاص پرس‌وجوهای @>). برای فیلتر و سورت بر روی مقادیر اسکالر داخل JSONB، ایندکس‌های بی‌تری روی عبارت‌های استخراج‌شده (مثل user_id یا زمان) کاراترند؛ همچنین می‌توان از ایندکس‌های جزئی و پوششی برای کاهش هزینه خواندن استفاده کرد. باید میان سرعت خواندن، اندازه ایندکس و سربار نوشتن توازن برقرار کرد، با EXPLAIN صحت استفاده از ایندکس را سنجید و از ایندکس‌گذاری بیش‌ازحد پرهیز نمود؛ در موارد پرتکرار، تبدیل چند کلید مهم به ستون‌های تولیدی و ایندکس‌کردن آن‌ها تعادلی عملی میان انعطاف و کارایی ایجاد می‌کند.

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy