🔵 عنوان مقاله
We Built an Open Source S3 Tables Alternative (8 minute read)

🟢 خلاصه مقاله:
RisingWave و Lakekeeper یک جایگزین متن‌باز برای S3 Tables ارائه کرده‌اند که با یک دستور، یک پشته کامل و «مدیریت‌شده» از Apache Iceberg را راه‌اندازی می‌کند. این راهکار با ترکیب یک REST catalog، ورود داده مبتنی بر SQL و یک موتور compaction سبک مبتنی بر DataFusion، عملیات را ساده می‌کند و بدون vendor lock-in، با DuckDB، Trino و Spark سازگار است و نیازی به نگه‌داری Spark برای مدیریت جدول‌ها ندارد. پشتیبانی از time travel، طراحی آگاه از پارتیشن و compaction خودکار، تجربه‌ای شبیه پایگاه‌داده از Iceberg می‌سازد، در حالی‌که ماهیت باز و ماژولارِ فرمت جدول حفظ می‌شود.

#ApacheIceberg #S3Tables #OpenSource #Lakehouse #RisingWave #Lakekeeper #DuckDB #Trino #Spark

🟣لینک مقاله:
https://medium.com/@yingjunwu/we-built-an-open-source-s3-tables-alternative-2b3c95ef4b3a?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
The Model Selection Showdown: 6 Considerations for Choosing the Best Model (5 minute read)

🟢 خلاصه مقاله:
انتخاب مدل مناسب در یادگیری ماشین با دنبال‌کردن شش گام عملی نتیجه می‌دهد: هدف را دقیق تعریف کنید و معیار موفقیت را با نیازهای ذینفعان هم‌راستا کنید؛ یک baseline ساده بسازید تا آستانه عملکرد و خطاهای داده روشن شوند؛ معیارهای سنجش را متناسب با مسئله و عدم‌توازن داده‌ها انتخاب کنید؛ با cross-validation درست (از جمله زمان‌محور برای سری‌های زمانی) برآورد تعمیم‌پذیری را مطمئن کنید و از نشت اطلاعات جلوگیری کنید؛ بین پیچیدگی و قابلیت تفسیر تعادل برقرار کنید و هزینه استقرار/نگه‌داری را بسنجید؛ و در نهایت، با داده‌های واقعی از طریق تست برون‌زمانی، A/B یا استقرار سایه اعتبارسنجی کنید و پایش مستمرِ رانش و کالیبراسیون داشته باشید. بهترین مدل لزوماً جدیدترین الگوریتم نیست، بلکه مدلی است که با مسئله، داده و نیاز کسب‌وکار بیشترین انطباق را دارد.

#ModelSelection #MachineLearning #DataScience #Metrics #CrossValidation #Interpretability #MLOps

🟣لینک مقاله:
https://machinelearningmastery.com/the-model-selection-showdown-6-considerations-for-choosing-the-best-model/?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Key Operational Enhancements and Integration Options in Postgres 16

🟢 خلاصه مقاله:
این مطلب با تمرکز بر مخاطبان Golang Weekly توضیح می‌دهد که Postgres 16 چه بهبودهایی برای عملیات روزمره و یکپارچه‌سازی با سرویس‌ها آورده است. نویسنده روی حوزه‌های عملی مثل کارایی پایدارتر تحت بار، رفتار بهتر autovacuum، و رصدپذیری دقیق‌تر برای IO و پردازه‌های پس‌زمینه تأکید می‌کند تا تنظیمات و عیب‌یابی سریع‌تر و مطمئن‌تر انجام شود. همچنین به ارتقاهای مرتبط با replication منطقی و سنک‌کردن ایمن‌تر، مدیریت slotها و سناریوهای failover اشاره می‌کند تا پیاده‌سازی‌های HA و چندمنطقه‌ای ساده‌تر شوند. در بخش یکپارچه‌سازی، گزینه‌های Go مانند pgx و database/sql، مدیریت connection pooling با pgxpool یا PgBouncer، اتصال به سامانه‌های رویدادمحور از طریق logical decoding و ابزارهایی مثل Debezium، و الگوهای LISTEN/NOTIFY و FDW مرور می‌شود. جمع‌بندی مقاله: Postgres 16 دردسرهای عملیاتی را کمتر و ادغام با معماری‌های متنوع را ساده‌تر می‌کند و یک چک‌لیست کوتاه برای ارزیابی و ارتقای امن ارائه می‌دهد.

#Postgres16 #PostgreSQL #Golang #Go #Database #Replication #Observability #Performance

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
memoize planner estimates in EXPLAIN.

🟢 خلاصه مقاله:
**
این مطلب که در شماره اخیر Golang Weekly معرفی شده، درباره memoize کردن برآوردهای planner در EXPLAIN است تا تحلیل پرس‌وجوها سریع‌تر و قابل‌اتکاتر شود. ایده اصلی این است که تخمین‌های میانی (مثل cardinality و هزینه‌ها) بر اساس نسخه نرمال‌شده‌ی بخش‌های پرس‌وجو و ورودی‌های اثرگذار (آمار جداول، وضعیت schema، و تنظیمات planner) ذخیره شوند و در اجرای‌های بعدی EXPLAIN دوباره استفاده شوند. نتیجه: کاهش هزینه محاسبات تکراری، ثبات بیشتر خروجی‌ها، و مقایسه آسان‌تر تغییرات.

در پیاده‌سازی با Go می‌توان با cacheهای سبک، هش‌کردن پرس‌وجوی نرمال‌شده و وضعیت کاتالوگ، و قلاب‌های ابطال (invalidation) قابل‌تنظیم به این هدف رسید؛ این رویکرد برای ابزارهای توسعه، CI و بنچمارک‌ها سودمند است. البته چالش‌ها هم مهم‌اند: کهنگی داده‌های cache با تغییر آمار یا تنظیمات، ضرورت سیاست‌های ابطال شفاف، ترجیحاً cache کردن فقط برآوردها (نه کل plan)، ارائه نشانگرهای hit/miss در خروجی EXPLAIN، و تعیین دامنه و سقف اندازه cache (مثلاً در سطح session).

به طور خلاصه، memoize کردن برآوردهای planner در EXPLAIN چرخه‌های تحلیل را تسریع و نتایج را پایدارتر می‌کند، به شرط آنکه مرزهای cache و سیاست‌های ابطال به‌خوبی مدیریت شوند.

#Golang #Go #EXPLAIN #Database #QueryPlanner #Memoization #Performance #Optimization

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

♨️ چین شمشیر رو برای بلاگرها از رو بست ؛ اینفلوئنسر ها باید مدرک تحصصی بگیرن!

▪️طبق قانون جدیدی که دولت چین تصویب کرده، از این به بعد هرکسی بخواد تو حوزه‌هایی مثل پزشکی، اقتصاد، حقوق یا آموزش ، محتوا تولید کنه باید مدرک دانشگاهی معتبر یا گواهی حرفه‌ای رسمی داشته باشه ؛ وگرنه ۱۴ هزار دلار جریمه میشه!

▪️پلتفرم‌هایی مثل Douyin، Weibo و Bilibili هم موظفن مدارک بلاگرها رو بررسی کنن و اگه کسی بدون صلاحیت سراغ این موضوعات بره، حسابش بسته میشه یا جریمه میخوره.

+ دولت چین میگه هدفش جلوگیری از «اطلاعات گمراه‌کننده» است، اما خیلیا معتقدن این یه حرکت برای کنترل شدیدتر فضای مجازی و ساکت کردن صدای منتقدهاست.

روز بزرگداشت کوروش بزرگ، شاه شاهان
بر همه‌ی ایرانیان گرامی و دوست‌داران تاریخ ایران‌زمین خجسته باد 🌞

به مناسبت این روز پرافتخار،❤️ ۶۰٪ تخفیف ویژه روی تمام تعرفه‌ها فقط تا ۱۰ آبان!

برای تبلیغات و همکاری:
📩 @mrbardia72

🛡 فرصت رو از دست نده، این تخفیف فقط سه روز فعاله!
💚🤍❤️

https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0

🔵 عنوان مقاله
Exploring Postgres 18's New UUIDv7 Support

🟢 خلاصه مقاله:
** پشتیبانی از UUIDv7 در Postgres 18 شناسه‌هایی یکتا، زمان‌مرتب و تقریباً یکنوا ایجاد می‌کند که بر خلاف UUIDv4، بر اساس زمان به‌صورت واژگانی مرتب می‌شوند. این ویژگی باعث بهبود محلیّت در ایندکس‌های B-tree، کاهش شکافت صفحات و بهبود کارایی درج‌های پیاپی می‌شود و کوئری‌هایی مثل ORDER BY id DESC با LIMIT و محدوده‌های زمانی را ساده‌تر و سریع‌تر می‌کند. در عین حال، به‌دلیل ترکیب زمان و تصادفی‌بودن، خطر نقاط داغ کاهش می‌یابد، هرچند در بارگذاری‌های بسیار همزمان باید پایش شود و پایداری ساعت سیستم اهمیت دارد. مهاجرت از UUIDv4 آسان است؛ می‌توان مقادیر قدیمی را حفظ کرد و تولید پیش‌فرض را برای رکوردهای جدید به UUIDv7 تغییر داد. برای اغلب لاگ‌های رویداد و بارهای شبه‌زمان‌محور، UUIDv7 توازن خوبی میان یکتایی، کارایی و سادگی کوئری فراهم می‌کند.

#Postgres #PostgreSQL #UUIDv7 #UUID #Database #Performance #Indexing #TimeSeries

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
PostGIS Performance: pg_stat_statements and Postgres Tuning

🟢 خلاصه مقاله:
**این مقاله نشان می‌دهد چطور با استفاده از PostGIS روی Postgres می‌توان کارایی پرس‌وجوهای مکانی را بهبود داد. محور اصلی کار، اندازه‌گیری دقیق با pg_stat_statements برای شناسایی پرهزینه‌ترین پرس‌وجوها و سپس تحلیل آن‌ها با EXPLAIN/ANALYZE است. توصیه‌های کلیدی شامل انتخاب درست geometry یا geography، ساخت ایندکس‌های GiST/SP-GiST، نوشتن شرط‌های قابل استفاده توسط ایندکس (مثل ST_Intersects و محدوده‌های جعبه‌ای)، و اجرای VACUUM/ANALYZE پس از بارگذاری‌های حجیم است. در بخش تنظیمات Postgres هم به shared_buffers، effective_cache_size، work_mem، موازی‌سازی، تنظیمات autovacuum و در صورت نیاز پارتیشن‌بندی اشاره می‌شود. برای سرویس‌های Go (به نقل از Golang Weekly)، استفاده از pooling مناسب، جلوگیری از الگوهای N+1، Batch کردن عملیات، بهره‌گیری از COPY و تعیین statement_timeout توصیه شده است. رویکرد کلی: اندازه‌گیری، اعمال تغییرات هدفمند، و اعتبارسنجی مداوم برای رسیدن به کارایی پایدار و سریع‌تر.

#PostGIS #PostgreSQL #pg_stat_statements #DatabaseTuning #Geospatial #Golang #Performance #SQL

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Postgres 18: OLD and NEW Rows in the RETURNING Clause

🟢 خلاصه مقاله:
Postgres 18 با تمرکز بر سه حوزه پیش می‌رود: ارگونومی توسعه، قابلیت مشاهده، و بارگذاری داده. پشتیبانی از ارجاع به ردیف‌های OLD و NEW در RETURNING باعث می‌شود نسخه‌های قبل و بعد از تغییر را در همان دستور SQL بگیرید؛ این کار لاگ‌برداری، ثبت تغییرات و منطق حل تعارض را ساده‌تر و کم‌هزینه‌تر می‌کند. بهبودهای COPY—به روایت Brandur Leach—کار با ورودی/خروجی‌های حجیم را خوش‌دست‌تر می‌کند و با پیام‌های واضح‌تر و پیش‌فرض‌های امن‌تر، خطاهای رایج را کم می‌کند. در سطح پایش، Deepak Mahto و Cédric Villemain به ارتقاهای Cumulative Statistics می‌پردازند که با شمارنده‌های منسجم‌تر و سربار کمتر، عیب‌یابی و تنظیم عملکرد را آسان‌تر می‌سازد. حاصل این تغییرات، ترکیبی از تجربه توسعه‌دهنده بهتر و بینش عملیاتی عمیق‌تر در Postgres 18 است.

#Postgres18 #PostgreSQL #RETURNING #COPY #SQL #Database #CumulativeStatistics #OpenSource

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Pipelining Comes to psql in Postgres 18

🟢 خلاصه مقاله:
** در Postgres 18، ابزار psql فرمان‌های داخلی برای فعال‌سازی و کنترل pipelining در اسکریپت‌های SQL اضافه کرده است. با این قابلیت، چندین کوئری پشت‌سرهم ارسال می‌شوند و منتظر پاسخ تک‌به‌تک نمی‌مانند؛ در نتیجه رفت‌وبرگشت‌های شبکه کمتر و زمان اجرا کوتاه‌تر می‌شود. به‌گفته Daniel، این کار می‌تواند بهره‌وری و throughput کوئری‌ها را به‌طور چشمگیری افزایش دهد، به‌ویژه در اسکریپت‌های پر از دستورات کوچک.

این ویژگی برای کارهای حجیم و خودکار مانند بارگذاری داده، پردازش‌های ETL، تحلیل‌ها و مهاجرت‌های اسکیما بسیار مفید است. می‌توان pipelining را فقط در بخش‌های مناسب یک اسکریپت فعال کرد و برای اطمینان از سازگاری و بازگردانی، مرزبندی تراکنش‌ها و مدیریت خطا را دقیق انجام داد. در صورت عدم استفاده، رفتار psql مانند قبل باقی می‌ماند و با سایر تکنیک‌های بهینه‌سازی سرور تکمیل می‌شود، نه اینکه جایگزین آن‌ها باشد.

#Postgres
#psql
#Pipelining
#SQL
#DatabasePerformance
#PostgreSQL18
#Throughput
#ETL

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
Building a Scalable Data Warehouse Backup System with AWS (6 minute read)

🟢 خلاصه مقاله:
اسکریبد یک سامانه پشتیبان‌گیری مقیاس‌پذیر برای انبارهای داده مبتنی بر S3 در مقیاس پتابایت ساخته است که چندین پایگاه‌داده را پوشش می‌دهد. این راهکار با رویکرد ترکیبی از AWS Lambda برای بارهای کوچک و ECS Fargate برای بارهای بزرگ، پشتیبان‌گیری ماهانه و افزایشی انجام می‌دهد؛ به این صورت که فقط فایل‌های Parquet جدید یا تغییرکرده کپی می‌شوند و در عین حال delta logs همیشه نگه داشته می‌شوند تا امکان بازسازی حالت‌ها وجود داشته باشد. اعتبارسنجی داده‌ها با تکیه بر S3 Inventory manifests انجام می‌شود و پردازش‌ها به‌صورت موازی برای افزایش کارایی اجرا می‌گردند. در پایان، نسخه‌های پشتیبان برای نگه‌داری بلندمدت در Glacier بایگانی می‌شوند.

#AWS #S3 #DataWarehouse #Backup #ECSFargate #Lambda #Parquet #Glacier

🟣لینک مقاله:
https://tech.scribd.com/blog/2025/building-scalable-data-warehouse-backup-system.html?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
SQL Shader (Tool)

🟢 خلاصه مقاله:
SQL Shader ابزاری مرورگری بر پایه DuckDB-WASM است که کوئری‌های SQL را به گرافیک‌های رویه‌ایِ بلادرنگ تبدیل می‌کند تا رفتار و کارایی موتور پایگاه‌داده را به‌صورت بصری کاوش و درک کنید. همه‌چیز به‌صورت محلی در مرورگر اجرا می‌شود، بدون نیاز به سرور و با حفظ حریم خصوصی. با تغییر کوئری‌ها—مثل فیلترها، نوع join یا اندازه داده—نمایش‌های بصری فوراً تغییر می‌کنند و شاخص‌هایی مانند زمان اجرا، تعداد ردیف‌ها یا الگوی عملگرها را به شکل قابل مشاهده نشان می‌دهند. این ابزار برای آموزش مفاهیم پایگاه‌داده، نمایش تعاملی عملکرد، و آزمایش سریع رفتار کوئری‌ها بسیار کاربردی است.

#SQL #DuckDB #WASM #WebAssembly #DataVisualization #DatabasePerformance #BrowserTools #SQLShader

🟣لینک مقاله:
https://dmkskd.github.io/sql-shader/?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🚀 به دنیای توسعه و تکنولوژی خوش اومدی!

اگر به موضوعات زیر علاقه‌مندی:

🔹 Golang
🔹 Linux & DevOps
🔹 Software Engineering
🔹 AI & Machine Learning
🔹 فرصت‌های شغلی ریموت (خارجی و داخلی)

ما برات یه مجموعه کانال‌های تخصصی ساختیم تا همیشه به‌روز، حرفه‌ای و الهام‌بخش بمونی!
📚 یادگیری، فرصت، شبکه‌سازی و پیشرفت، همش اینجاست...

📌 از این لینک همه چنل‌هامونو یه‌جا ببین و جوین شو:

👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0

با دو سال سابقه کار
حتی با اینکه کاراموز شرکت امازون هم بوده

شامل layoff اخیر شده و بیکار شده

متأسفانه ai خیلی قوی تر شده

و تهدید محسوب میشه

👋 درود به همه دوستان عزیز

📌 اگر شما هم مقاله، مطلب آموزشی یا هر چیزی که فکر می‌کنید درباره انواع دیتابیس ها می‌تونه مفید باشه دارید، خوشحال میشم برام بفرستید تا با اسم خودتون توی کانال منتشر کنم.

🤝 اینطوری هم به بقیه کمک می‌کنید و هم محتوای ارزشمندتون بیشتر دیده میشه.
@mrbardia72

درود به همه‌ی دوستان عزیز 🌿

اگر پیشنهاد یا انتقادی دارید که می‌تونه به بهتر شدن کانال‌ها ی زیر کمک کنه،
👉 https://news.1rj.ru/str/addlist/AJ7rh2IzIh02NTI0

خیلی خوشحال می‌شم نظرتون رو بدونم و ازش استفاده کنم 🙌

می‌تونید از طریق آی‌دی زیر با من در تماس باشید:

📩 @mrbardia72


منتظر نظرات خوب و سازنده‌تون هستم 💬
💚🤍❤️

مقایسه PostgreSQL در برابر MySQL — رقابتی میان دقت و سادگی

در تصویر اول، ستونی از نوع JSONB به همراه ایندکس GIN به جدول کاربران در پایگاه‌داده‌ی PostgreSQL اضافه شده است.
در تصویر دوم، اجرای یک کوئری بر روی ۵۰٬۰۰۰ رکورد در PostgreSQL حدود ۷ برابر سریع‌تر از MySQL انجام شد.

در اکوسیستم پایگاه‌داده‌های رابطه‌ای این دو نام بیش از همه در کانون توجه‌اند، هر دو از ستون‌های اصلی دنیای متن‌باز به شمار می‌آیند، اما فلسفه‌ی طراحی و نوع نگاهشان به داده، دو مسیر کاملاً متفاوت را دنبال می‌کند.

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

کارایی و الگوی مصرف
معمولاً در بارهای کاری سبک‌تر و اپلیکیشن‌های مبتنی بر خواندن زیاد MySQL عملکرد بهتری نشان می‌دهد.
ساختار ساده‌تر و تنظیمات ابتدایی بهینه‌اش باعث می‌شود برای استارتاپ‌ها، MVPها و پروژه‌های با معماری ساده انتخابی طبیعی باشد.
در سوی دیگر، PostgreSQL در سناریوهای تحلیلی، تراکنش‌های پیچیده و Queryهای چندلایه قدرت واقعی خود را نشان می‌دهد.
پشتیبانی از قابلیت‌هایی مانند CTE، Window Function و نوع داده‌ی JSONB آن را به گزینه‌ای ایده‌آل برای سیستم‌های داده‌محور تبدیل کرده است.

قابلیت گسترش و انعطاف‌پذیری فنی
پستگرس‌کیوال فراتر از یک دیتابیس کلاسیک عمل می‌کند.
تعریف نوع داده‌ی سفارشی، توابع دلخواه و حتی افزونه‌نویسی درون خود موتور، آن را به بستری برای طراحی معماری‌های داده‌ای پیچیده بدل کرده است.
در مقابل، MySQL ساده‌تر و مینیمال‌تر است — رویکردی که هم نقطه‌ی قوت است و هم محدودیت.

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


@<Babak Mirhosseini/>

🔵 عنوان مقاله
How We Scaled Raw GROUP BY to 100 B+ Rows In Under A Second (30 minute read)

🟢 خلاصه مقاله:
کلیک‌هاوس با معرفی قابلیت Parallel Replicas نشان می‌دهد چگونه می‌توان اجرای پرس‌وجوهای GROUP BY را به‌صورت افقی و بدون تغییر در چیدمان داده‌ها مقیاس داد؛ به‌گونه‌ای که تجمیع بیش از ۱۰۰ میلیارد ردیف در کمتر از یک ثانیه ممکن شود. در این روش، کار یک پرس‌وجوی واحد میان همه‌ی Replicaهای یک Shard تقسیم می‌شود، هر Replica بخشی از داده را می‌خواند و تجمیع‌های جزئی را می‌سازد، و در پایان نتایج به‌صورت قطعی با هم ادغام می‌شوند.

این رویکرد، بدون نیاز به Re-sharding، از Replicaها برای موازی‌سازی Query استفاده می‌کند، با SQL استاندارد سازگار است، و تأخیر انتهایی را برای داشبوردها و تحلیل‌های تعاملی کاهش می‌دهد. به‌دلیل سهم بالای GROUP BY در پرس‌وجوهای BI و رشد بارهای observability و AI analytics، Parallel Replicas راهی عملی برای مقیاس‌پذیری تقریباً نامحدود فراهم می‌کند و نمونه‌ی ۱۰۰B+ ردیف در <۱ ثانیه نشان می‌دهد که استفاده از Replicaها به‌عنوان ظرفیت محاسباتی موازی چه جهشی در کارایی ایجاد می‌کند.

#ClickHouse #ParallelReplicas #GROUPBY #Scalability #BigData #Analytics #OLAP #RealTime

🟣لینک مقاله:
https://clickhouse.com/blog/clickhouse-parallel-replicas?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
its Call for Proposals is open

🟢 خلاصه مقاله:
** آخرین شماره Golang Weekly اعلام کرده که بخش Call for Proposals برای یک رویداد/ابتکار مرتبط با جامعه Go باز شده است. از اعضای جامعه دعوت می‌شود ایده‌های خود را در قالب سخنرانی، ورکشاپ، لایتنینگ‌تاک و پنل ارسال کنند؛ موضوعات پیشنهادی شامل بهینه‌سازی کارایی، الگوهای هم‌روندی، ابزارها و فریم‌ورک‌ها، سرویس‌های cloud-native با Go، تست و observability، و مطالعات موردی تولیدی است. برای یک پیشنهاد قوی، خلاصه‌ای شفاف با مسئله، مخاطب هدف و دستاوردهای مشخص ارائه کنید؛ نمونه کد یا دمو کمک‌کننده است، و از سخنرانان تازه‌کار نیز استقبال می‌شود. برای جزئیات، زمان‌بندی و لینک ارسال، به شماره اخیر Golang Weekly مراجعه کنید و زودتر ارسال کنید.

#Golang #GolangWeekly #CFP #CallForProposals #GoCommunity #TechTalks #SoftwareEngineering

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

➖➖➖➖➖➖➖➖
👑 @Database_Academy

🔵 عنوان مقاله
The Feature We Were Afraid to Talk About (7 minute read)

🟢 خلاصه مقاله:
dltHub با صراحت توضیح می‌دهد که اتکای کامل به LLM برای ساخت خودکار data scaffold از روی مستندات، در عمل برای محیط‌های تولیدی قابل اعتماد نبود. نسخه اول، اسکَفولدها را مستقیم با LLM می‌ساخت و در ظاهر عالی بود، اما خطاهای ظریف و «توهمات» باعث شکست پایپ‌لاین‌ها و اتلاف زمان دیباگ می‌شد. در v2 رویکرد برعکس شد: ابتدا با پارسرها و اعتبارسنج‌های قطعی، حقایق قابل راستی‌آزمایی (مثل endpointها، schemaها، روش‌های احراز هویت و قواعد pagination) استخراج و تثبیت می‌شوند؛ سپس LLM فقط برای ظرایف معنایی وارد می‌شود—برای رفع ابهام‌ها، نام‌گذاری بهتر یا پیشنهاد تبدیل‌های سبک—آن هم با ارجاع شفاف به منبع تا قابلیت رهگیری و اصلاح حفظ شود. نتیجه، کاهش خطا و افزایش قابلیت بازتولید و دیباگ‌پذیری است؛ LLM ارزش افزوده می‌دهد اما موتور تصمیم قطعی نیست. درس کلیدی: در داده‌های تولیدی، باید LLM را با ریل‌های ایمنی، استخراج قطعی و اعتبارسنجی احاطه کرد، نه اینکه همه چیز را به آن سپرد.

#LLM #DataEngineering #MLOps #AI #ProductionReliability #DeterministicParsing #DataPipelines #dltHub

🟣لینک مقاله:
https://dlthub.com/blog/improving_generation_baseline?utm_source=tldrdata

➖➖➖➖➖➖➖➖
👑 @Database_Academy