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.
🔵 عنوان مقاله
Just Because You’re Getting an Index Scan, Doesn't Mean You Can’t Do Better
🟢 خلاصه مقاله:
وقتی در تجزیه و تحلیل طرحهای اجرای کوئری، شاهد اسکنهای ایندکس هستید، ممکن است گمان کنید که در مسیر مناسبی برای رسیدن به یک کوئری با عملکرد بالا قرار دارید. اما واقعیت این است که هنوز فرصتهای بهبود بسیاری وجود دارد تا کارایی کوئری خود را افزایش دهید. مایکل توضیح میدهد که حتی اگر از اسکنهای ایندکس استفاده میشود، نمیتوان نتیجه گرفت که بهترین حالت ممکن را یافتهاید؛ بلکه با کمی بررسی و تغییرات میتوان به نتایج بهتری دست یافت.
در واقع، اسکن ایندکسها ابزارهای قدرتمندی هستند، اما تنها راه حل نیستند. گاهی اوقات، استفاده از روشهای دیگری مانند جویندهای خاص یا تغییر در ساختار کوئری میتواند کارایی را به شدت بهبود بخشد. مهم است که همیشه چشمانداز وسیعتری داشته باشید و به دنبال راهکارهای کمهزینه و مؤثر برای بهینهسازی کوئریهای خود باشید. در نتیجه، باید همواره بررسی کنید که آیا مسیرهای جایگزین وجود دارند که بتوانند عملکرد سیستم شما را بهتر یا سریعتر کنند.
در نهایت، این نکته کلیدی است که هر چند شاهد اسکنهای ایندکس هستید، اما نباید از تلاش برای بهتر کردن عملکرد صرفنظر کنید. با کمی بررسی بیشتر و آزمایش روشهای متفاوت، میتوانید میزان بهرهوری پایگاه داده خود را افزایش دهید و بهترین نتیجه را در کوتاهترین زمان ممکن کسب کنید.
#بهینهسازی_پایگاه_داده #کاهش_زمان_اجرای_کوئری #ایندکس #عملکرد
🟣لینک مقاله:
https://postgresweekly.com/link/178920/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Just Because You’re Getting an Index Scan, Doesn't Mean You Can’t Do Better
🟢 خلاصه مقاله:
وقتی در تجزیه و تحلیل طرحهای اجرای کوئری، شاهد اسکنهای ایندکس هستید، ممکن است گمان کنید که در مسیر مناسبی برای رسیدن به یک کوئری با عملکرد بالا قرار دارید. اما واقعیت این است که هنوز فرصتهای بهبود بسیاری وجود دارد تا کارایی کوئری خود را افزایش دهید. مایکل توضیح میدهد که حتی اگر از اسکنهای ایندکس استفاده میشود، نمیتوان نتیجه گرفت که بهترین حالت ممکن را یافتهاید؛ بلکه با کمی بررسی و تغییرات میتوان به نتایج بهتری دست یافت.
در واقع، اسکن ایندکسها ابزارهای قدرتمندی هستند، اما تنها راه حل نیستند. گاهی اوقات، استفاده از روشهای دیگری مانند جویندهای خاص یا تغییر در ساختار کوئری میتواند کارایی را به شدت بهبود بخشد. مهم است که همیشه چشمانداز وسیعتری داشته باشید و به دنبال راهکارهای کمهزینه و مؤثر برای بهینهسازی کوئریهای خود باشید. در نتیجه، باید همواره بررسی کنید که آیا مسیرهای جایگزین وجود دارند که بتوانند عملکرد سیستم شما را بهتر یا سریعتر کنند.
در نهایت، این نکته کلیدی است که هر چند شاهد اسکنهای ایندکس هستید، اما نباید از تلاش برای بهتر کردن عملکرد صرفنظر کنید. با کمی بررسی بیشتر و آزمایش روشهای متفاوت، میتوانید میزان بهرهوری پایگاه داده خود را افزایش دهید و بهترین نتیجه را در کوتاهترین زمان ممکن کسب کنید.
#بهینهسازی_پایگاه_داده #کاهش_زمان_اجرای_کوئری #ایندکس #عملکرد
🟣لینک مقاله:
https://postgresweekly.com/link/178920/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgMustard
Just because you’re getting an index scan, doesn't mean you can’t do better! - pgMustard
An issue I often see folks missing is that they see that all of their scans involve indexes and they think that the query is as fast as it can be.
🔵 عنوان مقاله
Pipelining Comes to psql in Postgres 18
🟢 خلاصه مقاله:
در نسخه ۱۸ پایگاه داده پستگرس، ابزار جدیدی به نام «پایپلاینینگ» به ابزار خط فرمان psql افزوده شده است. این قابلیت امکان اجرای همزمان چند دستور یا عملیات در قالب لولهکشی را فراهم میکند، به گونهای که نتایج هر مرحله به صورت مستقیم و بدون نیاز به ذخیرهسازی موقت به مرحله بعدی منتقل میشود. دانیل اشاره کرده است که این ویژگی میتواند بر افزایش ظرفیت پردازش و سرعت اجرای کوئریها تاثیر چشمگیری داشته باشد، چرا که با کاهش زمان صرف شده برای انتقال و پردازش دادهها، توان عملیاتی سیستم به طور قابل توجهی بهبود مییابد.
استفاده از پایپلاینینگ در پستگرس ۱۸، یک پیشرفت مهم در بهبود کارایی و بهرهوری در اجرای کوئریهای پیچیده است. توسعهدهندگان و مدیران پایگاه داده اکنون میتوانند با بهرهگیری از این قابلیت، عملیاتهای دادهای خود را به صورت بهینهتر و سریعتر انجام دهند، به طوری که عملیاتهای متوالی و وابسته به هم با کمترین هزینه زمانی اجرا میشوند.
در نتیجه، این تغییر نویدبخش آیندهای است که در آن مدیریت و تجزیهوتحلیل دادههای بزرگتر و پیچیدهتر به راحتی و با کارایی بیشتری انجام خواهد شد. پایپلاینینگ در psql، ابزار مهمی است که روند توسعه و بهرهبرداری از دیتابیسهای پستگرس را به سمت مسیرهای جدیدی از عملکرد بهینه هدایت میکند.
#پستگرس #پایپلاینینگ #توسعه_پایگاه_داده #عملکرد_بهینه
🟣لینک مقاله:
https://postgresweekly.com/link/178921/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Pipelining Comes to psql in Postgres 18
🟢 خلاصه مقاله:
در نسخه ۱۸ پایگاه داده پستگرس، ابزار جدیدی به نام «پایپلاینینگ» به ابزار خط فرمان psql افزوده شده است. این قابلیت امکان اجرای همزمان چند دستور یا عملیات در قالب لولهکشی را فراهم میکند، به گونهای که نتایج هر مرحله به صورت مستقیم و بدون نیاز به ذخیرهسازی موقت به مرحله بعدی منتقل میشود. دانیل اشاره کرده است که این ویژگی میتواند بر افزایش ظرفیت پردازش و سرعت اجرای کوئریها تاثیر چشمگیری داشته باشد، چرا که با کاهش زمان صرف شده برای انتقال و پردازش دادهها، توان عملیاتی سیستم به طور قابل توجهی بهبود مییابد.
استفاده از پایپلاینینگ در پستگرس ۱۸، یک پیشرفت مهم در بهبود کارایی و بهرهوری در اجرای کوئریهای پیچیده است. توسعهدهندگان و مدیران پایگاه داده اکنون میتوانند با بهرهگیری از این قابلیت، عملیاتهای دادهای خود را به صورت بهینهتر و سریعتر انجام دهند، به طوری که عملیاتهای متوالی و وابسته به هم با کمترین هزینه زمانی اجرا میشوند.
در نتیجه، این تغییر نویدبخش آیندهای است که در آن مدیریت و تجزیهوتحلیل دادههای بزرگتر و پیچیدهتر به راحتی و با کارایی بیشتری انجام خواهد شد. پایپلاینینگ در psql، ابزار مهمی است که روند توسعه و بهرهبرداری از دیتابیسهای پستگرس را به سمت مسیرهای جدیدی از عملکرد بهینه هدایت میکند.
#پستگرس #پایپلاینینگ #توسعه_پایگاه_داده #عملکرد_بهینه
🟣لینک مقاله:
https://postgresweekly.com/link/178921/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
postgresql.verite.pro
Pipelining in psql (PostgreSQL 18)
the psql client version 18 comes with pipelining, which can speed up client-server communication. In this post, let's see how it works and how much can be g...
🔵 عنوان مقاله
Lessons from Scaling Postgres Queues to 100K Events Per Second
🟢 خلاصه مقاله:
رودرباستک تصمیم گرفت از پایگاه داده PostgreSQL به عنوان سیستم صفبندی اصلی خود به جای ابزارهایی مانند کافکا استفاده کند. این تیم در مورد تجربیات و درسهایی که در فرآیند راهاندازی و مقیاسپذیری این سامانه کسب کردهاند، توضیح میدهد. هدف آنها افزایش ظرفیت پردازش تا ۱۰۰ هزار رویداد در ثانیه است، و این چالش نیازمند به کارگیری راهکارهای نوآورانه و بهینه بود تا سیستم بتواند این حجم عظیم از رویدادها را به صورت موثر مدیریت کند.
در این مسیر، تیم توسعهدهندگان با مشکلاتی مانند کاهش زمان پاسخ، بهبود کارایی، و جلوگیری از تداخل دادهها مواجه شدند. آنها راهکارهایی مانند بهینهسازی ساختار جداول، افزایش توان عملیاتی سرورها، و پیادهسازی نمونههای توزیعشده را به کار گرفتند. این اقدامات باعث شد که سیستم PostgreSQL آنها بتواند در سطح مقیاس عظیم کار کند و مطمئناً نیازهای رو به رشد کسبوکارشان را برآورده سازد.
در نهایت، این تجربیات نشان میدهد که با استراتژیهای مناسب و درک صحیح از قابلیتهای پایگاه دادهها، میتوان سیستمهای مبتنی بر PostgreSQL را برای حجمهای بسیار بالا مقیاس داد. این داستان منبع ارزشمندی برای تیمهای فنی است که قصد دارند سیستمهای صفبندی مقیاسپذیر و قدرتمند بسازند، بدون نیاز به ابزارهای تخصصی مانند کافکا.
#پایگاه_داده #مقیاس_پذیری #PostgreSQL #توسعه
🟣لینک مقاله:
https://postgresweekly.com/link/178917/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Lessons from Scaling Postgres Queues to 100K Events Per Second
🟢 خلاصه مقاله:
رودرباستک تصمیم گرفت از پایگاه داده PostgreSQL به عنوان سیستم صفبندی اصلی خود به جای ابزارهایی مانند کافکا استفاده کند. این تیم در مورد تجربیات و درسهایی که در فرآیند راهاندازی و مقیاسپذیری این سامانه کسب کردهاند، توضیح میدهد. هدف آنها افزایش ظرفیت پردازش تا ۱۰۰ هزار رویداد در ثانیه است، و این چالش نیازمند به کارگیری راهکارهای نوآورانه و بهینه بود تا سیستم بتواند این حجم عظیم از رویدادها را به صورت موثر مدیریت کند.
در این مسیر، تیم توسعهدهندگان با مشکلاتی مانند کاهش زمان پاسخ، بهبود کارایی، و جلوگیری از تداخل دادهها مواجه شدند. آنها راهکارهایی مانند بهینهسازی ساختار جداول، افزایش توان عملیاتی سرورها، و پیادهسازی نمونههای توزیعشده را به کار گرفتند. این اقدامات باعث شد که سیستم PostgreSQL آنها بتواند در سطح مقیاس عظیم کار کند و مطمئناً نیازهای رو به رشد کسبوکارشان را برآورده سازد.
در نهایت، این تجربیات نشان میدهد که با استراتژیهای مناسب و درک صحیح از قابلیتهای پایگاه دادهها، میتوان سیستمهای مبتنی بر PostgreSQL را برای حجمهای بسیار بالا مقیاس داد. این داستان منبع ارزشمندی برای تیمهای فنی است که قصد دارند سیستمهای صفبندی مقیاسپذیر و قدرتمند بسازند، بدون نیاز به ابزارهای تخصصی مانند کافکا.
#پایگاه_داده #مقیاس_پذیری #PostgreSQL #توسعه
🟣لینک مقاله:
https://postgresweekly.com/link/178917/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
RudderStack
Lessons from scaling PostgreSQL queues to 100K events
This post is a chronicle of the critical, hard-won lessons learned while maturing PostgreSQL into a highly performant and resilient queuing system.