منطق پشت کلاستر این CockroachDB چقدر قشنگه.
نوعی دیتابیس SQL که به صورت Master Master کلاستر میشه و از پروتکل RAFT استفاده میکنه.
اما چی!؟ ، مگه RAFT ساختارش به صورت Master Slave ایی تعریف نمیشد؟ پس چجوری توی دیتابیس Master Master داره استفاده میشه؟
شاید اونجوری که CockroachDB میگه اصلا Master Master ایی در کار نیست یا تعریف ما متفاوته .
خلاصه اگه علاقه مند هستین چجوری توی CockroachDB ما RAFT داریم، خوشحال میشم مقاله ایی رو که نوشتم مطالعه کنین، حدودا هم ۵ دقیقه وقتتون رو میگیره.
https://medium.com/@parsagheiratian/the-mentality-behind-cockroachdb-0ed524fcc7ec
<Parsa Gheiratian/>
️️
نوعی دیتابیس SQL که به صورت Master Master کلاستر میشه و از پروتکل RAFT استفاده میکنه.
اما چی!؟ ، مگه RAFT ساختارش به صورت Master Slave ایی تعریف نمیشد؟ پس چجوری توی دیتابیس Master Master داره استفاده میشه؟
شاید اونجوری که CockroachDB میگه اصلا Master Master ایی در کار نیست یا تعریف ما متفاوته .
خلاصه اگه علاقه مند هستین چجوری توی CockroachDB ما RAFT داریم، خوشحال میشم مقاله ایی رو که نوشتم مطالعه کنین، حدودا هم ۵ دقیقه وقتتون رو میگیره.
https://medium.com/@parsagheiratian/the-mentality-behind-cockroachdb-0ed524fcc7ec
<Parsa Gheiratian/>
️️
Medium
The mentality behind CockroachDB
multi-active “master-master”, Raft, ranges, and how “master” really works
🔵 عنوان مقاله
The Art of Lean Governance: The Cybernetics of Data Quality (5 minute read)
🟢 خلاصه مقاله:
** این مقاله پیشنهاد میکند برای مدیریت کیفیت دادهها از رویکرد سایبرنتیک استفاده شود؛ یعنی اکوسیستم داده مانند یک سامانه خودتنظیم و یادگیرنده با حلقههای بازخورد، کنترل و بهبود مداوم دیده شود. عناصر کلیدی شامل موتورهای پویا برای آشتیدادن دادهها در لحظه، واژهنامههای کسبوکارِ تعبیهشده برای یکپارچگی معنایی، و تبارشناسی کامل دادهها جهت ردیابی علّی و حاکمیت قوی بر AI است. حاکمیت چابک با سیاستها بهصورت کد، دروازههای کیفیت در CI/CD، و اتوماسیون رویدادمحور اجرا میشود؛ مالکیت در تیمهای دامنه است و گروه مرکزی فقط استانداردها و ابزار مشترک را فراهم میکند. با تعریف SLOهای کیفیت و اجرای چرخه کشف → تشخیص → اصلاح → راستیآزمایی → یادگیری، کنترلها بهصورت پیشدستانه و مقیاسپذیر اعمال میشوند و ریسک، هزینه و زمان رفع خطا کاهش مییابد.
#DataQuality #Cybernetics #DataGovernance #AIGovernance #DataLineage #Observability #LeanGovernance #MLOps
🟣لینک مقاله:
https://tdan.com/the-art-of-lean-governance-the-cybernetics-of-data-quality/33051?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Art of Lean Governance: The Cybernetics of Data Quality (5 minute read)
🟢 خلاصه مقاله:
** این مقاله پیشنهاد میکند برای مدیریت کیفیت دادهها از رویکرد سایبرنتیک استفاده شود؛ یعنی اکوسیستم داده مانند یک سامانه خودتنظیم و یادگیرنده با حلقههای بازخورد، کنترل و بهبود مداوم دیده شود. عناصر کلیدی شامل موتورهای پویا برای آشتیدادن دادهها در لحظه، واژهنامههای کسبوکارِ تعبیهشده برای یکپارچگی معنایی، و تبارشناسی کامل دادهها جهت ردیابی علّی و حاکمیت قوی بر AI است. حاکمیت چابک با سیاستها بهصورت کد، دروازههای کیفیت در CI/CD، و اتوماسیون رویدادمحور اجرا میشود؛ مالکیت در تیمهای دامنه است و گروه مرکزی فقط استانداردها و ابزار مشترک را فراهم میکند. با تعریف SLOهای کیفیت و اجرای چرخه کشف → تشخیص → اصلاح → راستیآزمایی → یادگیری، کنترلها بهصورت پیشدستانه و مقیاسپذیر اعمال میشوند و ریسک، هزینه و زمان رفع خطا کاهش مییابد.
#DataQuality #Cybernetics #DataGovernance #AIGovernance #DataLineage #Observability #LeanGovernance #MLOps
🟣لینک مقاله:
https://tdan.com/the-art-of-lean-governance-the-cybernetics-of-data-quality/33051?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TDAN.com
The Art of Lean Governance: The Cybernetics of Data Quality
In the age of algorithmic intelligence, data is no longer just an asset — it is a self-regulating system whose health determines the stability and success of modern enterprises. To manage data effectively today, leaders must think in cybernetic terms — as…
Forwarded from Job Labdon
A Data Structure Algorithms Low Level Design and High Level Design collection of resources.
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
مجموعهای از منابع برای طراحی low level و high level توی مصاحبههای الگوریتمی و برنامهنویسی
#DSA #LLD #HLD #Algorithm #Interview #Leetcode #Question
https://github.com/arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
GitHub
GitHub - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD: A Data Structure Algorithms Low Level Design and High Level Design collection…
A Data Structure Algorithms Low Level Design and High Level Design collection of resources. - arpit20adlakha/Data-Structure-Algorithms-LLD-HLD
👍1
🔵 عنوان مقاله
PlanetScale for Postgres is Now GA
🟢 خلاصه مقاله:
PlanetScale اعلام کرد که PlanetScale for Postgres به مرحله GA رسیده و اکنون برای همه کاربران در دسترس است. این حرکت پس از آن انجام شد که شرکت در ماه جولای ورود خود به فضای PG را اعلام کرد و مجموعهای از بنچمارکها را منتشر نمود. این سرویس تا امروز در فاز private preview بود و اکنون برای استفاده در محیطهای تولیدی آماده اعلام شده است. به این ترتیب، تیمهایی که بر Postgres تکیه دارند میتوانند از پیشنهاد جدید PlanetScale استفاده کرده و آن را در مقیاس عملیاتی امتحان کنند.
#PlanetScale #Postgres #PG #Database #Cloud #GA #MySQL #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174747/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PlanetScale for Postgres is Now GA
🟢 خلاصه مقاله:
PlanetScale اعلام کرد که PlanetScale for Postgres به مرحله GA رسیده و اکنون برای همه کاربران در دسترس است. این حرکت پس از آن انجام شد که شرکت در ماه جولای ورود خود به فضای PG را اعلام کرد و مجموعهای از بنچمارکها را منتشر نمود. این سرویس تا امروز در فاز private preview بود و اکنون برای استفاده در محیطهای تولیدی آماده اعلام شده است. به این ترتیب، تیمهایی که بر Postgres تکیه دارند میتوانند از پیشنهاد جدید PlanetScale استفاده کرده و آن را در مقیاس عملیاتی امتحان کنند.
#PlanetScale #Postgres #PG #Database #Cloud #GA #MySQL #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/174747/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
PlanetScale for Postgres is now GA — PlanetScale
PlanetScale for Postgres is now generally available.
🔵 عنوان مقاله
Building a Dev Experience for Postgres in VS Code
🟢 خلاصه مقاله:
مایکروسافت با حضور Rob Emanuele در پادکست Talking Postgres به میزبانی Claire Giordano درباره ساخت یک تجربه توسعهدهنده برای Postgres در VS Code صحبت میکند. محور گفتگو، افزونه تازهٔ «IDE for Postgres» است که اوایل امسال توسط Microsoft منتشر شد و هدفش آوردن کارهای روزمرهٔ پایگاهداده به دل محیط آشنای VS Code و کاهش جابهجایی بین ابزارهاست. در این قسمت به انگیزهها، چالشهای رایج برنامهنویسان، نقش بازخورد جامعه، و مسیر آیندهٔ ابزار پرداخته میشود تا نشان دهد این افزونه چگونه گردشکار نوشتن و آزمون SQL و مدیریت تغییرات را سادهتر میکند.
#Postgres #VSCode #Microsoft #DeveloperExperience #TalkingPostgres #IDE #DatabaseTools #VSCodeExtension
🟣لینک مقاله:
https://postgresweekly.com/link/176991/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Building a Dev Experience for Postgres in VS Code
🟢 خلاصه مقاله:
مایکروسافت با حضور Rob Emanuele در پادکست Talking Postgres به میزبانی Claire Giordano درباره ساخت یک تجربه توسعهدهنده برای Postgres در VS Code صحبت میکند. محور گفتگو، افزونه تازهٔ «IDE for Postgres» است که اوایل امسال توسط Microsoft منتشر شد و هدفش آوردن کارهای روزمرهٔ پایگاهداده به دل محیط آشنای VS Code و کاهش جابهجایی بین ابزارهاست. در این قسمت به انگیزهها، چالشهای رایج برنامهنویسان، نقش بازخورد جامعه، و مسیر آیندهٔ ابزار پرداخته میشود تا نشان دهد این افزونه چگونه گردشکار نوشتن و آزمون SQL و مدیریت تغییرات را سادهتر میکند.
#Postgres #VSCode #Microsoft #DeveloperExperience #TalkingPostgres #IDE #DatabaseTools #VSCodeExtension
🟣لینک مقاله:
https://postgresweekly.com/link/176991/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Talking Postgres with Claire Giordano
Talking Postgres with Claire Giordano | Building a dev experience for Postgres in VS Code with Rob Emanuele
What do guitar busking, geospatial queries, and agentic coding have to do with Postgres? In Episode 33 of Talking Postgres, principal engineer Rob Emanuele at Microsoft shares his winding path from...
🔵 عنوان مقاله
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)
🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای بهروزرسانی دادهها معمولاً بهتر از INSERT OVERWRITE است، زیرا بهجای بازنویسی پارتیشنها، تغییرات را بهصورت دلتا در سطح فایل اضافه میکند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاهتر و صرفهجویی در هزینه ذخیرهسازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن میشود و در مواجهه با Partition Evolution آسیبپذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی دادههای تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشردهسازی و خانهتکانی دورهای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیشفرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه میشود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.
#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL
🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg (7 minute read)
🟢 خلاصه مقاله:
MERGE INTO همراه با استراتژی Merge-on-Read (MOR) در Apache Iceberg برای بهروزرسانی دادهها معمولاً بهتر از INSERT OVERWRITE است، زیرا بهجای بازنویسی پارتیشنها، تغییرات را بهصورت دلتا در سطح فایل اضافه میکند؛ نتیجه این کار کاهش I/O، زمان اجرای کوتاهتر و صرفهجویی در هزینه ذخیرهسازی است. در مقابل، INSERT OVERWRITE با هر تغییر کوچک مجبور به بازنویسی کامل پارتیشن میشود و در مواجهه با Partition Evolution آسیبپذیرتر است. رویکرد MOR با تکیه بر تکامل پارتیشن مبتنی بر متادیتا، بدون بازنویسی دادههای تاریخی، با الگوهای افزایشی مثل CDC و رویدادهای دیررس سازگار است. نقطه ضعف MOR نیاز به فشردهسازی و خانهتکانی دورهای و اندکی سربار در خواندن برای اعمال دلتاهاست؛ با این حال، برای اغلب بارهای کاری افزایشی، انتخاب پیشفرض بهتر MERGE INTO (MOR) است و INSERT OVERWRITE فقط زمانی توصیه میشود که قصد بازسازی کامل یا اصلاح گسترده و مشخص داده را دارید.
#ApacheIceberg #MERGEINTO #MergeOnRead #DataEngineering #DataLakehouse #PartitionEvolution #BigData #ETL
🟣لینک مقاله:
https://medium.com/expedia-group-tech/why-you-should-prefer-merge-into-over-insert-overwrite-in-apache-iceberg-b6b130cc27d2?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Why You Should Prefer MERGE INTO Over INSERT OVERWRITE in Apache Iceberg
Stop overwriting —start merging: a smarter approach to updating Iceberg tables
🔵 عنوان مقاله
All You Can Do Before Airflow (5 minute read)
🟢 خلاصه مقاله:
سادهترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپتهای Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمانبندیهای مدیریتشده مثل Cloud Scheduler یا EventBridge بههمراه logging، retry و alert کفایت میکند. نشانههای نیاز به Airflow زمانی ظاهر میشوند که وابستگیها و DAGها پیچیده میشوند، backfill و SLA اهمیت پیدا میکند، مالکیت بین تیمها توزیع میشود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیءاستور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: سادهترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.
#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
All You Can Do Before Airflow (5 minute read)
🟢 خلاصه مقاله:
سادهترین روش ارکستریشن را شروع کنید و فقط وقتی رشد واقعی پیچیدگی آن را توجیه کرد به Airflow مهاجرت کنید. برای بسیاری از نیازها، ترکیبی از cron، اسکریپتهای Bash یا Python، یک Makefile، کانتینرسازی با Docker Compose و زمانبندیهای مدیریتشده مثل Cloud Scheduler یا EventBridge بههمراه logging، retry و alert کفایت میکند. نشانههای نیاز به Airflow زمانی ظاهر میشوند که وابستگیها و DAGها پیچیده میشوند، backfill و SLA اهمیت پیدا میکند، مالکیت بین تیمها توزیع میشود و به observability، lineage، RBAC و مدیریت secrets نیاز دارید. قبل از مهاجرت، کارها را idempotent و کوچک کنید، state را در دیتابیس/شیءاستور نگه دارید، تنظیمات را در کد مدیریت کنید، تست و مستندسازی و پایش را جدی بگیرید. قاعده تصمیم این است: سادهترین ابزار کافی امروز را انتخاب کنید و فقط وقتی درد واقعی تجربه کردید به Airflow ارتقا دهید.
#DataOrchestration #ApacheAirflow #DataPipelines #ETL #DataEngineering #Scalability #CronJobs #Observability
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/all-you-can-do-before-airflow?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
All You Can Do Before Airflow:
4 Orchestration Levels From Cron to Full Pipelines
🔵 عنوان مقاله
How to Listen to Database Changes Through the WAL
🟢 خلاصه مقاله:
شنیدن تغییرات دیتابیس از طریق WAL در Postgres یک روش پایدار برای CDC است که بدون تریگر و پولینگ اضافه، رویدادهای INSERT/UPDATE/DELETE را با ترتیب مبتنی بر LSN و قابلیت بازیابی استریم میکند. راهاندازی شامل wal_level=logical، ساخت replication slot، انتخاب output plugin مثل pgoutput یا wal2json، گرفتن snapshot اولیه و ذخیره LSN برای پیشرفت مصرفکننده است. از منظر عملیاتی باید نگهداری WAL توسط replication slot، backpressure، تراکنشهای بزرگ، تغییرات schema، و مدیریت failover و امنیت را پایش کنید و با طراحی آیدمپوتنت در مقصد، تحویل at-least-once را کنترل کنید. در مطالب مرتبط، Peter Ullrich به transaction pooling با Pgcat و قیود آن میپردازد، Phil Eaton سفر یک کوئری SQL را در Postgres از parse تا execution روایت میکند، و Umair Shahid مفهوم Dirty Pages، نقش background writer/checkpointer و اثر تنظیمات بر پایداری I/O را توضیح میدهد.
#Postgres #WAL #ChangeDataCapture #LogicalDecoding #Pgcat #SQL #DirtyPages #DatabaseInternals
🟣لینک مقاله:
https://postgresweekly.com/link/176684/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Listen to Database Changes Through the WAL
🟢 خلاصه مقاله:
شنیدن تغییرات دیتابیس از طریق WAL در Postgres یک روش پایدار برای CDC است که بدون تریگر و پولینگ اضافه، رویدادهای INSERT/UPDATE/DELETE را با ترتیب مبتنی بر LSN و قابلیت بازیابی استریم میکند. راهاندازی شامل wal_level=logical، ساخت replication slot، انتخاب output plugin مثل pgoutput یا wal2json، گرفتن snapshot اولیه و ذخیره LSN برای پیشرفت مصرفکننده است. از منظر عملیاتی باید نگهداری WAL توسط replication slot، backpressure، تراکنشهای بزرگ، تغییرات schema، و مدیریت failover و امنیت را پایش کنید و با طراحی آیدمپوتنت در مقصد، تحویل at-least-once را کنترل کنید. در مطالب مرتبط، Peter Ullrich به transaction pooling با Pgcat و قیود آن میپردازد، Phil Eaton سفر یک کوئری SQL را در Postgres از parse تا execution روایت میکند، و Umair Shahid مفهوم Dirty Pages، نقش background writer/checkpointer و اثر تنظیمات بر پایداری I/O را توضیح میدهد.
#Postgres #WAL #ChangeDataCapture #LogicalDecoding #Pgcat #SQL #DirtyPages #DatabaseInternals
🟣لینک مقاله:
https://postgresweekly.com/link/176684/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Peterullrich
Listen to Database Changes through the Postgres WAL
An in-depth guide to listening to Postgres database changes through the WAL. Covers logical replication, publications, replication slots, and an Elixir implementation.
Forwarded from Linux Labdon
کاهش هزینه سیستمهای هوش مصنوعی با Semantic Caching
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
با رشد مدلهای زبانی بزرگ و پیشرفته، هزینه و زمان پاسخدهی هم به شدت افزایش پیدا کرده. مدلهایی مثل GPT-5 یا Claude برای کارهای پیچیده فوقالعادهاند، ولی استفاده از اونها هم پرهزینه و هم کند محسوب میشه. از طرف دیگه، AI Agentها واقعاً «توکنخور» هستن؛ یعنی برای انجام یک کار معمولاً چندین مرحله طی میکنن: تحقیق، برنامهریزی، عمل و بازتاب و تکرار. همین باعث میشه چندین بار با مدل تماس بگیرن و در نتیجه هزینه و تأخیر افزایش پیدا کنه و متنهای طولانیتر تولید بشه. برای مثال، یه بنچمارک اخیر از TheAgentCompany در ۲۰۲۵ نشون داده اجرای کامل یک Agent گاهی تا ۶.۸ دلار هزینه داره.
یکی از مشکلات اصلی در دنیای واقعی، تکراری بودن سوالهاست، مخصوصاً توی پشتیبانی مشتری. کاربران دائماً سوالهای مشابهی میپرسن: مثل «چطور پولم رو پس بگیرم؟» یا «شرایط بازگشت وجه چیه؟» و Agent مجبور میشه هر بار پاسخ رو از صفر تولید کنه. نتیجهش افزایش هزینه، طولانی شدن زمان پاسخ و فشار بیشتر روی سیستمهای RAG و زیرساختهاست.
در نگاه اول، ممکنه فکر کنیم کش کلاسیک کفایت میکنه. ایدهی کش ساده اینه که اگر یک سوال قبلاً پاسخ داده شده، دوباره سراغ مدل نریم. ولی مشکل اینجاست که کش سنتی دنبال Exact Match یا تطابق دقیق متنه. سوالهایی که از نظر معنی یکی هستن ولی عبارتهاشون فرق میکنه، مثل: «میخوام پولم رو پس بگیرم»، «چطور میتونم درخواست بازگشت وجه بدم؟» و «سیاست بازگشت پولتون چیه؟»، همه Cache Miss میشن و کش عملاً استفاده نمیشه.
اینجاست که Semantic Caching وارد میشه. به جای تطابق کلمهبهکلمه، کش به معنی و مفهوم جمله نگاه میکنه. مزیت اصلیش اینه که Recall و Hit Rate بالاتره و احتمال استفاده از کش و صرفهجویی خیلی بیشتر میشه. البته چالشش هم اینه که گاهی ممکنه جواب بیربط بده یا همون «False Positive» رخ بده.
روش کار Semantic Caching ساده است ولی هوشمندانه: ابتدا سوال کاربر به Embedding یا بردار عددی تبدیل میشه. بعد با بردارهای موجود در کش با Semantic Search مقایسه میشه. اگر فاصله معنایی کم باشه، پاسخ از کش برگردونده میشه؛ در غیر این صورت به RAG یا LLM میریم. در نهایت سوال و پاسخ جدید هم ذخیره میشه تا دفعه بعدی قابل استفاده باشه.
پیادهسازی Semantic Caching با چالشهایی همراهه؛ مثل دقت (Accuracy) که آیا کش جواب درست میده، کارایی (Performance) و میزان Cache Hit، سرعت سرویسدهی، آپدیتپذیری کش و اینکه آیا میتونیم کش رو گرم، تازهسازی یا پاکسازی کنیم. همچنین مشاهدهپذیری (Observability) مهمه تا بتونیم hit rate، latency، صرفهجویی هزینه و کیفیت کش رو بسنجیم.
معیارهای اصلی سنجش کش شامل Cache Hit Rate هست که نشون میده چند درصد درخواستها از کش پاسخ داده میشن و Precision/Recall/F1 Score که کیفیت و دقت پاسخها رو مشخص میکنه. برای بهبود دقت و کارایی کش هم میتونیم Threshold فاصله رو تنظیم کنیم، Reranker اضافه کنیم مثل Cross-encoder یا LLM-as-a-judge، از Fuzzy Matching برای تایپوها استفاده کنیم و فیلترهای اضافی مثل تشخیص پرسشهای زمانمحور (Temporal) یا تشخیص کد (Python، Java و…) اعمال کنیم تا سوالات اشتباه وارد کش نشن.
یه مثال واقعی از این تکنولوژی پروژه waLLMartCache در Walmart هست. اونها با نوآوریهایی مثل Load Balancer برای توزیع کش روی چند Node و Dual-tiered Storage که L1 = Vector DB و L2 = In-memory Cache مثل Redis هست، هم سرعت و هم دقت رو بالا بردن. Multi-tenancy هم باعث شده چند تیم یا اپلیکیشن از یک زیرساخت مشترک استفاده کنن. Decision Engine هم شامل تشخیص کد و زمانه و اگر سوال مناسب کش نباشه مستقیماً به LLM یا RAG میره. نتیجهش رسیدن به دقت نزدیک ۹۰٪ بوده.
<Reza Jafari/>
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
❤1
🔵 عنوان مقاله
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی میکند؛ لایهای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه میدهد چند نود همزمان عملیات نوشتن را بپذیرند و دادهها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال میکند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم میسازد.
نویسنده چالشهای اصلی Multi‑Master را توضیح میدهد: تشخیص و رفع تضادهای نوشتن، سیاستهای قابل پیکربندی مثل last‑update‑wins یا روشهای سفارشی، مدیریت شناسههای یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز میتواند تعارضها را کم کند. نتیجهگیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینهای قوی است.
در مقایسه با گزینههای دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی میگذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را میدهد. از آنجا که این مطلب در Golang Weekly آمده، نکات پیادهسازی برای سرویسهای Go نیز مطرح میشود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستمهای رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Spock: Logical Multi-Master PostgreSQL Replication
🟢 خلاصه مقاله:
این مقاله Spock را معرفی میکند؛ لایهای برای Logical Multi‑Master Replication روی PostgreSQL که اجازه میدهد چند نود همزمان عملیات نوشتن را بپذیرند و دادهها را بین خود همگام نگه دارند. برخلاف Physical Replication که به یک لیدر متکی است، Spock با استفاده از logical decoding تغییرات سطری را دریافت و روی نودهای دیگر اعمال میکند و بدین ترتیب امکان active‑active و حتی انتشار بخشی از DDL را فراهم میسازد.
نویسنده چالشهای اصلی Multi‑Master را توضیح میدهد: تشخیص و رفع تضادهای نوشتن، سیاستهای قابل پیکربندی مثل last‑update‑wins یا روشهای سفارشی، مدیریت شناسههای یکتا و sequenceها، و تغییر توپولوژی بدون توقف. از نظر عملیاتی نیز نظارت بر lag، ثبت و رصد تضادها، و طراحی الگوهای اپلیکیشنی مثل upsert و عملیات idempotent ضروری است؛ استفاده از UUID به جای sequenceهای متمرکز میتواند تعارضها را کم کند. نتیجهگیری این است که Spock جایگزین ساده برای سازگاری قوی سراسری نیست، اما برای سناریوهای active‑active با پذیرش eventual consistency گزینهای قوی است.
در مقایسه با گزینههای دیگر (Built‑in Logical Replication تک‑مستر، Physical Streaming، و راهکارهایی مانند BDR یا Bucardo)، Spock تمرکز را بر Multi‑Master منطقی میگذارد و در قبال پیچیدگی بیشتر، استقلال از یک primary واحد را میدهد. از آنجا که این مطلب در Golang Weekly آمده، نکات پیادهسازی برای سرویسهای Go نیز مطرح میشود: اتصال از طریق database/sql یا pgx به نود محلی برای کاهش تاخیر، مدیریت retry و conflict، و استفاده از الگوهایی مثل transactional outbox و CDC برای ساخت سیستمهای رویدادمحور قابل اتکا.
#PostgreSQL #Spock #LogicalReplication #MultiMaster #Golang #DistributedSystems #DatabaseReplication #HighAvailability
🟣لینک مقاله:
https://postgresweekly.com/link/177326/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - pgEdge/spock: Logical multi-master PostgreSQL replication
Logical multi-master PostgreSQL replication. Contribute to pgEdge/spock development by creating an account on GitHub.
🔵 عنوان مقاله
discuss what went wrong (and right!) with implementing asynchronous I/O
🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیادهسازی I/O ناهمگام توضیح میدهد که چرا ایده «عدم انسداد» ساده به نظر میرسد اما در عمل با تفاوتهای پلتفرمی و جزئیات ظریف سیستمعامل پیچیده میشود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نهتنها APIها متفاوتاند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبهای یا سطحی، زمانبندی، و چرخه عمر denoscriptorها هم فرق میکند.
در Go، فلسفه این بوده که پیچیدگی پشت goroutine و netpoller پنهان شود تا کدنویسی ساده و «مسدودکننده» بماند، در حالی که اجرای واقعی غیرمسدودکننده باشد. این انتخاب، یادگیری و صحت را بهبود داده، اما در مقیاس بالا مشکلهایی مثل انسدادهای پنهان در برنامهریز، نشت goroutine بهدلیل لغو ناقص، بیعدالتی بین ارتباطها، و اختلافات پلتفرمی در خطاها و semantics را آشکار کرده است.
اشتباهات رایج از «نشت انتزاع» میآیند: سادهسازی بیش از حد APIهای مسدودکننده، نبودِ backpressure کافی و رصدپذیری، اتکا زودهنگام به یک قابلیت خاص کرنل، و آزمونهای ناپایدار که تفاوتهای سیستمعاملها را میپوشانند؛ خروجی آن هم تاخیرهای غیرقابل پیشبینی، رشد حافظه و مشکلات پایداری است.
در عوض، نقاط قوت هم پررنگاند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانههای net/http و database/sql رفتارهای امنتری فراهم کردهاند. روی Linux، آزمایشهای محتاطانه با io_uring امید به کاهش syscallها و بیدارباشها را نشان میدهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارکهای دقیق هم جلوی پسرفتها را گرفتهاند.
جمعبندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازهگیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صفها، wakeupها و تعامل با scheduler سرمایهگذاری کنید. از قابلیتهای جدید کرنل بهصورت افزایشی و با احتیاط استفاده کنید و سطح برنامهنویسی را ساده نگه دارید. در عمل، از فراخوانیهای مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بیرویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعیاند، اما با انضباط مهندسی بهدست میآیند، نه صرفا با انتخاب یک primitive جدید.
#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller
🟣لینک مقاله:
https://postgresweekly.com/link/176360/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
discuss what went wrong (and right!) with implementing asynchronous I/O
🟢 خلاصه مقاله:
این مقاله در Golang Weekly با مرور تجربه پیادهسازی I/O ناهمگام توضیح میدهد که چرا ایده «عدم انسداد» ساده به نظر میرسد اما در عمل با تفاوتهای پلتفرمی و جزئیات ظریف سیستمعامل پیچیده میشود. بین Linux (epoll و io_uring)، BSD (kqueue) و Windows (IOCP) نهتنها APIها متفاوتاند، بلکه معنای آمادگی در برابر تکمیل، تریگر لبهای یا سطحی، زمانبندی، و چرخه عمر denoscriptorها هم فرق میکند.
در Go، فلسفه این بوده که پیچیدگی پشت goroutine و netpoller پنهان شود تا کدنویسی ساده و «مسدودکننده» بماند، در حالی که اجرای واقعی غیرمسدودکننده باشد. این انتخاب، یادگیری و صحت را بهبود داده، اما در مقیاس بالا مشکلهایی مثل انسدادهای پنهان در برنامهریز، نشت goroutine بهدلیل لغو ناقص، بیعدالتی بین ارتباطها، و اختلافات پلتفرمی در خطاها و semantics را آشکار کرده است.
اشتباهات رایج از «نشت انتزاع» میآیند: سادهسازی بیش از حد APIهای مسدودکننده، نبودِ backpressure کافی و رصدپذیری، اتکا زودهنگام به یک قابلیت خاص کرنل، و آزمونهای ناپایدار که تفاوتهای سیستمعاملها را میپوشانند؛ خروجی آن هم تاخیرهای غیرقابل پیشبینی، رشد حافظه و مشکلات پایداری است.
در عوض، نقاط قوت هم پررنگاند: مدل «کدنویسی مسدودکننده، اجرای ناهمگام» با بهبودهای تدریجی در runtime، netpoller، تایمرها و preemption همراه شده و الگوهای استاندارد مثل context.Context برای لغو، channels برای backpressure، و کتابخانههای net/http و database/sql رفتارهای امنتری فراهم کردهاند. روی Linux، آزمایشهای محتاطانه با io_uring امید به کاهش syscallها و بیدارباشها را نشان میدهد، با fallbacks برای سازگاری. استقرار تدریجی و بنچمارکهای دقیق هم جلوی پسرفتها را گرفتهاند.
جمعبندی عملی: پیش و پس از تغییر مسیر I/O حتما اندازهگیری کنید؛ لغو را به چرخه عمر منابع گره بزنید؛ منطق مخصوص هر پلتفرم را ایزوله نگه دارید؛ backpressure را در APIها نمایان کنید؛ و روی رصدپذیری (tracing/metrics) برای عمق صفها، wakeupها و تعامل با scheduler سرمایهگذاری کنید. از قابلیتهای جدید کرنل بهصورت افزایشی و با احتیاط استفاده کنید و سطح برنامهنویسی را ساده نگه دارید. در عمل، از فراخوانیهای مبتنی بر context و timeout استفاده کنید، از ایجاد goroutine بیرویه برای I/O پرهیز کنید، به استانداردها تکیه کنید، تنها با داده سراغ tuning بروید، و حتما روی Linux، BSD و Windows تست بگیرید. دستاوردهای I/O ناهمگام واقعیاند، اما با انضباط مهندسی بهدست میآیند، نه صرفا با انتخاب یک primitive جدید.
#Golang #AsyncIO #Concurrency #SystemsProgramming #epoll #kqueue #io_uring #Netpoller
🟣لینک مقاله:
https://postgresweekly.com/link/176360/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Talking Postgres with Claire Giordano
Talking Postgres with Claire Giordano | What went wrong (& what went right) with AIO with Andres Freund
Six years, a prototype, and a brief multi-layered descent into “wronger and wronger” design—what does it take to land a major architectural change in Postgres? In Episode 31 of Talking Postgres, An...
❤1
🔵 عنوان مقاله
be careful when you do minor version upgrades
🟢 خلاصه مقاله:
** ارتقای نسخههای بهظاهر «جزئی» میتواند در سیستمهای مبتنی بر Debian پیامدهای بزرگی داشته باشد. بهروزرسانی نقطهای Debian ممکن است کتابخانههای مرتبط با locale و collation را تغییر دهد و پایگاه داده شما را به بهروزرسانی collation وادار کند؛ نتیجه میتواند بازسازی نمایهها، تغییر ترتیب مرتبسازی متن، افت کارایی و حتی اختلال در سرویس باشد. این وضعیت معمولاً با apt upgrade یا unattended-upgrades و همچنین تصاویر کانتینری با برچسبهای غیرثابت رخ میدهد. برای کاهش ریسک، همان نسخه را در staging تست کنید، بستهها را pin/hold کنید، یادداشتهای انتشار Debian و پایگاه داده را بخوانید، پنجره نگهداری در نظر بگیرید، پشتیبان مطمئن بگیرید و قبل/بعد از ارتقا وضعیت collation را بررسی کنید. «ارتقای جزئی» را نیز مانند ارتقای عمده جدی بگیرید تا از تغییر ناخواسته collation جلوگیری شود.
#Debian #Database #Collation #PostgreSQL #MySQL #Apt #Upgrade #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/177311/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
be careful when you do minor version upgrades
🟢 خلاصه مقاله:
** ارتقای نسخههای بهظاهر «جزئی» میتواند در سیستمهای مبتنی بر Debian پیامدهای بزرگی داشته باشد. بهروزرسانی نقطهای Debian ممکن است کتابخانههای مرتبط با locale و collation را تغییر دهد و پایگاه داده شما را به بهروزرسانی collation وادار کند؛ نتیجه میتواند بازسازی نمایهها، تغییر ترتیب مرتبسازی متن، افت کارایی و حتی اختلال در سرویس باشد. این وضعیت معمولاً با apt upgrade یا unattended-upgrades و همچنین تصاویر کانتینری با برچسبهای غیرثابت رخ میدهد. برای کاهش ریسک، همان نسخه را در staging تست کنید، بستهها را pin/hold کنید، یادداشتهای انتشار Debian و پایگاه داده را بخوانید، پنجره نگهداری در نظر بگیرید، پشتیبان مطمئن بگیرید و قبل/بعد از ارتقا وضعیت collation را بررسی کنید. «ارتقای جزئی» را نیز مانند ارتقای عمده جدی بگیرید تا از تغییر ناخواسته collation جلوگیری شود.
#Debian #Database #Collation #PostgreSQL #MySQL #Apt #Upgrade #DevOps
🟣لینک مقاله:
https://postgresweekly.com/link/177311/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Reddit
From the PostgreSQL community on Reddit: Docker's official Postgres image is shipping breaking changes in minor upgrades
Explore this post and more from the PostgreSQL community
❤1
🔵 عنوان مقاله
A PGConf EU 2025 Trip Summary
🟢 خلاصه مقاله:
کنفرانس PGConf EU 2025 دو هفته پیش در Latvia برگزار شد و بهعنوان رویداد اصلی Postgres در اروپا، جمع زیادی از متخصصان و فعالان جامعه را گرد هم آورد. Claire از پادکست Talking Postgres گزارشی مفصل از سفرش منتشر کرده که تجربههای او را هم بهعنوان سخنران و هم نماینده Microsoft پوشش میدهد؛ از روند آمادهسازی و ارائه، پرسشوپاسخهای فنی و گفتوگوهای راهرویی تا تعامل با شرکتها و جامعه متنباز. او در کنار نکات کاربردی درباره برنامهریزی، فضا و ریتم رویداد، به جنبههای اجتماعی و شبکهسازی هم پرداخته است. این گزارش با عکسهای فراوان از محل برگزاری، شرکتکنندگان و حالوهوای شهر همراه است و در نهایت تصویری روشن از وضعیت پویای اکوسیستم Postgres در اروپا ارائه میکند.
#Postgres #PGConfEU #PostgreSQL #Microsoft #Database #OpenSource #Latvia #TechConference
🟣لینک مقاله:
https://postgresweekly.com/link/176679/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A PGConf EU 2025 Trip Summary
🟢 خلاصه مقاله:
کنفرانس PGConf EU 2025 دو هفته پیش در Latvia برگزار شد و بهعنوان رویداد اصلی Postgres در اروپا، جمع زیادی از متخصصان و فعالان جامعه را گرد هم آورد. Claire از پادکست Talking Postgres گزارشی مفصل از سفرش منتشر کرده که تجربههای او را هم بهعنوان سخنران و هم نماینده Microsoft پوشش میدهد؛ از روند آمادهسازی و ارائه، پرسشوپاسخهای فنی و گفتوگوهای راهرویی تا تعامل با شرکتها و جامعه متنباز. او در کنار نکات کاربردی درباره برنامهریزی، فضا و ریتم رویداد، به جنبههای اجتماعی و شبکهسازی هم پرداخته است. این گزارش با عکسهای فراوان از محل برگزاری، شرکتکنندگان و حالوهوای شهر همراه است و در نهایت تصویری روشن از وضعیت پویای اکوسیستم Postgres در اروپا ارائه میکند.
#Postgres #PGConfEU #PostgreSQL #Microsoft #Database #OpenSource #Latvia #TechConference
🟣لینک مقاله:
https://postgresweekly.com/link/176679/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TECHCOMMUNITY.MICROSOFT.COM
Postgres Trip Summary from PGConf EU 2025 (with lots of photos) | Microsoft Community Hub
Overview of my experience as a Postgres speaker, as a Microsoft sponsor, and happy attendee at PGConf EU 2025, with lots of photographs.
❤1
🔵 عنوان مقاله
Updating Passwords Now That MD5 Password Support is Deprecated
🟢 خلاصه مقاله:
با کنار گذاشته شدن پشتیبانی از رمزهای عبور مبتنی بر MD5، لازم است گذار به روشهای امنتر انجام شود؛ کاری روتین و نهچندان هیجانانگیز که به قول Dan Langille اما برای سلامت سیستمها ضروری است. ضعفهای MD5 سالهاست شناخته شدهاند، و بسیاری از پلتفرمها اکنون آن را غیرفعال میکنند. راهکار عملی شامل این مراحل است: شناسایی همه سیستمها و حسابهایی که هنوز MD5 دارند، انتخاب جایگزین مناسب مانند SCRAM-SHA-256 برای پایگاهدادهها یا bcrypt/scrypt/yescrypt/Argon2 برای سیستمعامل و برنامهها، بهروزرسانی پیکربندیها و اطمینان از سازگاری کلاینتها پیش از قطع کامل MD5. برای بازتولید هشها میتوان از ورود بعدی کاربر، مهلت چرخش رمز، یا مهاجرت مرحلهای استفاده کرد؛ حسابهای سرویس نیز نیازمند مدیریت ویژه و هماهنگی انتشار هستند. تست جامع، پایش خطاهای احراز هویت، برنامه بازگشت، و حذف نهایی مسیرهای قدیمی، کلید یک مهاجرت موفقاند. نتیجه هرچند کمزرقوبرق، اما ارتقای واقعی امنیت، کاهش ریسک انطباق، و آیندهپذیری بهتر سامانههای احراز هویت است.
#MD5 #PasswordSecurity #Deprecation #Hashing #Migration #SecurityOps #SCRAM #Argon2 #bcrypt
🟣لینک مقاله:
https://postgresweekly.com/link/177317/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Updating Passwords Now That MD5 Password Support is Deprecated
🟢 خلاصه مقاله:
با کنار گذاشته شدن پشتیبانی از رمزهای عبور مبتنی بر MD5، لازم است گذار به روشهای امنتر انجام شود؛ کاری روتین و نهچندان هیجانانگیز که به قول Dan Langille اما برای سلامت سیستمها ضروری است. ضعفهای MD5 سالهاست شناخته شدهاند، و بسیاری از پلتفرمها اکنون آن را غیرفعال میکنند. راهکار عملی شامل این مراحل است: شناسایی همه سیستمها و حسابهایی که هنوز MD5 دارند، انتخاب جایگزین مناسب مانند SCRAM-SHA-256 برای پایگاهدادهها یا bcrypt/scrypt/yescrypt/Argon2 برای سیستمعامل و برنامهها، بهروزرسانی پیکربندیها و اطمینان از سازگاری کلاینتها پیش از قطع کامل MD5. برای بازتولید هشها میتوان از ورود بعدی کاربر، مهلت چرخش رمز، یا مهاجرت مرحلهای استفاده کرد؛ حسابهای سرویس نیز نیازمند مدیریت ویژه و هماهنگی انتشار هستند. تست جامع، پایش خطاهای احراز هویت، برنامه بازگشت، و حذف نهایی مسیرهای قدیمی، کلید یک مهاجرت موفقاند. نتیجه هرچند کمزرقوبرق، اما ارتقای واقعی امنیت، کاهش ریسک انطباق، و آیندهپذیری بهتر سامانههای احراز هویت است.
#MD5 #PasswordSecurity #Deprecation #Hashing #Migration #SecurityOps #SCRAM #Argon2 #bcrypt
🟣لینک مقاله:
https://postgresweekly.com/link/177317/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
👍2
🔵 عنوان مقاله
State of Containers and Serverless (8 minute read)
🟢 خلاصه مقاله:
روندهای کلیدی در گزارش State of Containers and Serverless از Datadog که بر پایه دادههای هزاران محیط cloud-native تهیه شده، پنج نکته اصلی را نشان میدهد: ۱) استفاده از GPU با سرعت در حال رشد است؛ اکنون حدود ۶٪ از سازمانها از آن بهره میبرند و ساعات اجرای اینستنسها نسبت به دو سال پیش تقریباً سه برابر شده است. ۲) بارهای کاری AI در حال ظهورند و حدود ۷٪ از workloadهای کانتینری را تشکیل میدهند و در کنار پایگاهدادهها و سرویسهای وب اجرا میشوند. ۳) بیشتر کانتینرها کمتر از ۵۰٪ حافظه و کمتر از ۲۵٪ CPU مصرف میکنند که بیانگر افزونتخصیص گسترده و فرصتهای بهینهسازی هزینه از طریق right-sizing و تنظیم بهتر autoscaling است. ۴) بیش از ۶۴٪ از کلاسترهای Kubernetes از Horizontal Pod Autoscaler (HPA) استفاده میکنند، اما تنها ۲۰٪ به آن متریکهای سفارشی اپلیکیشن میدهند؛ تکیه صرف بر CPU/Memory باعث مقیاسپذیری نامتوازن با تقاضای واقعی میشود. ۵) پلتفرمهای مبتنی بر Arm در حال گسترشاند و با قیمت/کارایی و بهرهوری انرژی بهتر جذاب شدهاند، اما به پشتیبانی multi-arch، سازگاری وابستگیها و تنظیم درست CI/CD نیاز دارند. جمعبندی: پذیرش GPU و AI شتاب گرفته، اما برای بهبود کارایی و واکنشپذیری، باید روی right-sizing، متریکهای سفارشی برای HPA و ارزیابی هدفمند Arm تمرکز شود.
#CloudNative #Containers #Kubernetes #Serverless #Datadog #GPU #AI #ARM
🟣لینک مقاله:
https://www.datadoghq.com/state-of-containers-and-serverless/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
State of Containers and Serverless (8 minute read)
🟢 خلاصه مقاله:
روندهای کلیدی در گزارش State of Containers and Serverless از Datadog که بر پایه دادههای هزاران محیط cloud-native تهیه شده، پنج نکته اصلی را نشان میدهد: ۱) استفاده از GPU با سرعت در حال رشد است؛ اکنون حدود ۶٪ از سازمانها از آن بهره میبرند و ساعات اجرای اینستنسها نسبت به دو سال پیش تقریباً سه برابر شده است. ۲) بارهای کاری AI در حال ظهورند و حدود ۷٪ از workloadهای کانتینری را تشکیل میدهند و در کنار پایگاهدادهها و سرویسهای وب اجرا میشوند. ۳) بیشتر کانتینرها کمتر از ۵۰٪ حافظه و کمتر از ۲۵٪ CPU مصرف میکنند که بیانگر افزونتخصیص گسترده و فرصتهای بهینهسازی هزینه از طریق right-sizing و تنظیم بهتر autoscaling است. ۴) بیش از ۶۴٪ از کلاسترهای Kubernetes از Horizontal Pod Autoscaler (HPA) استفاده میکنند، اما تنها ۲۰٪ به آن متریکهای سفارشی اپلیکیشن میدهند؛ تکیه صرف بر CPU/Memory باعث مقیاسپذیری نامتوازن با تقاضای واقعی میشود. ۵) پلتفرمهای مبتنی بر Arm در حال گسترشاند و با قیمت/کارایی و بهرهوری انرژی بهتر جذاب شدهاند، اما به پشتیبانی multi-arch، سازگاری وابستگیها و تنظیم درست CI/CD نیاز دارند. جمعبندی: پذیرش GPU و AI شتاب گرفته، اما برای بهبود کارایی و واکنشپذیری، باید روی right-sizing، متریکهای سفارشی برای HPA و ارزیابی هدفمند Arm تمرکز شود.
#CloudNative #Containers #Kubernetes #Serverless #Datadog #GPU #AI #ARM
🟣لینک مقاله:
https://www.datadoghq.com/state-of-containers-and-serverless/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Datadog
State of Containers and Serverless | Datadog
We analyze cloud compute trends, from containers to serverless to rising GPU and Arm adoption, as organizations seek efficiency and cost control.
🔵 عنوان مقاله
Training a Tokenizer for BERT Models (4 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد چگونه با استفاده از کتابخانههای tokenizers و datasets از Hugging Face یک WordPiece tokenizer اختصاصی برای BERT آموزش دهیم: دادهها با یک iterator بارگذاری میشوند، یک واژگان 30,522 کلمهای همراه با BERT special tokens مانند [PAD]، [UNK]، [CLS]، [SEP] و [MASK] ساخته میشود، و تنظیمات اختیاری مانند lowercase و pre-tokenization اعمال میگردد. سپس برای استفاده عملی، padding و truncation فعال میشود و tokenizer ذخیره و روی نمونهها تست میشود. در مرحلهی آموزش یا fine-tuning مدل BERT، باید همخوانی tokenizer و مدل حفظ شود؛ اگر از یک BERT ازپیشآموزشدادهشده با tokenizer جدید استفاده میکنید، ممکن است نیاز به تغییر اندازهی embeddingها مطابق با واژگان جدید داشته باشید. این روند زمینه را برای پیشپردازش داده و fine-tuning مؤثر فراهم میکند.
#BERT #Tokenizer #WordPiece #HuggingFace #NLP #Tokenization #MachineLearning
🟣لینک مقاله:
https://machinelearningmastery.com/training-a-tokenizer-for-bert-models/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Training a Tokenizer for BERT Models (4 minute read)
🟢 خلاصه مقاله:
این مقاله توضیح میدهد چگونه با استفاده از کتابخانههای tokenizers و datasets از Hugging Face یک WordPiece tokenizer اختصاصی برای BERT آموزش دهیم: دادهها با یک iterator بارگذاری میشوند، یک واژگان 30,522 کلمهای همراه با BERT special tokens مانند [PAD]، [UNK]، [CLS]، [SEP] و [MASK] ساخته میشود، و تنظیمات اختیاری مانند lowercase و pre-tokenization اعمال میگردد. سپس برای استفاده عملی، padding و truncation فعال میشود و tokenizer ذخیره و روی نمونهها تست میشود. در مرحلهی آموزش یا fine-tuning مدل BERT، باید همخوانی tokenizer و مدل حفظ شود؛ اگر از یک BERT ازپیشآموزشدادهشده با tokenizer جدید استفاده میکنید، ممکن است نیاز به تغییر اندازهی embeddingها مطابق با واژگان جدید داشته باشید. این روند زمینه را برای پیشپردازش داده و fine-tuning مؤثر فراهم میکند.
#BERT #Tokenizer #WordPiece #HuggingFace #NLP #Tokenization #MachineLearning
🟣لینک مقاله:
https://machinelearningmastery.com/training-a-tokenizer-for-bert-models/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
PgManage 1.4: Web Tool for Database Management
🟢 خلاصه مقاله:
PgManage 1.4 یک ابزار تحت وب متنباز برای مدیریت پایگاهداده است که با تمرکز بر Postgres طراحی شده اما از MySQL، SQLite و Oracle هم پشتیبانی میکند. این ابزار امکان اتصال و کار همزمان با چند پایگاهداده را فراهم میکند و مرور اشیایی مانند جداول، نماها و توابع را آسان میسازد. اجرای تحت وب و ماهیت متنباز آن، راهاندازی را ساده و استفاده در تیمهای دارای فناوریهای متنوع را عملی و روان میکند.
#PgManage #Postgres #DatabaseManagement #OpenSource #WebTool #MySQL #SQLite #Oracle
🟣لینک مقاله:
https://postgresweekly.com/link/177320/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
PgManage 1.4: Web Tool for Database Management
🟢 خلاصه مقاله:
PgManage 1.4 یک ابزار تحت وب متنباز برای مدیریت پایگاهداده است که با تمرکز بر Postgres طراحی شده اما از MySQL، SQLite و Oracle هم پشتیبانی میکند. این ابزار امکان اتصال و کار همزمان با چند پایگاهداده را فراهم میکند و مرور اشیایی مانند جداول، نماها و توابع را آسان میسازد. اجرای تحت وب و ماهیت متنباز آن، راهاندازی را ساده و استفاده در تیمهای دارای فناوریهای متنوع را عملی و روان میکند.
#PgManage #Postgres #DatabaseManagement #OpenSource #WebTool #MySQL #SQLite #Oracle
🟣لینک مقاله:
https://postgresweekly.com/link/177320/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - commandprompt/pgmanage: Web tool for database management
Web tool for database management. Contribute to commandprompt/pgmanage development by creating an account on GitHub.
Forwarded from AI Labdon
مدل opus 4.5 دیروز اومد. بینظیره. بهترین مدل دنیا برای coding با اختلاف زیاد.
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!
<Amin Anvary/>
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
یک اتفاق مهم دیگه اینکه Anthropic برای اولین بار قیمت بهترین مدل خودش رو به یک سوم تا یک پنجم قیمت قبلی کاهش داده!!
هر میلیون اینپوت از ۲۵ دلار شده ۵ دلار و هر میلیون output هم از ۷۵ دلار شده ۱۵ دلار!
<Amin Anvary/>
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0
❤1👍1🔥1
🔵 عنوان مقاله
A SQL Query's Roadtrip Through Postgres
🟢 خلاصه مقاله:
این مطلب با الهام از توضیحات Jesús Espino و Umair Shahid نشان میدهد یک پرسوجوی SQL در Postgres چگونه از مرحله دریافت و parse، به planنویسی و سپس اجرا میرسد. Postgres با اتکا به optimizer مسیرهای دسترسی مناسب را انتخاب میکند و هنگام اجرا، دادهها را از طریق buffer manager به حافظه میآورد و با MVCC دید سازگار هر تراکنش را تضمین میکند. در مسیر نوشتن، ابتدا تغییرات در WAL ثبت میشوند و صفحات بهروزشده در حافظه به «dirty pages» تبدیل میگردند؛ یعنی نسخه درونحافظهای با نسخه روی دیسک تفاوت دارد. سپس background writer و checkpointer بهتدریج این صفحات را روی دیسک مینویسند تا پایداری داده و بازیابی سریع پس از خطا ممکن شود. تنظیماتی مثل shared_buffers و پارامترهای مربوط به checkpoint و WAL روی تأخیر، توان عملیاتی و الگوی I/O اثر مستقیم دارند. برای توسعهدهندگان، انتخاب شاخصهای مناسب، شکلدهی درست پرسوجوها و پایش با ابزارهایی مانند pg_stat_bgwriter و pg_buffercache به درک فشار نوشتن، نسبت صفحات dirty و کارایی حافظه کمک میکند.
#Postgres #SQL #DatabaseInternals #WAL #DirtyPages #QueryPlanner #Checkpoints #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/176686/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
A SQL Query's Roadtrip Through Postgres
🟢 خلاصه مقاله:
این مطلب با الهام از توضیحات Jesús Espino و Umair Shahid نشان میدهد یک پرسوجوی SQL در Postgres چگونه از مرحله دریافت و parse، به planنویسی و سپس اجرا میرسد. Postgres با اتکا به optimizer مسیرهای دسترسی مناسب را انتخاب میکند و هنگام اجرا، دادهها را از طریق buffer manager به حافظه میآورد و با MVCC دید سازگار هر تراکنش را تضمین میکند. در مسیر نوشتن، ابتدا تغییرات در WAL ثبت میشوند و صفحات بهروزشده در حافظه به «dirty pages» تبدیل میگردند؛ یعنی نسخه درونحافظهای با نسخه روی دیسک تفاوت دارد. سپس background writer و checkpointer بهتدریج این صفحات را روی دیسک مینویسند تا پایداری داده و بازیابی سریع پس از خطا ممکن شود. تنظیماتی مثل shared_buffers و پارامترهای مربوط به checkpoint و WAL روی تأخیر، توان عملیاتی و الگوی I/O اثر مستقیم دارند. برای توسعهدهندگان، انتخاب شاخصهای مناسب، شکلدهی درست پرسوجوها و پایش با ابزارهایی مانند pg_stat_bgwriter و pg_buffercache به درک فشار نوشتن، نسبت صفحات dirty و کارایی حافظه کمک میکند.
#Postgres #SQL #DatabaseInternals #WAL #DirtyPages #QueryPlanner #Checkpoints #Performance
🟣لینک مقاله:
https://postgresweekly.com/link/176686/web
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Internals for interns
A SQL Query's Roadtrip Through Postgres | Internals for interns
Ever wonder what happens when you type SELECT * FROM users WHERE id = 42; and hit Enter? That simple query triggers a fascinating journey through PostgreSQL’s internals—a complex series of operations involving multiple processes, sophisticated memory management…
🔵 عنوان مقاله
TOON (GitHub Repo)
🟢 خلاصه مقاله:
TOON یک جایگزین فشرده و خوانا برای JSON است که با حفظ همان دادهها، از قالب جدولی و تورفتگی استفاده میکند تا LLMها آن را راحتتر و دقیقتر پردازش کنند. این روش در آرایههای یکنواخت از اشیاء با تعریف یک بار کلیدها و نمایش ردیفهای مقدار، معمولاً ۳۰ تا ۶۰ درصد توکن کمتری نسبت به JSON مصرف میکند و خطاهای پرانتز/نقلقول را کاهش میدهد. TOON برای خروجیهای ساختیافته، تبادل داده در زنجیره ابزارهای هوش مصنوعی و مجموعهدادههای تکراری مناسب است و بدون از دستدادن معنا، بهطور قابل اعتماد به JSON رفتوبرگشت میشود.
#TOON #JSON #LLM #DataFormat #TokenEfficiency #PromptEngineering #Parsing #OpenSource
🟣لینک مقاله:
https://github.com/toon-format/toon?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TOON (GitHub Repo)
🟢 خلاصه مقاله:
TOON یک جایگزین فشرده و خوانا برای JSON است که با حفظ همان دادهها، از قالب جدولی و تورفتگی استفاده میکند تا LLMها آن را راحتتر و دقیقتر پردازش کنند. این روش در آرایههای یکنواخت از اشیاء با تعریف یک بار کلیدها و نمایش ردیفهای مقدار، معمولاً ۳۰ تا ۶۰ درصد توکن کمتری نسبت به JSON مصرف میکند و خطاهای پرانتز/نقلقول را کاهش میدهد. TOON برای خروجیهای ساختیافته، تبادل داده در زنجیره ابزارهای هوش مصنوعی و مجموعهدادههای تکراری مناسب است و بدون از دستدادن معنا، بهطور قابل اعتماد به JSON رفتوبرگشت میشود.
#TOON #JSON #LLM #DataFormat #TokenEfficiency #PromptEngineering #Parsing #OpenSource
🟣لینک مقاله:
https://github.com/toon-format/toon?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - toon-format/toon: 🎒 Token-Oriented Object Notation (TOON) – Compact, human-readable, schema-aware JSON for LLM prompts.…
🎒 Token-Oriented Object Notation (TOON) – Compact, human-readable, schema-aware JSON for LLM prompts. Spec, benchmarks, TypeScript SDK. - toon-format/toon
🔵 عنوان مقاله
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.