🔵 عنوان مقاله
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.
🔵 عنوان مقاله
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.❤3