🔵 عنوان مقاله
Storing Products, Prices and Orders in Postgres
🟢 خلاصه مقاله:
این مقاله نشان میدهد که در ذخیرهسازی محصولات، قیمتها و سفارشها در Postgres نرمالسازی افراطی میتواند دقت تاریخی و کارایی را مختل کند. راهکار پیشنهادی، ترکیب یک هسته رابطهای با دنرمالسازی هدفمند است: نگهداشتن اسنپشات «همانطور که فروخته شد» در سطرهای سفارش (نام/SKU، قیمت، ارز، مالیات و تخفیف) و نسخهبندی یا تاریخدار کردن قیمتها برای حفظ سابقه. برای مقادیر پولی از NUMERIC/DECIMAL و کد ارز استفاده میشود، محاسبات مالیات و تخفیف ذخیره میگردد، و ویژگیهای متغیر محصول در JSONB همراه با قیود و ایندکسهای مناسب مدیریت میشوند. همچنین بر مهاجرتهای افزایشی، تراکنشها و ایندکسگذاری/پارتیشنبندی برای مقیاسپذیری تأکید میکند تا هم صحت داده و هم عملکرد تضمین شود.
#Postgres #DatabaseDesign #DataModeling #Ecommerce #Pricing #Normalization #Denormalization #SQL
🟣لینک مقاله:
https://postgresweekly.com/link/177314/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Storing Products, Prices and Orders in Postgres
🟢 خلاصه مقاله:
این مقاله نشان میدهد که در ذخیرهسازی محصولات، قیمتها و سفارشها در Postgres نرمالسازی افراطی میتواند دقت تاریخی و کارایی را مختل کند. راهکار پیشنهادی، ترکیب یک هسته رابطهای با دنرمالسازی هدفمند است: نگهداشتن اسنپشات «همانطور که فروخته شد» در سطرهای سفارش (نام/SKU، قیمت، ارز، مالیات و تخفیف) و نسخهبندی یا تاریخدار کردن قیمتها برای حفظ سابقه. برای مقادیر پولی از NUMERIC/DECIMAL و کد ارز استفاده میشود، محاسبات مالیات و تخفیف ذخیره میگردد، و ویژگیهای متغیر محصول در JSONB همراه با قیود و ایندکسهای مناسب مدیریت میشوند. همچنین بر مهاجرتهای افزایشی، تراکنشها و ایندکسگذاری/پارتیشنبندی برای مقیاسپذیری تأکید میکند تا هم صحت داده و هم عملکرد تضمین شود.
#Postgres #DatabaseDesign #DataModeling #Ecommerce #Pricing #Normalization #Denormalization #SQL
🟣لینک مقاله:
https://postgresweekly.com/link/177314/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
CYBERTEC PostgreSQL | Services & Support
Storing products, prices and orders in PostgreSQL
This blog talks about the best practices in PostgreSQL for a data model. This blog also includes an example, read to know more.
🔵 عنوان مقاله
pg_roaringbitmap 1.0: Roaring Bitmap Extension
🟢 خلاصه مقاله:
** نسخه ۱.۰ pg_roaringbitmap یک افزونه پایدار و آمادهبهکار برای PostgreSQL ارائه میکند که Roaring bitmaps را بهصورت بومی در پایگاهداده در دسترس میگذارد. Roaring bitmaps ساختارهایی فشرده و بهینه برای نمایش مجموعههای بزرگ از اعداد صحیح هستند که معمولاً در سرعت و مصرف حافظه از بیتمپهای فشرده مرسوم بهتر عمل میکنند، بهویژه در عملگرهایی مانند اجتماع، اشتراک و محاسبه کاردینالیتی.
این افزونه امکان ذخیرهسازی و پردازش مستقیم Roaring bitmaps در SQL را فراهم میکند؛ در نتیجه فیلترهای عضویت، پرسوجوهای تحلیلی و بارهای کاری بزرگ با حافظه و I/O کمتر و سرعت بیشتر اجرا میشوند. چنین قابلیتی برای تحلیل رویداد، تلهمتری، حوزههای ad-tech و ایندکسگذاری معکوس کاربرد ویژهای دارد و به تیمها کمک میکند بدون ترک پایگاهداده، از مزایای فشردهسازی و کارایی بالای Roaring bitmaps بهره ببرند.
#PostgreSQL #pg_roaringbitmap #RoaringBitmap #Database #Compression #Performance #Analytics
🟣لینک مقاله:
https://postgresweekly.com/link/176997/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_roaringbitmap 1.0: Roaring Bitmap Extension
🟢 خلاصه مقاله:
** نسخه ۱.۰ pg_roaringbitmap یک افزونه پایدار و آمادهبهکار برای PostgreSQL ارائه میکند که Roaring bitmaps را بهصورت بومی در پایگاهداده در دسترس میگذارد. Roaring bitmaps ساختارهایی فشرده و بهینه برای نمایش مجموعههای بزرگ از اعداد صحیح هستند که معمولاً در سرعت و مصرف حافظه از بیتمپهای فشرده مرسوم بهتر عمل میکنند، بهویژه در عملگرهایی مانند اجتماع، اشتراک و محاسبه کاردینالیتی.
این افزونه امکان ذخیرهسازی و پردازش مستقیم Roaring bitmaps در SQL را فراهم میکند؛ در نتیجه فیلترهای عضویت، پرسوجوهای تحلیلی و بارهای کاری بزرگ با حافظه و I/O کمتر و سرعت بیشتر اجرا میشوند. چنین قابلیتی برای تحلیل رویداد، تلهمتری، حوزههای ad-tech و ایندکسگذاری معکوس کاربرد ویژهای دارد و به تیمها کمک میکند بدون ترک پایگاهداده، از مزایای فشردهسازی و کارایی بالای Roaring bitmaps بهره ببرند.
#PostgreSQL #pg_roaringbitmap #RoaringBitmap #Database #Compression #Performance #Analytics
🟣لینک مقاله:
https://postgresweekly.com/link/176997/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - ChenHuajun/pg_roaringbitmap: RoaringBitmap extension for PostgreSQL
RoaringBitmap extension for PostgreSQL. Contribute to ChenHuajun/pg_roaringbitmap development by creating an account on GitHub.
🔵 عنوان مقاله
Microsoft Unveils a New Postgres Service: Azure HorizonDB
🟢 خلاصه مقاله:
** مایکروسافت سرویس جدیدی برای Postgres با نام Azure HorizonDB معرفی کرده که در کنار Azure Database for PostgreSQL عرضه میشود و برای نیازهای بسیار سنگین سازمانی هدفگذاری شده است. این سرویس با پشتیبانی تا 3072 vCores در میان نودها و ظرفیت پایگاهداده تا 128TB، روی کارایی و مقیاسپذیری تمرکز دارد. فعلاً در مرحله پیشنمایش اولیه است و احتمالاً با قیمتگذاری پریمیوم/پرهزینه ارائه خواهد شد.
#Microsoft #Azure #PostgreSQL #HorizonDB #CloudDatabase #Scalability #EarlyPreview
🟣لینک مقاله:
https://postgresweekly.com/link/177306/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Microsoft Unveils a New Postgres Service: Azure HorizonDB
🟢 خلاصه مقاله:
** مایکروسافت سرویس جدیدی برای Postgres با نام Azure HorizonDB معرفی کرده که در کنار Azure Database for PostgreSQL عرضه میشود و برای نیازهای بسیار سنگین سازمانی هدفگذاری شده است. این سرویس با پشتیبانی تا 3072 vCores در میان نودها و ظرفیت پایگاهداده تا 128TB، روی کارایی و مقیاسپذیری تمرکز دارد. فعلاً در مرحله پیشنمایش اولیه است و احتمالاً با قیمتگذاری پریمیوم/پرهزینه ارائه خواهد شد.
#Microsoft #Azure #PostgreSQL #HorizonDB #CloudDatabase #Scalability #EarlyPreview
🟣لینک مقاله:
https://postgresweekly.com/link/177306/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TECHCOMMUNITY.MICROSOFT.COM
Announcing Azure HorizonDB | Microsoft Community Hub
Affan Dar, Vice President of Engineering, PostgreSQL at MicrosoftCharles Feddersen, Partner Director of Program Management, PostgreSQL at Microsoft
Today at...
Today at...
🔵 عنوان مقاله
From Text to Token: How Tokenization Pipelines Work
🟢 خلاصه مقاله:
** این مطلب در دو بخش به نکات کاربردی میپردازد. در بخش اول، «From Text to Token: How Tokenization Pipelines Work» به قلم James Blackwood-Sewell توضیح میدهد که چگونه متن خام طی مراحلی مانند نرمالسازی، پیشتوکنیزهکردن و بهکارگیری الگوریتمهای زیرواژهای مثل BPE، WordPiece و Unigram به توکن تبدیل میشود. نکاتی مانند ساخت واژگان، استفاده از توکنهای ویژه (PAD، BOS/EOS، CLS/SEP)، مدیریت نویسههای ناشناخته، حفظ آفستها، و چالشهای چندزبانه و ایموجیها مطرح میشود. همچنین بر ملاحظات مهندسی مانند تکهتکهکردن متنهای بلند، اسلایدینگ ویندو، تفاوت نیازهای آموزش و استنتاج، و بهینهسازی عملکرد با ابزارهایی مانند Hugging Face Tokenizers و SentencePiece تأکید میشود؛ چرا که تعداد توکنها مستقیماً بر هزینه و تأخیر سامانههای LLM اثر میگذارد.
در بخش دوم، «Understanding and Setting Postgres JDBC Fetch Size» نوشته Shane Borden توضیح میدهد که رفتار پیشفرض Postgres JDBC ممکن است برای نتایج بزرگ حافظه را پر کند و چگونه با فعالکردن سرور-ساید کرسرها و تنظیم setFetchSize (یا defaultRowFetchSize) میتوان نتایج را بهصورت batched و استریمشده دریافت کرد. به ارتباط این تنظیم با autocommit، بازههای پیشنهادی برای اندازه batch، موازنه بین تعداد رفتوبرگشت شبکه و مصرف حافظه، و نکات عملی مانند بستن بهموقع ResultSet/Statement و هماهنگی با تنظیمات ORM (مثلاً hibernate.jdbc.fetch_size) پرداخته میشود. جمعبندی این است که کنار بهینهسازی fetch size، طراحی کوئری و ایندکس مناسب و پروفایلکردن حافظه و زمان، برای پایایی و کارایی ضروری است.
#Tokenization #NLP #Postgres #JDBC #PerformanceTuning #DataEngineering #LLM #Database
🟣لینک مقاله:
https://postgresweekly.com/link/175726/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
From Text to Token: How Tokenization Pipelines Work
🟢 خلاصه مقاله:
** این مطلب در دو بخش به نکات کاربردی میپردازد. در بخش اول، «From Text to Token: How Tokenization Pipelines Work» به قلم James Blackwood-Sewell توضیح میدهد که چگونه متن خام طی مراحلی مانند نرمالسازی، پیشتوکنیزهکردن و بهکارگیری الگوریتمهای زیرواژهای مثل BPE، WordPiece و Unigram به توکن تبدیل میشود. نکاتی مانند ساخت واژگان، استفاده از توکنهای ویژه (PAD، BOS/EOS، CLS/SEP)، مدیریت نویسههای ناشناخته، حفظ آفستها، و چالشهای چندزبانه و ایموجیها مطرح میشود. همچنین بر ملاحظات مهندسی مانند تکهتکهکردن متنهای بلند، اسلایدینگ ویندو، تفاوت نیازهای آموزش و استنتاج، و بهینهسازی عملکرد با ابزارهایی مانند Hugging Face Tokenizers و SentencePiece تأکید میشود؛ چرا که تعداد توکنها مستقیماً بر هزینه و تأخیر سامانههای LLM اثر میگذارد.
در بخش دوم، «Understanding and Setting Postgres JDBC Fetch Size» نوشته Shane Borden توضیح میدهد که رفتار پیشفرض Postgres JDBC ممکن است برای نتایج بزرگ حافظه را پر کند و چگونه با فعالکردن سرور-ساید کرسرها و تنظیم setFetchSize (یا defaultRowFetchSize) میتوان نتایج را بهصورت batched و استریمشده دریافت کرد. به ارتباط این تنظیم با autocommit، بازههای پیشنهادی برای اندازه batch، موازنه بین تعداد رفتوبرگشت شبکه و مصرف حافظه، و نکات عملی مانند بستن بهموقع ResultSet/Statement و هماهنگی با تنظیمات ORM (مثلاً hibernate.jdbc.fetch_size) پرداخته میشود. جمعبندی این است که کنار بهینهسازی fetch size، طراحی کوئری و ایندکس مناسب و پروفایلکردن حافظه و زمان، برای پایایی و کارایی ضروری است.
#Tokenization #NLP #Postgres #JDBC #PerformanceTuning #DataEngineering #LLM #Database
🟣لینک مقاله:
https://postgresweekly.com/link/175726/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Paradedb
From Text to Token: How Tokenization Pipelines Work
Understanding how search engines transform text into tokens through character filtering, tokenization, stemming, and stopword removal.
🔵 عنوان مقاله
Ax 1.0: Efficient Optimization With Adaptive Experimentation (5 minute read)
🟢 خلاصه مقاله:
این مقاله Ax 1.0 را بهعنوان یک پلتفرم متنباز برای بهینهسازی تطبیقی در مقیاس تولیدی معرفی میکند که در Meta برای سیستمهای ML بهکار میرود. Ax بهجای تکیه بر جستوجوی brute-force مانند grid/random، از روشهای Bayesian و آزمایشهای پیدرپی استفاده میکند تا جستوجو را کارآمدتر کرده و زمان و محاسبات را کاهش دهد. این پلتفرم برای تنظیم hyperparameterها، بهینهسازی معیارها و تیونینگ سیستم طراحی شده و با قیود پیچیده، دادههای پرنویز، پیشنهادهای موازی و توقف زودهنگام بهخوبی کنار میآید. یک مقاله پژوهشی پیوست نیز معماری، قابلیتها و عملکرد Ax را در مقیاس بزرگ تشریح میکند و امکان بهرهگیری از این توانمندیها را برای جامعه متنباز فراهم میسازد.
#Ax #BayesianOptimization #HyperparameterTuning #Meta #MLOps #AdaptiveExperimentation #SequentialOptimization #OpenSource
🟣لینک مقاله:
https://engineering.fb.com/2025/11/18/open-source/efficient-optimization-ax-open-platform-adaptive-experimentation/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Ax 1.0: Efficient Optimization With Adaptive Experimentation (5 minute read)
🟢 خلاصه مقاله:
این مقاله Ax 1.0 را بهعنوان یک پلتفرم متنباز برای بهینهسازی تطبیقی در مقیاس تولیدی معرفی میکند که در Meta برای سیستمهای ML بهکار میرود. Ax بهجای تکیه بر جستوجوی brute-force مانند grid/random، از روشهای Bayesian و آزمایشهای پیدرپی استفاده میکند تا جستوجو را کارآمدتر کرده و زمان و محاسبات را کاهش دهد. این پلتفرم برای تنظیم hyperparameterها، بهینهسازی معیارها و تیونینگ سیستم طراحی شده و با قیود پیچیده، دادههای پرنویز، پیشنهادهای موازی و توقف زودهنگام بهخوبی کنار میآید. یک مقاله پژوهشی پیوست نیز معماری، قابلیتها و عملکرد Ax را در مقیاس بزرگ تشریح میکند و امکان بهرهگیری از این توانمندیها را برای جامعه متنباز فراهم میسازد.
#Ax #BayesianOptimization #HyperparameterTuning #Meta #MLOps #AdaptiveExperimentation #SequentialOptimization #OpenSource
🟣لینک مقاله:
https://engineering.fb.com/2025/11/18/open-source/efficient-optimization-ax-open-platform-adaptive-experimentation/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Engineering at Meta
Efficient Optimization With Ax, an Open Platform for Adaptive Experimentation
We’ve released Ax 1.0, an open-source platform that uses machine learning to automatically guide complex, resource-intensive experimentation. Ax is used at scale across Meta to improve AI models, t…
یه تلهی بزرگ که پروژهها و اغلب برنامهنویسهای بکند توش میوفتن، اینه که برای حل یه مشکل، سعی میکنن یه مشکل جدید ایجاد کنن.
دیتابیس همیشه Source of Truth هستش، و اضافه کردن لایهی کش، میتونه بعضی مواقع ریسک stale شدن دیتا رو ایجاد کنه. چون مثلا ممکنه در لحظهی آپدیت کش، ردیس خطا بده و ...
به نظر من کش زمانی باید به پروژه اضافه بشه که سیستم، زیر بار دیگه جوابگوی تعداد ریکوئستها نباشه و latency به اندازهی خوبی بالا رفته باشه. اندازهگیری این تاخیر هم، یه عدد ثابت نداره. باید در یک بازهی زمانی محاسبه بشه.
اگه احساس بر اینه که کوئریها سنگین هستن و باید کش اضافه بشه، میتونه چند تا احتمال وجود داشته باشه:
۱- نورمالیزیشن درست انجام نشده
۲- دومین درست تعریف نشده
۳- کوئریها بهینه نیستند (ممکنه بجای گرفتن لیستی از رکوردها، یکی یکی واکشی میشن)
@ | <آرش | Arash/>
دیتابیس همیشه Source of Truth هستش، و اضافه کردن لایهی کش، میتونه بعضی مواقع ریسک stale شدن دیتا رو ایجاد کنه. چون مثلا ممکنه در لحظهی آپدیت کش، ردیس خطا بده و ...
به نظر من کش زمانی باید به پروژه اضافه بشه که سیستم، زیر بار دیگه جوابگوی تعداد ریکوئستها نباشه و latency به اندازهی خوبی بالا رفته باشه. اندازهگیری این تاخیر هم، یه عدد ثابت نداره. باید در یک بازهی زمانی محاسبه بشه.
اگه احساس بر اینه که کوئریها سنگین هستن و باید کش اضافه بشه، میتونه چند تا احتمال وجود داشته باشه:
۱- نورمالیزیشن درست انجام نشده
۲- دومین درست تعریف نشده
۳- کوئریها بهینه نیستند (ممکنه بجای گرفتن لیستی از رکوردها، یکی یکی واکشی میشن)
@ | <آرش | Arash/>
👍3
Forwarded from AI Labdon
قابلیتِ جالبِ Gemini 3 که با Banana Pro میسر هست !
مثلا اگر یک ویدئو آموزشی ۲۰ دقیقه ای یوتیوب دارید و وقت ندارید کامل ببینید و میخواید خلاصه ش رو به صورت یک پوستر گرافیکی ( اینفوگرافیک ) داشته باشید !
آموزش نحوه استفاده از این قابلیت :
۱ لینک ویدئو یوتیوب رو Copy میکنید .
۲ وارد Gemini میشید .
۳ لینک کپی شده رو Paste میکنید و ازش بخواید که ویدئو رو آنالیز و بررسی کنه .
۴ بعد از اینکه بررسی کرد ، حالا این پرامپت وارد کنید !
مثلا اگر یک ویدئو آموزشی ۲۰ دقیقه ای یوتیوب دارید و وقت ندارید کامل ببینید و میخواید خلاصه ش رو به صورت یک پوستر گرافیکی ( اینفوگرافیک ) داشته باشید !
آموزش نحوه استفاده از این قابلیت :
۱ لینک ویدئو یوتیوب رو Copy میکنید .
۲ وارد Gemini میشید .
۳ لینک کپی شده رو Paste میکنید و ازش بخواید که ویدئو رو آنالیز و بررسی کنه .
۴ بعد از اینکه بررسی کرد ، حالا این پرامپت وارد کنید !
Prompt : Generate an image of an infographic explaining the concept presented in the video.❤2
چهار استراتژی کلیدی برای مقیاسپذیری مؤثر پایگاه داده
با رشد سیستمها و افزایش تعداد کاربران، پایگاه داده به یکی از حساسترین و چالشبرانگیزترین بخشهای معماری نرمافزار تبدیل میشود. انتخاب رویکرد مناسب برای مقیاسپذیری، نقش مهمی در حفظ کارایی، پایداری و در دسترسپذیری سرویس دارد. در این مقاله، چهار استراتژی رایج و اثربخش برای مقیاسپذیری پایگاه داده را بررسی میکنیم.
۱) استراتژی Vertical Scaling (افزایش ظرفیت سختافزاری)
سادهترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سختافزاری نظیر CPU، RAM و فضای ذخیرهسازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرمافزار انجام میشود و در بسیاری از سیستمها، اولین گام منطقی برای افزایش ظرفیت به شمار میآید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.
۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخههای متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم میسازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال میشود، Leader تغییرات را به نودهای Follower منتقل میکند، عملیات خواندن میتواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواستهای خواندن است.
۳) استراتژی Caching (افزایش سرعت با ذخیرهسازی موقت)
استفاده از Cache، از تکرار درخواستهای غیرضروری به پایگاه داده جلوگیری میکند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره میشود.
درخواستهای بعدی، در صورت وجود داده در Cache، بهسرعت پاسخ داده میشوند.
این روش علاوه بر کاهش بار پایگاه داده، بهطور چشمگیری سرعت پاسخگویی را نیز افزایش میدهد.
۴) استراتژی Partitioning / Sharding (مقیاسپذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخشهای مستقل (Partitions یا Shards) و توزیع آنها در چندین سرور، امکان افزایش ظرفیتپذیری عملیات نوشتن را فراهم میکند.
در این مدل:
هر شارد بخشی از داده را مدیریت میکند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال میشود،
بار نوشتن میان چندین ماشین تقسیم میگردد.
این رویکرد برای سامانههایی که حجم عملیات نوشتن آنها بالا است، روشی پایدار و قابل اعتماد به حساب میآید.
ارتباط Replication و Sharding
در معماریهای بزرگ، Sharding و Replication معمولاً بهصورت ترکیبی مورد استفاده قرار میگیرند.
هر شارد روی چندین نود Replicate میشود تا در صورت خرابی یک نود، دسترسپذیری داده حفظ گردد.
جمعبندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستونهای اصلی مقیاسپذیری پایگاه داده در معماریهای مدرن محسوب میشوند.
انتخاب مناسب میان این روشها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیتهای معماری هر سیستم بستگی دارد.
بهکارگیری درست و ترکیبی این استراتژیها، امکان ساخت سامانههایی پایدار، سریع و قابلاتکا را فراهم میکند.
@ | <Amir Rahimi Nejad/>
با رشد سیستمها و افزایش تعداد کاربران، پایگاه داده به یکی از حساسترین و چالشبرانگیزترین بخشهای معماری نرمافزار تبدیل میشود. انتخاب رویکرد مناسب برای مقیاسپذیری، نقش مهمی در حفظ کارایی، پایداری و در دسترسپذیری سرویس دارد. در این مقاله، چهار استراتژی رایج و اثربخش برای مقیاسپذیری پایگاه داده را بررسی میکنیم.
۱) استراتژی Vertical Scaling (افزایش ظرفیت سختافزاری)
سادهترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سختافزاری نظیر CPU، RAM و فضای ذخیرهسازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرمافزار انجام میشود و در بسیاری از سیستمها، اولین گام منطقی برای افزایش ظرفیت به شمار میآید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.
۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخههای متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم میسازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال میشود، Leader تغییرات را به نودهای Follower منتقل میکند، عملیات خواندن میتواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواستهای خواندن است.
۳) استراتژی Caching (افزایش سرعت با ذخیرهسازی موقت)
استفاده از Cache، از تکرار درخواستهای غیرضروری به پایگاه داده جلوگیری میکند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره میشود.
درخواستهای بعدی، در صورت وجود داده در Cache، بهسرعت پاسخ داده میشوند.
این روش علاوه بر کاهش بار پایگاه داده، بهطور چشمگیری سرعت پاسخگویی را نیز افزایش میدهد.
۴) استراتژی Partitioning / Sharding (مقیاسپذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخشهای مستقل (Partitions یا Shards) و توزیع آنها در چندین سرور، امکان افزایش ظرفیتپذیری عملیات نوشتن را فراهم میکند.
در این مدل:
هر شارد بخشی از داده را مدیریت میکند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال میشود،
بار نوشتن میان چندین ماشین تقسیم میگردد.
این رویکرد برای سامانههایی که حجم عملیات نوشتن آنها بالا است، روشی پایدار و قابل اعتماد به حساب میآید.
ارتباط Replication و Sharding
در معماریهای بزرگ، Sharding و Replication معمولاً بهصورت ترکیبی مورد استفاده قرار میگیرند.
هر شارد روی چندین نود Replicate میشود تا در صورت خرابی یک نود، دسترسپذیری داده حفظ گردد.
جمعبندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستونهای اصلی مقیاسپذیری پایگاه داده در معماریهای مدرن محسوب میشوند.
انتخاب مناسب میان این روشها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیتهای معماری هر سیستم بستگی دارد.
بهکارگیری درست و ترکیبی این استراتژیها، امکان ساخت سامانههایی پایدار، سریع و قابلاتکا را فراهم میکند.
@ | <Amir Rahimi Nejad/>
❤1
Forwarded from Bardia & Erfan
♨️ با احترام به تمام پزشکان، امروز میخوام یه هوش مصنوعی پزشک معرفی کنم.
▪️همه ما ممکنه روزانه سوالات پزشکی رو در مورد علائم یا حال ناخوش خودمون یا اطرافیانمون داشته باشیم. چی میشد اگه یه هوش مصنوعی وجود داشت که به آخرین اطلاعات علم پزشکی هم دسترسی داشت و میشد ازش مشورت گرفت؟
👩⚕️داکوس در کنار شماست ؛)
▪️یک پلتفرم سلامت هوشمنده که از یه چت بات برای تولید گزارشهای سلامت شخصیسازیشده متناسب با هر فرد استفاده میکنه.
▪️کاربرها میتونن با چت بات گفتگو کنن و یه گزارش سلامت تولید کنن یا احتمال انواع ابتلا به بیماری رو شناسایی کنن.
+ اینم بگم که شما فقط اجازه ارسال و دریافت تا 7 پیغام رو به صورت رایگان و روزانه دارید و برای ادامه استفاده باید اشتراک ماهانه تهیه کرد. 👇👇
▫️http://docus.ai
▪️همه ما ممکنه روزانه سوالات پزشکی رو در مورد علائم یا حال ناخوش خودمون یا اطرافیانمون داشته باشیم. چی میشد اگه یه هوش مصنوعی وجود داشت که به آخرین اطلاعات علم پزشکی هم دسترسی داشت و میشد ازش مشورت گرفت؟
👩⚕️داکوس در کنار شماست ؛)
▪️یک پلتفرم سلامت هوشمنده که از یه چت بات برای تولید گزارشهای سلامت شخصیسازیشده متناسب با هر فرد استفاده میکنه.
▪️کاربرها میتونن با چت بات گفتگو کنن و یه گزارش سلامت تولید کنن یا احتمال انواع ابتلا به بیماری رو شناسایی کنن.
+ اینم بگم که شما فقط اجازه ارسال و دریافت تا 7 پیغام رو به صورت رایگان و روزانه دارید و برای ادامه استفاده باید اشتراک ماهانه تهیه کرد. 👇👇
▫️http://docus.ai
Forwarded from Bardia & Erfan
Media is too big
VIEW IN TELEGRAM
بلکفرایدی تبدیل شد به یک بازی کثیف؛ قیمتها قبلش باد شد، امید کاذب ساختند، مردم رو ساعتها پشت گوشی نگه داشتند که شاید «محصول ۲۰۰ میلیونی رو با ۹۰٪ تخفیف» بگیرن.
اینفلوئنسرهایی که با اعتماد همین مردم مشهور شدند، برای چندصد میلیون، هیزم آتیش فریب شدند.
فروشگاههایی که بهجای بازاریابی علمی، دروغ و تکنیک زرد رو انتخاب کردند.
نتیجه؟
نه «اعتبار برند» ساختید، نه «وفاداری مشتری»… فقط یک کولهبار نفرت روی دوش مردم گذاشتید.
اینا تخفیف نبود؛ یک توهین به شعور عمومی بود.
به امید روزی که هرجا چیزی «مفت» دیدیم، کورکورانه نپریم توش.
#بلک_فرایدی #فریب_تخفیف #تکنوکسب #بازاریابی #مردم #ایران
اینفلوئنسرهایی که با اعتماد همین مردم مشهور شدند، برای چندصد میلیون، هیزم آتیش فریب شدند.
فروشگاههایی که بهجای بازاریابی علمی، دروغ و تکنیک زرد رو انتخاب کردند.
نتیجه؟
نه «اعتبار برند» ساختید، نه «وفاداری مشتری»… فقط یک کولهبار نفرت روی دوش مردم گذاشتید.
اینا تخفیف نبود؛ یک توهین به شعور عمومی بود.
به امید روزی که هرجا چیزی «مفت» دیدیم، کورکورانه نپریم توش.
#بلک_فرایدی #فریب_تخفیف #تکنوکسب #بازاریابی #مردم #ایران
❤1👍1🔥1
🔵 عنوان مقاله
PostGIS Performance: Intersection Predicates and Overlays
🟢 خلاصه مقاله:
خلاصهای از یک نوشته در ادامهٔ مجموعهای برای بهبود کارایی PostGIS است که بر دو بخش کلیدی تمرکز دارد: «intersection predicates» مثل ST_Intersects، ST_Touches و ST_Contains و «overlay»ها مثل ST_Intersection و ST_Union. راهبرد اصلی این است: ابتدا با فیلتر سریع جعبهمحیطی (&& روی ایندکس GiST) تعداد کاندیداها را کم کنید و سپس رابطهٔ دقیق را با GEOS بررسی کنید. برای پرسوجوهای معمول، سادهترین predicate که نیازتان را پوشش میدهد انتخاب شود؛ از ST_Intersects برای joinهای اولیه استفاده و در صورت نیاز دقیقتر کنید. عملیات overlay چون هندسهٔ جدید میسازند، پرهزینهاند؛ فقط وقتی واقعاً خروجی هندسی لازم است سراغشان بروید و برای ادغامهای بزرگ ST_UnaryUnion را ترجیح دهید. برای هندسههای حجیم از ST_Subdivide و در صورت امکان از کاهش جزئیات با ST_SimplifyPreserveTopology یا ST_SnapToGrid بهره ببرید. همچنین: ایندکس GiST بسازید، فیلترهای صفتی را زود اعمال کنید، از اعمال توابع روی ستون هندسی در WHERE که جلوی استفاده از ایندکس را میگیرد پرهیز کنید، و با EXPLAIN صحت استفاده از ایندکس و برآوردها را بررسی کنید. نتیجهٔ عملی: انتخاب predicate مناسب، اجتناب از overlay غیرضروری، و نگهداشتن هندسهها و ایندکسها در وضعیتی سازگار با برنامهریز، کارایی پایدار PostgreSQL/PostGIS را تضمین میکند.
#PostGIS #PostgreSQL #GIS #GEOS #SpatialIndex #ST_Intersects #Geospatial #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/177315/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PostGIS Performance: Intersection Predicates and Overlays
🟢 خلاصه مقاله:
خلاصهای از یک نوشته در ادامهٔ مجموعهای برای بهبود کارایی PostGIS است که بر دو بخش کلیدی تمرکز دارد: «intersection predicates» مثل ST_Intersects، ST_Touches و ST_Contains و «overlay»ها مثل ST_Intersection و ST_Union. راهبرد اصلی این است: ابتدا با فیلتر سریع جعبهمحیطی (&& روی ایندکس GiST) تعداد کاندیداها را کم کنید و سپس رابطهٔ دقیق را با GEOS بررسی کنید. برای پرسوجوهای معمول، سادهترین predicate که نیازتان را پوشش میدهد انتخاب شود؛ از ST_Intersects برای joinهای اولیه استفاده و در صورت نیاز دقیقتر کنید. عملیات overlay چون هندسهٔ جدید میسازند، پرهزینهاند؛ فقط وقتی واقعاً خروجی هندسی لازم است سراغشان بروید و برای ادغامهای بزرگ ST_UnaryUnion را ترجیح دهید. برای هندسههای حجیم از ST_Subdivide و در صورت امکان از کاهش جزئیات با ST_SimplifyPreserveTopology یا ST_SnapToGrid بهره ببرید. همچنین: ایندکس GiST بسازید، فیلترهای صفتی را زود اعمال کنید، از اعمال توابع روی ستون هندسی در WHERE که جلوی استفاده از ایندکس را میگیرد پرهیز کنید، و با EXPLAIN صحت استفاده از ایندکس و برآوردها را بررسی کنید. نتیجهٔ عملی: انتخاب predicate مناسب، اجتناب از overlay غیرضروری، و نگهداشتن هندسهها و ایندکسها در وضعیتی سازگار با برنامهریز، کارایی پایدار PostgreSQL/PostGIS را تضمین میکند.
#PostGIS #PostgreSQL #GIS #GEOS #SpatialIndex #ST_Intersects #Geospatial #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/177315/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Crunchy Data
PostGIS Performance: Intersection Predicates and Overlays | Crunchy Data Blog
What is difference between the boolean true / false ST_Intersects and ST_Contains and the overlay options of ST_Intersection and ST_Difference? Also, combining these two ideas can get you really fast queries for geometries fully contained inside areas.
Forwarded from AI Labdon
🤖 علاقهمند به دنیای هوش مصنوعی هستی؟
🏖 دنبال میکنی که چطور AI داره دنیا رو متحول میکنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدلهای زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دورهها و منابع یادگیری
📈 بررسی ترندها و آینده فناوریهای مرتبط با هوش مصنوعی
🍄همهی اینها به زبان ساده، خلاصه و قابل فهم برای همه علاقهمندان — از مبتدی تا حرفهای!
👇👇👇👇👇👇
https://www.tgoop.com/ai_labdon
🏖 دنبال میکنی که چطور AI داره دنیا رو متحول میکنه؟
🍻پس جای درستی اومدی!
🎯 در کانال ما هر روز:
🔍 جدیدترین اخبار و دستاوردهای دنیای AI
🧠 تحلیل تخصصی در حوزه یادگیری ماشین، دیپ لرنینگ و مدلهای زبانی
💼 بررسی کاربردهای هوش مصنوعی در پزشکی، صنعت، آموزش، امنیت و اقتصاد
🛠 معرفی ابزارها، دورهها و منابع یادگیری
📈 بررسی ترندها و آینده فناوریهای مرتبط با هوش مصنوعی
🍄همهی اینها به زبان ساده، خلاصه و قابل فهم برای همه علاقهمندان — از مبتدی تا حرفهای!
👇👇👇👇👇👇
https://www.tgoop.com/ai_labdon
🔵 عنوان مقاله
dbt's new Fusion Engine for smarter, cost-effective data ops (Sponsor)
🟢 خلاصه مقاله:
تیمهای داده با یک گزینه سخت روبرو هستند: یا با سرعت بالا کار کنند و هزینههای ابری را به صورت چشمگیری افزایش دهند، یا هزینهها را کنترل کنند و در کیفیت فداکاری نمایند. این مشکل همچنان یکی از چالشهای اصلی در مدیریت دادهها است. اما خبر خوب این است که نرمافزار Fusion جدید شرکت dbt راه حلی هوشمندانه ارائه کرده است. این موتور با استفاده از ارکستراسیون مبتنی بر آگاهی از وضعیت، مدلها و آزمایشهای تغییر نکرده را به صورت خودکار نادیده میگیرد، و بدین ترتیب بهرهوری تا ۲۹ درصد افزایش یافته است. این فناوری جدید قادر است کنترل هزینهها را در حالی که تازهسازی دادهها حفظ میکند، توازن بخشد.
برای درک بهتر از قابلیتهای Fusion، پیشنهاد میشود در جلسه زنده (۳ و ۴ دسامبر) شرکت کنید و مشاهده نمایید که چگونه این فناوری به شرکتهایی مانند Obie Insurance و Analytics8 کمک میکند تا خطوط لوله داده سریعتر و کارآمدتر عمل کنند و از هدر رفتن منابع جلوگیری کنند. این ابزار نوآورانه نشان میدهد که چگونه میتوان بهرهوری در عملیات داده را افزایش داد و هزینهها را کنترل کرد، بدون اینکه کیفیت دادهها فدا شود.
#مدیریت_داده #هوشمندانه #کاهش_هزینه #Fusion
🟣لینک مقاله:
https://www.getdbt.com/resources/webinars/how-the-dbt-fusion-engine-optimizes-data-work/?utm_medium=paid-email&utm_source=tldr&utm_campaign=q4-2026_tldr-newsletters_cv&utm_content=_newsletter3___&utm_term=all_all__
➖➖➖➖➖➖➖➖
👑 @Database_Academy
dbt's new Fusion Engine for smarter, cost-effective data ops (Sponsor)
🟢 خلاصه مقاله:
تیمهای داده با یک گزینه سخت روبرو هستند: یا با سرعت بالا کار کنند و هزینههای ابری را به صورت چشمگیری افزایش دهند، یا هزینهها را کنترل کنند و در کیفیت فداکاری نمایند. این مشکل همچنان یکی از چالشهای اصلی در مدیریت دادهها است. اما خبر خوب این است که نرمافزار Fusion جدید شرکت dbt راه حلی هوشمندانه ارائه کرده است. این موتور با استفاده از ارکستراسیون مبتنی بر آگاهی از وضعیت، مدلها و آزمایشهای تغییر نکرده را به صورت خودکار نادیده میگیرد، و بدین ترتیب بهرهوری تا ۲۹ درصد افزایش یافته است. این فناوری جدید قادر است کنترل هزینهها را در حالی که تازهسازی دادهها حفظ میکند، توازن بخشد.
برای درک بهتر از قابلیتهای Fusion، پیشنهاد میشود در جلسه زنده (۳ و ۴ دسامبر) شرکت کنید و مشاهده نمایید که چگونه این فناوری به شرکتهایی مانند Obie Insurance و Analytics8 کمک میکند تا خطوط لوله داده سریعتر و کارآمدتر عمل کنند و از هدر رفتن منابع جلوگیری کنند. این ابزار نوآورانه نشان میدهد که چگونه میتوان بهرهوری در عملیات داده را افزایش داد و هزینهها را کنترل کرد، بدون اینکه کیفیت دادهها فدا شود.
#مدیریت_داده #هوشمندانه #کاهش_هزینه #Fusion
🟣لینک مقاله:
https://www.getdbt.com/resources/webinars/how-the-dbt-fusion-engine-optimizes-data-work/?utm_medium=paid-email&utm_source=tldr&utm_campaign=q4-2026_tldr-newsletters_cv&utm_content=_newsletter3___&utm_term=all_all__
➖➖➖➖➖➖➖➖
👑 @Database_Academy
dbt Labs
Smarter pipelines, 29% more efficient: How the dbt Fusion engine optimizes data work | dbt Labs
Learn how how dbt Fusion helps data teams run smarter, deliver faster, and spend less time rebuilding.
🔵 عنوان مقاله
an inaugural PostgreSQL Edinburgh meetup
🟢 خلاصه مقاله:
در تاریخ ۱۱ دسامبر، اولین نشست کاربران PostgreSQL در ادینبورگ، اسکاتلند، برگزار میشود. این رویداد فرصتی عالی برای توسعهدهندگان و علاقهمندان به پایگاههای داده است تا بتوانند در کنار هم درباره جدیدترین فناوریها، بهترین رویهها و تجارب خود بحث و تبادل نظر کنند. با حضور کارشناسان و متخصصان این حوزه، شرکتکنندگان میتوانند از دانش و نکات عملی بهرهمند شده و شبکهسازی مفیدی در فضای فناوری اطلاعات داشته باشند.
این نشست نخستین تجربه از نوع خود در این منطقه است و انتظار میرود جذابیت زیادی برای علاقهمندان به پایگاه دادههای متنباز داشته باشد. به همه علاقهمندان پیشنهاد میشود که در این رویداد شرکت کنند و فرصت آشنایی عمیقتر با فناوری PostgreSQL و نکات کاربردی آن را از دست ندهند.
#PostgreSQL #ادینبورگ #فناوری_اطلاعات #پایگاه_داده
🟣لینک مقاله:
https://postgresweekly.com/link/177310/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
an inaugural PostgreSQL Edinburgh meetup
🟢 خلاصه مقاله:
در تاریخ ۱۱ دسامبر، اولین نشست کاربران PostgreSQL در ادینبورگ، اسکاتلند، برگزار میشود. این رویداد فرصتی عالی برای توسعهدهندگان و علاقهمندان به پایگاههای داده است تا بتوانند در کنار هم درباره جدیدترین فناوریها، بهترین رویهها و تجارب خود بحث و تبادل نظر کنند. با حضور کارشناسان و متخصصان این حوزه، شرکتکنندگان میتوانند از دانش و نکات عملی بهرهمند شده و شبکهسازی مفیدی در فضای فناوری اطلاعات داشته باشند.
این نشست نخستین تجربه از نوع خود در این منطقه است و انتظار میرود جذابیت زیادی برای علاقهمندان به پایگاه دادههای متنباز داشته باشد. به همه علاقهمندان پیشنهاد میشود که در این رویداد شرکت کنند و فرصت آشنایی عمیقتر با فناوری PostgreSQL و نکات کاربردی آن را از دست ندهند.
#PostgreSQL #ادینبورگ #فناوری_اطلاعات #پایگاه_داده
🟣لینک مقاله:
https://postgresweekly.com/link/177310/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
-=vyruss=- / blog
Announcing the inaugural PostgreSQL Edinburgh meetup
Thrilled to announce the launch of the PostgreSQL Edinburgh meetup! December 11th @ the University of Edinburgh's Old College (pizza, networking, and talks).
🔵 عنوان مقاله
what was new with Azure Database for PostgreSQL
🟢 خلاصه مقاله:
در جدیدترین مقاله منتشر شده در خبرنامه هفتگی Golang، به بررسی قابلیتها و امکانات تازه در سرویس Azure Database for PostgreSQL پرداخته شده است. این سرویس یکی از گزینههای محبوب برای توسعهدهندگان است که نیازمند یک پایگاه داده قدرتمند و مقیاسپذیر در قالب سرویسهای ابری هستند.
در این مقاله، ابتدا به ویژگیهای جدید در نسخههای اخیر Azure Database for PostgreSQL اشاره شده است؛ از جمله بهبودهای در عملکرد، امنیت، و امکانات مدیریت. این پیشرفتها کمک میکنند تا توسعهدهندگان بتوانند با اطمینان بیشتری برنامههای خود را بر بستر Azure پیادهسازی کنند و بهرهوری را افزایش دهند.
سپس، به ابزارهای جدید و بهروزرسانیهای رابط کاربری اشاره شده است که فرآیند راهاندازی، مانیتورینگ و نگهداری پایگاه داده را بسیار سادهتر کرده است. همچنین، امکانات مدیریت هزینه و مقیاسپذیری خودکار نیز از دیگر مزایای جدید این سرویس است که به کاربران امکان میدهد هزینهها را کنترل کرده و عملکرد سیستم را بر اساس نیازهای لحظهای تنظیم کنند.
در نهایت، مقاله بر اهمیت این بهروزرسانیها در تسهیل توسعه و عملیات اپلیکیشنهای ابری تأکید کرده و توصیه میکند که توسعهدهندگان و مدیران موارد ذکر شده را حتماً مورد توجه قرار دهند تا بهرهوری و امنیت پروژههای خود را افزایش دهند.
#Azure #PostgreSQL #سرویس_ابری #پایگاه_داده
🟣لینک مقاله:
https://postgresweekly.com/link/176985/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
what was new with Azure Database for PostgreSQL
🟢 خلاصه مقاله:
در جدیدترین مقاله منتشر شده در خبرنامه هفتگی Golang، به بررسی قابلیتها و امکانات تازه در سرویس Azure Database for PostgreSQL پرداخته شده است. این سرویس یکی از گزینههای محبوب برای توسعهدهندگان است که نیازمند یک پایگاه داده قدرتمند و مقیاسپذیر در قالب سرویسهای ابری هستند.
در این مقاله، ابتدا به ویژگیهای جدید در نسخههای اخیر Azure Database for PostgreSQL اشاره شده است؛ از جمله بهبودهای در عملکرد، امنیت، و امکانات مدیریت. این پیشرفتها کمک میکنند تا توسعهدهندگان بتوانند با اطمینان بیشتری برنامههای خود را بر بستر Azure پیادهسازی کنند و بهرهوری را افزایش دهند.
سپس، به ابزارهای جدید و بهروزرسانیهای رابط کاربری اشاره شده است که فرآیند راهاندازی، مانیتورینگ و نگهداری پایگاه داده را بسیار سادهتر کرده است. همچنین، امکانات مدیریت هزینه و مقیاسپذیری خودکار نیز از دیگر مزایای جدید این سرویس است که به کاربران امکان میدهد هزینهها را کنترل کرده و عملکرد سیستم را بر اساس نیازهای لحظهای تنظیم کنند.
در نهایت، مقاله بر اهمیت این بهروزرسانیها در تسهیل توسعه و عملیات اپلیکیشنهای ابری تأکید کرده و توصیه میکند که توسعهدهندگان و مدیران موارد ذکر شده را حتماً مورد توجه قرار دهند تا بهرهوری و امنیت پروژههای خود را افزایش دهند.
#Azure #PostgreSQL #سرویس_ابری #پایگاه_داده
🟣لینک مقاله:
https://postgresweekly.com/link/176985/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TECHCOMMUNITY.MICROSOFT.COM
October 2025 Recap: Azure Database for PostgreSQL | Microsoft Community Hub
Hello Azure Community,
We are excited to bring October 2025 recap blog for Azure Database for PostgreSQL! This blog focuses on key announcements around the...
We are excited to bring October 2025 recap blog for Azure Database for PostgreSQL! This blog focuses on key announcements around the...
🔵 عنوان مقاله
Wrappers: A Foreign Data Wrapper Development Framework for Rust
🟢 خلاصه مقاله:
در این مقاله، ابتدا به معرفی یک چارچوب توسعه برای ساخت Wrapperهای داده خارجی (FDWs) در پایگاهداده پستگرس با زبان برنامهنویسی رست (Rust) پرداخته میشود. این چارچوب، ابزارهای مدرن و کارآمدی را در اختیار توسعهدهندگان قرار میدهد تا بتوانند به راحتی و با کارایی بالا، افزونههای جدیدی برای پستگرس ایجاد کنند. وابسته بودن به رست در این پروژه، امکان بهرهگیری از مزایای سرعت، امنیت و استحکام این زبان برنامهنویسی را فراهم میکند.
در ادامه، مقاله به مجموعهای گسترده از FDWs آماده اشاره میکند که با استفاده از این چارچوب توسعه یافتهاند. این مجموعه، پوششدهنده سیستمهای مختلفی مانند Apache Iceberg، Clickhouse، BigQuery و AWS S3 است. هر یک از این Wrapperها، امکان دسترسی سریع و ساده به دادههای ذخیره شده در پلتفرمهای متنوع را فراهم میآورد و به توسعهدهندگان کمک میکند تا عملیاتهای پیچیده بر روی دادهها را به شکلی مؤثر و بومی انجام دهند. این پروژه نشان میدهد که چگونه ابزارهای متنباز میتوانند کارایی و انعطافپذیری را در مدیریت دادههای بزرگ افزایش دهند و بیدرنگ، کاربردهای گستردهتری در اکوسیستمهای دادهای مدرن پیدا کنند.
#پستگرس #رست #دیٹاواپگر #فریمورک
🟣لینک مقاله:
https://postgresweekly.com/link/177682/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Wrappers: A Foreign Data Wrapper Development Framework for Rust
🟢 خلاصه مقاله:
در این مقاله، ابتدا به معرفی یک چارچوب توسعه برای ساخت Wrapperهای داده خارجی (FDWs) در پایگاهداده پستگرس با زبان برنامهنویسی رست (Rust) پرداخته میشود. این چارچوب، ابزارهای مدرن و کارآمدی را در اختیار توسعهدهندگان قرار میدهد تا بتوانند به راحتی و با کارایی بالا، افزونههای جدیدی برای پستگرس ایجاد کنند. وابسته بودن به رست در این پروژه، امکان بهرهگیری از مزایای سرعت، امنیت و استحکام این زبان برنامهنویسی را فراهم میکند.
در ادامه، مقاله به مجموعهای گسترده از FDWs آماده اشاره میکند که با استفاده از این چارچوب توسعه یافتهاند. این مجموعه، پوششدهنده سیستمهای مختلفی مانند Apache Iceberg، Clickhouse، BigQuery و AWS S3 است. هر یک از این Wrapperها، امکان دسترسی سریع و ساده به دادههای ذخیره شده در پلتفرمهای متنوع را فراهم میآورد و به توسعهدهندگان کمک میکند تا عملیاتهای پیچیده بر روی دادهها را به شکلی مؤثر و بومی انجام دهند. این پروژه نشان میدهد که چگونه ابزارهای متنباز میتوانند کارایی و انعطافپذیری را در مدیریت دادههای بزرگ افزایش دهند و بیدرنگ، کاربردهای گستردهتری در اکوسیستمهای دادهای مدرن پیدا کنند.
#پستگرس #رست #دیٹاواپگر #فریمورک
🟣لینک مقاله:
https://postgresweekly.com/link/177682/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
fdw.dev
Postgres Wrappers - Wrappers
A PostgreSQL extension for connecting to external data sources
🔵 عنوان مقاله
Why Strong Consistency? (6 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری، مفهوم سازگاری قوی همواره از اهمیت ویژهای برخوردار است، زیرا تضمین میکند دادهها در تمامی نسخههای تکراری برابر و بهروز باقی بمانند. در حالی که سازگاری نهایی یا eventual consistency در مواردی مانند تراکنشهای نادر و با تأخیر کم، کارآمد است، اما در سرویسهایی که نیاز به قابلیتهای بالای در دسترس بودن دارند، مشکلاتی ایجاد میکند. این نوع سازگاری نیازمند مسیرهای مسیریابی پیچیده، مدیریت خطا و آزمایشهای فراوان است تا از ناهماهنگی دادهها جلوگیری شود.
شرکتهای پیشرفته در حوزه دیتابیس، مانند اماور، با توسعه فناوریهایی همچون Aurora DSQL، توانستهاند این مشکل را حل کنند. این سامانه با ترکیب بهروزرسانیهای مونوتونیک در دفترچههای ثبت وقایع و جستوجوهای مبتنی بر زمان، تضمین میکند که تمامی نسخههای تکراری دادهها در حالت سازگاری قوی قرار داشته باشند. در این روش، نسخههای مختلف تنها منتظر میمانند تا تمام نوشتنهای قبلی روی آنها اعمال شود، و در نتیجه توسعهدهندگان میتوانند راحتتر و بدون نیاز به قلابهای پیچیده سازگاری، برنامههای خود را بنویسند و اجرا کنند.
در نهایت، Aurora DSQL با این رویکرد، سطح اطمینان و یکپارچگی دادهها در سرویسهای مبتنی بر دیتابیس را افزایش میدهد و تجربه کاربری بینقصی را فراهم میآورد، در حالی که پیچیدگیهای مدیریت سازگاری را به حداقل میرساند. این فناوری نشان میدهد چگونه میتوان با رعایت تعادل میان سرعت و دقت، سرویسهای قوی و قابل اعتماد ارائه داد.
#سازگاری_قوی #پایگاه_داده #Aurora #توسعه چاہ
🟣لینک مقاله:
https://brooker.co.za/blog/2025/11/18/consistency.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why Strong Consistency? (6 minute read)
🟢 خلاصه مقاله:
در دنیای فناوری، مفهوم سازگاری قوی همواره از اهمیت ویژهای برخوردار است، زیرا تضمین میکند دادهها در تمامی نسخههای تکراری برابر و بهروز باقی بمانند. در حالی که سازگاری نهایی یا eventual consistency در مواردی مانند تراکنشهای نادر و با تأخیر کم، کارآمد است، اما در سرویسهایی که نیاز به قابلیتهای بالای در دسترس بودن دارند، مشکلاتی ایجاد میکند. این نوع سازگاری نیازمند مسیرهای مسیریابی پیچیده، مدیریت خطا و آزمایشهای فراوان است تا از ناهماهنگی دادهها جلوگیری شود.
شرکتهای پیشرفته در حوزه دیتابیس، مانند اماور، با توسعه فناوریهایی همچون Aurora DSQL، توانستهاند این مشکل را حل کنند. این سامانه با ترکیب بهروزرسانیهای مونوتونیک در دفترچههای ثبت وقایع و جستوجوهای مبتنی بر زمان، تضمین میکند که تمامی نسخههای تکراری دادهها در حالت سازگاری قوی قرار داشته باشند. در این روش، نسخههای مختلف تنها منتظر میمانند تا تمام نوشتنهای قبلی روی آنها اعمال شود، و در نتیجه توسعهدهندگان میتوانند راحتتر و بدون نیاز به قلابهای پیچیده سازگاری، برنامههای خود را بنویسند و اجرا کنند.
در نهایت، Aurora DSQL با این رویکرد، سطح اطمینان و یکپارچگی دادهها در سرویسهای مبتنی بر دیتابیس را افزایش میدهد و تجربه کاربری بینقصی را فراهم میآورد، در حالی که پیچیدگیهای مدیریت سازگاری را به حداقل میرساند. این فناوری نشان میدهد چگونه میتوان با رعایت تعادل میان سرعت و دقت، سرویسهای قوی و قابل اعتماد ارائه داد.
#سازگاری_قوی #پایگاه_داده #Aurora #توسعه چاہ
🟣لینک مقاله:
https://brooker.co.za/blog/2025/11/18/consistency.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
brooker.co.za
Why Strong Consistency? - Marc's Blog
🔵 عنوان مقاله
State, Scale, and Signals: Rethinking Orchestration with Durable Execution (52 minute podcast)
🟢 خلاصه مقاله:
در سالهای اخیر، مفهوم اجرای مقاوم یا «دورهپذیری» در سیستمهای توزیعشده اهمیت فزایندهای یافته است. این رویکرد، باعث تغییر نگاه ما نسبت به مسئله قابلیت اطمینان در این نوع سیستمها شده است. بر خلاف رویکردهای سنتی که اجرای عملیاتها را بر پایه اطمینان از صحت و کامل بودن هر عملیات بر عهده برنامه و توسعهدهنده میگذاشت، اجرای مقاوم این مسئولیت را به سطح پلتفرم و زیرساختها منتقل میکند. در این حالت، سیستم یا پلتفرم، عملیاتها را به گونهای طراحی میکند که در صورت بروز خطا یا استثنا، بتواند به صورت خودکار عملیات را بازیابی و ادامه دهد، به گونهای که اطمینان کلی سیستم حفظ شود.
این مفهوم باعث میشود تا توسعهدهندگان تمرکز کمتری بر مدیریت خطاهای جزئی داشته باشند و بیشتر بر روی منطق کسبوکار و عملکردهای کلیدی تمرکز کنند. اجرای مقاوم، سطحی از اطمینان را فراهم میکند که دیگر نیازی نیست هر بار نگرانی درباره صحت اجرای هر عملیات به صورت جداگانه وجود داشته باشد؛ زیرا سیستم به صورت خودکار خطاها را تشخیص و اصلاح میکند. این تحول، درک ما از طراحی و ارکستراسیون سیستمهای توزیعشده را تغییر میدهد و اهمیت زیادی در ساخت سیستمهای مقاوم و پویا دارد.
در نتیجه، رویکرد «اجرای مقاوم» به ما امکان میدهد تا سیستمهای بزرگ، مقیاسپذیر و پایدارتر بسازیم، چرا که تضمین میکند عملیات حساس در لایههای پایینتر به صورت قابل اعتماد اجرا شوند و خطاهای احتمالی به صورت خودکار مدیریت شوند. این مفهوم جدید در زمینه سیستمهای توزیعشده پلی است برای آیندهای با سیستمهای مطمئنتر، مقاومتر و کارآمدتر.
#سیستمهای_توزیع_شده #پایدار_سازی #ارکستراسیون_سیستم #پلتفرم
🟣لینک مقاله:
https://www.dataengineeringpodcast.com/durable-execution-data-ai-orchestration-episode-489?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
State, Scale, and Signals: Rethinking Orchestration with Durable Execution (52 minute podcast)
🟢 خلاصه مقاله:
در سالهای اخیر، مفهوم اجرای مقاوم یا «دورهپذیری» در سیستمهای توزیعشده اهمیت فزایندهای یافته است. این رویکرد، باعث تغییر نگاه ما نسبت به مسئله قابلیت اطمینان در این نوع سیستمها شده است. بر خلاف رویکردهای سنتی که اجرای عملیاتها را بر پایه اطمینان از صحت و کامل بودن هر عملیات بر عهده برنامه و توسعهدهنده میگذاشت، اجرای مقاوم این مسئولیت را به سطح پلتفرم و زیرساختها منتقل میکند. در این حالت، سیستم یا پلتفرم، عملیاتها را به گونهای طراحی میکند که در صورت بروز خطا یا استثنا، بتواند به صورت خودکار عملیات را بازیابی و ادامه دهد، به گونهای که اطمینان کلی سیستم حفظ شود.
این مفهوم باعث میشود تا توسعهدهندگان تمرکز کمتری بر مدیریت خطاهای جزئی داشته باشند و بیشتر بر روی منطق کسبوکار و عملکردهای کلیدی تمرکز کنند. اجرای مقاوم، سطحی از اطمینان را فراهم میکند که دیگر نیازی نیست هر بار نگرانی درباره صحت اجرای هر عملیات به صورت جداگانه وجود داشته باشد؛ زیرا سیستم به صورت خودکار خطاها را تشخیص و اصلاح میکند. این تحول، درک ما از طراحی و ارکستراسیون سیستمهای توزیعشده را تغییر میدهد و اهمیت زیادی در ساخت سیستمهای مقاوم و پویا دارد.
در نتیجه، رویکرد «اجرای مقاوم» به ما امکان میدهد تا سیستمهای بزرگ، مقیاسپذیر و پایدارتر بسازیم، چرا که تضمین میکند عملیات حساس در لایههای پایینتر به صورت قابل اعتماد اجرا شوند و خطاهای احتمالی به صورت خودکار مدیریت شوند. این مفهوم جدید در زمینه سیستمهای توزیعشده پلی است برای آیندهای با سیستمهای مطمئنتر، مقاومتر و کارآمدتر.
#سیستمهای_توزیع_شده #پایدار_سازی #ارکستراسیون_سیستم #پلتفرم
🟣لینک مقاله:
https://www.dataengineeringpodcast.com/durable-execution-data-ai-orchestration-episode-489?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Data Engineering Podcast
State, Scale, and Signals: Rethinking Orchestration with Durable Execution
Summary
In this episode Preeti Somal, EVP of Engineering at Temporal, talks about the durable execution model and how it reshapes the way teams build…
In this episode Preeti Somal, EVP of Engineering at Temporal, talks about the durable execution model and how it reshapes the way teams build…
❤1
🔵 عنوان مقاله
Super Fast Aggregations Coming to Postgres 19
🟢 خلاصه مقاله:
نسخهی بعدی پستگرس، یعنی نسخه ۱۹، در راه است و هنوز ده ماه تا عرضه آن زمان باقی مانده است، اما اخیراً برخی از تغییرات اخیر نشان میدهد که کاربران میتوانند منتظر انجام تجمعهای بسیار سریعتر باشند، بدون نیاز به تغییر در نحوه نوشتن کوئریهای خود. یکی از ویژگیهای مهم این بهبود، تغییر در روش بهکارگیری اجماعها است. در نسخههای قبلی، فرآیند رایج این بود که ابتدا جدولها را با عمل JOIN پیوند میدادید و سپس بر روی نتیجه، عملیات تجمع انجام میدادید. اما در نسخه ۱۹، به کمک بهبودهای جدید، به جای این روش، به optimizer اجازه داده میشود که در صورت مناسب بودن، ابتدا عملیات تجمع انجام شده و سپس عمل JOIN صورت گیرد. این تغییر میتواند به طور قابلتوجهی سرعت اجرای کوئریها را افزایش دهد و کارایی سیستم را بهتر کند.
این قابلیت جدید، برخلاف رویکرد رایج "از ابتدا JOIN، سپس تجمع"، طرحی انعطافپذیرتر و بهینهتر است که بر اساس شرایط هر کوئری، بهترین روش را انتخاب میکند. این بهبود، به ویژه در مورد کوئریهایی که نیازمند عملیات دستهبندی و تجمیع دادههای بزرگ هستند، تأثیر به سزایی دارد و میتواند زمان اجرای آنها را به طور چشمگیری کاهش دهد.
در نتیجه، این تحولات نشاندهنده آیندهای روشن برای کاربرانی است که در پی بهبود سرعت و کارایی پایگاه دادههای خود هستند. گرچه نسخه ۱۹ هنوز چند ماه دیگر فاصله دارد، اما پیشرفتهای فعلی نویدبخش اصلاحاتی بزرگ در رفتار و عملکرد سیستمهای پایگاه داده مبتنی بر پستگرس است.
#پایگاه_داده #پستگرس #بهبود_کارایی #توسعه_نظامی
🟣لینک مقاله:
https://postgresweekly.com/link/177659/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Super Fast Aggregations Coming to Postgres 19
🟢 خلاصه مقاله:
نسخهی بعدی پستگرس، یعنی نسخه ۱۹، در راه است و هنوز ده ماه تا عرضه آن زمان باقی مانده است، اما اخیراً برخی از تغییرات اخیر نشان میدهد که کاربران میتوانند منتظر انجام تجمعهای بسیار سریعتر باشند، بدون نیاز به تغییر در نحوه نوشتن کوئریهای خود. یکی از ویژگیهای مهم این بهبود، تغییر در روش بهکارگیری اجماعها است. در نسخههای قبلی، فرآیند رایج این بود که ابتدا جدولها را با عمل JOIN پیوند میدادید و سپس بر روی نتیجه، عملیات تجمع انجام میدادید. اما در نسخه ۱۹، به کمک بهبودهای جدید، به جای این روش، به optimizer اجازه داده میشود که در صورت مناسب بودن، ابتدا عملیات تجمع انجام شده و سپس عمل JOIN صورت گیرد. این تغییر میتواند به طور قابلتوجهی سرعت اجرای کوئریها را افزایش دهد و کارایی سیستم را بهتر کند.
این قابلیت جدید، برخلاف رویکرد رایج "از ابتدا JOIN، سپس تجمع"، طرحی انعطافپذیرتر و بهینهتر است که بر اساس شرایط هر کوئری، بهترین روش را انتخاب میکند. این بهبود، به ویژه در مورد کوئریهایی که نیازمند عملیات دستهبندی و تجمیع دادههای بزرگ هستند، تأثیر به سزایی دارد و میتواند زمان اجرای آنها را به طور چشمگیری کاهش دهد.
در نتیجه، این تحولات نشاندهنده آیندهای روشن برای کاربرانی است که در پی بهبود سرعت و کارایی پایگاه دادههای خود هستند. گرچه نسخه ۱۹ هنوز چند ماه دیگر فاصله دارد، اما پیشرفتهای فعلی نویدبخش اصلاحاتی بزرگ در رفتار و عملکرد سیستمهای پایگاه داده مبتنی بر پستگرس است.
#پایگاه_داده #پستگرس #بهبود_کارایی #توسعه_نظامی
🟣لینک مقاله:
https://postgresweekly.com/link/177659/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
What Are 'Dirty Pages' in Postgres?
🟢 خلاصه مقاله:
در سیستمهای پایگاه داده مانند PostgreSQL، مفهوم «صفحات کثیف» یا "Dirty Pages" اهمیت ویژهای دارد. این صفحات زمانی رخ میدهند که دادهها در حافظه موقت تغییر میکنند، اما این تغییرات هنوز به طور همزمان در هارد دیسک ذخیره نشده است. در واقع، هنگامی که یک تراکنش در حال انجام است و تغییراتی در دادهها ایجاد میکند، این تغییرات ابتدا در فضای کش یا حافظه موقت ثبت میشوند تا پردازش سریعتر صورت گیرد. اما این تغییرات تا زمانی که به صورت رسمی در فایلهای پایگاه داده نوشته نشوند، در حالت «کثیف» باقی میمانند.
وجود صفحات کثیف در حافظه نشاندهنده این است که سیستم پایگاه داده ما در حالت آستانهای از بهروزرسانیها قرار دارد و نیاز است تا این صفحات در فرصت مناسب به دیسک انتقال یافته و ذخیره شوند. این انتقال معمولا توسط فرآیندی به نام «اجرای چرخههای نگهداری» یا Vacuum در PostgreSQL انجام میشود؛ فرآیندی که علاوه بر پاکسازی صفحات کثیف، باعث بهینهسازی عملکرد و جلوگیری از رشد بیرویه فایلهای قدیمی میشود. بنابراین، مدیریت صحیح صفحات کثیف یکی از کلیدهای نگهداری کارآمد و مطمئن پایگاه داده است.
در نتیجه، درک مفهوم صفحات کثیف و فرآیندهای مربوط به آنها، به مدیران پایگاه داده کمک میکند تا بهتر بتوانند عملکرد سیستمهای خود را پایش و حفظ کنند، و همچنین در کاهش ریسکهای مربوط به خطاهای تراکنشی و امکان بازیابی اطلاعات، موثر باشند.
#پایگاه_داده #PostgreSQL #مدیریت_داده #کاهش_خطا
🟣لینک مقاله:
https://postgresweekly.com/link/176687/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
What Are 'Dirty Pages' in Postgres?
🟢 خلاصه مقاله:
در سیستمهای پایگاه داده مانند PostgreSQL، مفهوم «صفحات کثیف» یا "Dirty Pages" اهمیت ویژهای دارد. این صفحات زمانی رخ میدهند که دادهها در حافظه موقت تغییر میکنند، اما این تغییرات هنوز به طور همزمان در هارد دیسک ذخیره نشده است. در واقع، هنگامی که یک تراکنش در حال انجام است و تغییراتی در دادهها ایجاد میکند، این تغییرات ابتدا در فضای کش یا حافظه موقت ثبت میشوند تا پردازش سریعتر صورت گیرد. اما این تغییرات تا زمانی که به صورت رسمی در فایلهای پایگاه داده نوشته نشوند، در حالت «کثیف» باقی میمانند.
وجود صفحات کثیف در حافظه نشاندهنده این است که سیستم پایگاه داده ما در حالت آستانهای از بهروزرسانیها قرار دارد و نیاز است تا این صفحات در فرصت مناسب به دیسک انتقال یافته و ذخیره شوند. این انتقال معمولا توسط فرآیندی به نام «اجرای چرخههای نگهداری» یا Vacuum در PostgreSQL انجام میشود؛ فرآیندی که علاوه بر پاکسازی صفحات کثیف، باعث بهینهسازی عملکرد و جلوگیری از رشد بیرویه فایلهای قدیمی میشود. بنابراین، مدیریت صحیح صفحات کثیف یکی از کلیدهای نگهداری کارآمد و مطمئن پایگاه داده است.
در نتیجه، درک مفهوم صفحات کثیف و فرآیندهای مربوط به آنها، به مدیران پایگاه داده کمک میکند تا بهتر بتوانند عملکرد سیستمهای خود را پایش و حفظ کنند، و همچنین در کاهش ریسکهای مربوط به خطاهای تراکنشی و امکان بازیابی اطلاعات، موثر باشند.
#پایگاه_داده #PostgreSQL #مدیریت_داده #کاهش_خطا
🟣لینک مقاله:
https://postgresweekly.com/link/176687/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy