🔵 عنوان مقاله
the original 1986 paper
🟢 خلاصه مقاله:
**این متن به مقاله‌ی سال ۱۹۸۶ می‌پردازد که اهداف طراحی Postgres را تعریف کرد و نشان می‌دهد چگونه همان دیدگاه، امروز در PostgreSQL به‌خوبی محقق شده است. تمرکز مقاله بر قابلیت توسعه‌پذیری، پشتیبانی از داده‌های پیچیده، تضمین‌های تراکنشی و معماری پایدار است و نتیجه می‌گیرد که تصمیم‌های اولیه بسیار آینده‌نگرانه بوده‌اند؛ به‌طوری‌که «سازندگان PostgreSQL واقعاً عالی از پس آن برآمده‌اند.»
#Postgres #PostgreSQL #DatabaseSystems #DBMS #SystemsResearch #DataManagement #SoftwareArchitecture
🟣لینک مقاله:
https://postgresweekly.com/link/174750/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
the original 1986 paper
🟢 خلاصه مقاله:
**این متن به مقاله‌ی سال ۱۹۸۶ می‌پردازد که اهداف طراحی Postgres را تعریف کرد و نشان می‌دهد چگونه همان دیدگاه، امروز در PostgreSQL به‌خوبی محقق شده است. تمرکز مقاله بر قابلیت توسعه‌پذیری، پشتیبانی از داده‌های پیچیده، تضمین‌های تراکنشی و معماری پایدار است و نتیجه می‌گیرد که تصمیم‌های اولیه بسیار آینده‌نگرانه بوده‌اند؛ به‌طوری‌که «سازندگان PostgreSQL واقعاً عالی از پس آن برآمده‌اند.»
#Postgres #PostgreSQL #DatabaseSystems #DBMS #SystemsResearch #DataManagement #SoftwareArchitecture
🟣لینک مقاله:
https://postgresweekly.com/link/174750/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
How Anthropic Built a Multi-Agent Research System (16 minute read)
🟢 خلاصه مقاله:
**
Anthropic یک سیستم پژوهشی چندعاملی ساخته که در پرسش‌های پیچیده بیش از ۹۰٪ بهتر از روش‌های تک‌عامل عمل می‌کند. این برتری از اکتشاف پویا، پرامپت‌های دقیق و نقش‌محور، و لایه‌های ارزیابیِ سخت‌گیرانه به‌دست می‌آید. در معماری سیستم، یک عامل راهبر چند زیرعاملِ موازی را هدایت می‌کند و یک راستی‌سنجِ ارجاعات، ادعاها را با منابع تطبیق می‌دهد تا خطاها و ادعاهای بی‌پشتوانه کاهش یابد. در مقابل، به‌خاطر اجزای متعدد و مراحل تکراریِ راستی‌آزمایی، مصرف توکن و هزینه‌ها حدود ۱۵ برابر می‌شود و پیچیدگی تولیدی و تأخیر نیز بالا می‌رود؛ بنابراین این رویکرد برای کارهای پژوهشی حساس و دشوار که دقت و قابلیت استناد مهم‌تر از سرعت و هزینه است مناسب‌تر است.
#MultiAgentSystems #Anthropic #AIResearch #LLM #PromptEngineering #Evaluation #Scalability #TokenCosts
🟣لینک مقاله:
https://blog.bytebytego.com/p/how-anthropic-built-a-multi-agent?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Anthropic Built a Multi-Agent Research System (16 minute read)
🟢 خلاصه مقاله:
**
Anthropic یک سیستم پژوهشی چندعاملی ساخته که در پرسش‌های پیچیده بیش از ۹۰٪ بهتر از روش‌های تک‌عامل عمل می‌کند. این برتری از اکتشاف پویا، پرامپت‌های دقیق و نقش‌محور، و لایه‌های ارزیابیِ سخت‌گیرانه به‌دست می‌آید. در معماری سیستم، یک عامل راهبر چند زیرعاملِ موازی را هدایت می‌کند و یک راستی‌سنجِ ارجاعات، ادعاها را با منابع تطبیق می‌دهد تا خطاها و ادعاهای بی‌پشتوانه کاهش یابد. در مقابل، به‌خاطر اجزای متعدد و مراحل تکراریِ راستی‌آزمایی، مصرف توکن و هزینه‌ها حدود ۱۵ برابر می‌شود و پیچیدگی تولیدی و تأخیر نیز بالا می‌رود؛ بنابراین این رویکرد برای کارهای پژوهشی حساس و دشوار که دقت و قابلیت استناد مهم‌تر از سرعت و هزینه است مناسب‌تر است.
#MultiAgentSystems #Anthropic #AIResearch #LLM #PromptEngineering #Evaluation #Scalability #TokenCosts
🟣لینک مقاله:
https://blog.bytebytego.com/p/how-anthropic-built-a-multi-agent?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Bytebytego
How Anthropic Built a Multi-Agent Research System
In this article, we will understand the architecture of the multi-agent research system that Anthropic built.
🔵 عنوان مقاله
Postgres Partitioning Best Practices: Sofia's Story
🟢 خلاصه مقاله:
سofia در یک پلتفرم تحلیلی شلوغ، با تبدیل جداول بزرگ Postgres به پارتیشن‌های زمان‌محور و همسو با الگوهای فیلترگذاری، تاخیر کوئری‌ها را به‌طور محسوس کاهش داد. او با رعایت اصولی مثل انتخاب کلید پارتیشن درست، اندازه‌گذاری معقول پارتیشن‌ها، خودکارسازی چرخه ایجاد/ضمیمه/حذف، استفاده سنجیده از ایندکس‌های محلی و جمع‌آوری آمار در سطح هر پارتیشن، باعث شد Partition Pruning و برنامه‌ریز Postgres بهتر عمل کنند. نگهداشت هم ساده‌تر شد: حذف داده قدیمی با Drop پارتیشن، Vacuum/Analyze قابل پیش‌بینی، و بهره‌گیری از Partition-wise Join/Aggregate.
برای بهبود نوشتن، او با الهام از نکات Karen Jex و Warda Bibi، نقش حیاتی WAL را درک کرد و آن را روی یک دیسک مجزا و پرتحمل (مثلا NVMe) قرار داد تا رقابت I/O با داده اصلی کم شود. سپس تنظیمات WAL را هوشمندانه تیون کرد (مانند wal_level، max_wal_size، wal_buffers، و زمان‌بندی Checkpoint) و با پایش pg_stat_wal و pg_stat_bgwriter رفتار سیستم را زیر نظر گرفت. ترکیب پارتیشن‌بندی درست و جداسازی WAL روی دیسک مستقل، کارایی و پایداری را همزمان بالا برد، بدون پیچیده کردن معماری.
#Postgres
#WAL
#Partitioning
#DatabasePerformance
#Scaling
#Storage
#DevOps
#BestPractices
🟣لینک مقاله:
https://postgresweekly.com/link/174761/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres Partitioning Best Practices: Sofia's Story
🟢 خلاصه مقاله:
سofia در یک پلتفرم تحلیلی شلوغ، با تبدیل جداول بزرگ Postgres به پارتیشن‌های زمان‌محور و همسو با الگوهای فیلترگذاری، تاخیر کوئری‌ها را به‌طور محسوس کاهش داد. او با رعایت اصولی مثل انتخاب کلید پارتیشن درست، اندازه‌گذاری معقول پارتیشن‌ها، خودکارسازی چرخه ایجاد/ضمیمه/حذف، استفاده سنجیده از ایندکس‌های محلی و جمع‌آوری آمار در سطح هر پارتیشن، باعث شد Partition Pruning و برنامه‌ریز Postgres بهتر عمل کنند. نگهداشت هم ساده‌تر شد: حذف داده قدیمی با Drop پارتیشن، Vacuum/Analyze قابل پیش‌بینی، و بهره‌گیری از Partition-wise Join/Aggregate.
برای بهبود نوشتن، او با الهام از نکات Karen Jex و Warda Bibi، نقش حیاتی WAL را درک کرد و آن را روی یک دیسک مجزا و پرتحمل (مثلا NVMe) قرار داد تا رقابت I/O با داده اصلی کم شود. سپس تنظیمات WAL را هوشمندانه تیون کرد (مانند wal_level، max_wal_size، wal_buffers، و زمان‌بندی Checkpoint) و با پایش pg_stat_wal و pg_stat_bgwriter رفتار سیستم را زیر نظر گرفت. ترکیب پارتیشن‌بندی درست و جداسازی WAL روی دیسک مستقل، کارایی و پایداری را همزمان بالا برد، بدون پیچیده کردن معماری.
#Postgres
#WAL
#Partitioning
#DatabasePerformance
#Scaling
#Storage
#DevOps
#BestPractices
🟣لینک مقاله:
https://postgresweekly.com/link/174761/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Blogspot
Postgres Partitioning Best Practices: Sofia's Story
Thank you to everyone who came to listen to my talk, "Postgres Partitioning Best Practices", at Euruko in Viana do Castelo, Portugal ...
🔵 عنوان مقاله
Agentic AI, Agent Memory, & Context Engineering (7 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد که چرا الگوهای رایج مبتنی بر vector store و RAG در مقیاس بزرگ دچار افت کیفیت می‌شوند: با رشد داده‌ها و افزایش محتوای تولیدشده توسط خود عامل‌ها، بازیابی ناپایدار می‌شود و «دادهٔ زائد» انباشته می‌گردد. راه‌حل‌های پیشرو با ترکیب vector و graph database و افزودن یک حافظهٔ تکاملی مبتنی بر بازخورد، امکان یادگیری تدریجی عامل‌ها از تعاملات را فراهم می‌کنند و مشکل context windowهای ایستا و شکننده را برطرف می‌سازند. در این رویکرد یک پشتهٔ لایه‌ای شکل می‌گیرد: ingest تخصصی و غنی‌سازی متادیتا، نمایش ترکیبی embedding+گراف، حافظهٔ چندلایه (کوتاه‌مدت، اپیزودیک، بلندمدت)، بازیابی هیبریدی با مسیریابی وظیفه‌محور، و لایهٔ بازخورد برای ترفیع دانش مفید و هرس محتوای کهنه یا تکراری. نتیجه، زمینه‌های فشرده و مبتنی بر منبع برای هر وظیفه است که دقت، قابلیت کنترل، و ایمنی را بالا می‌برد و هزینهٔ توکن را کاهش می‌دهد. جمع‌بندی: گذار از RAG صرف به «Context Engineering» به‌عنوان یک فرایند محصول‌محور، کیفیت بازیابی را پایدار می‌کند و با معیارهایی مانند grounded-answer rate، hit rate، تازگی، و هزینهٔ هر کار موفق، بهبود مستمر عامل‌ها را قابل‌اندازه‌گیری می‌سازد.
#AgenticAI #RAG #ContextEngineering #VectorDatabases #GraphDatabases #AIAgents #Memory #Retrieval
🟣لینک مقاله:
https://thebigdataguy.substack.com/p/agentic-ai-agent-memory-and-context?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Agentic AI, Agent Memory, & Context Engineering (7 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح می‌دهد که چرا الگوهای رایج مبتنی بر vector store و RAG در مقیاس بزرگ دچار افت کیفیت می‌شوند: با رشد داده‌ها و افزایش محتوای تولیدشده توسط خود عامل‌ها، بازیابی ناپایدار می‌شود و «دادهٔ زائد» انباشته می‌گردد. راه‌حل‌های پیشرو با ترکیب vector و graph database و افزودن یک حافظهٔ تکاملی مبتنی بر بازخورد، امکان یادگیری تدریجی عامل‌ها از تعاملات را فراهم می‌کنند و مشکل context windowهای ایستا و شکننده را برطرف می‌سازند. در این رویکرد یک پشتهٔ لایه‌ای شکل می‌گیرد: ingest تخصصی و غنی‌سازی متادیتا، نمایش ترکیبی embedding+گراف، حافظهٔ چندلایه (کوتاه‌مدت، اپیزودیک، بلندمدت)، بازیابی هیبریدی با مسیریابی وظیفه‌محور، و لایهٔ بازخورد برای ترفیع دانش مفید و هرس محتوای کهنه یا تکراری. نتیجه، زمینه‌های فشرده و مبتنی بر منبع برای هر وظیفه است که دقت، قابلیت کنترل، و ایمنی را بالا می‌برد و هزینهٔ توکن را کاهش می‌دهد. جمع‌بندی: گذار از RAG صرف به «Context Engineering» به‌عنوان یک فرایند محصول‌محور، کیفیت بازیابی را پایدار می‌کند و با معیارهایی مانند grounded-answer rate، hit rate، تازگی، و هزینهٔ هر کار موفق، بهبود مستمر عامل‌ها را قابل‌اندازه‌گیری می‌سازد.
#AgenticAI #RAG #ContextEngineering #VectorDatabases #GraphDatabases #AIAgents #Memory #Retrieval
🟣لینک مقاله:
https://thebigdataguy.substack.com/p/agentic-ai-agent-memory-and-context?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
Agentic AI, Agent Memory, & Context Engineering
Graph Exchange, Fall 2025 - Conference summary of Neo4j, Cognee, DeepLearning.AI and Letta
Forwarded from Bardia & Erfan
اگه با دلار ۱۰۰۰ تومنی زندگیتو جمع کردی
با دلار ۱۰۰ تومنی نصیحت نکن.
با دلار ۱۰۰ تومنی نصیحت نکن.
❤1
🔵 عنوان مقاله
Writing Nothing But Docs for a Week
🟢 خلاصه مقاله:
Lev Kokotov، سازنده PgDog (ابزار connection pooler و sharder برای Postgres)، یک هفته کامل را صرف نوشتن و بهبود مستندات کرد تا شروع کار، پیکربندی و اجرای تولیدی برای کاربران ساده‌تر و شفاف‌تر شود. خروجی این تمرکز شامل راهنمای شروع سریع، آموزش‌های گام‌به‌گام، دستورالعمل‌های عملی برای مقیاس‌پذیری و رفع اشکال، و توضیح روشن معماری و محدودیت‌هاست. او تأکید می‌کند که «مستندسازی» خود نوعی بازبینی طراحی است: هنگام نوشتن، ابهام‌ها و نقص‌ها آشکار می‌شوند و همین باعث بهبود نام‌گذاری‌ها، پیش‌فرض‌ها و تجربه تنظیمات شد. این رویکرد، هم پذیرش PgDog را سریع‌تر می‌کند و هم مشارکت جامعه را تسهیل می‌کند، چون مستندات زنده‌اند و به بازخورد و اصلاحات کاربران تکیه دارند.
#Postgres #PgDog #Documentation #OpenSource #Sharding #ConnectionPooling #DeveloperExperience #Databases
🟣لینک مقاله:
https://postgresweekly.com/link/174759/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Writing Nothing But Docs for a Week
🟢 خلاصه مقاله:
Lev Kokotov، سازنده PgDog (ابزار connection pooler و sharder برای Postgres)، یک هفته کامل را صرف نوشتن و بهبود مستندات کرد تا شروع کار، پیکربندی و اجرای تولیدی برای کاربران ساده‌تر و شفاف‌تر شود. خروجی این تمرکز شامل راهنمای شروع سریع، آموزش‌های گام‌به‌گام، دستورالعمل‌های عملی برای مقیاس‌پذیری و رفع اشکال، و توضیح روشن معماری و محدودیت‌هاست. او تأکید می‌کند که «مستندسازی» خود نوعی بازبینی طراحی است: هنگام نوشتن، ابهام‌ها و نقص‌ها آشکار می‌شوند و همین باعث بهبود نام‌گذاری‌ها، پیش‌فرض‌ها و تجربه تنظیمات شد. این رویکرد، هم پذیرش PgDog را سریع‌تر می‌کند و هم مشارکت جامعه را تسهیل می‌کند، چون مستندات زنده‌اند و به بازخورد و اصلاحات کاربران تکیه دارند.
#Postgres #PgDog #Documentation #OpenSource #Sharding #ConnectionPooling #DeveloperExperience #Databases
🟣لینک مقاله:
https://postgresweekly.com/link/174759/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PgDog
Writing nothing but docs for a week
🤝2
🔵 عنوان مقاله
pgexporter 0.7: Prometheus Exporter for Postgres
🟢 خلاصه مقاله:
pgexporter 0.7 یک Prometheus Exporter برای Postgres است که با بهبودهای مهم در متریک‌های هسته و اضافه‌شدن متریک‌های جدید برای autovacuum منتشر شده است. این نسخه همچنین از افزونه‌های PostGIS، pg_stat_statements، pgvector و Timescale پشتیبانی می‌کند تا مشاهده‌پذیری دقیق‌تری بر بارهای کاری مکانی، کارایی پرس‌وجوها، جست‌وجوی برداری و سناریوهای سری‌زمانی فراهم شود. این به‌روزرسانی‌ها رصدپذیری، عیب‌یابی و برنامه‌ریزی ظرفیت را در کلاسترهای Postgres ساده‌تر می‌کند. برای جزئیات بیشتر به صفحهٔ اصلی پروژه مراجعه کنید.
#pgexporter #Postgres #Prometheus #Monitoring #PostGIS #pg_stat_statements #pgvector #Timescale
🟣لینک مقاله:
https://postgresweekly.com/link/174767/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgexporter 0.7: Prometheus Exporter for Postgres
🟢 خلاصه مقاله:
pgexporter 0.7 یک Prometheus Exporter برای Postgres است که با بهبودهای مهم در متریک‌های هسته و اضافه‌شدن متریک‌های جدید برای autovacuum منتشر شده است. این نسخه همچنین از افزونه‌های PostGIS، pg_stat_statements، pgvector و Timescale پشتیبانی می‌کند تا مشاهده‌پذیری دقیق‌تری بر بارهای کاری مکانی، کارایی پرس‌وجوها، جست‌وجوی برداری و سناریوهای سری‌زمانی فراهم شود. این به‌روزرسانی‌ها رصدپذیری، عیب‌یابی و برنامه‌ریزی ظرفیت را در کلاسترهای Postgres ساده‌تر می‌کند. برای جزئیات بیشتر به صفحهٔ اصلی پروژه مراجعه کنید.
#pgexporter #Postgres #Prometheus #Monitoring #PostGIS #pg_stat_statements #pgvector #Timescale
🟣لینک مقاله:
https://postgresweekly.com/link/174767/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgexporter.github.io
pgexporter 0.7.0 | pgexporter
Documentation website for pgexporter
Forwarded from VIP
🚀 به دنیای توسعه و تکنولوژی خوش اومدی!
اگر به موضوعات زیر علاقه‌مندی:
🔹 Golang
🔹 Linux & DevOps
🔹 Software Engineering
🔹 AI & Machine Learning
🔹 فرصت‌های شغلی ریموت (خارجی و داخلی)
ما برات یه مجموعه کانال‌های تخصصی ساختیم تا همیشه به‌روز، حرفه‌ای و الهام‌بخش بمونی!
📚 یادگیری، فرصت، شبکه‌سازی و پیشرفت، همش اینجاست...
📌 از این لینک همه چنل‌هامونو یه‌جا ببین و جوین شو:
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
اگر به موضوعات زیر علاقه‌مندی:
🔹 Golang
🔹 Linux & DevOps
🔹 Software Engineering
🔹 AI & Machine Learning
🔹 فرصت‌های شغلی ریموت (خارجی و داخلی)
ما برات یه مجموعه کانال‌های تخصصی ساختیم تا همیشه به‌روز، حرفه‌ای و الهام‌بخش بمونی!
📚 یادگیری، فرصت، شبکه‌سازی و پیشرفت، همش اینجاست...
📌 از این لینک همه چنل‌هامونو یه‌جا ببین و جوین شو:
👉 https://t.iss.one/addlist/AJ7rh2IzIh02NTI0
❤1
🔵 عنوان مقاله
the top programming languages in 2025
🟢 خلاصه مقاله:
در ۲۰۲۵، محبوب‌ترین زبان‌ها حول سه جریان شکل می‌گیرند: وب و فول‌استک با JavaScript/TypeScript، داده و AI با Python، و سیستم‌ها و زیرساخت با Go، Rust و C/C++. در بسیاری از فهرست‌ها SQL به‌دلیل نقش محوری در دسترسی به داده و تحلیل‌ها در رتبه چهارم قرار می‌گیرد و میان پایگاه‌های داده سنتی و انبارهای ابری (مانند BigQuery، Snowflake و Redshift) پلی مشترک است. در بک‌اند سازمانی Java و اکوسیستم JVM همچنان پرتقاضا هستند و Kotlin در توسعه مدرن JVM رشد می‌کند؛ در موبایل، Kotlin و Swift پیشرو مانده‌اند و راهکارهای کراس‌پلتفرم مانند Flutter و React Native جایگاه خود را حفظ کرده‌اند. نتیجه عملی: برای شروع، Python یا JavaScript به‌همراه SQL انتخابی مطمئن است؛ برای سیستم‌های کارایی‌محور، Go یا Rust مناسب‌ترند.
#ProgrammingLanguages #2025Trends #SQL #Python #JavaScript #TypeScript #Rust #Go
🟣لینک مقاله:
https://postgresweekly.com/link/174752/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
the top programming languages in 2025
🟢 خلاصه مقاله:
در ۲۰۲۵، محبوب‌ترین زبان‌ها حول سه جریان شکل می‌گیرند: وب و فول‌استک با JavaScript/TypeScript، داده و AI با Python، و سیستم‌ها و زیرساخت با Go، Rust و C/C++. در بسیاری از فهرست‌ها SQL به‌دلیل نقش محوری در دسترسی به داده و تحلیل‌ها در رتبه چهارم قرار می‌گیرد و میان پایگاه‌های داده سنتی و انبارهای ابری (مانند BigQuery، Snowflake و Redshift) پلی مشترک است. در بک‌اند سازمانی Java و اکوسیستم JVM همچنان پرتقاضا هستند و Kotlin در توسعه مدرن JVM رشد می‌کند؛ در موبایل، Kotlin و Swift پیشرو مانده‌اند و راهکارهای کراس‌پلتفرم مانند Flutter و React Native جایگاه خود را حفظ کرده‌اند. نتیجه عملی: برای شروع، Python یا JavaScript به‌همراه SQL انتخابی مطمئن است؛ برای سیستم‌های کارایی‌محور، Go یا Rust مناسب‌ترند.
#ProgrammingLanguages #2025Trends #SQL #Python #JavaScript #TypeScript #Rust #Go
🟣لینک مقاله:
https://postgresweekly.com/link/174752/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
IEEE Spectrum
The Top Programming Languages 2025
Python reigns supreme again, but is AI changing the game for programming languages? Find out how coding is transforming.
🔥1
🔵 عنوان مقاله
'the PostgreSQL creators totally nailed it.'
🟢 خلاصه مقاله:
در آخرین شماره Golang Weekly، مقاله‌ای تأکید می‌کند که سازندگان PostgreSQL «کاملاً درست عمل کردند». نویسنده توضیح می‌دهد چرا این پایگاه‌داده با ترکیب استانداردهای شفاف SQL، قابلیت اتکا، کارایی بالا و امکاناتی مانند JSONB و ایندکس‌های قدرتمند، برای طیف وسیعی از نیازها مناسب است. برای توسعه‌دهندگان Go، هم‌نشینی PostgreSQL با ابزارهایی مثل pgx و GORM، سادگی در ادغام، و رفتار قابل پیش‌بینی در محیط تولید، ارزش ویژه‌ای دارد. جامعه فعال، مستندسازی خوب و سازگاری عقب‌رو نیز استفاده بلندمدت را مطمئن می‌کند. جمع‌بندی مقاله این است که برای بسیاری از تیم‌های Go، PostgreSQL یک انتخاب پیش‌فرض قوی و عملیاتی است و سازندگانش در رسیدن به این تعادل «حرفه‌ای» عمل کرده‌اند.
#PostgreSQL #Golang #Go #Databases #GolangWeekly #OpenSource #Backend #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/174751/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
'the PostgreSQL creators totally nailed it.'
🟢 خلاصه مقاله:
در آخرین شماره Golang Weekly، مقاله‌ای تأکید می‌کند که سازندگان PostgreSQL «کاملاً درست عمل کردند». نویسنده توضیح می‌دهد چرا این پایگاه‌داده با ترکیب استانداردهای شفاف SQL، قابلیت اتکا، کارایی بالا و امکاناتی مانند JSONB و ایندکس‌های قدرتمند، برای طیف وسیعی از نیازها مناسب است. برای توسعه‌دهندگان Go، هم‌نشینی PostgreSQL با ابزارهایی مثل pgx و GORM، سادگی در ادغام، و رفتار قابل پیش‌بینی در محیط تولید، ارزش ویژه‌ای دارد. جامعه فعال، مستندسازی خوب و سازگاری عقب‌رو نیز استفاده بلندمدت را مطمئن می‌کند. جمع‌بندی مقاله این است که برای بسیاری از تیم‌های Go، PostgreSQL یک انتخاب پیش‌فرض قوی و عملیاتی است و سازندگانش در رسیدن به این تعادل «حرفه‌ای» عمل کرده‌اند.
#PostgreSQL #Golang #Go #Databases #GolangWeekly #OpenSource #Backend #SoftwareEngineering
🟣لینک مقاله:
https://postgresweekly.com/link/174751/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Postgres’ Original Project Goals: The Creators Totally Nailed It | Crunchy Data Blog
Dig in to the original goals of the Postgres academic project at UC Berkeley and how they shaped the Postgres we use today.
❤3
🔵 عنوان مقاله
Getting Excited About Postgres 18
🟢 خلاصه مقاله:
Postgres 18 تا یک هفته دیگر نهایی می‌شود و مهم‌ترین ویژگی تازه‌اش asynchronous I/O است؛ قابلیتی که امکان انجام عملیات خواندن/نوشتن بدون مسدود کردن مسیر اجرای اصلی را می‌دهد و در بسیاری از سناریوها باعث افزایش توان عملیاتی و کاهش تأخیر می‌شود. این تغییر برای بارهای کاری پرتراکنش، سیستم‌های ترکیبی OLTP/تحلیلی و پردازش‌های سنگین I/O نوید عملکرد روان‌تر و پایدارتر را می‌دهد. با انتشار نسخه نهایی، انتظار می‌رود راهنماها و بهترین‌عمل‌ها برای بهره‌گیری از این بهبودها ارائه شود و تیم‌ها بتوانند با تنظیمات مناسب، از جهش عملکردی Postgres 18 بهره ببرند.
#Postgres18 #Postgres #PostgreSQL #AsynchronousIO #Database #Performance #OpenSource
🟣لینک مقاله:
https://postgresweekly.com/link/174461/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Getting Excited About Postgres 18
🟢 خلاصه مقاله:
Postgres 18 تا یک هفته دیگر نهایی می‌شود و مهم‌ترین ویژگی تازه‌اش asynchronous I/O است؛ قابلیتی که امکان انجام عملیات خواندن/نوشتن بدون مسدود کردن مسیر اجرای اصلی را می‌دهد و در بسیاری از سناریوها باعث افزایش توان عملیاتی و کاهش تأخیر می‌شود. این تغییر برای بارهای کاری پرتراکنش، سیستم‌های ترکیبی OLTP/تحلیلی و پردازش‌های سنگین I/O نوید عملکرد روان‌تر و پایدارتر را می‌دهد. با انتشار نسخه نهایی، انتظار می‌رود راهنماها و بهترین‌عمل‌ها برای بهره‌گیری از این بهبودها ارائه شود و تیم‌ها بتوانند با تنظیمات مناسب، از جهش عملکردی Postgres 18 بهره ببرند.
#Postgres18 #Postgres #PostgreSQL #AsynchronousIO #Database #Performance #OpenSource
🟣لینک مقاله:
https://postgresweekly.com/link/174461/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
Get Excited About Postgres 18 | Crunchy Data Blog
New to Postgres 18, features like asynchronous i/o, uuid v7, b-tree skip scans, and virtual generated columns.
❤1
🔵 عنوان مقاله
"database is not accepting commands": What Now?
🟢 خلاصه مقاله:
وقتی پیام "database is not accepting commands" ظاهر می‌شود، در سیستم‌هایی مثل PostgreSQL معمولاً به‌معنای ورود به حالت حفاظتی برای جلوگیری از Transaction ID Wraparound است؛ یعنی پایگاه داده برای محافظت از خود جلوی عملیات عادی را گرفته و باید فوراً اقدام کنید. توصیه Laurenz این است که ابتدا ترافیک نوشتن را کم یا متوقف کنید، با دسترسی کافی وصل شوید و روی جداول/پایگاه‌های در خطر VACUUM و در صورت نیاز VACUUM FREEZE اجرا کنید؛ اگر اتصال معمولی ممکن نیست، از حالت نگهداری محدود استفاده کنید تا relfrozenxid ایمن جلو برود. برای پیشگیری، پایش منظم سن تراکنش‌ها، تنظیم درست autovacuum، زمان‌بندی VACUUM برای جداول بزرگ، کوتاه نگه‌داشتن تراکنش‌های طولانی و برنامه‌ریزی نگهداری دوره‌ای ضروری است. از روش‌های "نامطلوب" مثل غیرفعال‌کردن autovacuum، بالا بردن بی‌هدف autovacuum_freeze_max_age یا سرکوب هشدارها برای به تعویق انداختن مشکل پرهیز کنید؛ این‌ها خطر را بیشتر می‌کنند. راه‌حل واقعی، نگهداری منظم، پایش و پیکربندی درست است، نه عقب‌انداختن مشکل.
#PostgreSQL #TransactionIDWraparound #Autovacuum #VACUUM #DatabaseMaintenance #DBA #IncidentResponse
🟣لینک مقاله:
https://postgresweekly.com/link/174454/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
"database is not accepting commands": What Now?
🟢 خلاصه مقاله:
وقتی پیام "database is not accepting commands" ظاهر می‌شود، در سیستم‌هایی مثل PostgreSQL معمولاً به‌معنای ورود به حالت حفاظتی برای جلوگیری از Transaction ID Wraparound است؛ یعنی پایگاه داده برای محافظت از خود جلوی عملیات عادی را گرفته و باید فوراً اقدام کنید. توصیه Laurenz این است که ابتدا ترافیک نوشتن را کم یا متوقف کنید، با دسترسی کافی وصل شوید و روی جداول/پایگاه‌های در خطر VACUUM و در صورت نیاز VACUUM FREEZE اجرا کنید؛ اگر اتصال معمولی ممکن نیست، از حالت نگهداری محدود استفاده کنید تا relfrozenxid ایمن جلو برود. برای پیشگیری، پایش منظم سن تراکنش‌ها، تنظیم درست autovacuum، زمان‌بندی VACUUM برای جداول بزرگ، کوتاه نگه‌داشتن تراکنش‌های طولانی و برنامه‌ریزی نگهداری دوره‌ای ضروری است. از روش‌های "نامطلوب" مثل غیرفعال‌کردن autovacuum، بالا بردن بی‌هدف autovacuum_freeze_max_age یا سرکوب هشدارها برای به تعویق انداختن مشکل پرهیز کنید؛ این‌ها خطر را بیشتر می‌کنند. راه‌حل واقعی، نگهداری منظم، پایش و پیکربندی درست است، نه عقب‌انداختن مشکل.
#PostgreSQL #TransactionIDWraparound #Autovacuum #VACUUM #DatabaseMaintenance #DBA #IncidentResponse
🟣لینک مقاله:
https://postgresweekly.com/link/174454/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
CYBERTEC PostgreSQL | Services & Support
How to handle "database is not accepting commands"
I'll explain how to handle the dreaded error message "database is not accepting commands" and alert you to the responses you should avoid.
🔵 عنوان مقاله
pgAudit 18.0: An Audit Logging Extension
🟢 خلاصه مقاله:
این نسخه جدید از pgAudit با پشتیبانی کامل از Postgres 18 منتشر شده و ثبت لاگ‌های حسابرسی از فعالیت‌های پایگاه‌داده را بدون وقفه برای تیم‌هایی که در حال ارتقا هستند امکان‌پذیر می‌کند. pgAudit با تولید لاگ‌های ساخت‌یافته از رویدادهایی مانند اجرای دستورات SQL، تغییر نقش‌ها و دسترسی به اشیای حساس، به سازمان‌ها کمک می‌کند الزامات انطباق در حوزه‌های دولتی، مالی و استانداردهای ISO را برآورده کنند. ادغام با لاگینگ بومی Postgres و تنظیم‌پذیری دامنه و جزئیات ثبت، تعادلی بین پوشش، کارایی و هزینه ذخیره‌سازی فراهم می‌کند و انتقال سیاست‌های حسابرسی به Postgres 18 را ساده و پایدار نگه می‌دارد.
#Postgres #pgAudit #AuditLogging #Compliance #Security #DataGovernance #ISO
🟣لینک مقاله:
https://postgresweekly.com/link/174766/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgAudit 18.0: An Audit Logging Extension
🟢 خلاصه مقاله:
این نسخه جدید از pgAudit با پشتیبانی کامل از Postgres 18 منتشر شده و ثبت لاگ‌های حسابرسی از فعالیت‌های پایگاه‌داده را بدون وقفه برای تیم‌هایی که در حال ارتقا هستند امکان‌پذیر می‌کند. pgAudit با تولید لاگ‌های ساخت‌یافته از رویدادهایی مانند اجرای دستورات SQL، تغییر نقش‌ها و دسترسی به اشیای حساس، به سازمان‌ها کمک می‌کند الزامات انطباق در حوزه‌های دولتی، مالی و استانداردهای ISO را برآورده کنند. ادغام با لاگینگ بومی Postgres و تنظیم‌پذیری دامنه و جزئیات ثبت، تعادلی بین پوشش، کارایی و هزینه ذخیره‌سازی فراهم می‌کند و انتقال سیاست‌های حسابرسی به Postgres 18 را ساده و پایدار نگه می‌دارد.
#Postgres #pgAudit #AuditLogging #Compliance #Security #DataGovernance #ISO
🟣لینک مقاله:
https://postgresweekly.com/link/174766/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pgaudit/pgaudit: PostgreSQL Audit Extension
PostgreSQL Audit Extension. Contribute to pgaudit/pgaudit development by creating an account on GitHub.
🔵 عنوان مقاله
Understanding WAL and Optimizing It with a Dedicated Disk
🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و به‌صورت پایدار flush می‌شوند و سپس در صورت نیاز روی داده‌های اصلی اعمال یا بازپخش می‌گردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایل‌های داده نیز روی آن I/O تصادفی انجام می‌دهند، وقفه و رقابت صف موجب جهش در تاخیر به‌ویژه در p99/p999 می‌شود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله می‌کند، الگوی نوشتن ترتیبی را حفظ می‌کند و تاخیر را قابل پیش‌بینی‌تر و بهره‌وری را بیشتر می‌سازد.
در عمل می‌توان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایل‌سیستم‌های رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسب‌اند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینه‌سازی WAL معمولاً با سگمنت‌بندی و پیش‌اختصاص فایل‌ها، نوشتن هم‌تراز با بلوک، checksum، batch کردن درخواست‌ها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام می‌شود. اندازه‌گیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابه‌انتها) مشخص می‌کند آیا دیسک اختصاصی هزینه‌اش را جبران می‌کند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سخت‌گیرانه، این ایزولاسیون معمولاً ارزشمند است.
#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign
🟣لینک مقاله:
https://postgresweekly.com/link/174762/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Understanding WAL and Optimizing It with a Dedicated Disk
🟢 خلاصه مقاله:
WAL روشی کلیدی برای پایداری و ریکاوری پس از کرش است: تغییرات ابتدا به شکل ترتیبی در یک لاگ نوشته و به‌صورت پایدار flush می‌شوند و سپس در صورت نیاز روی داده‌های اصلی اعمال یا بازپخش می‌گردند. گلوگاه اصلی معمولاً همان fsync/flush است که باید دوام را تضمین کند. وقتی WAL روی همان دیسکی باشد که فایل‌های داده نیز روی آن I/O تصادفی انجام می‌دهند، وقفه و رقابت صف موجب جهش در تاخیر به‌ویژه در p99/p999 می‌شود. قرار دادن WAL روی یک دیسک اختصاصی این مسیر حساس را ایزوله می‌کند، الگوی نوشتن ترتیبی را حفظ می‌کند و تاخیر را قابل پیش‌بینی‌تر و بهره‌وری را بیشتر می‌سازد.
در عمل می‌توان از یک NVMe مستقل یا یک ولوم ابری جداگانه استفاده کرد؛ فایل‌سیستم‌های رایج مانند ext4 یا XFS با تنظیمات ساده و بدون سربار اضافی مناسب‌اند و باید اطمینان داشت که semantics مربوط به write barrier و cache flush مطابق نیازهای دوام هستند. از منظر Golang، بهینه‌سازی WAL معمولاً با سگمنت‌بندی و پیش‌اختصاص فایل‌ها، نوشتن هم‌تراز با بلوک، checksum، batch کردن درخواست‌ها، group commit با آستانه زمانی/حجمی، استفاده سنجیده از O_DSYNC/fdatasync و مدیریت دقیق بافر انجام می‌شود. اندازه‌گیری دقیق قبل و بعد (میانگین و p99 fsync، نرخ نوشتن، و زمان انتهابه‌انتها) مشخص می‌کند آیا دیسک اختصاصی هزینه‌اش را جبران می‌کند یا خیر؛ برای بارهای نوشتاری بالا یا SLA سخت‌گیرانه، این ایزولاسیون معمولاً ارزشمند است.
#WAL #Golang #Databases #Performance #Storage #NVMe #SystemsDesign
🟣لینک مقاله:
https://postgresweekly.com/link/174762/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Stormatics
PostgreSQL WAL: Boost Performance with a Dedicated Disk
Learn how to speed up PostgreSQL by moving WAL to its own disk. Cut I/O contention and improve write performance safely.
❤1
🔵 عنوان مقاله
Polars at Decathlon: Ready to Play? (5 minute read)
🟢 خلاصه مقاله:
Decathlon با به‌کارگیری Polars، پیچیدگی و هزینه زیرساخت داده را کاهش داد. آن‌ها برای پایپ‌لاین‌هایی با ورودی کمتر از 50 GiB، Polars را جایگزین pandas کردند و در کنار آن، Spark را برای موارد مناسب حفظ نمودند. موتور استریمینگ جدید Polars امکان اجرای پایپ‌لاین‌هایی تا 1 TiB را تنها با 10 GiB RAM و 4 CPU فراهم کرد؛ در حالی‌که اجرای درون‌حافظه‌ای قبلی به حدود 100 GiB RAM نیاز داشت. نتیجه این تغییر، هزینه محاسباتی افزایشی نزدیک به صفر، اجرای بسیار سریع‌تر کارها و ساده‌تر شدن توسعه و نگهداری پایپ‌لاین‌ها برای بارهای کاری مناسب بود.
#Polars
#Decathlon
#DataPipelines
#StreamingEngine
#Spark
#Pandas
#CostOptimization
🟣لینک مقاله:
https://pola.rs/posts/case-decathlon/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Polars at Decathlon: Ready to Play? (5 minute read)
🟢 خلاصه مقاله:
Decathlon با به‌کارگیری Polars، پیچیدگی و هزینه زیرساخت داده را کاهش داد. آن‌ها برای پایپ‌لاین‌هایی با ورودی کمتر از 50 GiB، Polars را جایگزین pandas کردند و در کنار آن، Spark را برای موارد مناسب حفظ نمودند. موتور استریمینگ جدید Polars امکان اجرای پایپ‌لاین‌هایی تا 1 TiB را تنها با 10 GiB RAM و 4 CPU فراهم کرد؛ در حالی‌که اجرای درون‌حافظه‌ای قبلی به حدود 100 GiB RAM نیاز داشت. نتیجه این تغییر، هزینه محاسباتی افزایشی نزدیک به صفر، اجرای بسیار سریع‌تر کارها و ساده‌تر شدن توسعه و نگهداری پایپ‌لاین‌ها برای بارهای کاری مناسب بود.
#Polars
#Decathlon
#DataPipelines
#StreamingEngine
#Spark
#Pandas
#CostOptimization
🟣لینک مقاله:
https://pola.rs/posts/case-decathlon/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pola.rs
Polars at Decathlon: Ready to Play?
DataFrames for the new era
❤1
🔵 عنوان مقاله
Implementing IAM as a Data Engineer: A Practical Example (7 minute read)
🟢 خلاصه مقاله:
** اجرای IAM برای Azure Storage با تعریف دقیق پرسونـاها، نگاشت مجوزهای لازم و خودکارسازی تخصیص نقش‌ها با Terraform آغاز می‌شود. در این رویکرد، اصل Principle of Least Privilege محور است؛ یعنی هر هویت فقط به حداقل دسترسی لازم، آن هم در کوچک‌ترین دامنه ممکن (مثل سطح کانتینر)، مجهز می‌شود. برای تعادل امنیت و سادگی عملیاتی، از نقش‌های داخلی Azure مانند Storage Blob Data Reader برای دسترسی فقط‌خواندنی و Storage Blob Data Contributor برای نوشتن و به‌روزرسانی استفاده می‌شود. خودکارسازی IAM با Infrastructure as Code (Terraform) باعث می‌شود دسترسی‌ها مقیاس‌پذیر، قابل ممیزی و به‌سادگی نگهداری شوند و ریسک حساب‌های بیش‌ازحد مجاز و پیکربندی‌های موردی به‌شدت کاهش یابد.
#IAM #Azure #AzureStorage #Terraform #LeastPrivilege #DataEngineering #InfrastructureAsCode #DevSecOps
🟣لینک مقاله:
https://atlonglastanalytics.substack.com/p/implementing-iam-as-a-data-engineer?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Implementing IAM as a Data Engineer: A Practical Example (7 minute read)
🟢 خلاصه مقاله:
** اجرای IAM برای Azure Storage با تعریف دقیق پرسونـاها، نگاشت مجوزهای لازم و خودکارسازی تخصیص نقش‌ها با Terraform آغاز می‌شود. در این رویکرد، اصل Principle of Least Privilege محور است؛ یعنی هر هویت فقط به حداقل دسترسی لازم، آن هم در کوچک‌ترین دامنه ممکن (مثل سطح کانتینر)، مجهز می‌شود. برای تعادل امنیت و سادگی عملیاتی، از نقش‌های داخلی Azure مانند Storage Blob Data Reader برای دسترسی فقط‌خواندنی و Storage Blob Data Contributor برای نوشتن و به‌روزرسانی استفاده می‌شود. خودکارسازی IAM با Infrastructure as Code (Terraform) باعث می‌شود دسترسی‌ها مقیاس‌پذیر، قابل ممیزی و به‌سادگی نگهداری شوند و ریسک حساب‌های بیش‌ازحد مجاز و پیکربندی‌های موردی به‌شدت کاهش یابد.
#IAM #Azure #AzureStorage #Terraform #LeastPrivilege #DataEngineering #InfrastructureAsCode #DevSecOps
🟣لینک مقاله:
https://atlonglastanalytics.substack.com/p/implementing-iam-as-a-data-engineer?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
Implementing IAM as a Data Engineer: A Practical Example
A practical case study walking you through how I design an IAM solution by combining the use case with personas.
❤1
🔵 عنوان مقاله
Compiling Postgres to WebAssembly with PGlite
🟢 خلاصه مقاله:
این ارائه ۳۰ دقیقه‌ای از Sam Willis نشان می‌دهد چگونه می‌توان Postgres را برای اجرای مستقیم در WebAssembly کامپایل کرد و PGlite چه‌طور این ایده را به راهکاری کاربردی تبدیل می‌کند. انگیزه اصلی، اجرای دیتابیس در مرورگر یا محیط‌های edge است تا بتوان به اپ‌های آفلاین، دموهای قابل تکرار، تست سریع و اجرای ایمن و ایزوله بدون نیاز به سرور دست یافت.
در ادامه، مسیر فنی از کد Cِ Postgres تا WebAssembly توضیح داده می‌شود: محدودیت‌های WASI، نبود fork و برخی سیستم‌کال‌های POSIX، شبیه‌سازی فایل‌سیستم و شیوه‌های معمول برای پایداری داده در مرورگر (مثل IndexedDB یا OPFS) یا فضای ذخیره‌سازی معادل در edge. همچنین بازطراحی همزمانی بدون مدل چندپردازه، بسته‌بندی باینری برای کاهش زمان شروع، و مدیریت کارهای پس‌زمینه بررسی می‌شود.
از منظر توسعه‌دهنده، PGlite یک API ساده برای راه‌اندازی سریع، اجرای SQL، مهاجرت‌ها و seed داده ارائه می‌کند و سناریوهایی مثل تحلیل سمت‌کلاینت، مستندسازی تعاملی، تست انتهابه‌انتها بدون سرور، و آموزش را پوشش می‌دهد. ادغام با ابزارها و runtimeهایی مانند Node و Deno نیز مطرح است تا همان artifactِ Wasm در محیط‌های مختلف پایدار اجرا شود.
در نهایت، محدودیت‌ها و راهکارها شفاف بیان می‌شوند: اندازه باینری، تأخیر شروع، سقف حافظه مرورگر، کارایی I/O و چالش‌های مربوط به extensions یا کارگران پس‌زمینه؛ به‌همراه راهبردهایی مانند snapshot آماده، بارگذاری تنبل، و استفاده از Web Workers. جمع‌بندی ارائه می‌کند که PGlite در کجا انتخاب مناسبی است—از نمونه‌سازی سریع و ویژگی‌های آفلاین تا پردازش ایمن سمت‌کاربر و CI قابل اتکا—و چگونه می‌توان آغاز به کار کرد.
#WebAssembly #Postgres #PGlite #WASM #WASI #EdgeComputing #BrowserDatabases #DeveloperExperience
🟣لینک مقاله:
https://postgresweekly.com/link/174466/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Compiling Postgres to WebAssembly with PGlite
🟢 خلاصه مقاله:
این ارائه ۳۰ دقیقه‌ای از Sam Willis نشان می‌دهد چگونه می‌توان Postgres را برای اجرای مستقیم در WebAssembly کامپایل کرد و PGlite چه‌طور این ایده را به راهکاری کاربردی تبدیل می‌کند. انگیزه اصلی، اجرای دیتابیس در مرورگر یا محیط‌های edge است تا بتوان به اپ‌های آفلاین، دموهای قابل تکرار، تست سریع و اجرای ایمن و ایزوله بدون نیاز به سرور دست یافت.
در ادامه، مسیر فنی از کد Cِ Postgres تا WebAssembly توضیح داده می‌شود: محدودیت‌های WASI، نبود fork و برخی سیستم‌کال‌های POSIX، شبیه‌سازی فایل‌سیستم و شیوه‌های معمول برای پایداری داده در مرورگر (مثل IndexedDB یا OPFS) یا فضای ذخیره‌سازی معادل در edge. همچنین بازطراحی همزمانی بدون مدل چندپردازه، بسته‌بندی باینری برای کاهش زمان شروع، و مدیریت کارهای پس‌زمینه بررسی می‌شود.
از منظر توسعه‌دهنده، PGlite یک API ساده برای راه‌اندازی سریع، اجرای SQL، مهاجرت‌ها و seed داده ارائه می‌کند و سناریوهایی مثل تحلیل سمت‌کلاینت، مستندسازی تعاملی، تست انتهابه‌انتها بدون سرور، و آموزش را پوشش می‌دهد. ادغام با ابزارها و runtimeهایی مانند Node و Deno نیز مطرح است تا همان artifactِ Wasm در محیط‌های مختلف پایدار اجرا شود.
در نهایت، محدودیت‌ها و راهکارها شفاف بیان می‌شوند: اندازه باینری، تأخیر شروع، سقف حافظه مرورگر، کارایی I/O و چالش‌های مربوط به extensions یا کارگران پس‌زمینه؛ به‌همراه راهبردهایی مانند snapshot آماده، بارگذاری تنبل، و استفاده از Web Workers. جمع‌بندی ارائه می‌کند که PGlite در کجا انتخاب مناسبی است—از نمونه‌سازی سریع و ویژگی‌های آفلاین تا پردازش ایمن سمت‌کاربر و CI قابل اتکا—و چگونه می‌توان آغاز به کار کرد.
#WebAssembly #Postgres #PGlite #WASM #WASI #EdgeComputing #BrowserDatabases #DeveloperExperience
🟣لینک مقاله:
https://postgresweekly.com/link/174466/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
YouTube
"Compiling Postgres to WASM with PGlite" with Sam Willis
This talk introduces our investigations into creating a lightweight WASM build of Postgres. It covers our objectives for the project and how we approached the work. It talks through some of the challenges we faced, lessons we've learned and opportunities…
🔵 عنوان مقاله
The End of Digital Analytics (20 minute read)
🟢 خلاصه مقاله:
**پایان مدل سنتی Digital analytics مبتنی بر کلیک و داشبوردهای سبک GA فرا رسیده است؛ حذف کوکی‌های شخص ثالث، محدودیت‌های حریم خصوصی و ضعف‌های GA4 باعث شکستن انتساب و بی‌اعتمادی به گزارش‌ها شده‌اند. دو جانشین در حال رشدند: 1) بهینه‌سازی عملیاتی تجربه مشتری با تمرکز بر سفرهای کلیدی محصول، کاهش اصطکاک، افزایش Activation و اجرای آزمایش‌ها و تریگرهای رفتاری؛ 2) هوش درآمدی مبتنی بر انبار داده که رفتار کاربران را به نتایج مالی پیوند می‌دهد. داده‌ها در Snowflake/BigQuery/Databricks یکپارچه می‌شوند و با یک لایه معنایی به سیگنال‌های عملیاتی مانند ریسک Churn، تمایل به Expansion و LTV تبدیل می‌شوند. وظیفه مهندسان داده روشن است: مدل‌های Warehouse-native با dbt، همبندی هویت دقیق (Deterministic/Probabilistic با رعایت حریم خصوصی)، و پایپ‌لاین‌های رویدادی بازپردازشی برای مدیریت داده‌های دیررس و نسخه‌بندی. سپس این سیگنال‌ها از طریق Reverse ETL و ابزارهای فعال‌سازی مثل Braze/Iterable/Customer.io و همچنین CRM به عملیات تزریق می‌شوند و اثرشان با Holdout/Uplift سنجیده می‌شود. نتیجه: Analytics از گزارش‌دهی منفعل به تصمیم‌سازی پیوسته و مرتبط با درآمد تغییر ماهیت می‌دهد.
#DigitalAnalytics #GA4 #DataEngineering #CustomerExperience #RevenueIntelligence #DataWarehouse #Attribution
🟣لینک مقاله:
https://timodechau.com/the-end-of-digital-analytics/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The End of Digital Analytics (20 minute read)
🟢 خلاصه مقاله:
**پایان مدل سنتی Digital analytics مبتنی بر کلیک و داشبوردهای سبک GA فرا رسیده است؛ حذف کوکی‌های شخص ثالث، محدودیت‌های حریم خصوصی و ضعف‌های GA4 باعث شکستن انتساب و بی‌اعتمادی به گزارش‌ها شده‌اند. دو جانشین در حال رشدند: 1) بهینه‌سازی عملیاتی تجربه مشتری با تمرکز بر سفرهای کلیدی محصول، کاهش اصطکاک، افزایش Activation و اجرای آزمایش‌ها و تریگرهای رفتاری؛ 2) هوش درآمدی مبتنی بر انبار داده که رفتار کاربران را به نتایج مالی پیوند می‌دهد. داده‌ها در Snowflake/BigQuery/Databricks یکپارچه می‌شوند و با یک لایه معنایی به سیگنال‌های عملیاتی مانند ریسک Churn، تمایل به Expansion و LTV تبدیل می‌شوند. وظیفه مهندسان داده روشن است: مدل‌های Warehouse-native با dbt، همبندی هویت دقیق (Deterministic/Probabilistic با رعایت حریم خصوصی)، و پایپ‌لاین‌های رویدادی بازپردازشی برای مدیریت داده‌های دیررس و نسخه‌بندی. سپس این سیگنال‌ها از طریق Reverse ETL و ابزارهای فعال‌سازی مثل Braze/Iterable/Customer.io و همچنین CRM به عملیات تزریق می‌شوند و اثرشان با Holdout/Uplift سنجیده می‌شود. نتیجه: Analytics از گزارش‌دهی منفعل به تصمیم‌سازی پیوسته و مرتبط با درآمد تغییر ماهیت می‌دهد.
#DigitalAnalytics #GA4 #DataEngineering #CustomerExperience #RevenueIntelligence #DataWarehouse #Attribution
🟣لینک مقاله:
https://timodechau.com/the-end-of-digital-analytics/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Timo Dechau
The End of Digital Analytics
as we know it.
When Amplitude announced their new chief evangelist some days ago, most people saw a standard hire - congratulations comments galore. I saw something different: a clear signal that digital analytics as we know it is fundamentally over.
This…
When Amplitude announced their new chief evangelist some days ago, most people saw a standard hire - congratulations comments galore. I saw something different: a clear signal that digital analytics as we know it is fundamentally over.
This…
🔵 عنوان مقاله
Tuning Asynchronous I/O (AIO) in Postgres 18
🟢 خلاصه مقاله:
در Postgres 18 قابلیت AIO اضافه شده که امکان ارسال همزمان عملیات خواندن/نوشتن بدون بلوکه‌کردن پردازش‌ها را می‌دهد. نتیجه‌اش استفاده بهتر از CPU، افزایش توان عبوری و کاهش لگ‌های انتهای توزیع، به‌ویژه روی SSD/NVMe است. برای تیونینگ، از مقدارهای پیش‌فرض شروع کنید و با اندازه‌گیری دقیق جلو بروید؛ عمق صف مهم‌ترین اهرم است: عمق کم پهنا‌باند را هدر می‌دهد و عمق زیاد تاخیر را بالا می‌برد. اندازه‌ی دسته‌های ارسال، shared_buffers، و ریتم نوشتن‌های WAL/چک‌پوینت باید با نوع کار (OLTP در برابر تحلیل‌محور) و نوع دیسک تنظیم شوند. با pg_stat_io و رویدادهای انتظار در Postgres و ابزارهای سیستم‌عاملی مثل iostat، perf و pidstat پ99 تاخیر، صف‌ها و استفاده‌ی دیسک/CPU را پایش کنید. تفاوت‌های پلتفرمی مهم‌اند: روی Linux با io_uring، فایل‌سیستم‌ها (XFS/ext4/ZFS) و دیسک‌های ابری/شبکه‌ای رفتار متفاوتی دارند؛ HDD به عمق صف محافظه‌کارانه‌تر نیاز دارد و NVMe از عمق بیشتر سود می‌برد. در تمام مراحل، دوام (fsync، synchronous_commit) را با تست خرابی و بازیابی راستی‌آزمایی کنید. رویکرد مرحله‌ای—بالقوه با pgbench—و تنظیم تدریجی عمق صف و پارامترهای نوشتن، معمولاً بهترین کارایی پایدار را به‌همراه می‌آورد.
#Postgres #AIO #DatabasePerformance #io_uring #WAL #NVMe #Linux #Postgres18
🟣لینک مقاله:
https://postgresweekly.com/link/174756/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Tuning Asynchronous I/O (AIO) in Postgres 18
🟢 خلاصه مقاله:
در Postgres 18 قابلیت AIO اضافه شده که امکان ارسال همزمان عملیات خواندن/نوشتن بدون بلوکه‌کردن پردازش‌ها را می‌دهد. نتیجه‌اش استفاده بهتر از CPU، افزایش توان عبوری و کاهش لگ‌های انتهای توزیع، به‌ویژه روی SSD/NVMe است. برای تیونینگ، از مقدارهای پیش‌فرض شروع کنید و با اندازه‌گیری دقیق جلو بروید؛ عمق صف مهم‌ترین اهرم است: عمق کم پهنا‌باند را هدر می‌دهد و عمق زیاد تاخیر را بالا می‌برد. اندازه‌ی دسته‌های ارسال، shared_buffers، و ریتم نوشتن‌های WAL/چک‌پوینت باید با نوع کار (OLTP در برابر تحلیل‌محور) و نوع دیسک تنظیم شوند. با pg_stat_io و رویدادهای انتظار در Postgres و ابزارهای سیستم‌عاملی مثل iostat، perf و pidstat پ99 تاخیر، صف‌ها و استفاده‌ی دیسک/CPU را پایش کنید. تفاوت‌های پلتفرمی مهم‌اند: روی Linux با io_uring، فایل‌سیستم‌ها (XFS/ext4/ZFS) و دیسک‌های ابری/شبکه‌ای رفتار متفاوتی دارند؛ HDD به عمق صف محافظه‌کارانه‌تر نیاز دارد و NVMe از عمق بیشتر سود می‌برد. در تمام مراحل، دوام (fsync، synchronous_commit) را با تست خرابی و بازیابی راستی‌آزمایی کنید. رویکرد مرحله‌ای—بالقوه با pgbench—و تنظیم تدریجی عمق صف و پارامترهای نوشتن، معمولاً بهترین کارایی پایدار را به‌همراه می‌آورد.
#Postgres #AIO #DatabasePerformance #io_uring #WAL #NVMe #Linux #Postgres18
🟣لینک مقاله:
https://postgresweekly.com/link/174756/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Tomas Vondra
Tuning AIO in PostgreSQL 18
One of the significant improvements in PG18 is AIO. What are some basic tuning recommendations?
🔵 عنوان مقاله
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** الگوی Outbox روشی عملی برای حذف مشکل دو‌نوشتن و تضمین تحویل مطمئن پیام‌هاست. در این روش، تغییرات دامنه و یک رکورد رویداد در جدول outbox داخل همان تراکنش Postgres ذخیره می‌شوند؛ سپس یک پردازشگر در Go رویدادها را از جدول خوانده و به پیام‌رسان‌هایی مانند Kafka یا RabbitMQ منتشر می‌کند. با استفاده از فیلدهایی مانند ID، کلید موجودیت، نوع رویداد، payload به صورت JSONB، وضعیت/تعداد تلاش، و زمان‌ها، همگامی داده و پیام تضمین می‌شود. پردازشگر با انتخاب دسته‌های کوچک و به‌کارگیری SELECT … FOR UPDATE SKIP LOCKED از رقابت جلوگیری کرده، پس از انتشار وضعیت را به «پردازش‌شده» تغییر می‌دهد و شکست‌ها را با backoff و صف خطا مدیریت می‌کند. این الگو تحویل حداقل-یک‌بار را فراهم می‌کند و با مصرف‌کننده‌های idempotent می‌توان به پردازش مؤثرِ یک‌باره رسید. برای کارایی بهتر، ایندکس‌گذاری بر status و created_at، پارتیشن‌بندی جدول، حفظ ترتیب بر اساس کلید موجودیت و نظارت بر عمق صف و تأخیر انتشار توصیه می‌شود. به‌عنوان جایگزین، CDC با منبع‌خوانی منطقی Postgres (مثلاً Debezium) می‌تواند به‌جای polling استفاده شود، هرچند پیچیدگی عملیاتی بیشتری دارد. با آزمون‌های یکپارچه، مدیریت مهاجرت‌های شِما و پاک‌سازی داده‌های پردازش‌شده، پیاده‌سازی در Go و Postgres به پلی پایدار بین پایگاه‌داده و سامانه پیام‌رسان تبدیل می‌شود؛ همان رویکردی که Alex Pliutau در معرفی پیاده‌سازی Outbox با Go و Postgres بر آن تأکید دارد.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Reliability #Messaging
🟣لینک مقاله:
https://postgresweekly.com/link/174464/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Implement the Outbox Pattern in Go and Postgres
🟢 خلاصه مقاله:
** الگوی Outbox روشی عملی برای حذف مشکل دو‌نوشتن و تضمین تحویل مطمئن پیام‌هاست. در این روش، تغییرات دامنه و یک رکورد رویداد در جدول outbox داخل همان تراکنش Postgres ذخیره می‌شوند؛ سپس یک پردازشگر در Go رویدادها را از جدول خوانده و به پیام‌رسان‌هایی مانند Kafka یا RabbitMQ منتشر می‌کند. با استفاده از فیلدهایی مانند ID، کلید موجودیت، نوع رویداد، payload به صورت JSONB، وضعیت/تعداد تلاش، و زمان‌ها، همگامی داده و پیام تضمین می‌شود. پردازشگر با انتخاب دسته‌های کوچک و به‌کارگیری SELECT … FOR UPDATE SKIP LOCKED از رقابت جلوگیری کرده، پس از انتشار وضعیت را به «پردازش‌شده» تغییر می‌دهد و شکست‌ها را با backoff و صف خطا مدیریت می‌کند. این الگو تحویل حداقل-یک‌بار را فراهم می‌کند و با مصرف‌کننده‌های idempotent می‌توان به پردازش مؤثرِ یک‌باره رسید. برای کارایی بهتر، ایندکس‌گذاری بر status و created_at، پارتیشن‌بندی جدول، حفظ ترتیب بر اساس کلید موجودیت و نظارت بر عمق صف و تأخیر انتشار توصیه می‌شود. به‌عنوان جایگزین، CDC با منبع‌خوانی منطقی Postgres (مثلاً Debezium) می‌تواند به‌جای polling استفاده شود، هرچند پیچیدگی عملیاتی بیشتری دارد. با آزمون‌های یکپارچه، مدیریت مهاجرت‌های شِما و پاک‌سازی داده‌های پردازش‌شده، پیاده‌سازی در Go و Postgres به پلی پایدار بین پایگاه‌داده و سامانه پیام‌رسان تبدیل می‌شود؛ همان رویکردی که Alex Pliutau در معرفی پیاده‌سازی Outbox با Go و Postgres بر آن تأکید دارد.
#OutboxPattern #Go #Postgres #Microservices #EventDriven #TransactionalOutbox #Reliability #Messaging
🟣لینک مقاله:
https://postgresweekly.com/link/174464/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
packagemain.tech
How to implement the Outbox pattern in Go and Postgres
How and why to use the Outbox pattern to build a robust event-driven system.