Database Labdon – Telegram
Database Labdon
834 subscribers
33 photos
3 videos
1 file
817 links
🕸 Database Academy

حمایت مالی:
https://www.coffeete.ir/mrbardia72

ادمین:
@mrbardia72
Download Telegram
🔵 عنوان مقاله
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
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
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
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
👍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
🔵 عنوان مقاله
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
Forwarded from AI Labdon
مدل opus 4.5 دیروز اومد. بینظیره. بهترین مدل دنیا برای coding با اختلاف زیاد.
یک اتفاق مهم دیگه اینکه 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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
🔵 عنوان مقاله
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
یه تله‌ی بزرگ که پروژه‌ها و اغلب برنامه‌‌نویس‌های بکند توش میوفتن، اینه که برای حل یه مشکل، سعی می‌کنن یه مشکل جدید ایجاد کنن.

دیتابیس همیشه Source of Truth هستش، و اضافه کردن لایه‌ی کش، می‌تونه بعضی مواقع ریسک stale شدن دیتا رو ایجاد کنه. چون مثلا ممکنه در لحظه‌ی آپدیت کش، ردیس خطا بده و ...

به نظر من کش زمانی باید به پروژه اضافه بشه که سیستم، زیر بار دیگه جواب‌گوی تعداد ریکوئست‌ها نباشه و latency به اندازه‌ی خوبی بالا رفته باشه. اندازه‌گیری این تاخیر هم، یه عدد ثابت نداره. باید در یک بازه‌ی زمانی محاسبه بشه.

اگه احساس بر اینه که کوئری‌ها سنگین هستن و باید کش اضافه بشه، میتونه چند تا احتمال وجود داشته باشه:
۱- نورمالیزیشن درست انجام نشده
۲- دومین درست تعریف نشده
۳- کوئری‌ها بهینه نیستند (ممکنه بجای گرفتن لیستی از رکورد‌ها، یکی یکی واکشی می‌شن)

@ | <آرش | Arash/>
👍3
Forwarded from AI Labdon
قابلیتِ جالبِ Gemini 3 که با Banana Pro میسر هست !

مثلا اگر یک ویدئو آموزشی ۲۰ دقیقه ای یوتیوب دارید و وقت ندارید کامل ببینید و میخواید خلاصه ش رو به صورت یک پوستر گرافیکی ( اینفوگرافیک ) داشته باشید !

آموزش نحوه استفاده از این قابلیت :

۱ لینک ویدئو یوتیوب رو Copy میکنید .

۲ وارد Gemini میشید .

۳ لینک کپی شده رو Paste میکنید و ازش بخواید که ویدئو رو آنالیز و بررسی کنه .

۴ بعد از اینکه بررسی کرد ، حالا این پرامپت وارد کنید !

Prompt :  Generate an image of an infographic explaining the concept presented in the video.
3
چهار استراتژی کلیدی برای مقیاس‌پذیری مؤثر پایگاه داده

با رشد سیستم‌ها و افزایش تعداد کاربران، پایگاه داده به یکی از حساس‌ترین و چالش‌برانگیزترین بخش‌های معماری نرم‌افزار تبدیل می‌شود. انتخاب رویکرد مناسب برای مقیاس‌پذیری، نقش مهمی در حفظ کارایی، پایداری و در دسترس‌پذیری سرویس دارد. در این مقاله، چهار استراتژی رایج و اثربخش برای مقیاس‌پذیری پایگاه داده را بررسی می‌کنیم.

۱) استراتژی Vertical Scaling (افزایش ظرفیت سخت‌افزاری)
ساده‌ترین روش برای افزایش توان پردازشی پایگاه داده، ارتقای منابع سخت‌افزاری نظیر CPU، RAM و فضای ذخیره‌سازی است.
این رویکرد بدون نیاز به تغییرات ساختاری در نرم‌افزار انجام می‌شود و در بسیاری از سیستم‌ها، اولین گام منطقی برای افزایش ظرفیت به شمار می‌آید.
با این حال، Vertical Scaling دارای محدودیت ذاتی است و نهایتاً تا سقف مشخصی قابل افزایش است.

۲) استراتژی Replication (توزیع بار خواندن)
در Replication با ایجاد نسخه‌های متعدد از داده، امکان توزیع بار خواندن بین چندین نود را فراهم می‌سازد.
در این مدل:
عملیات نوشتن تنها به یک نود Leader ارسال می‌شود، Leader تغییرات را به نودهای Follower منتقل می‌کند، عملیات خواندن می‌تواند توسط هر یک از نودهای Leader یا Follower انجام شود.
هدف اصلی این روش افزایش ظرفیت Read و بهبود کارایی سامانه در مواجهه با تعداد زیاد درخواست‌های خواندن است.

۳) استراتژی Caching (افزایش سرعت با ذخیره‌سازی موقت)
استفاده از Cache، از تکرار درخواست‌های غیرضروری به پایگاه داده جلوگیری می‌کند.
در این رویکرد، نخستین درخواست داده را از پایگاه داده دریافت کرده و نتیجه آن در Cache ذخیره می‌شود.
درخواست‌های بعدی، در صورت وجود داده در Cache، به‌سرعت پاسخ داده می‌شوند.
این روش علاوه بر کاهش بار پایگاه داده، به‌طور چشمگیری سرعت پاسخ‌گویی را نیز افزایش می‌دهد.

۴) استراتژی Partitioning / Sharding (مقیاس‌پذیری افقی برای مدیریت بار نوشتن)
استراتژی Sharding با تقسیم داده به بخش‌های مستقل (Partitions یا Shards) و توزیع آن‌ها در چندین سرور، امکان افزایش ظرفیت‌پذیری عملیات نوشتن را فراهم می‌کند.
در این مدل:
هر شارد بخشی از داده را مدیریت می‌کند،
هر درخواست نوشتن تنها به شارد مربوطه ارسال می‌شود،
بار نوشتن میان چندین ماشین تقسیم می‌گردد.
این رویکرد برای سامانه‌هایی که حجم عملیات نوشتن آن‌ها بالا است، روشی پایدار و قابل اعتماد به حساب می‌آید.

ارتباط Replication و Sharding
در معماری‌های بزرگ، Sharding و Replication معمولاً به‌صورت ترکیبی مورد استفاده قرار می‌گیرند.
هر شارد روی چندین نود Replicate می‌شود تا در صورت خرابی یک نود، دسترس‌پذیری داده حفظ گردد.

جمع‌بندی
چهار روش Vertical Scaling، Replication، Caching و Sharding، ستون‌های اصلی مقیاس‌پذیری پایگاه داده در معماری‌های مدرن محسوب می‌شوند.
انتخاب مناسب میان این روش‌ها به نیازهای عملکردی، حجم داده، الگوی دسترسی و محدودیت‌های معماری هر سیستم بستگی دارد.
به‌کارگیری درست و ترکیبی این استراتژی‌ها، امکان ساخت سامانه‌هایی پایدار، سریع و قابل‌اتکا را فراهم می‌کند.


@ | <Amir Rahimi Nejad/>
1
Forwarded from Future Pulse Persian
♨️ با احترام به تمام پزشکان، امروز میخوام یه هوش مصنوعی پزشک معرفی کنم.

▪️همه ما ممکنه روزانه سوالات پزشکی رو در مورد علائم یا حال ناخوش خودمون یا اطرافیانمون داشته باشیم. چی میشد اگه یه هوش مصنوعی وجود داشت که به آخرین اطلاعات علم پزشکی هم دسترسی داشت و میشد ازش مشورت گرفت؟

👩‍⚕️داکوس در کنار شماست ؛)

▪️یک پلتفرم سلامت هوشمنده که از یه چت بات برای تولید گزارشهای سلامت شخصی‌سازی‌شده متناسب با هر فرد استفاده میکنه.
▪️کاربرها میتونن با چت بات گفتگو کنن و یه گزارش سلامت تولید کنن یا احتمال انواع ابتلا به بیماری رو شناسایی کنن. 

+ اینم بگم که شما فقط اجازه ارسال و دریافت تا 7 پیغام رو به صورت رایگان و روزانه دارید و برای ادامه استفاده باید اشتراک ماهانه تهیه کرد. 👇👇

▫️http://docus.ai
Forwarded from Future Pulse Persian
Media is too big
VIEW IN TELEGRAM
بلک‌فرایدی تبدیل شد به یک بازی کثیف؛ قیمت‌ها قبلش باد شد، امید کاذب ساختند، مردم رو ساعت‌ها پشت گوشی نگه داشتند که شاید «محصول ۲۰۰ میلیونی رو با ۹۰٪ تخفیف» بگیرن.

اینفلوئنسرهایی که با اعتماد همین مردم مشهور شدند، برای چندصد میلیون، هیزم آتیش فریب شدند.
فروشگاه‌هایی که به‌جای بازاریابی علمی، دروغ و تکنیک زرد رو انتخاب کردند.

نتیجه؟
نه «اعتبار برند» ساختید، نه «وفاداری مشتری»… فقط یک کوله‌بار نفرت روی دوش مردم گذاشتید.
اینا تخفیف نبود؛ یک توهین به شعور عمومی بود.
به امید روزی که هرجا چیزی «مفت» دیدیم، کورکورانه نپریم توش.

#بلک_فرایدی #فریب_تخفیف #تکنوکسب #بازاریابی #مردم #ایران
1👍1🔥1
🔵 عنوان مقاله
PostGIS Performance: Intersection Predicates and Overlays

🟢 خلاصه مقاله:
خلاصه‌ای از یک نوشته در ادامهٔ مجموعه‌ای برای بهبود کارایی PostGIS است که بر دو بخش کلیدی تمرکز دارد: «intersection predicates» مثل ST_Intersects، ST_Touches و ST_Contains و «overlay»ها مثل ST_Intersection و ST_Union. راهبرد اصلی این است: ابتدا با فیلتر سریع جعبه‌محیطی (&& روی ایندکس GiST) تعداد کاندیداها را کم کنید و سپس رابطهٔ دقیق را با GEOS بررسی کنید. برای پرس‌وجوهای معمول، ساده‌ترین predicate که نیازتان را پوشش می‌دهد انتخاب شود؛ از ST_Intersects برای joinهای اولیه استفاده و در صورت نیاز دقیق‌تر کنید. عملیات overlay چون هندسهٔ جدید می‌سازند، پرهزینه‌اند؛ فقط وقتی واقعاً خروجی هندسی لازم است سراغشان بروید و برای ادغام‌های بزرگ ST_UnaryUnion را ترجیح دهید. برای هندسه‌های حجیم از ST_Subdivide و در صورت امکان از کاهش جزئیات با ST_SimplifyPreserveTopology یا ST_SnapToGrid بهره ببرید. همچنین: ایندکس GiST بسازید، فیلترهای صفتی را زود اعمال کنید، از اعمال توابع روی ستون هندسی در WHERE که جلوی استفاده از ایندکس را می‌گیرد پرهیز کنید، و با EXPLAIN صحت استفاده از ایندکس و برآوردها را بررسی کنید. نتیجهٔ عملی: انتخاب predicate مناسب، اجتناب از overlay غیرضروری، و نگه‌داشتن هندسه‌ها و ایندکس‌ها در وضعیتی سازگار با برنامه‌ریز، کارایی پایدار PostgreSQL/PostGIS را تضمین می‌کند.

#PostGIS #PostgreSQL #GIS #GEOS #SpatialIndex #ST_Intersects #Geospatial #Performance

🟣لینک مقاله:
https://postgresweekly.com/link/177315/web


👑 @Database_Academy