وکتور دیتابیس‌ها (Vector Databases)
در دنیای امروز، با رشد مدل‌های زبانی بزرگ (LLMها) و اپلیکیشن‌های هوش مصنوعی، یک نیاز جدید در حوزه ذخیره‌سازی داده به‌وجود آمده که چیزی نیست جز درک معنا، نه فقط داده‌های خام.
اینجاست که وکتور دیتابیس‌ها (Vector Databases) وارد صحنه می‌شوند.

برخلاف دیتابیس‌های سنتی که داده‌ها را بر اساس کلید، متن یا ساختار ذخیره‌سازی می‌کنند، وکتور دیتابیس‌ها داده‌ها را به صورت بردارهای عددی چندبُعدی نگهداری می‌کنند. این بردارها در واقع نمایانگر معنا و مفهوم پشت داده‌ها هستند نه صرفاً کلمات یا مقادیر ظاهری.
کاربرد اصلی این نوع دیتابیس‌ها در سیستم‌هایی است که نیاز به جست‌وجوی معنایی (Semantic Search)، تطبیق شباهت (Similarity Matching) و حافظه بلندمدت برای LLMها دارند. به‌عنوان مثال، در یک چت‌بات هوشمند، وکتور دیتابیس کمک می‌کند تا سیستم مکالمات قبلی یا اطلاعات مشابه را بر اساس معنا بازیابی کند، نه فقط تطبیق واژه‌ها.

تفاوت اصلی با دیتابیس‌های سنتی
در دیتابیس‌های رابطه‌ای یا NoSQL، داده بر اساس کلیدها و تطبیق دقیق بازیابی می‌شود.
اما در وکتور دیتابیس، داده‌ها بر اساس درجه شباهت معنایی پیدا می‌شوند.
یعنی اگر کاربر بگوید:
"بهترین مکان برای مطالعه با قهوه خوب"
سیستم می‌تواند داده‌هایی مثل "کافه مناسب برای فریلنسرها" را هم به عنوان نتیجه مرتبط برگرداند.

️ نمونه‌های شناخته‌شده وکتور دیتابیس‌ها
ابزار Pinecone : سرویس ابری مخصوص ذخیره و جست‌وجوی برداری (ساده برای اتصال به LLMها)
ابزار Weaviate : متن‌باز و ماژولار، با قابلیت اضافه کردن embedding model داخلی
ابزار Milvus : یکی از قدرتمندترین پلتفرم‌های متن‌باز در مقیاس بالا (ساخته Zilliz)
ابزار Qdrant : دیتابیس برداری سریع و سبک با API دوستانه (مناسب پروژه‌های کوچک تا متوسط)
ابزار pgvector : افزونه PostgreSQL برای ذخیره و جست‌وجوی برداری (راه ساده برای پروژه‌های موجود)

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

وکتور دیتابیس‌ها پلی هستند بین داده‌های ساخت‌یافته و درک انسانی.
فناوری‌ای که به سیستم‌ها کمک می‌کند “بفهمند”، نه فقط “ذخیره کنند”.

<Amir Rahimi Nejad/>

🔵 عنوان مقاله
PostgreSQL Event Calendar

🟢 خلاصه مقاله:
PostgreSQL Event Calendar یک سایت متمرکز برای رصد رویدادهای مرتبط با Postgres است و یک فایل ICS / iCalendar هم ارائه می‌دهد که می‌توانید به تقویم خود اضافه کنید تا رویدادها را بدون پیگیری دستی دنبال کنید. فهرست رویدادها تا PGDay Austria در سپتامبر 2026 ادامه دارد که امکان برنامه‌ریزی بلندمدت را برای علاقه‌مندان و اعضای جامعه Postgres فراهم می‌کند.

#PostgreSQL #Postgres #iCalendar #ICS #TechEvents #DatabaseCommunity #PGDayAustria #OpenSource

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Transaction Pooling in Postgres with Pgcat

🟢 خلاصه مقاله:
این مرور سه موضوع مرتبط در عملیات Postgres را کنار هم می‌گذارد: مدیریت اتصال‌ها با Transaction Pooling از طریق Pgcat، سفر یک پرس‌وجوی SQL درون Postgres، و نقش «Dirty Pages» در کارایی و دوام. در Transaction Pooling، Pgcat اتصال‌های سمت سرور را فقط در طول تراکنش قرض می‌دهد و با افزایش استفاده مجدد از Backendها، هزینه اتصال‌های کوتاه‌عمر را کاهش می‌دهد—به‌ویژه در بارهای Serverless و Microservices. بهای آن، حساسیت به حالت‌های سطح نشست است؛ پس باید وضعیت را داخل تراکنش نگه داشت و به زمان‌بندی‌ها، اندازه Pool و مشاهده‌پذیری توجه کرد. «سفر» Phil Eaton نشان می‌دهد پرس‌وجو چگونه از Parse/Rewrite/Plan به Execution می‌رسد، با تکیه بر آمار و ایندکس‌ها، MVCC، قفل‌ها، Shared Buffers و WAL. توضیحات Jesús Espino و Umair Shahid درباره Dirty Pages می‌گوید صفحاتِ تغییرکرده در حافظه برای کارایی خوب‌اند، اما باید با Checkpoint، Background Writer و تنظیمات WAL مدیریت شوند تا از جهش‌های تاخیری جلوگیری شود. کنار هم، این سه دیدگاه کمک می‌کنند با تغذیه کارآمد اتصال‌ها، فهم مسیر اجرای پرس‌وجو و تنظیم مسیر نوشتن، Postgres را سریع‌تر و قابل‌پیش‌بینی‌تر اجرا کنید.

#Postgres #Pgcat #TransactionPooling #ConnectionPooling #SQL #DatabaseInternals #DirtyPages #WAL

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
PGSync 5.0: Postgres to ElasticSearch/OpenSearch Syncing

🟢 خلاصه مقاله:
PGSync 5.0 یک میان‌افزار برای همگام‌سازی داده‌های Postgres با ElasticSearch/OpenSearch است. این ابزار تغییرات دیتابیس را به‌صورت لحظه‌ای دریافت می‌کند و آن‌ها را به اسناد ساخت‌یافته JSON تبدیل کرده و در ایندکس‌های جست‌وجو می‌نویسد. هدف آن کاهش پیچیدگی ETL سفارشی، پایداری و تاخیر پایین در به‌روزرسانی ایندکس‌ها است. PGSync از الگوهایی مثل backfill اولیه، استریم‌ تغییرات، denormalization، نگاشت انعطاف‌پذیر جدول‌به‌سند و upsertهای idempotent پشتیبانی می‌کند. در نسخه ۵ تمرکز بر کارایی، سادگی پیکربندی و سازگاری یکپارچه با ElasticSearch و OpenSearch است تا مسیر پایدار و سریعی از جدول‌های Postgres به اسناد قابل جست‌وجو فراهم شود.

#PGSync #Postgres #ElasticSearch #OpenSearch #CDC #SearchIndexing #DataSync #RealTime

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

منطق پشت کلاستر این CockroachDB چقدر قشنگه.
نوعی دیتابیس SQL که به صورت Master Master کلاستر میشه و از پروتکل RAFT استفاده میکنه.

اما چی!؟ ، مگه RAFT ساختارش به صورت Master Slave ایی تعریف نمیشد؟ پس چجوری توی دیتابیس Master Master داره استفاده‌ میشه؟
شاید اونجوری که CockroachDB میگه اصلا Master Master ایی در کار نیست یا تعریف ما متفاوته .
خلاصه اگه علاقه مند هستین چجوری توی CockroachDB ما RAFT داریم، خوشحال میشم مقاله ایی رو که نوشتم مطالعه کنین، حدودا هم ۵ دقیقه وقتتون رو میگیره.

https://medium.com/@parsagheiratian/the-mentality-behind-cockroachdb-0ed524fcc7ec

<Parsa Gheiratian/>
️️

🔵 عنوان مقاله
The Art of Lean Governance: The Cybernetics of Data Quality (5 minute read)

🟢 خلاصه مقاله:
** این مقاله پیشنهاد می‌کند برای مدیریت کیفیت داده‌ها از رویکرد سایبرنتیک استفاده شود؛ یعنی اکوسیستم داده مانند یک سامانه خودتنظیم و یادگیرنده با حلقه‌های بازخورد، کنترل و بهبود مداوم دیده شود. عناصر کلیدی شامل موتورهای پویا برای آشتی‌دادن داده‌ها در لحظه، واژه‌نامه‌های کسب‌وکارِ تعبیه‌شده برای یکپارچگی معنایی، و تبارشناسی کامل داده‌ها جهت ردیابی علّی و حاکمیت قوی بر AI است. حاکمیت چابک با سیاست‌ها به‌صورت کد، دروازه‌های کیفیت در CI/CD، و اتوماسیون رویدادمحور اجرا می‌شود؛ مالکیت در تیم‌های دامنه است و گروه مرکزی فقط استانداردها و ابزار مشترک را فراهم می‌کند. با تعریف SLOهای کیفیت و اجرای چرخه کشف → تشخیص → اصلاح → راستی‌آزمایی → یادگیری، کنترل‌ها به‌صورت پیش‌دستانه و مقیاس‌پذیر اعمال می‌شوند و ریسک، هزینه و زمان رفع خطا کاهش می‌یابد.

#DataQuality #Cybernetics #DataGovernance #AIGovernance #DataLineage #Observability #LeanGovernance #MLOps

🟣لینک مقاله:
https://tdan.com/the-art-of-lean-governance-the-cybernetics-of-data-quality/33051?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعه‌ای از منابع برای طراحی low level و high level توی مصاحبه‌های الگوریتمی و برنامه‌نویسی

#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question


https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD

🔵 عنوان مقاله
PlanetScale for Postgres is Now GA

🟢 خلاصه مقاله:
PlanetScale اعلام کرد که PlanetScale for Postgres به مرحله GA رسیده و اکنون برای همه کاربران در دسترس است. این حرکت پس از آن انجام شد که شرکت در ماه جولای ورود خود به فضای PG را اعلام کرد و مجموعه‌ای از بنچمارک‌ها را منتشر نمود. این سرویس تا امروز در فاز private preview بود و اکنون برای استفاده در محیط‌های تولیدی آماده اعلام شده است. به این ترتیب، تیم‌هایی که بر Postgres تکیه دارند می‌توانند از پیشنهاد جدید PlanetScale استفاده کرده و آن را در مقیاس عملیاتی امتحان کنند.

#PlanetScale #Postgres #PG #Database #Cloud #GA #MySQL #DevOps

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Building a Dev Experience for Postgres in VS Code

🟢 خلاصه مقاله:
مایکروسافت با حضور Rob Emanuele در پادکست Talking Postgres به میزبانی Claire Giordano درباره ساخت یک تجربه توسعه‌دهنده برای Postgres در VS Code صحبت می‌کند. محور گفتگو، افزونه تازهٔ «IDE for Postgres» است که اوایل امسال توسط Microsoft منتشر شد و هدفش آوردن کارهای روزمرهٔ پایگاه‌داده به دل محیط آشنای VS Code و کاهش جابه‌جایی بین ابزارهاست. در این قسمت به انگیزه‌ها، چالش‌های رایج برنامه‌نویسان، نقش بازخورد جامعه، و مسیر آیندهٔ ابزار پرداخته می‌شود تا نشان دهد این افزونه چگونه گردش‌کار نوشتن و آزمون SQL و مدیریت تغییرات را ساده‌تر می‌کند.

#Postgres #VSCode #Microsoft #DeveloperExperience #TalkingPostgres #IDE #DatabaseTools #VSCodeExtension

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)

🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای به‌روزرسانی داده‌ها معمولاً بهتر از INSERT OVERWRITE است، زیرا به‌جای بازنویسی پارتیشن‌ها، تغییرات را به‌صورت دلتا در سطح فایل اضافه می‌کند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاه‌تر و صرفه‌جویی در هزینه ذخیره‌سازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن می‌شود و در مواجهه با Partition Evolution آسیب‌پذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی داده‌های تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشرده‌سازی و خانه‌تکانی دوره‌ای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیش‌فرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه می‌شود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.

#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL

🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
All You Can Do Before Airflow (5 minute read)

🟢 خلاصه مقاله:
ساده‌ترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپت‌های Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمان‌بندی‌های مدیریت‌شده مثل Cloud Scheduler یا EventBridge به‌همراه logging، retry و alert کفایت می‌کند. نشانه‌های نیاز به Airflow زمانی ظاهر می‌شوند که وابستگی‌ها و DAGها پیچیده می‌شوند، backfill و SLA اهمیت پیدا می‌کند، مالکیت بین تیم‌ها توزیع می‌شود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیء‌استور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: ساده‌ترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.

#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability

🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
How to Listen to Database Changes Through the WAL

🟢 خلاصه مقاله:
شنیدن تغییرات دیتابیس از طریق WAL در Postgres یک روش پایدار برای CDC است که بدون تریگر و پولینگ اضافه، رویدادهای INSERT/UPDATE/DELETE را با ترتیب مبتنی بر LSN و قابلیت بازیابی استریم می‌کند. راه‌اندازی شامل wal_level=logical، ساخت replication slot، انتخاب output plugin مثل pgoutput یا wal2json، گرفتن snapshot اولیه و ذخیره LSN برای پیشرفت مصرف‌کننده است. از منظر عملیاتی باید نگه‌داری WAL توسط replication slot، backpressure، تراکنش‌های بزرگ، تغییرات schema، و مدیریت failover و امنیت را پایش کنید و با طراحی آیدمپوتنت در مقصد، تحویل at-least-once را کنترل کنید. در مطالب مرتبط، Peter Ullrich به transaction pooling با Pgcat و قیود آن می‌پردازد، Phil Eaton سفر یک کوئری SQL را در Postgres از parse تا execution روایت می‌کند، و Umair Shahid مفهوم Dirty Pages، نقش background writer/checkpointer و اثر تنظیمات بر پایداری I/O را توضیح می‌دهد.

#Postgres #WAL #ChangeDataCapture #LogicalDecoding #Pgcat #SQL #DirtyPages #DatabaseInternals

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

کاهش هزینه سیستم‌های هوش مصنوعی با Semantic Caching

با رشد مدل‌های زبانی بزرگ و پیشرفته، هزینه و زمان پاسخ‌دهی هم به شدت افزایش پیدا کرده. مدل‌هایی مثل GPT-5 یا Claude برای کارهای پیچیده فوق‌العاده‌اند، ولی استفاده از اون‌ها هم پرهزینه و هم کند محسوب می‌شه. از طرف دیگه، AI Agentها واقعاً «توکن‌خور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی می‌کنن: تحقیق، برنامه‌ریزی، عمل و بازتاب و تکرار. همین باعث می‌شه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متن‌های طولانی‌تر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.

یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوال‌هاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوال‌های مشابهی می‌پرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور می‌شه هر بار پاسخ رو از صفر تولید کنه. نتیجه‌ش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستم‌های RAG و زیرساخت‌هاست.

در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت می‌کنه. ایده‌ی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوال‌هایی که از نظر معنی یکی هستن ولی عبارت‌هاشون فرق می‌کنه، مثل: «می‌خوام پولم رو پس بگیرم»، «چطور می‌تونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss می‌شن و کش عملاً استفاده نمی‌شه.

اینجاست که Semantic Caching وارد می‌شه. به جای تطابق کلمه‌به‌کلمه، کش به معنی و مفهوم جمله نگاه می‌کنه. مزیت اصلی‌ش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفه‌جویی خیلی بیشتر می‌شه. البته چالشش هم اینه که گاهی ممکنه جواب بی‌ربط بده یا همون «False Positive» رخ بده.

روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل می‌شه. بعد با بردارهای موجود در کش با Semantic Search مقایسه می‌شه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده می‌شه؛ در غیر این صورت به RAG یا LLM می‌ریم. در نهایت سوال و پاسخ جدید هم ذخیره می‌شه تا دفعه بعدی قابل استفاده باشه.

پیاده‌سازی Semantic Caching با چالش‌هایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست می‌ده، کارایی (Performance) و میزان Cache Hit، سرعت سرویس‌دهی، آپدیت‌پذیری کش و اینکه آیا می‌تونیم کش رو گرم، تازه‌سازی یا پاکسازی کنیم. همچنین مشاهده‌پذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفه‌جویی هزینه و کیفیت کش رو بسنجیم.

معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون می‌ده چند درصد درخواست‌ها از کش پاسخ داده می‌شن و Precision/Recall/F1 Score که کیفیت و دقت پاسخ‌ها رو مشخص می‌کنه. برای بهبود دقت و کارایی کش هم می‌تونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسش‌های زمان‌محور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.

یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اون‌ها با نوآوری‌هایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG می‌ره. نتیجه‌ش رسیدن به دقت نزدیک ۹۰٪ بوده.

<Reza Jafari/>

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

🔵 عنوان مقاله
Spock: Logical Multi-Master PostgreSQL Replication

🟢 خلاصه مقاله:
این مقاله Spock را معرفی می‌کند؛ لایه‌ای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه می‌دهد چند نود هم‌زمان عملیات نوشتن را بپذیرند و داده‌ها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال می‌کند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم می‌سازد.

نویسنده چالش‌های اصلی Multi‑Master را توضیح می‌دهد: تشخیص و رفع تضادهای نوشتن، سیاست‌های قابل پیکربندی مثل last‑update‑wins یا روش‌های سفارشی، مدیریت شناسه‌های یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز می‌تواند تعارض‌ها را کم کند. نتیجه‌گیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینه‌ای قوی است.

در مقایسه با گزینه‌های دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی می‌گذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را می‌دهد. از آن‌جا که این مطلب در Golang Weekly آمده، نکات پیاده‌سازی برای سرویس‌های Go نیز مطرح می‌شود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستم‌های رویدادمحور قابل اتکا.

#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
discuss what went wrong (and right!) with implementing asynchronous I/O

🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیاده‌سازی I/O ناهمگام توضیح می‌دهد که چرا ایده «عدم انسداد» ساده به نظر می‌رسد اما در عمل با تفاوت‌های پلتفرمی و جزئیات ظریف سیستم‌عامل پیچیده می‌شود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نه‌تنها APIها متفاوت‌اند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبه‌ای یا سطحی، زمان‌بندی، و چرخه عمر denoscriptorها هم فرق می‌کند.

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

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

در عوض، نقاط قوت هم پررنگ‌اند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانه‌های net/http و database/sql رفتارهای امن‌تری فراهم کرده‌اند. روی Linux، آزمایش‌های محتاطانه با io_uring امید به کاهش syscallها و بیدارباش‌ها را نشان می‌دهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارک‌های دقیق هم جلوی پسرفت‌ها را گرفته‌اند.

جمع‌بندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازه‌گیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صف‌ها، wakeupها و تعامل با scheduler سرمایه‌گذاری کنید. از قابلیت‌های جدید کرنل به‌صورت افزایشی و با احتیاط استفاده کنید و سطح برنامه‌نویسی را ساده نگه دارید. در عمل، از فراخوانی‌های مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بی‌رویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعی‌اند، اما با انضباط مهندسی به‌دست می‌آیند، نه صرفا با انتخاب یک primitive جدید.

#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
be careful when you do minor version upgrades

🟢 خلاصه مقاله:
** ارتقای نسخه‌های به‌ظاهر «جزئی» می‌تواند در سیستم‌های مبتنی بر Debian پیامدهای بزرگی داشته باشد. به‌روزرسانی نقطه‌ای Debian ممکن است کتابخانه‌های مرتبط با locale و collation را تغییر دهد و پایگاه داده شما را به به‌روزرسانی collation وادار کند؛ نتیجه می‌تواند بازسازی نمایه‌ها، تغییر ترتیب مرتب‌سازی متن، افت کارایی و حتی اختلال در سرویس باشد. این وضعیت معمولاً با apt upgrade یا unattended-upgrades و همچنین تصاویر کانتینری با برچسب‌های غیرثابت رخ می‌دهد. برای کاهش ریسک، همان نسخه را در staging تست کنید، بسته‌ها را pin/hold کنید، یادداشت‌های انتشار Debian و پایگاه داده را بخوانید، پنجره نگه‌داری در نظر بگیرید، پشتیبان مطمئن بگیرید و قبل/بعد از ارتقا وضعیت collation را بررسی کنید. «ارتقای جزئی» را نیز مانند ارتقای عمده جدی بگیرید تا از تغییر ناخواسته collation جلوگیری شود.

#Debian #Database #Collation #PostgreSQL #MySQL #Apt #Upgrade #DevOps

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
A PGConf EU 2025 Trip Summary

🟢 خلاصه مقاله:
کنفرانس PGConf EU 2025 دو هفته پیش در Latvia برگزار شد و به‌عنوان رویداد اصلی Postgres در اروپا، جمع زیادی از متخصصان و فعالان جامعه را گرد هم آورد. Claire از پادکست Talking Postgres گزارشی مفصل از سفرش منتشر کرده که تجربه‌های او را هم به‌عنوان سخنران و هم نماینده Microsoft پوشش می‌دهد؛ از روند آماده‌سازی و ارائه، پرسش‌و‌پاسخ‌های فنی و گفت‌وگوهای راهرویی تا تعامل با شرکت‌ها و جامعه متن‌باز. او در کنار نکات کاربردی درباره برنامه‌ریزی، فضا و ریتم رویداد، به جنبه‌های اجتماعی و شبکه‌سازی هم پرداخته است. این گزارش با عکس‌های فراوان از محل برگزاری، شرکت‌کنندگان و حال‌وهوای شهر همراه است و در نهایت تصویری روشن از وضعیت پویای اکوسیستم Postgres در اروپا ارائه می‌کند.

#Postgres #PGConfEU #PostgreSQL #Microsoft #Database #OpenSource #Latvia #TechConference

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Updating Passwords Now That MD5 Password Support is Deprecated

🟢 خلاصه مقاله:
با کنار گذاشته شدن پشتیبانی از رمزهای عبور مبتنی بر MD5، لازم است گذار به روش‌های امن‌تر انجام شود؛ کاری روتین و نه‌چندان هیجان‌انگیز که به قول Dan Langille اما برای سلامت سیستم‌ها ضروری است. ضعف‌های MD5 سال‌هاست شناخته شده‌اند، و بسیاری از پلتفرم‌ها اکنون آن را غیرفعال می‌کنند. راهکار عملی شامل این مراحل است: شناسایی همه سیستم‌ها و حساب‌هایی که هنوز MD5 دارند، انتخاب جایگزین مناسب مانند SCRAM-SHA-256 برای پایگاه‌داده‌ها یا bcrypt/scrypt/yescrypt/Argon2 برای سیستم‌عامل و برنامه‌ها، به‌روزرسانی پیکربندی‌ها و اطمینان از سازگاری کلاینت‌ها پیش از قطع کامل MD5. برای بازتولید هش‌ها می‌توان از ورود بعدی کاربر، مهلت چرخش رمز، یا مهاجرت مرحله‌ای استفاده کرد؛ حساب‌های سرویس نیز نیازمند مدیریت ویژه و هماهنگی انتشار هستند. تست جامع، پایش خطاهای احراز هویت، برنامه بازگشت، و حذف نهایی مسیرهای قدیمی، کلید یک مهاجرت موفق‌اند. نتیجه هرچند کم‌زرق‌وبرق، اما ارتقای واقعی امنیت، کاهش ریسک انطباق، و آینده‌پذیری بهتر سامانه‌های احراز هویت است.

#MD5 #PasswordSecurity #Deprecation #Hashing #Migration #SecurityOps #SCRAM #Argon2 #bcrypt

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
State of Containers and Serverless (8 minute read)

🟢 خلاصه مقاله:
روندهای کلیدی در گزارش State of Containers and Serverless از Datadog که بر پایه داده‌های هزاران محیط cloud-native تهیه شده، پنج نکته اصلی را نشان می‌دهد: ۱) استفاده از GPU با سرعت در حال رشد است؛ اکنون حدود ۶٪ از سازمان‌ها از آن بهره می‌برند و ساعات اجرای اینستنس‌ها نسبت به دو سال پیش تقریباً سه برابر شده است. ۲) بارهای کاری AI در حال ظهورند و حدود ۷٪ از workloadهای کانتینری را تشکیل می‌دهند و در کنار پایگاه‌داده‌ها و سرویس‌های وب اجرا می‌شوند. ۳) بیشتر کانتینرها کمتر از ۵۰٪ حافظه و کمتر از ۲۵٪ CPU مصرف می‌کنند که بیانگر افزون‌تخصیص گسترده و فرصت‌های بهینه‌سازی هزینه از طریق right-sizing و تنظیم بهتر autoscaling است. ۴) بیش از ۶۴٪ از کلاسترهای Kubernetes از Horizontal Pod Autoscaler (HPA) استفاده می‌کنند، اما تنها ۲۰٪ به آن متریک‌های سفارشی اپلیکیشن می‌دهند؛ تکیه صرف بر CPU/Memory باعث مقیاس‌پذیری نامتوازن با تقاضای واقعی می‌شود. ۵) پلتفرم‌های مبتنی بر Arm در حال گسترش‌اند و با قیمت/کارایی و بهره‌وری انرژی بهتر جذاب شده‌اند، اما به پشتیبانی multi-arch، سازگاری وابستگی‌ها و تنظیم درست CI/CD نیاز دارند. جمع‌بندی: پذیرش GPU و AI شتاب گرفته، اما برای بهبود کارایی و واکنش‌پذیری، باید روی right-sizing، متریک‌های سفارشی برای HPA و ارزیابی هدفمند Arm تمرکز شود.

#CloudNative #Containers #Kubernetes #Serverless #Datadog #GPU #AI #ARM

🟣لینک مقاله:
https://www.datadoghq.com/state-of-containers-and-serverless/?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Training a Tokenizer for BERT Models (4 minute read)

🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد چگونه با استفاده از کتابخانه‌های tokenizers و datasets از Hugging Face یک WordPiece tokenizer اختصاصی برای BERT آموزش دهیم: داده‌ها با یک iterator بارگذاری می‌شوند، یک واژگان 30,522 کلمه‌ای همراه با BERT special tokens مانند [PAD]، [UNK]، [CLS]، [SEP] و [MASK] ساخته می‌شود، و تنظیمات اختیاری مانند lowercase و pre-tokenization اعمال می‌گردد. سپس برای استفاده عملی، padding و truncation فعال می‌شود و tokenizer ذخیره و روی نمونه‌ها تست می‌شود. در مرحله‌ی آموزش یا fine-tuning مدل BERT، باید همخوانی tokenizer و مدل حفظ شود؛ اگر از یک BERT ازپیش‌آموزش‌داده‌شده با tokenizer جدید استفاده می‌کنید، ممکن است نیاز به تغییر اندازه‌ی embeddingها مطابق با واژگان جدید داشته باشید. این روند زمینه را برای پیش‌پردازش داده و fine-tuning مؤثر فراهم می‌کند.

#BERT #Tokenizer #WordPiece #HuggingFace #NLP #Tokenization #MachineLearning

🟣لینک مقاله:
https://machinelearningmastery.com/training-a-tokenizer-for-bert-models/?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
PgManage 1.4: Web Tool for Database Management

🟢 خلاصه مقاله:
PgManage 1.4 یک ابزار تحت وب متن‌باز برای مدیریت پایگاه‌داده است که با تمرکز بر Postgres طراحی شده اما از MySQL، SQLite و Oracle هم پشتیبانی می‌کند. این ابزار امکان اتصال و کار هم‌زمان با چند پایگاه‌داده را فراهم می‌کند و مرور اشیایی مانند جداول، نماها و توابع را آسان می‌سازد. اجرای تحت وب و ماهیت متن‌باز آن، راه‌اندازی را ساده و استفاده در تیم‌های دارای فناوری‌های متنوع را عملی و روان می‌کند.

#PgManage #Postgres #DatabaseManagement #OpenSource #WebTool #MySQL #SQLite #Oracle

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy