🔵 عنوان مقاله
PostgREST 14: A RESTful API for Postgres Databases
🟢 خلاصه مقاله:
در سال ۲۰۲۵، سال پرکاری برای سرورهای وب مستقل بود که به طور مستقیم، بانک اطلاعاتی پستگرس شما را به یک رابط برنامهنویسی تحت وب RESTful تبدیل میکنند. در این سال، نسخههای ۱۳ و ۱۴ این ابزار قدرتمند و محبوب عرضه شدند، هر کدام با قابلیتها و بهبودهای خاص خودشان که کار توسعهدهندگان را بسیار راحتتر و کارآمدتر کرده است.
این پروژه، که PostgREST نام دارد، به توسعهدهندگان اجازه میدهد تا بدون نیاز به نوشتن کدهای پیچیده، به سرعت و با سهولت، از بانک اطلاعاتی پستگرس خود در قالب APIهای استاندارد استفاده کنند. نسخههای جدید علاوه بر بهبودهای عملکرد، امکانات تازهای ارائه میدهند که توسعه و مدیریت APIها را سادهتر و انعطافپذیرتر میسازند.
در مجموع، سال ۲۰۲۵ نشان داد که ابزارهای متنباز و مخصوص مدیریت بانکهای اطلاعاتی، همچنان در حال توسعه و ارتقاء هستند و آیندهای روشن در انتظار آنها است، چیزی که به توسعهدهندگان این امکان را میدهد تا در پروژههایشان بهرهوری بیشتری داشته باشند.
#پستگرس #API #وبسرویس #توسعه
🟣لینک مقاله:
https://postgresweekly.com/link/178696/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgREST 14: A RESTful API for Postgres Databases
🟢 خلاصه مقاله:
در سال ۲۰۲۵، سال پرکاری برای سرورهای وب مستقل بود که به طور مستقیم، بانک اطلاعاتی پستگرس شما را به یک رابط برنامهنویسی تحت وب RESTful تبدیل میکنند. در این سال، نسخههای ۱۳ و ۱۴ این ابزار قدرتمند و محبوب عرضه شدند، هر کدام با قابلیتها و بهبودهای خاص خودشان که کار توسعهدهندگان را بسیار راحتتر و کارآمدتر کرده است.
این پروژه، که PostgREST نام دارد، به توسعهدهندگان اجازه میدهد تا بدون نیاز به نوشتن کدهای پیچیده، به سرعت و با سهولت، از بانک اطلاعاتی پستگرس خود در قالب APIهای استاندارد استفاده کنند. نسخههای جدید علاوه بر بهبودهای عملکرد، امکانات تازهای ارائه میدهند که توسعه و مدیریت APIها را سادهتر و انعطافپذیرتر میسازند.
در مجموع، سال ۲۰۲۵ نشان داد که ابزارهای متنباز و مخصوص مدیریت بانکهای اطلاعاتی، همچنان در حال توسعه و ارتقاء هستند و آیندهای روشن در انتظار آنها است، چیزی که به توسعهدهندگان این امکان را میدهد تا در پروژههایشان بهرهوری بیشتری داشته باشند.
#پستگرس #API #وبسرویس #توسعه
🟣لینک مقاله:
https://postgresweekly.com/link/178696/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostgREST 13.0
PostgREST Documentation
, PostgREST is a standalone web server that turns your PostgreSQL database directly into a RESTful API. The structural constraints and permissions in the database determine the API endpoints and operations. Sponsors:,, Database as Single Source of Truth:…
مروری بر مفاهیم 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/
در ارائه اخیرم برای شرکت آپ، یک مخزن 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/
GitHub
GitHub - ap-incubator/vector-database: Vector DB tutorial
Vector DB tutorial. Contribute to ap-incubator/vector-database development by creating an account on GitHub.
🔵 عنوان مقاله
Which Indexes Could Be Corrupted After an OS Upgrade?
🟢 خلاصه مقاله:
وقتی سیستمعامل شما بهروزرسانی میشود، ممکن است تاثیراتی بر روی پایگاههای داده شما داشته باشد. یکی از این اثرات مهم، تغییر در نحوه تعریف و تنظیمات مقایسهکنندهها (collations) است که در بانکهای اطلاعاتی مانند Postgres مورد استفاده قرار میگیرند. این بهروزرسانیهای سیستمعامل میتواند وابستههای نرمافزاری را بروزرسانی کرده و در نتیجه، ساختار و عملکرد برخی شاخصها را مختل کند.
وقتی تعریفهای جدید از collation تغییر کند، شاخصهای مربوط به جداول و ستونها ممکن است دچار مشکل شوند. این مشکلات ممکن است شامل اختلال در صحت و عملکرد عملیات جستجو و مرتبسازی در پایگاه داده باشد، زیرا شاخصها بر اساس تنظیمات قبلی ساخته شدهاند که حالا دیگر با نسخه جدید سیستمعامل سازگاری ندارند. این وضعیت میتواند منجر به خراب شدن یا ناسازگاری شاخصها شده و کارایی سیستم را کاهش دهد.
برای جلوگیری از این مشکلات، پیشنهاد میشود پس از بهروزرسانی سیستمعامل، تمامی شاخصها را مجدداً بازسازی کنید. همچنین، بررسی سلامت شاخصها و انجام آزمونهای کارایی قبل و بعد از بهروزرسانی میتواند کمک کند تا هر گونه مشکل به سرعت شناسایی و برطرف شود. در نهایت، آگاهی و برنامهریزی دقیق پیش از انجام هر نوع بهروزرسانی، مهمترین راهکار برای حفظ سلامت و کارایی پایگاههای داده است.
#پایگاه_داده #آسیب_پذیری #بهروزرسانی_سیستم #شاخصها
🟣لینک مقاله:
https://postgresweekly.com/link/178675/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Which Indexes Could Be Corrupted After an OS Upgrade?
🟢 خلاصه مقاله:
وقتی سیستمعامل شما بهروزرسانی میشود، ممکن است تاثیراتی بر روی پایگاههای داده شما داشته باشد. یکی از این اثرات مهم، تغییر در نحوه تعریف و تنظیمات مقایسهکنندهها (collations) است که در بانکهای اطلاعاتی مانند Postgres مورد استفاده قرار میگیرند. این بهروزرسانیهای سیستمعامل میتواند وابستههای نرمافزاری را بروزرسانی کرده و در نتیجه، ساختار و عملکرد برخی شاخصها را مختل کند.
وقتی تعریفهای جدید از collation تغییر کند، شاخصهای مربوط به جداول و ستونها ممکن است دچار مشکل شوند. این مشکلات ممکن است شامل اختلال در صحت و عملکرد عملیات جستجو و مرتبسازی در پایگاه داده باشد، زیرا شاخصها بر اساس تنظیمات قبلی ساخته شدهاند که حالا دیگر با نسخه جدید سیستمعامل سازگاری ندارند. این وضعیت میتواند منجر به خراب شدن یا ناسازگاری شاخصها شده و کارایی سیستم را کاهش دهد.
برای جلوگیری از این مشکلات، پیشنهاد میشود پس از بهروزرسانی سیستمعامل، تمامی شاخصها را مجدداً بازسازی کنید. همچنین، بررسی سلامت شاخصها و انجام آزمونهای کارایی قبل و بعد از بهروزرسانی میتواند کمک کند تا هر گونه مشکل به سرعت شناسایی و برطرف شود. در نهایت، آگاهی و برنامهریزی دقیق پیش از انجام هر نوع بهروزرسانی، مهمترین راهکار برای حفظ سلامت و کارایی پایگاههای داده است.
#پایگاه_داده #آسیب_پذیری #بهروزرسانی_سیستم #شاخصها
🟣لینک مقاله:
https://postgresweekly.com/link/178675/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
CYBERTEC PostgreSQL | Services & Support
Which indexes can be corrupted after an operating system upgrade?
Rebuilding indexes after an operating system upgrade is painful. Learn how to rebuild only those indexes that really need it!
Forwarded from Gopher Academy
شرکت Microsoft قصد دارد تا پایان سال ۲۰۳۰ تمام کدهای نوشتهشده به زبانهای C و C++ را با Rust جایگزین کند.
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
🔥3
سلام . در بخشهای قبلی، نحوه ایجاد کلیدها در پایگاهداده 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
دستور 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
lnkd.in
LinkedIn
This link will take you to a page that’s not on LinkedIn
در بلاگ 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 انعطافپذیری و امکانات بیشتری ارائه میده.
🔑 ۱) مدل شبکه و اتصال
• ا**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 انعطافپذیری و امکانات بیشتری ارائه میده.
❤1👍1🍾1
دیتابیسهای قدرتمند بساز بدون کد نوشتن! NocoDB ابزار اوپن سورس جایگزین Airtable
با رابط spreadsheet-like راحت، میتونی دیتابیس هارو بسازی ، ویوهای متنوع (گرید، کانبان، گالری، فرم، تقویم)، فیلتر/سورت پیشرفته، فرمولا، لینک/لوکآپ، کنترل دسترسی دقیق و ادغام با Slack، Discord، AWS S3 و کلی ابزار دیگه!
github.com/nocodb/nocodb
<POURYA/>
با رابط 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/>
توی این مقاله خیلی ساده flow اجرای یه کوئری رو توضیح دادم که MySQL دقیقا پشت صحنه چه فرآیندی رو انجام میده تا هم پرفورمنس رو حفظ کنه و هم نتیجه رو به کاربر برگردونه. میتونید مقاله رو توی لینک زیر بخونید:
https://farshadth.medium.com/how-mysql-works-behind-the-scenes-72746950cd65
<Farshad Tofighi/>
Medium
How MySQL Works Behind the Scenes
Many people think MySQL always reads and writes data directly from disk, but in reality, it is designed to minimize disk access and…
👍2
وقتی SQL Server بیشازحد به حافظهاش اعتماد میکنه.
خیلی وقتها مشکل از خود کوئری نیست،
از Execution Plan قدیمیه که دیگه با دیتای فعلی همخوانی نداره.
سناریوی رایج:
Batch Update با TOP
لوپ یا Job طولانی
دیتایی که وسط کار شدیداً تغییر میکنه
کوئری بیخطا تموم میشه، ولی هنوز دیتا باقی مونده!
علتش؟ SQL Server یه Plan میسازه، Cache
میکنه و میگه:
«دفعه بعد هم اوضاع همینه»
در حالی که نیست.
اینجاست که این خط نجاتدهنده میاد وسط:
OPTION (RECOMPILE)
چی کار میکنه؟
هر بار Compile جدید، تخمین دقیقتر، Join درستتر، Memory Grant واقعی، پایان دادن به رفتارهای «عجیب ولی بیخطا»
جمعبندی:
ء Recompile یعنی «تصمیمگیری با وضعیت امروز دیتا، نه خاطرات دیروز»
| <Sajjad Zibafar/>
خیلی وقتها مشکل از خود کوئری نیست،
از Execution Plan قدیمیه که دیگه با دیتای فعلی همخوانی نداره.
سناریوی رایج:
Batch Update با TOP
لوپ یا Job طولانی
دیتایی که وسط کار شدیداً تغییر میکنه
کوئری بیخطا تموم میشه، ولی هنوز دیتا باقی مونده!
علتش؟ SQL Server یه Plan میسازه، Cache
میکنه و میگه:
«دفعه بعد هم اوضاع همینه»
در حالی که نیست.
اینجاست که این خط نجاتدهنده میاد وسط:
OPTION (RECOMPILE)
چی کار میکنه؟
هر بار Compile جدید، تخمین دقیقتر، Join درستتر، Memory Grant واقعی، پایان دادن به رفتارهای «عجیب ولی بیخطا»
جمعبندی:
ء Recompile یعنی «تصمیمگیری با وضعیت امروز دیتا، نه خاطرات دیروز»
| <Sajjad Zibafar/>
❤2
Forwarded from Future Pulse Persian
وضعیت اینترنت ایران طبق رادار های کلود فلیر
احتمال قطع دسترسی اینترنت با این وضعیت خیلی زیاده...
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
احتمال قطع دسترسی اینترنت با این وضعیت خیلی زیاده...
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
❤1👍1
🔵 عنوان مقاله
Kafka is Fast, I'll Use Postgres
🟢 خلاصه مقاله:
کافکا سریع است، پس من از پستگرس استفاده میکنم.
در حالی که از یک پست دیگر درباره جایگزینی پستگرس به جای ریدیس برای کشینگ الهام گرفته شده بود، نویسنده تصمیم گرفت بررسی کند آیا پستگرس واقعاً قدرتمند است و میتواند در مواردی که معمولاً کافکا انتخاب میشود، عملکرد مناسبی داشته باشد.
در این مقاله، او به مقایسه قابلیتهای پستگرس و کافکا پرداخته و بررسی میکند که آیا پستگرس به عنوان جایگزینی سریع و کارآمد، میتواند نیازهای جریان داده، پیامرسانی و پردازش رویداد را برآورده سازد یا خیر.
نتیجهگیری نشان میدهد که در برخی موارد، پستگرس میتواند گزینهای گزینهپذیر بر جای کافکا باشد، بهویژه زمانی که سادگی، هزینه و سازگاری با زیرساختهای موجود اهمیت دارد. این مقاله دیدگاه جدیدی در انتخاب ابزارهای مدیریت دادهها و جریانهای اطلاعاتی ارائه میدهد.
#پستگرس #کافکا #مدیریت_دیتا #تکنولوژی
🟣لینک مقاله:
https://postgresweekly.com/link/178913/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Kafka is Fast, I'll Use Postgres
🟢 خلاصه مقاله:
کافکا سریع است، پس من از پستگرس استفاده میکنم.
در حالی که از یک پست دیگر درباره جایگزینی پستگرس به جای ریدیس برای کشینگ الهام گرفته شده بود، نویسنده تصمیم گرفت بررسی کند آیا پستگرس واقعاً قدرتمند است و میتواند در مواردی که معمولاً کافکا انتخاب میشود، عملکرد مناسبی داشته باشد.
در این مقاله، او به مقایسه قابلیتهای پستگرس و کافکا پرداخته و بررسی میکند که آیا پستگرس به عنوان جایگزینی سریع و کارآمد، میتواند نیازهای جریان داده، پیامرسانی و پردازش رویداد را برآورده سازد یا خیر.
نتیجهگیری نشان میدهد که در برخی موارد، پستگرس میتواند گزینهای گزینهپذیر بر جای کافکا باشد، بهویژه زمانی که سادگی، هزینه و سازگاری با زیرساختهای موجود اهمیت دارد. این مقاله دیدگاه جدیدی در انتخاب ابزارهای مدیریت دادهها و جریانهای اطلاعاتی ارائه میدهد.
#پستگرس #کافکا #مدیریت_دیتا #تکنولوژی
🟣لینک مقاله:
https://postgresweekly.com/link/178913/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TopicPartition
Kafka is fast -- I'll use Postgres
Why you should just use Postgres instead of Kafka for small-scale message queuing and pub-sub patterns. Benchmarks and practical tests included.
🔵 عنوان مقاله
Postgres in the Time of Monster Hardware
🟢 خلاصه مقاله:
در دنیای امروز، تصور کنید که پردازشگر مورد استفاده در سیستمهای کاری شما چقدر قدرتمند است. ممکن است باور نکنید، اما تصور داشتن پردازندهای مانند AMD EPYC با ۱۹۲ هسته در هر سوکت و رم ۱۰ ترابایتی، کاملاً در دسترس است. این نوع از سختافزارهای مدرن، قابلیتهایی بینظیر را فراهم میکند و قدرت پردازش فوقالعادهای را در اختیار ما قرار میدهد. چنین امکاناتی، ما را به سؤالهایی درباره روشهای امروزی برای توسعه و مقیاسبندی سرورهای پایگاه داده و بهرهبرداری بهینه از این سختافزارهای عظیم، وا میدارد.
در نتیجه، نیاز به راهکارهای نوین و کارآمد در زمینه مدیریت بانکهای اطلاعاتی در عصر سختافزارهای غولپیکر، بیش از پیش احساس میشود. این امکانات ابتدا ما را ترغیب میکند که به سمت راهکارهای مقیاسپذیر، توزیعشده و بهینه حرکت کنیم، تا بتوانیم از توان بینظیر سختافزارهای جدید بهره ببریم و عملکرد سیستمهای پایگاه داده را به سطح جدیدی ارتقا دهیم. در نتیجه، ما باید ابزارها و فناوریهایی را توسعه دهیم که بتوانند با این تجهیزات قدرتمند هماهنگ شوند و به بهرهبرداری حداکثری برسند.
در نهایت، این روند نشان میدهد که دنیای پایگاههای داده در حال گذار به فضاهای جدید است، جایی که فناوریهای مدرن و سختافزارهای قدرتمند نقش کلیدی در آیندهسازی آنها ایفا میکنند. توانمندسازی سرورها با چنین سختافزارهای عظیم، نیازمند تفکر نوآورانه و بهکارگیری راهکارهای پیشرفته است تا از امکانات بینظیر آنها بهرهمند شویم و سیستمهای دادهای قدرتمندتری بسازیم.
#پایگاه_داده #مقیاسپذیری #تکنولوژی_مدرن #سختافزار
🟣لینک مقاله:
https://postgresweekly.com/link/178922/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Postgres in the Time of Monster Hardware
🟢 خلاصه مقاله:
در دنیای امروز، تصور کنید که پردازشگر مورد استفاده در سیستمهای کاری شما چقدر قدرتمند است. ممکن است باور نکنید، اما تصور داشتن پردازندهای مانند AMD EPYC با ۱۹۲ هسته در هر سوکت و رم ۱۰ ترابایتی، کاملاً در دسترس است. این نوع از سختافزارهای مدرن، قابلیتهایی بینظیر را فراهم میکند و قدرت پردازش فوقالعادهای را در اختیار ما قرار میدهد. چنین امکاناتی، ما را به سؤالهایی درباره روشهای امروزی برای توسعه و مقیاسبندی سرورهای پایگاه داده و بهرهبرداری بهینه از این سختافزارهای عظیم، وا میدارد.
در نتیجه، نیاز به راهکارهای نوین و کارآمد در زمینه مدیریت بانکهای اطلاعاتی در عصر سختافزارهای غولپیکر، بیش از پیش احساس میشود. این امکانات ابتدا ما را ترغیب میکند که به سمت راهکارهای مقیاسپذیر، توزیعشده و بهینه حرکت کنیم، تا بتوانیم از توان بینظیر سختافزارهای جدید بهره ببریم و عملکرد سیستمهای پایگاه داده را به سطح جدیدی ارتقا دهیم. در نتیجه، ما باید ابزارها و فناوریهایی را توسعه دهیم که بتوانند با این تجهیزات قدرتمند هماهنگ شوند و به بهرهبرداری حداکثری برسند.
در نهایت، این روند نشان میدهد که دنیای پایگاههای داده در حال گذار به فضاهای جدید است، جایی که فناوریهای مدرن و سختافزارهای قدرتمند نقش کلیدی در آیندهسازی آنها ایفا میکنند. توانمندسازی سرورها با چنین سختافزارهای عظیم، نیازمند تفکر نوآورانه و بهکارگیری راهکارهای پیشرفته است تا از امکانات بینظیر آنها بهرهمند شویم و سیستمهای دادهای قدرتمندتری بسازیم.
#پایگاه_داده #مقیاسپذیری #تکنولوژی_مدرن #سختافزار
🟣لینک مقاله:
https://postgresweekly.com/link/178922/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
EDB
Postgres in the time of monster hardware
🔵 عنوان مقاله
Benchmarking Postgres 17 vs 18
🟢 خلاصه مقاله:
در این مقاله، نویسنده به بررسی و مقایسه دقیق عملکرد نسخههای مختلف پایگاه داده PostgreSQL، یعنی نسخههای ۱۷ و ۱۸، پرداخته است. او با اجرای مجموعهای گسترده از آزمونها در حدود ۹۶ ترکیب متفاوت، تلاش کرده است تا تفاوتهای عملکرد این دو نسخه را ارزیابی کند. نتایج این آزمایشها نشان میدهد که نسخه ۱۸ پایگاه داده PostgreSQL، در کنار بهبودهای عملکردی قابل توجه، مزایای بیشتری نسبت به نسخه قبلی خود دارد.
نکته مهمی که در این بررسی مشخص شد، نقش پررنگ دیسکهای محلی است؛ به گونهای که استفاده از دیسکهای داخلی و ذاتی، تاثیر زیادی بر سرعت و کارایی سیستم دارد. همچنین، تنظیمات و پیکربندیهای سیستم همچنان اهمیت زیادی دارند و شخصیسازی آنها میتواند بهرهوری سیستم را به طرز چشمگیری افزایش دهد. در مجموع، این آزمایشها نشان میدهند که ارتقای نسخه و بهینهسازی تنظیمات، همچنان راهکاری مؤثر برای بهبود عملکرد پایگاه داده است.
در پایان، میتوان نتیجه گرفت که PostgreSQL ۱۸ نسبت به نسخههای پیشین خود، پیشرفت قابل توجهی دارد و بهرهمندی از دیسکهای داخلی و انجام تنظیمات دقیق، ارزش ادامهدار بودن این بهبودها را دوچندان میسازد.
#پایگاه_داده #PostgreSQL #بهبود_عملکرد #تست_پرفورمنس
🟣لینک مقاله:
https://postgresweekly.com/link/178918/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Benchmarking Postgres 17 vs 18
🟢 خلاصه مقاله:
در این مقاله، نویسنده به بررسی و مقایسه دقیق عملکرد نسخههای مختلف پایگاه داده PostgreSQL، یعنی نسخههای ۱۷ و ۱۸، پرداخته است. او با اجرای مجموعهای گسترده از آزمونها در حدود ۹۶ ترکیب متفاوت، تلاش کرده است تا تفاوتهای عملکرد این دو نسخه را ارزیابی کند. نتایج این آزمایشها نشان میدهد که نسخه ۱۸ پایگاه داده PostgreSQL، در کنار بهبودهای عملکردی قابل توجه، مزایای بیشتری نسبت به نسخه قبلی خود دارد.
نکته مهمی که در این بررسی مشخص شد، نقش پررنگ دیسکهای محلی است؛ به گونهای که استفاده از دیسکهای داخلی و ذاتی، تاثیر زیادی بر سرعت و کارایی سیستم دارد. همچنین، تنظیمات و پیکربندیهای سیستم همچنان اهمیت زیادی دارند و شخصیسازی آنها میتواند بهرهوری سیستم را به طرز چشمگیری افزایش دهد. در مجموع، این آزمایشها نشان میدهند که ارتقای نسخه و بهینهسازی تنظیمات، همچنان راهکاری مؤثر برای بهبود عملکرد پایگاه داده است.
در پایان، میتوان نتیجه گرفت که PostgreSQL ۱۸ نسبت به نسخههای پیشین خود، پیشرفت قابل توجهی دارد و بهرهمندی از دیسکهای داخلی و انجام تنظیمات دقیق، ارزش ادامهدار بودن این بهبودها را دوچندان میسازد.
#پایگاه_داده #PostgreSQL #بهبود_عملکرد #تست_پرفورمنس
🟣لینک مقاله:
https://postgresweekly.com/link/178918/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
Benchmarking Postgres 17 vs 18 — PlanetScale
Postgres 18 brings a significant improvement to read performance via async I/O and I/O worker threads. Here we compare its performance to Postgres 17.