🔵 عنوان مقاله
Data lessons from inside Meta (Shridhar Iyer) (12 minute read)
🟢 خلاصه مقاله:
امپراتوری دادههای متا به سمت اتحاد و سازماندهی بهتر حرکت کرده است. پلتفرم دادههای این شرکت اکنون به یک ساختار منسجم و قوی تبدیل شده است که شامل لایههای متعددی مانند کاتالوگ متمرکز، طبقهبندی، روابط اولیه و سیاستهای مدیریت اطلاعات است. این تحول بزرگ باعث شده است که مدیریت دادهها راحتتر، کارآمدتر و قابل کنترلتر باشد، و تیمهای مختلف بتوانند به راحتی به دادههای مورد نیاز دسترسی پیدا کنند و فرآیندهای تحلیلی را سریعتر انجام دهند.
در مسیر توسعه این سیستم، متا با درسهای مهمی درباره مقیاس و هزینهها روبهرو شده است. یکی از این درسها این بود که حذف یا اصلاح سریع ستونهای خطایابی کوتاه، توانسته است صرفهجوییهای زیادی در هزینهها ایجاد کند؛ به طوری که تنها با کاهش چندین ستون، میلیونها دلار صرفهجویی شد. همچنین، برای جداول اصلی که بخش قابل توجهی از پایگاه دادهها را تشکیل میدهند، به جای حذف کردن نسخهها، روی نسخهبندی آنها تمرکز شد تا تاریخچه تغییرات حفظ شده و عملیات بهبودیافتهتر انجام شود. این رویکرد، علاوه بر حفظ دادههای حیاتی، کارایی سیستم را نیز افزایش داد.
در نهایت، متا به سمت هوش مصنوعی و قابلیتهای پیشرفتهتر پیش میرود؛ اما این مسیر با ساختارهای کاری قابل استفاده مجدد و اصول اولیه فرآیندهای کاری شروع میشود. پایهگذاری روندهای قابل تکرار و استانداردسازی فرآیندها، نقطه شروع مهمی است تا بتوان سیستمهای هوشمند و یادگیری ماشین را به طور مؤثر توسعه داد. در مجموع، درسهای متا نشان میدهد که توسعه و مدیریت دادهها در مقیاس بزرگ نیازمند ساختار منسجم، تصمیمات هوشمندانه و تمرکز بر استانداردسازی است.
#داده #مدیریت_داده #هوشمندسازی #پایگاه_داده
🟣لینک مقاله:
https://roundup.getdbt.com/p/data-lessons-from-inside-meta-shridhar?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Data lessons from inside Meta (Shridhar Iyer) (12 minute read)
🟢 خلاصه مقاله:
امپراتوری دادههای متا به سمت اتحاد و سازماندهی بهتر حرکت کرده است. پلتفرم دادههای این شرکت اکنون به یک ساختار منسجم و قوی تبدیل شده است که شامل لایههای متعددی مانند کاتالوگ متمرکز، طبقهبندی، روابط اولیه و سیاستهای مدیریت اطلاعات است. این تحول بزرگ باعث شده است که مدیریت دادهها راحتتر، کارآمدتر و قابل کنترلتر باشد، و تیمهای مختلف بتوانند به راحتی به دادههای مورد نیاز دسترسی پیدا کنند و فرآیندهای تحلیلی را سریعتر انجام دهند.
در مسیر توسعه این سیستم، متا با درسهای مهمی درباره مقیاس و هزینهها روبهرو شده است. یکی از این درسها این بود که حذف یا اصلاح سریع ستونهای خطایابی کوتاه، توانسته است صرفهجوییهای زیادی در هزینهها ایجاد کند؛ به طوری که تنها با کاهش چندین ستون، میلیونها دلار صرفهجویی شد. همچنین، برای جداول اصلی که بخش قابل توجهی از پایگاه دادهها را تشکیل میدهند، به جای حذف کردن نسخهها، روی نسخهبندی آنها تمرکز شد تا تاریخچه تغییرات حفظ شده و عملیات بهبودیافتهتر انجام شود. این رویکرد، علاوه بر حفظ دادههای حیاتی، کارایی سیستم را نیز افزایش داد.
در نهایت، متا به سمت هوش مصنوعی و قابلیتهای پیشرفتهتر پیش میرود؛ اما این مسیر با ساختارهای کاری قابل استفاده مجدد و اصول اولیه فرآیندهای کاری شروع میشود. پایهگذاری روندهای قابل تکرار و استانداردسازی فرآیندها، نقطه شروع مهمی است تا بتوان سیستمهای هوشمند و یادگیری ماشین را به طور مؤثر توسعه داد. در مجموع، درسهای متا نشان میدهد که توسعه و مدیریت دادهها در مقیاس بزرگ نیازمند ساختار منسجم، تصمیمات هوشمندانه و تمرکز بر استانداردسازی است.
#داده #مدیریت_داده #هوشمندسازی #پایگاه_داده
🟣لینک مقاله:
https://roundup.getdbt.com/p/data-lessons-from-inside-meta-shridhar?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Getdbt
Data lessons from inside Meta (Shridhar Iyer)
Shridhar Iyer spent 13 years inside Meta's data organization. He joins Tristan on what big tech takes for granted, why you never delete a column at scale, and what it takes to become AI-native.
🔵 عنوان مقاله
How and Why Netflix Built a Real-Time Distributed Graph: Part 3 — Querying the graph with gRPC execution API (20 minute read)
🟢 خلاصه مقاله:
در قسمت سوم مقاله “چگونه و چرا نتفلیکس یک گراف توزیعشده در زمان واقعی ساخت”، به بررسی نحوهٔ پرسوجو از این گراف با استفاده از API اجرای gRPC میپردازیم. در این بخش، تمرکز بر روی سازوکارهای تکنولوژیکی و کارایی سیستم است که نتفلیکس در پردازش میلیاردها نود و میلیاردها یال به کار میگیرد.
شبکه پرسوجوی لرزهنگار نتفلیکس (RDG) قادر است با بهرهگیری از پاراللسازی مرحلهای، در هر نمونه سیستم، بین ۱۶ تا ۲۴ رشته اجرای ناهمزمان (async) را فعال کند. این رویکرد باعث میشود عملیات پرسوجو بتواند بسیار سریع انجام شود و در عین حال، سیستم بتواند حجم گستردهای از دادهها را در کوتاهترین زمان ممکن مدیریت کند. این ساختار برای پاسخدهی به درخواستها، سطوح حافظهپنهان (کَش) را با توجه به نوسانات دادهها تنظیم میکند، به طوری که نرخ برخورد (hit rate) در موارد دادههای پایدار به ۷۰ تا ۸۰ درصد میرسد. این امر در نتیجه باعث کاهش قابل توجه زمان پاسخها میشود؛ به عنوان نمونه، حتی پرسوجوهای چندهاپی (سهگام) در کمتر از ۱۵۰ میلیثانیه در حالت معمول اجرایی میشوند، آن هم در مسیرهای دروازهزن (P99) که سختترین حالتها را نشان میدهند.
در نتیجه، این معماری مقیاسپذیر و بهینه، نتفلیکس را قادر ساخته است که پرسوجوهای پیچیده در زمان واقعی را با کارایی بالا و کمترین تأخیر ممکن انجام دهد، که این دقیقا نیاز این پلتفرم بزرگ در ارائه خدمات بیوقفه و سریع است.
#گراف_پرسوجو #زمان_واقعی #پایگاه_داده #نتفلیکس
🟣لینک مقاله:
https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-3-querying-the-graph-with-grpc-0f3468349607?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How and Why Netflix Built a Real-Time Distributed Graph: Part 3 — Querying the graph with gRPC execution API (20 minute read)
🟢 خلاصه مقاله:
در قسمت سوم مقاله “چگونه و چرا نتفلیکس یک گراف توزیعشده در زمان واقعی ساخت”، به بررسی نحوهٔ پرسوجو از این گراف با استفاده از API اجرای gRPC میپردازیم. در این بخش، تمرکز بر روی سازوکارهای تکنولوژیکی و کارایی سیستم است که نتفلیکس در پردازش میلیاردها نود و میلیاردها یال به کار میگیرد.
شبکه پرسوجوی لرزهنگار نتفلیکس (RDG) قادر است با بهرهگیری از پاراللسازی مرحلهای، در هر نمونه سیستم، بین ۱۶ تا ۲۴ رشته اجرای ناهمزمان (async) را فعال کند. این رویکرد باعث میشود عملیات پرسوجو بتواند بسیار سریع انجام شود و در عین حال، سیستم بتواند حجم گستردهای از دادهها را در کوتاهترین زمان ممکن مدیریت کند. این ساختار برای پاسخدهی به درخواستها، سطوح حافظهپنهان (کَش) را با توجه به نوسانات دادهها تنظیم میکند، به طوری که نرخ برخورد (hit rate) در موارد دادههای پایدار به ۷۰ تا ۸۰ درصد میرسد. این امر در نتیجه باعث کاهش قابل توجه زمان پاسخها میشود؛ به عنوان نمونه، حتی پرسوجوهای چندهاپی (سهگام) در کمتر از ۱۵۰ میلیثانیه در حالت معمول اجرایی میشوند، آن هم در مسیرهای دروازهزن (P99) که سختترین حالتها را نشان میدهند.
در نتیجه، این معماری مقیاسپذیر و بهینه، نتفلیکس را قادر ساخته است که پرسوجوهای پیچیده در زمان واقعی را با کارایی بالا و کمترین تأخیر ممکن انجام دهد، که این دقیقا نیاز این پلتفرم بزرگ در ارائه خدمات بیوقفه و سریع است.
#گراف_پرسوجو #زمان_واقعی #پایگاه_داده #نتفلیکس
🟣لینک مقاله:
https://netflixtechblog.com/how-and-why-netflix-built-a-real-time-distributed-graph-part-3-querying-the-graph-with-grpc-0f3468349607?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
How and Why Netflix Built a Real-Time Distributed Graph: Part 3 — Querying the graph with gRPC…
Authors: Nilesh Mishra and Ajit Koti
🔵 عنوان مقاله
SQL Improvements in Postgres 11–18: A Personal Selection
🟢 خلاصه مقاله:
در نسخههای ۱۱ تا ۱۸ پستگرس، شاهد پیشرفتهای قابل توجهی در بخشهای مختلف SQL بودهایم. این نسخهها هشت انتشار مختلف را در بر میگیرند که هر کدام ویژگیهای جدید و بهبودهای ویژهای را به همراه داشتهاند. در این مقاله، یک متخصص دیرینه در توسعه پایگاههای داده، مهمترین ویژگیهای این دورهها را بر اساس موضوعات مختلف انتخاب و دستهبندی کرده است.
یکی از بخشهایی که قطعاً توجهها را جلب میکند، مدلسازی عضویت در گروهها در طول زمان است. ابزارهای جدید مانند tstzmultirange و تابع range_agg() امکانات بینظیری را در این حوزه فراهم کردهاند. این ابزارها به توسعهدهندگان اجازه میدهند تحلیلهای پیچیدهتری بر روی تغییرات عضویت در گروهها انجام دهند و روندهای تاریخی را به شکل موثرتری نشان دهند. اگر به دنبال درک بهتر نحوه مدیریت و تحلیل عضویتهای زمانی در پایگاه دادههای خود هستید، مطالعه این قسمت ارزش زیادی دارد.
در کل، نسخههای ۱۱ تا ۱۸ پستگرس مجموعهای غنی از قابلیتهای جدید ارائه میدهند که کار با SQL و مدلسازی دادهها را سادهتر، سریعتر و قدرتمندتر میکنند. مطمئناً این تحولات میتوانند تاثیر قابل توجهی در پروژههای دادهمحور شما داشته باشند.
#پستگرس #SQL #پایگاه_داده #توسعه
🟣لینک مقاله:
https://tapoueh.org/blog/2026/07/sql-improvements-in-postgresql-1118-a-personal-selection/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
SQL Improvements in Postgres 11–18: A Personal Selection
🟢 خلاصه مقاله:
در نسخههای ۱۱ تا ۱۸ پستگرس، شاهد پیشرفتهای قابل توجهی در بخشهای مختلف SQL بودهایم. این نسخهها هشت انتشار مختلف را در بر میگیرند که هر کدام ویژگیهای جدید و بهبودهای ویژهای را به همراه داشتهاند. در این مقاله، یک متخصص دیرینه در توسعه پایگاههای داده، مهمترین ویژگیهای این دورهها را بر اساس موضوعات مختلف انتخاب و دستهبندی کرده است.
یکی از بخشهایی که قطعاً توجهها را جلب میکند، مدلسازی عضویت در گروهها در طول زمان است. ابزارهای جدید مانند tstzmultirange و تابع range_agg() امکانات بینظیری را در این حوزه فراهم کردهاند. این ابزارها به توسعهدهندگان اجازه میدهند تحلیلهای پیچیدهتری بر روی تغییرات عضویت در گروهها انجام دهند و روندهای تاریخی را به شکل موثرتری نشان دهند. اگر به دنبال درک بهتر نحوه مدیریت و تحلیل عضویتهای زمانی در پایگاه دادههای خود هستید، مطالعه این قسمت ارزش زیادی دارد.
در کل، نسخههای ۱۱ تا ۱۸ پستگرس مجموعهای غنی از قابلیتهای جدید ارائه میدهند که کار با SQL و مدلسازی دادهها را سادهتر، سریعتر و قدرتمندتر میکنند. مطمئناً این تحولات میتوانند تاثیر قابل توجهی در پروژههای دادهمحور شما داشته باشند.
#پستگرس #SQL #پایگاه_داده #توسعه
🟣لینک مقاله:
https://tapoueh.org/blog/2026/07/sql-improvements-in-postgresql-1118-a-personal-selection/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dimitri Fontaine
SQL Improvements in PostgreSQL 11–18: A Personal Selection
Seven major versions of PostgreSQL shipped between 2018 and 2025, one per year without exception, and each with a changelog of 150 to 200 user-visible changes. …
🔵 عنوان مقاله
pyhctsa: Python Toolkit for Highly Comparative Time-Series Analysis (GitHub Repo)
🟢 خلاصه مقاله:
ابزار pyhctsa یک مجموعه قدرتمند و کارآمد در زبان پایتون است که برای تحلیلهای جامع و پیوسته بر روی دادههای سری زمانی طراحی شده است. این ابزار به کاربران امکان میدهد صدها ویژگی آماری و ساختاری مختلف را از یک یا چند سری زمانی استخراج کنند. یکی از مزایای مهم این مجموعه، قابلیت پیکربندی و سفارشیسازی مجموعه ویژگیها است که به محققان و تحلیلگران داده امکان میدهد بر اساس نیازهای خاص، ویژگیهای دلخواه خود را اضافه یا تغییر دهند. علاوه بر این، pyhctsa قادر است ورودیهای با طولهای متفاوت را به خوبی مدیریت کند و در نتیجه، انعطافپذیری بالایی برای تحلیل دادههای متنوع دارد.
این مجموعه ابزار همچنین از فراخوانی مستقیم عملیات و انجام تحلیلها به صورت همزمان بر روی هستههای پردازشی محلی CPU پشتیبانی میکند. این قابلیت باعث میشود روند تحلیل دادهها بسیار سریعتر و بهینهتر انجام شود، به ویژه در مواردی که حجم دادهها زیاد است یا نیاز است تحلیلهای پیچیده و زمانبر انجام شود. به طور کلی، pyhctsa ابزاری قدرتمند و انعطافپذیر است که فرآیند تحلیل سریهای زمانی را آسانتر، سریعتر و قابل تنظیمتر میکند، و برای دانشمندان، محققان و تحلیلگران داده بسیار مفید است.
#تحلیل_سری_زمانی #ابزار_پایتون #دادهکاوی #پیشرفته
🟣لینک مقاله:
https://github.com/DynamicsAndNeuralSystems/pyhctsa?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pyhctsa: Python Toolkit for Highly Comparative Time-Series Analysis (GitHub Repo)
🟢 خلاصه مقاله:
ابزار pyhctsa یک مجموعه قدرتمند و کارآمد در زبان پایتون است که برای تحلیلهای جامع و پیوسته بر روی دادههای سری زمانی طراحی شده است. این ابزار به کاربران امکان میدهد صدها ویژگی آماری و ساختاری مختلف را از یک یا چند سری زمانی استخراج کنند. یکی از مزایای مهم این مجموعه، قابلیت پیکربندی و سفارشیسازی مجموعه ویژگیها است که به محققان و تحلیلگران داده امکان میدهد بر اساس نیازهای خاص، ویژگیهای دلخواه خود را اضافه یا تغییر دهند. علاوه بر این، pyhctsa قادر است ورودیهای با طولهای متفاوت را به خوبی مدیریت کند و در نتیجه، انعطافپذیری بالایی برای تحلیل دادههای متنوع دارد.
این مجموعه ابزار همچنین از فراخوانی مستقیم عملیات و انجام تحلیلها به صورت همزمان بر روی هستههای پردازشی محلی CPU پشتیبانی میکند. این قابلیت باعث میشود روند تحلیل دادهها بسیار سریعتر و بهینهتر انجام شود، به ویژه در مواردی که حجم دادهها زیاد است یا نیاز است تحلیلهای پیچیده و زمانبر انجام شود. به طور کلی، pyhctsa ابزاری قدرتمند و انعطافپذیر است که فرآیند تحلیل سریهای زمانی را آسانتر، سریعتر و قابل تنظیمتر میکند، و برای دانشمندان، محققان و تحلیلگران داده بسیار مفید است.
#تحلیل_سری_زمانی #ابزار_پایتون #دادهکاوی #پیشرفته
🟣لینک مقاله:
https://github.com/DynamicsAndNeuralSystems/pyhctsa?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - DynamicsAndNeuralSystems/pyhctsa: The most comprehensive time-series feature extraction package in Python.
The most comprehensive time-series feature extraction package in Python. - DynamicsAndNeuralSystems/pyhctsa
🔵 عنوان مقاله
Dispatches from O'Reilly: The Best Risk Mitigation Strategy in Data? A Single Source of Truth (6 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها، یکی از مهمترین چالشها، جلوگیری از تناقض در اعداد و اطلاعات است که میتواند کارایی و اعتماد به دادهها را زیر سوال ببرد. از همین رو، تعریف معیارها و معیارهای کلیدی فقط یکبار در لایه معنایی، راهحل موثری است تا اطمینان حاصل شود که تمامی ابزارهای تحلیل مانند Tableau، Power BI و نوتبوکها، همگی بر اساس دادههای یکسان و دقیق عمل میکنند. این رویکرد نه تنها خطر برخورد با ارقام متناقض را کاهش میدهد، بلکه فرآیند کنترل مجوزها و پیگیری تغییرات را از یک نقطه واحد ممکن ساخته و امکان ردیابی و حسابرسی سادهتر را فراهم میکند.
در حقیقت، لایه معنایی نقش استراتژیک در کاهش ریسکهای عملیاتی دارد و به عنوان یک لایه اختیاری شناخته نمیشود بلکه جزو اجزای ضروری سیستمهای تحلیل و مدیریت داده است. با استفاده از این ساختار، سازمانها میتوانند با اطمینان بیشتری تصمیمگیری کنند و از صحت و ثبات دادههایشان در تمامی سطوح بهرهمند شوند، چرا که تمامی تغییرات و مجوزهای مربوط به معیارها و دادهها، از یک مکان مرکزی قابل کنترل است و خطاهای احتمالی به حداقل میرسد.
در نتیجه، استراتژی تکمنبع حقیقت در دادهها، بهترین رویکرد برای کاهش ریسکهای عملیاتی و افزایش شفافیت در مدیریت دادهها است، روشی که تضمین میکند تمامی اتصالات به دادههای سازمان، بر پایه استانداردهای یکسان و قابل اعتماد صورت گیرد.
#مدیریت_داده #کیفیت_اطلاعات #امنیت_داده #بهرهوری_سیستم
🟣لینک مقاله:
https://stackoverflow.blog/2026/07/31/dispatches-from-o-reilly-the-best-risk-mitigation-strategy-in-data-a-single-source-of-truth/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Dispatches from O'Reilly: The Best Risk Mitigation Strategy in Data? A Single Source of Truth (6 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها، یکی از مهمترین چالشها، جلوگیری از تناقض در اعداد و اطلاعات است که میتواند کارایی و اعتماد به دادهها را زیر سوال ببرد. از همین رو، تعریف معیارها و معیارهای کلیدی فقط یکبار در لایه معنایی، راهحل موثری است تا اطمینان حاصل شود که تمامی ابزارهای تحلیل مانند Tableau، Power BI و نوتبوکها، همگی بر اساس دادههای یکسان و دقیق عمل میکنند. این رویکرد نه تنها خطر برخورد با ارقام متناقض را کاهش میدهد، بلکه فرآیند کنترل مجوزها و پیگیری تغییرات را از یک نقطه واحد ممکن ساخته و امکان ردیابی و حسابرسی سادهتر را فراهم میکند.
در حقیقت، لایه معنایی نقش استراتژیک در کاهش ریسکهای عملیاتی دارد و به عنوان یک لایه اختیاری شناخته نمیشود بلکه جزو اجزای ضروری سیستمهای تحلیل و مدیریت داده است. با استفاده از این ساختار، سازمانها میتوانند با اطمینان بیشتری تصمیمگیری کنند و از صحت و ثبات دادههایشان در تمامی سطوح بهرهمند شوند، چرا که تمامی تغییرات و مجوزهای مربوط به معیارها و دادهها، از یک مکان مرکزی قابل کنترل است و خطاهای احتمالی به حداقل میرسد.
در نتیجه، استراتژی تکمنبع حقیقت در دادهها، بهترین رویکرد برای کاهش ریسکهای عملیاتی و افزایش شفافیت در مدیریت دادهها است، روشی که تضمین میکند تمامی اتصالات به دادههای سازمان، بر پایه استانداردهای یکسان و قابل اعتماد صورت گیرد.
#مدیریت_داده #کیفیت_اطلاعات #امنیت_داده #بهرهوری_سیستم
🟣لینک مقاله:
https://stackoverflow.blog/2026/07/31/dispatches-from-o-reilly-the-best-risk-mitigation-strategy-in-data-a-single-source-of-truth/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
stackoverflow.blog
Dispatches from O'Reilly: The best risk mitigation strategy in data? A single source of truth - Stack Overflow
Your semantic layer is a risk mitigation strategy. Not risk in the abstract, compliance-framework sense, but the practical, operational risk that quietly drains organizations every day.
🔵 عنوان مقاله
TimeSeries Tiered Storage Journey: Kafka/Flink Streams to Native Cassandra Cold Reads (6 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت دادههای زمانی بزرگ، طراحی سیستمهایی کارآمد و مقیاسپذیر اهمیت زیادی دارد. شرکت نتفلیکس با توسعه «سطحبندی ذخیرهسازی زمانی» (TimeSeries Tiered Storage) توانسته است حجم عظیمی از دادههای زمانی چندپتابایتی را با کارایی بالا مدیریت کند. در این سیستم، دادههای قدیمیتر و غیرقابل تغییر که دیگر نیازی به دسترسی سریع ندارند، از حافظه گرم در کاساندرا به ذخیرهسازی ارزانقیمتتر مانند S3 منتقل میشوند. این استراتژی به کاهش هزینهها و استفاده بهینه از منابع زیرساختی کمک میکند، در حالی که سرعت بازیابی دادههای قدیمیتر همچنان مناسب است.
در نسخه اولیه این سیستم، از فناوریهایی مانند کافکا و فلینگ بهره گرفته شد. دادهها در قالب پارکت بهوسیله این ابزارها در حالتی پیوسته و مداوم به سمت S3 هدایت میشدند و روزانه عملیات فشردهسازی مجدد بر روی دادهها انجام میگرفت. این رویکرد امکان ارائه خوانشهای سرد با کمترین تأخیر حدود ۵۰۰ میلیثانیه در سطح p۹۹ را فراهم میکرد، ولی در عین حال، هزینه عملیاتی آن بسیار بالا بود و نیازمند زیرساختهای قدرتمند و نگهداری مداوم بود.
در اصلاحات بعدی، نتفلیکس تصمیم گرفت تا از قابلیتهای بومی کاساندرا برای خوانش در سطح سرد بهرهمند شود. این سامانه به طور مستقیم از نسخههای پشتیبان S3، که حاوی دادههای فشرده سرد هستند، خوانش میکند. این رویکرد نه تنها حجم دادههایی که میتوان مدیریت کرد را افزایش داد، بلکه زمان پاسخدهی شدیداً بهبود یافته است؛ بهطوری که latency سطح p۹۰ حدود ۳۰ درصد کاهش یافته است. این تغییرات، باعث شد که سیستم بتواند به طور مؤثرتری نیازهای عملیاتی و تحلیلهای بزرگمقیاس را برآورده کند، بدون اینکه هزینهها و پیچیدگیها افزایش یابند.
در نتیجه، این مسیر تحول در ذخیرهسازی دادههای زمانبندی شده نمونهای از نوآوری در حوزه دادههای بزرگ است که توازنی هوشمندانه میان هزینه، کارایی و مقیاسپذیری برقرار میکند و به سازمانها کمک میکند تا دادههای تاریخی خود را به بهترین شکل مدیریت کنند.
#ذخیرهسازی_زمانی #کاساندرا #دیتای_بزرگ #مدیریت_داده
🟣لینک مقاله:
https://netflixtechblog.medium.com/timeseries-tiered-storage-journey-kafka-flink-streams-to-native-cassandra-cold-reads-e59d597c9d60?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
TimeSeries Tiered Storage Journey: Kafka/Flink Streams to Native Cassandra Cold Reads (6 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت دادههای زمانی بزرگ، طراحی سیستمهایی کارآمد و مقیاسپذیر اهمیت زیادی دارد. شرکت نتفلیکس با توسعه «سطحبندی ذخیرهسازی زمانی» (TimeSeries Tiered Storage) توانسته است حجم عظیمی از دادههای زمانی چندپتابایتی را با کارایی بالا مدیریت کند. در این سیستم، دادههای قدیمیتر و غیرقابل تغییر که دیگر نیازی به دسترسی سریع ندارند، از حافظه گرم در کاساندرا به ذخیرهسازی ارزانقیمتتر مانند S3 منتقل میشوند. این استراتژی به کاهش هزینهها و استفاده بهینه از منابع زیرساختی کمک میکند، در حالی که سرعت بازیابی دادههای قدیمیتر همچنان مناسب است.
در نسخه اولیه این سیستم، از فناوریهایی مانند کافکا و فلینگ بهره گرفته شد. دادهها در قالب پارکت بهوسیله این ابزارها در حالتی پیوسته و مداوم به سمت S3 هدایت میشدند و روزانه عملیات فشردهسازی مجدد بر روی دادهها انجام میگرفت. این رویکرد امکان ارائه خوانشهای سرد با کمترین تأخیر حدود ۵۰۰ میلیثانیه در سطح p۹۹ را فراهم میکرد، ولی در عین حال، هزینه عملیاتی آن بسیار بالا بود و نیازمند زیرساختهای قدرتمند و نگهداری مداوم بود.
در اصلاحات بعدی، نتفلیکس تصمیم گرفت تا از قابلیتهای بومی کاساندرا برای خوانش در سطح سرد بهرهمند شود. این سامانه به طور مستقیم از نسخههای پشتیبان S3، که حاوی دادههای فشرده سرد هستند، خوانش میکند. این رویکرد نه تنها حجم دادههایی که میتوان مدیریت کرد را افزایش داد، بلکه زمان پاسخدهی شدیداً بهبود یافته است؛ بهطوری که latency سطح p۹۰ حدود ۳۰ درصد کاهش یافته است. این تغییرات، باعث شد که سیستم بتواند به طور مؤثرتری نیازهای عملیاتی و تحلیلهای بزرگمقیاس را برآورده کند، بدون اینکه هزینهها و پیچیدگیها افزایش یابند.
در نتیجه، این مسیر تحول در ذخیرهسازی دادههای زمانبندی شده نمونهای از نوآوری در حوزه دادههای بزرگ است که توازنی هوشمندانه میان هزینه، کارایی و مقیاسپذیری برقرار میکند و به سازمانها کمک میکند تا دادههای تاریخی خود را به بهترین شکل مدیریت کنند.
#ذخیرهسازی_زمانی #کاساندرا #دیتای_بزرگ #مدیریت_داده
🟣لینک مقاله:
https://netflixtechblog.medium.com/timeseries-tiered-storage-journey-kafka-flink-streams-to-native-cassandra-cold-reads-e59d597c9d60?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
TimeSeries Tiered Storage Journey: Kafka/Flink Streams to Native Cassandra Cold Reads
By Oleksii Tkachuk, Rajiv Shringi, Chris Lohfink, Abe Ratnofsky, Kartik Sathyanarayanan
Forwarded from Pavel Durov (Pavel Durov)
For over half that time — the past 7,5 years — it's been one of the 10 most downloaded mobile apps in the world.
A whole generation has grown up with it
Please open Telegram to view this post
VIEW IN TELEGRAM
در بلاگ جدیدم رفتم سراغ بررسی عملی پردازش ۱۰ گیگابایت داده روی لپتاپ شخصی با DuckDB و تجربههای کلیدی پردازش دادههای بزرگ بدون نیاز به کلود یا سرورهای گرانقیمت را نوشتم.
در نهایت ۳۰ میلیون سطر داده متنی (حدود ۱۰.۵ گیگابایت) فقط در ۸۸ ثانیه وارد یک فایل ۲.۶۷ گیگابایتی DuckDB شد و زمان کوئریها از ۲.۱ ثانیه به ۰.۰۳ ثانیه رسید (۷۰ برابر سریعتر).
البته باید حدود ۵۰ گیگ دیتای دیگه هم بهش اضافه بشه. ولی با این حال، سرعت موقع کوئری در حد میلی ثانیه ست.
چند نکته بسیار مهم از این تجربه عملی:
- قبل از شروع بارگذاری، بایتهای فایل را چک کنید. خطاهای کدگذاری مثل CP1252 و کاراکترهای غیر استاندارد میتوانند همان اول کار پردازش را خراب کنند.
- الگوی all_varchar = true: ابتدا تمام ستونها را متنی بخوانید و سپس درون خود SQL نوع دادهها را تبدیل کنید. این کار مانع از تبدیل بیصدا و اشتباه دادهها به NULL میشود و صفرهای ابتدای کدها را حفظ میکند.
- در جداول تحلیلی از Primary Key استفاده نکنید. تعریف کلید اصلی باعث ساخت ایندکسهای سنگین میشود که سرعت بارگذاری را ۱۷ برابر کندتر و حجم فایل را ۵.۶ برابر بزرگتر میکند.
- مدیریت حافظه: با تنظیم preserve_insertion_order = false حافظه مصرفی بهشدت کاهش پیدا میکند و DuckDB حتی با محدودیت شدید حافظه (۱ گیگابایت رم) دادهها را بدون افت سرعت روی دیسک مدیریت میکند.
متن کامل مقاله:
http://mlnotes.substack.com
<Mehdi Allahyari/>
در نهایت ۳۰ میلیون سطر داده متنی (حدود ۱۰.۵ گیگابایت) فقط در ۸۸ ثانیه وارد یک فایل ۲.۶۷ گیگابایتی DuckDB شد و زمان کوئریها از ۲.۱ ثانیه به ۰.۰۳ ثانیه رسید (۷۰ برابر سریعتر).
البته باید حدود ۵۰ گیگ دیتای دیگه هم بهش اضافه بشه. ولی با این حال، سرعت موقع کوئری در حد میلی ثانیه ست.
چند نکته بسیار مهم از این تجربه عملی:
- قبل از شروع بارگذاری، بایتهای فایل را چک کنید. خطاهای کدگذاری مثل CP1252 و کاراکترهای غیر استاندارد میتوانند همان اول کار پردازش را خراب کنند.
- الگوی all_varchar = true: ابتدا تمام ستونها را متنی بخوانید و سپس درون خود SQL نوع دادهها را تبدیل کنید. این کار مانع از تبدیل بیصدا و اشتباه دادهها به NULL میشود و صفرهای ابتدای کدها را حفظ میکند.
- در جداول تحلیلی از Primary Key استفاده نکنید. تعریف کلید اصلی باعث ساخت ایندکسهای سنگین میشود که سرعت بارگذاری را ۱۷ برابر کندتر و حجم فایل را ۵.۶ برابر بزرگتر میکند.
- مدیریت حافظه: با تنظیم preserve_insertion_order = false حافظه مصرفی بهشدت کاهش پیدا میکند و DuckDB حتی با محدودیت شدید حافظه (۱ گیگابایت رم) دادهها را بدون افت سرعت روی دیسک مدیریت میکند.
متن کامل مقاله:
http://mlnotes.substack.com
<Mehdi Allahyari/>
Substack
The MLnotes Newsletter | Mehdi Allahyari | Substack
MLnotes shares bite-sized insights on AI, ML, GenAI, agents, and RAG—from real-world applications to careers and startups—helping cut through the noise of rapid AI progress. Click to read The MLnotes Newsletter, by Mehdi Allahyari, a Substack publication…
🔵 عنوان مقاله
Stop graphing everything: when GraphRAG actually beats vector RAG (5 minute read)
🟢 خلاصه مقاله:
در دنیای پردازش دادهها، روشهای مختلفی برای بازیابی و تحلیل اطلاعات وجود دارد که هر یک بر اساس نوع نیاز و نوع پرسشها، کارایی متفاوتی دارند. یکی از تفاوتهای کلیدی میان این روشها، در نحوه ارتباط و بررسی دادهها است. در این مقاله، به مقایسه بین دو رویکرد مهم، یعنی GraphRAG و vector RAG، میپردازیم و مشخص میکنیم چه زمانی هر یک بهتر عمل میکنند.
روش GraphRAG برای مواردی بسیار مؤثر است که نیاز به بررسی چند مرحلهای، روابط پیچیده و یا قابلیت توضیح و تبیین نتایج دارند. این رویکرد، با تمرکز بر ساختارهای گراف و ارتباطات میان دادهها، امکان تحلیل سلسلهمراتب و روابط چندلایه را فراهم میکند. به همین دلیل، در مسائلی مانند پرسشهای چندمرحلهای، تحلیل روابط میان اجزا، یا مواردی که نیاز به شفافسازی فرآیند است، GraphRAG برتری دارد.
در مقابل، vector RAG بیشتر برای جستجوهای معنایی و سریعتر مناسب است، جایی که هدف یافتن پاسخهای مرتبط و تشخیص شباهتهاست. این روش، بر پایه نمایش دادهها در قالب برداریهای وکتوری استوار است که انجامهای محاسباتی را سریعتر و اقتصادیتر میکند. بنابراین، در مواردی که نیاز به جستجوهای سریع و کمهزینه دارید و وضوح رابطه اهمیت کمتری دارد، vector RAG گزینه مناسبتری است.
در نتیجه، تصمیمگیری درباره استفاده از هر کدام باید بر اساس نوع پرسش و نیازهای پروژه انجام شود، به طوری که بتوان بهترین توازن را بین دقت، هزینه و سرعت برقرار کرد. فهم تفاوتها و کاربردهای این فناوریها به توسعهدهندگان و محققان کمک میکند تا به بهترین شکل از امکانات موجود بهرهمند شوند و کارایی سیستمهای خود را افزایش دهند.
#هوش_مصنوعی #یادگیری_ماشین #تحلیل_داده #رسانههای_دیجیتال
🟣لینک مقاله:
https://venturebeat.com/orchestration/stop-graphing-everything-when-graphrag-actually-beats-vector-rag?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Stop graphing everything: when GraphRAG actually beats vector RAG (5 minute read)
🟢 خلاصه مقاله:
در دنیای پردازش دادهها، روشهای مختلفی برای بازیابی و تحلیل اطلاعات وجود دارد که هر یک بر اساس نوع نیاز و نوع پرسشها، کارایی متفاوتی دارند. یکی از تفاوتهای کلیدی میان این روشها، در نحوه ارتباط و بررسی دادهها است. در این مقاله، به مقایسه بین دو رویکرد مهم، یعنی GraphRAG و vector RAG، میپردازیم و مشخص میکنیم چه زمانی هر یک بهتر عمل میکنند.
روش GraphRAG برای مواردی بسیار مؤثر است که نیاز به بررسی چند مرحلهای، روابط پیچیده و یا قابلیت توضیح و تبیین نتایج دارند. این رویکرد، با تمرکز بر ساختارهای گراف و ارتباطات میان دادهها، امکان تحلیل سلسلهمراتب و روابط چندلایه را فراهم میکند. به همین دلیل، در مسائلی مانند پرسشهای چندمرحلهای، تحلیل روابط میان اجزا، یا مواردی که نیاز به شفافسازی فرآیند است، GraphRAG برتری دارد.
در مقابل، vector RAG بیشتر برای جستجوهای معنایی و سریعتر مناسب است، جایی که هدف یافتن پاسخهای مرتبط و تشخیص شباهتهاست. این روش، بر پایه نمایش دادهها در قالب برداریهای وکتوری استوار است که انجامهای محاسباتی را سریعتر و اقتصادیتر میکند. بنابراین، در مواردی که نیاز به جستجوهای سریع و کمهزینه دارید و وضوح رابطه اهمیت کمتری دارد، vector RAG گزینه مناسبتری است.
در نتیجه، تصمیمگیری درباره استفاده از هر کدام باید بر اساس نوع پرسش و نیازهای پروژه انجام شود، به طوری که بتوان بهترین توازن را بین دقت، هزینه و سرعت برقرار کرد. فهم تفاوتها و کاربردهای این فناوریها به توسعهدهندگان و محققان کمک میکند تا به بهترین شکل از امکانات موجود بهرهمند شوند و کارایی سیستمهای خود را افزایش دهند.
#هوش_مصنوعی #یادگیری_ماشین #تحلیل_داده #رسانههای_دیجیتال
🟣لینک مقاله:
https://venturebeat.com/orchestration/stop-graphing-everything-when-graphrag-actually-beats-vector-rag?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Venturebeat
Stop graphing everything: When GraphRAG actually beats vector RAG
Everyone is bolting knowledge graphs onto their RAG pipelines. Here is what the published research actually says about whether it improves answer quality, and by how much.
🔵 عنوان مقاله
Introducing pg-java: A New Postgres Driver for the JVM
🟢 خلاصه مقاله:
در دنیای پایگاههای داده، درایورهای مخصوص زبان جاوا نقش بسیار مهمی در ارتباط امن و مؤثر برنامههای کاربردی با سرورهای پایگاه داده دارند. یکی از این درایورها، pgjdbc، مدتهاست که به عنوان راهحلی اصلی برای اتصال برنامههای جاوا به پایگاه داده پستگرس عمل میکند. اما حالا، توسعهدهندهای که مدتها مسئولیت نگهداری و بهبود این درایور را بر عهده داشته، تصمیم گرفته است یک درایور جدید و کاملاً از صفر ساخته شده بر اساس معماری مدرن و بهینه برای نسل آینده برنامهنویسی جاوا ارائه دهد: درایور "pg-java". این درایور جدید بر پایه تکنولوژی Threadهای مجازی توسعه یافته و هدف آن بهبود عملکرد و سادگی است.
در این مقاله، سازنده این درایور جدید توضیح میدهد که چرا و چگونه اقدام به طراحی و پیادهسازی یک درایور کاملاً جدید و مبتنی بر مفاهیم نوین کرده است. او اشاره میکند که با توجه به نیازهای روزافزون برنامههای مدرن و محدودیتهای درایورهای قدیمی، لازم بود راهحلی نوین و مطابق با آخرین فناوریها ارائه شود. در نتیجه، درایور "pg-java" با تمرکز بر همکاری با Threadهای مجازی و معماری سبک، توانسته است پتانسیلهای تازهای در مدیریت اتصالها و عملیاتهای پایگاه داده ارائه دهد.
در حالی که این پروژه هنوز در مرحله پیشانتشار است، توسعهدهندگان و کاربران علاقهمند به فناوریهای نوین میتوانند در انتظار نسخه نهایی و با امکانات کامل این درایور باشند. هدف اصلی این پروژه، بهبود کارایی، سادگی و قابلیت اتکا در برنامهنویسی با پایگاه داده پستگرس در بستر JVM است، به طوری که توسعهدهندگان بتوانند برنامههای سریعتر و بهتر بنویسند و بهرهوری خود را افزایش دهند. در نتیجه، "pg-java" به عنوان یک گام مهم در نوآوریهای حوزه بانکهای اطلاعاتی و توسعه نرمافزارهای مدرن به شمار میآید.
#پستگرس #درایور_جاوا #توسعه_نواورانه #برنامهنویسی
🟣لینک مقاله:
https://launchbylunch.com/posts/2026/Jul/29/introducing-pg-java/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Introducing pg-java: A New Postgres Driver for the JVM
🟢 خلاصه مقاله:
در دنیای پایگاههای داده، درایورهای مخصوص زبان جاوا نقش بسیار مهمی در ارتباط امن و مؤثر برنامههای کاربردی با سرورهای پایگاه داده دارند. یکی از این درایورها، pgjdbc، مدتهاست که به عنوان راهحلی اصلی برای اتصال برنامههای جاوا به پایگاه داده پستگرس عمل میکند. اما حالا، توسعهدهندهای که مدتها مسئولیت نگهداری و بهبود این درایور را بر عهده داشته، تصمیم گرفته است یک درایور جدید و کاملاً از صفر ساخته شده بر اساس معماری مدرن و بهینه برای نسل آینده برنامهنویسی جاوا ارائه دهد: درایور "pg-java". این درایور جدید بر پایه تکنولوژی Threadهای مجازی توسعه یافته و هدف آن بهبود عملکرد و سادگی است.
در این مقاله، سازنده این درایور جدید توضیح میدهد که چرا و چگونه اقدام به طراحی و پیادهسازی یک درایور کاملاً جدید و مبتنی بر مفاهیم نوین کرده است. او اشاره میکند که با توجه به نیازهای روزافزون برنامههای مدرن و محدودیتهای درایورهای قدیمی، لازم بود راهحلی نوین و مطابق با آخرین فناوریها ارائه شود. در نتیجه، درایور "pg-java" با تمرکز بر همکاری با Threadهای مجازی و معماری سبک، توانسته است پتانسیلهای تازهای در مدیریت اتصالها و عملیاتهای پایگاه داده ارائه دهد.
در حالی که این پروژه هنوز در مرحله پیشانتشار است، توسعهدهندگان و کاربران علاقهمند به فناوریهای نوین میتوانند در انتظار نسخه نهایی و با امکانات کامل این درایور باشند. هدف اصلی این پروژه، بهبود کارایی، سادگی و قابلیت اتکا در برنامهنویسی با پایگاه داده پستگرس در بستر JVM است، به طوری که توسعهدهندگان بتوانند برنامههای سریعتر و بهتر بنویسند و بهرهوری خود را افزایش دهند. در نتیجه، "pg-java" به عنوان یک گام مهم در نوآوریهای حوزه بانکهای اطلاعاتی و توسعه نرمافزارهای مدرن به شمار میآید.
#پستگرس #درایور_جاوا #توسعه_نواورانه #برنامهنویسی
🟣لینک مقاله:
https://launchbylunch.com/posts/2026/Jul/29/introducing-pg-java/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Launchbylunch
Introducing pg-java, a new PostgreSQL driver for the JVM
🔵 عنوان مقاله
Semantic Layers in Apache Superset: SIP-182 and Apache Ossie (14 minute read)
🟢 خلاصه مقاله:
در حال حاضر، پروژههای دادهمحور به دنبال بهبود فرآیند تحلیل و نمایش اطلاعات هستند تا بتوانند تصمیمات هوشمندانهتری را اتخاذ کنند. یکی از ابزارهای محبوب در این حوزه، "آپاتاش سوپرسِت" است که به تازگی قابلیت پشتیبانی از لایههای معنایی را به صورت کامل افزوده است. این قابلیت، جایگزین استفاده از پایگاههای داده موقت برای محاسبات و ابعاد مختلف شده است، و به کاربران امکان میدهد تا با ساختن لایههای معنایی دقیقتر و قابل تفسیر، فرآیند تحلیل دادهها را به سطح جدیدی برسانند.
در نسخه جدید سوپرسِت، رابط کاربری جدیدی با نام "SemanticLayer/Explorable" معرفی شده است که درخواستهای مربوط به نمودارها را به صورت اشیاء "SemanticQuery" تبدیل میکند. این امر موجب میشود تا دادهها به صورت جدولهای Arrow برگردانده شوند، و این قابلیت در نسخه 7.0 این ابزار در دسترس قرار گیرد. این تحول، مسیر را برای توسعههای پیشرفتهتر و تحلیلهای پیچیدهتر هموار میسازد و امکان بهرهگیری بهتر از دادههای بزرگ را فراهم میکند.
علاوه بر این، پروژهای جدید به نام "Apache Ossie" در حال ساخت است که نقش یک لایه تبادل دادههای مستقل از فروشنده را دارد. این لایه، هر دو قالب JSON و YAML را پشتیبانی میکند و هدف آن ایجاد یک استاندارد مشترک برای رد و بدل کردن دادهها و تنظیمات بین ابزارهای مختلف است. با این رویکرد، انتظارات برای انسجام و هماهنگی درون اکوسیستمهای دادهمحور افزایش یافته و تبادلات میان ابزارهای متفاوت سادهتر و مؤثرتر میشود.
در مجموع، این تحولات نشان میدهد که اکوسیستم دادههای تجزیه و تحلیل در حال حرکت به سمت پایداری، استانداردسازی و توانمندسازی کاربران است تا بتوانند به شکلی دقیقتر و جامعتر به دادههای خود دست یابند و تصمیمگیریهای استراتژیک بهتری انجام دهند.
#تحلیل_داده #هوشمندی_کسب_و_کار #هوش_مصنوعی #توسعه_فناوری
🟣لینک مقاله:
https://preset.io/blog/semantic-layers-in-superset/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Semantic Layers in Apache Superset: SIP-182 and Apache Ossie (14 minute read)
🟢 خلاصه مقاله:
در حال حاضر، پروژههای دادهمحور به دنبال بهبود فرآیند تحلیل و نمایش اطلاعات هستند تا بتوانند تصمیمات هوشمندانهتری را اتخاذ کنند. یکی از ابزارهای محبوب در این حوزه، "آپاتاش سوپرسِت" است که به تازگی قابلیت پشتیبانی از لایههای معنایی را به صورت کامل افزوده است. این قابلیت، جایگزین استفاده از پایگاههای داده موقت برای محاسبات و ابعاد مختلف شده است، و به کاربران امکان میدهد تا با ساختن لایههای معنایی دقیقتر و قابل تفسیر، فرآیند تحلیل دادهها را به سطح جدیدی برسانند.
در نسخه جدید سوپرسِت، رابط کاربری جدیدی با نام "SemanticLayer/Explorable" معرفی شده است که درخواستهای مربوط به نمودارها را به صورت اشیاء "SemanticQuery" تبدیل میکند. این امر موجب میشود تا دادهها به صورت جدولهای Arrow برگردانده شوند، و این قابلیت در نسخه 7.0 این ابزار در دسترس قرار گیرد. این تحول، مسیر را برای توسعههای پیشرفتهتر و تحلیلهای پیچیدهتر هموار میسازد و امکان بهرهگیری بهتر از دادههای بزرگ را فراهم میکند.
علاوه بر این، پروژهای جدید به نام "Apache Ossie" در حال ساخت است که نقش یک لایه تبادل دادههای مستقل از فروشنده را دارد. این لایه، هر دو قالب JSON و YAML را پشتیبانی میکند و هدف آن ایجاد یک استاندارد مشترک برای رد و بدل کردن دادهها و تنظیمات بین ابزارهای مختلف است. با این رویکرد، انتظارات برای انسجام و هماهنگی درون اکوسیستمهای دادهمحور افزایش یافته و تبادلات میان ابزارهای متفاوت سادهتر و مؤثرتر میشود.
در مجموع، این تحولات نشان میدهد که اکوسیستم دادههای تجزیه و تحلیل در حال حرکت به سمت پایداری، استانداردسازی و توانمندسازی کاربران است تا بتوانند به شکلی دقیقتر و جامعتر به دادههای خود دست یابند و تصمیمگیریهای استراتژیک بهتری انجام دهند.
#تحلیل_داده #هوشمندی_کسب_و_کار #هوش_مصنوعی #توسعه_فناوری
🟣لینک مقاله:
https://preset.io/blog/semantic-layers-in-superset/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
preset.io
Semantic Layers in Apache Superset: SIP-182 and Apache Ossie
Superset always had a semantic layer. It was called the dataset. SIP-182 just made it one of many, with a path to Apache Ossie.
❤1
🔵 عنوان مقاله
you can use it on the Web
🟢 خلاصه مقاله:
در دنیای امروز، استفاده از ابزارهای هوشمند در فضای وب به سرعت در حال افزایش است. اگر در حال آمادهسازی یک ارائه یا مقاله وبلاگی هستید، حتماً این ابزارها را امتحان کنید تا بتوانید محتواهای خود را بهتر و سریعتر توسعه دهید. این فناوریها به شما کمک میکنند تا با صرف کمترین زمان، اطلاعات را به شیوهای جذاب و قابل فهم ارائه دهید و روند کاریتان را بهبود بخشید. استفاده از این ابزارها نه تنها فرآیند تولید محتوا را تسریع میکند، بلکه کیفیت نهایی کار شما را هم چند برابر مینماید و باعث میشود تا پیام شما به بهترین شکل به مخاطبان منتقل شود. بنابراین، نترسید و از امکانات دیجیتال برای ارتقاء پروژههای خود بهرهمند شوید.
#هوش_مصنوعی #تولید_محتوا #وب_سایت #نوآوری
🟣لینک مقاله:
https://theartofpostgresql.com/postgresql-sql-formatter/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
you can use it on the Web
🟢 خلاصه مقاله:
در دنیای امروز، استفاده از ابزارهای هوشمند در فضای وب به سرعت در حال افزایش است. اگر در حال آمادهسازی یک ارائه یا مقاله وبلاگی هستید، حتماً این ابزارها را امتحان کنید تا بتوانید محتواهای خود را بهتر و سریعتر توسعه دهید. این فناوریها به شما کمک میکنند تا با صرف کمترین زمان، اطلاعات را به شیوهای جذاب و قابل فهم ارائه دهید و روند کاریتان را بهبود بخشید. استفاده از این ابزارها نه تنها فرآیند تولید محتوا را تسریع میکند، بلکه کیفیت نهایی کار شما را هم چند برابر مینماید و باعث میشود تا پیام شما به بهترین شکل به مخاطبان منتقل شود. بنابراین، نترسید و از امکانات دیجیتال برای ارتقاء پروژههای خود بهرهمند شوید.
#هوش_مصنوعی #تولید_محتوا #وب_سایت #نوآوری
🟣لینک مقاله:
https://theartofpostgresql.com/postgresql-sql-formatter/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Theartofpostgresql
PostgreSQL SQL Formatter
Paste a query and get it back in the book's river-aligned style — free, in your browser, no signup.
🔵 عنوان مقاله
Rebuilding Postgres for 300x Faster Analytics
🟢 خلاصه مقاله:
در دنیای پایگاههای داده، سرعت و کارآمدی در تجزیه و تحلیل دادهها اهمیت بسیار بالایی دارد. اخیراً توسعهدهندگان ابزارهای متعددی در تلاش برای بهبود این جوانب هستند، و یکی از جدیدترین پیشرفتها، بازساختن موتور پایگاه داده PostgreSQL برای تضمین سرعتی بینظیر است. به عنوان نمونه، پروژهای به نام pgrust ایجاد شده که قصد دارد PostgreSQL را با استفاده از زبان برنامهنویسی Rust مجدداً بازنویسی کند تا عملکرد و سرعت آن را به طور چشمگیری افزایش دهد.
در این فرآیند، مفاهیم کلیدی مانند دستهبندی یا batching، تلفیق عملیات (operator fusion) و استفاده از دستورهای SIMD نقش حیاتی دارند. این تکنیکها امکان اجرای چندین عملیات به صورت همزمان و بهینهسازی روند پردازش را فراهم میکنند. بهرهگیری از batching به سیستم اجازه میدهد که دادهها را در دستههای بزرگتر پردازش کند، این امر به کاهش هزینههای مربوط به هر عملیات و افزایش سرعت کلی کمک میکند. تلفیق عملیات نیز با تجمیع مراحل مختلف در یک عملیات واحد، فرآیندهای تکراری را حذف کرده و کارایی را بهبود میبخشد.
در نهایت، استفاده از فناوری SIMD (Single Instruction Multiple Data) امکان انجام چندین عملیات بر روی دادههای همعرض را به صورت همزمان فراهم میکند. این تکنولوژی مخصوصاً در پردازشهای دادهای حجیم نقش مهمی دارد، و به طور قابل توجهی زمان اجرای کوئریها را کاهش میدهد. با این رویکردها، ساخت موتورهای پایگاه داده جدید مانند pgrust میتواند تحولی عظیم در تحلیلهای دادهای سرعتپایین و محدودکننده باشد، و امکان انجام تحلیلهای سریعتر و موثرتر را برای کاربران فراهم کند.
این پیشرفتها نشان میدهند که آینده مدیریت دادهها با بهرهگیری از تکنولوژیهای نوین و هوشمندانه، بسیار درخشانتر و پربارتر خواهد بود.
#پایگاه_داده #سرعت_بالا #تحلیل_داده #تکنولوژی
🟣لینک مقاله:
https://malisper.me/how-we-made-postgres-hundreds-of-times-faster-the-query-engine/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Rebuilding Postgres for 300x Faster Analytics
🟢 خلاصه مقاله:
در دنیای پایگاههای داده، سرعت و کارآمدی در تجزیه و تحلیل دادهها اهمیت بسیار بالایی دارد. اخیراً توسعهدهندگان ابزارهای متعددی در تلاش برای بهبود این جوانب هستند، و یکی از جدیدترین پیشرفتها، بازساختن موتور پایگاه داده PostgreSQL برای تضمین سرعتی بینظیر است. به عنوان نمونه، پروژهای به نام pgrust ایجاد شده که قصد دارد PostgreSQL را با استفاده از زبان برنامهنویسی Rust مجدداً بازنویسی کند تا عملکرد و سرعت آن را به طور چشمگیری افزایش دهد.
در این فرآیند، مفاهیم کلیدی مانند دستهبندی یا batching، تلفیق عملیات (operator fusion) و استفاده از دستورهای SIMD نقش حیاتی دارند. این تکنیکها امکان اجرای چندین عملیات به صورت همزمان و بهینهسازی روند پردازش را فراهم میکنند. بهرهگیری از batching به سیستم اجازه میدهد که دادهها را در دستههای بزرگتر پردازش کند، این امر به کاهش هزینههای مربوط به هر عملیات و افزایش سرعت کلی کمک میکند. تلفیق عملیات نیز با تجمیع مراحل مختلف در یک عملیات واحد، فرآیندهای تکراری را حذف کرده و کارایی را بهبود میبخشد.
در نهایت، استفاده از فناوری SIMD (Single Instruction Multiple Data) امکان انجام چندین عملیات بر روی دادههای همعرض را به صورت همزمان فراهم میکند. این تکنولوژی مخصوصاً در پردازشهای دادهای حجیم نقش مهمی دارد، و به طور قابل توجهی زمان اجرای کوئریها را کاهش میدهد. با این رویکردها، ساخت موتورهای پایگاه داده جدید مانند pgrust میتواند تحولی عظیم در تحلیلهای دادهای سرعتپایین و محدودکننده باشد، و امکان انجام تحلیلهای سریعتر و موثرتر را برای کاربران فراهم کند.
این پیشرفتها نشان میدهند که آینده مدیریت دادهها با بهرهگیری از تکنولوژیهای نوین و هوشمندانه، بسیار درخشانتر و پربارتر خواهد بود.
#پایگاه_داده #سرعت_بالا #تحلیل_داده #تکنولوژی
🟣لینک مقاله:
https://malisper.me/how-we-made-postgres-hundreds-of-times-faster-the-query-engine/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
malisper.me
Rebuilding Postgres for 300x faster analytics: batching, operator fusion, and SIMD - malisper.me
Last week we released version 0.2 of pgrust. This release was all about performance. It’s 10x faster than the previous version of pgrust. On OLTP benchmarks, pgrust is 30% faster than Postgres, and on Clickbench, Clickhouse’s benchmark for analytical databases…
🔵 عنوان مقاله
Never mind clean data. Annotate as you collect it. (11 minute read)
🟢 خلاصه مقاله:
در دنیای هوش مصنوعی، پیشفرض کردن دادههای تمیز و بدون خطا چندان منطقی نیست. بهتر است هنگام جمعآوری دادهها، فرآیند برچسبگذاری و افزودن توضیحات انجام شود. این روش کمک میکند تا اطلاعات درون دادهها، مانند منبع، ساختار و تاریخچه، به صورت مستمر حفظ و ثبت شود. چرا که بسیاری از خطاها و توهمهایی که در مدلهای هوش مصنوعی ظاهر میشوند، ناشی از Daten قدیمی، ناسازگار یا غیر معتبر است. بر اساس نظرات مؤسسه گارتنر، تا ۶۰ درصد پروژههای هوش مصنوعی در غیاب متادیتا و ابزارهای رصد، با شکست مواجه میشوند و بخش عمدهای از هزینههای آموزش مدلهای پیشرفته صرف پاکسازی و تایید صحت دادهها میگردد.
برای جلوگیری از این مشکلات، باید در حین فرآیند جمعآوری دادهها، زنجیره منشا و مرجعیت اطلاعات را ضبط کرد. بهرهگیری از قراردادهای داده و مدلهای مدیریت دارایی داده (DBOMs) به تیمهای توسعه کمک میکند تا عوامل هوشمند را بر اساس منبع و اعتبار آنها هدایت و کنترل کنند. این رویکرد سبب میشود که مدلهای آموزشدیده بر پایه دادههای معتبر و قابل اعتماد باشند و از تولید نتایج نادرست یا توهمآمیز جلوگیری شود. به طور کلی، حفظ شفافیت و منشا دادهها در فرآیند هوش مصنوعی اهمیت بسیار زیادی دارد و پایه اصلی برای سامانههای قابل اعتماد است.
#هوش_مصنوعی #مدیریت_داده #متادیتا #اتکاپذیری
🟣لینک مقاله:
https://www.cio.com/article/4204899/never-mind-clean-data-annotate-as-you-collect-it.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Never mind clean data. Annotate as you collect it. (11 minute read)
🟢 خلاصه مقاله:
در دنیای هوش مصنوعی، پیشفرض کردن دادههای تمیز و بدون خطا چندان منطقی نیست. بهتر است هنگام جمعآوری دادهها، فرآیند برچسبگذاری و افزودن توضیحات انجام شود. این روش کمک میکند تا اطلاعات درون دادهها، مانند منبع، ساختار و تاریخچه، به صورت مستمر حفظ و ثبت شود. چرا که بسیاری از خطاها و توهمهایی که در مدلهای هوش مصنوعی ظاهر میشوند، ناشی از Daten قدیمی، ناسازگار یا غیر معتبر است. بر اساس نظرات مؤسسه گارتنر، تا ۶۰ درصد پروژههای هوش مصنوعی در غیاب متادیتا و ابزارهای رصد، با شکست مواجه میشوند و بخش عمدهای از هزینههای آموزش مدلهای پیشرفته صرف پاکسازی و تایید صحت دادهها میگردد.
برای جلوگیری از این مشکلات، باید در حین فرآیند جمعآوری دادهها، زنجیره منشا و مرجعیت اطلاعات را ضبط کرد. بهرهگیری از قراردادهای داده و مدلهای مدیریت دارایی داده (DBOMs) به تیمهای توسعه کمک میکند تا عوامل هوشمند را بر اساس منبع و اعتبار آنها هدایت و کنترل کنند. این رویکرد سبب میشود که مدلهای آموزشدیده بر پایه دادههای معتبر و قابل اعتماد باشند و از تولید نتایج نادرست یا توهمآمیز جلوگیری شود. به طور کلی، حفظ شفافیت و منشا دادهها در فرآیند هوش مصنوعی اهمیت بسیار زیادی دارد و پایه اصلی برای سامانههای قابل اعتماد است.
#هوش_مصنوعی #مدیریت_داده #متادیتا #اتکاپذیری
🟣لینک مقاله:
https://www.cio.com/article/4204899/never-mind-clean-data-annotate-as-you-collect-it.html?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
🔵 عنوان مقاله
Beyond Happy Path Engineering: Databases (18 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت بانکهای اطلاعاتی، تمرکز تنها بر مسیرهای موفق و همیشگی کافی نیست. اغلب مواقع، خطاها و مشکلاتی در لبههای سیستم رخ میدهد که میتوانند کسبوکار و فرآیندهای مهم را مختل کنند. برای مثال، خواندن نسخههای کپیکار شده کهن، تاییدهای مبهم، وضعیتهای بنبست (Deadlock) یا مهاجرتهای زنده (Live Migration) همگی میتوانند جریانهای کاری را شکسته و حلوفصل را دشوار کنند. بنابراین، اهمیت دارد که هنگام طراحی و پیادهسازی سیستمهای بانک اطلاعاتی، تنها به مسیرهای صحیح تمرکز نکنیم، بلکه شرایط و استثناها را نیز در نظر گرفته و در مقابل آنها واکنش مناسب نشان دهیم.
پیشنهاد عملی در این زمینه، اعمال محدودیتها و قوانین مشخص در مرزهای پایگاه داده است؛ یعنی در نقطهای که سیستم با بیرون در ارتباط است، باید با محافظت از نوشتنها، محدود کردن تراکنشها، استفاده از تراکنشهای کوتاه، تکرارهای ایمن و قفلنشدنی، از صحت و یکنواختی دادهها اطمینان حاصل کنیم. بهعلاوه، میبایست روشهای واضح و قابل اعتماد برای بازیابی و واکنش در صورت بروز خطاها تعریف شود؛ این اقدامات سبب میشود سیستم بتواند در مواجهه با رخدادهای پیشبینینشده، همچنان پایدار و مطمئن باقی بماند و عملیاتها به درستی ادامه یابد.
در نتیجه، تمرکز بر کنترل و نظارت بر لبههای پایگاه داده و تضمین اجرای صحیح invariantها، کلید ارزیابی و بهبود سیستمهای دادهبنیان است. این رویکرد، به صورت عملیاتی، استحکام و قابلیت اطمینان سیستمهای بانک اطلاعاتی را در برابر پیچیدگیهای احتمالی ارتقا میدهد و فرآیندهای کسبوکار را مقاومتر میسازد.
#مدیریت_بانک_اطلاعاتی #پایداری_سیستم #توسعه_نرمافزار #رکوردهای_ایمن
🟣لینک مقاله:
https://blog.gaborkoos.com/posts/2026-08-01-Beyond-Happy-Path-Engineering-Databases/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Beyond Happy Path Engineering: Databases (18 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت بانکهای اطلاعاتی، تمرکز تنها بر مسیرهای موفق و همیشگی کافی نیست. اغلب مواقع، خطاها و مشکلاتی در لبههای سیستم رخ میدهد که میتوانند کسبوکار و فرآیندهای مهم را مختل کنند. برای مثال، خواندن نسخههای کپیکار شده کهن، تاییدهای مبهم، وضعیتهای بنبست (Deadlock) یا مهاجرتهای زنده (Live Migration) همگی میتوانند جریانهای کاری را شکسته و حلوفصل را دشوار کنند. بنابراین، اهمیت دارد که هنگام طراحی و پیادهسازی سیستمهای بانک اطلاعاتی، تنها به مسیرهای صحیح تمرکز نکنیم، بلکه شرایط و استثناها را نیز در نظر گرفته و در مقابل آنها واکنش مناسب نشان دهیم.
پیشنهاد عملی در این زمینه، اعمال محدودیتها و قوانین مشخص در مرزهای پایگاه داده است؛ یعنی در نقطهای که سیستم با بیرون در ارتباط است، باید با محافظت از نوشتنها، محدود کردن تراکنشها، استفاده از تراکنشهای کوتاه، تکرارهای ایمن و قفلنشدنی، از صحت و یکنواختی دادهها اطمینان حاصل کنیم. بهعلاوه، میبایست روشهای واضح و قابل اعتماد برای بازیابی و واکنش در صورت بروز خطاها تعریف شود؛ این اقدامات سبب میشود سیستم بتواند در مواجهه با رخدادهای پیشبینینشده، همچنان پایدار و مطمئن باقی بماند و عملیاتها به درستی ادامه یابد.
در نتیجه، تمرکز بر کنترل و نظارت بر لبههای پایگاه داده و تضمین اجرای صحیح invariantها، کلید ارزیابی و بهبود سیستمهای دادهبنیان است. این رویکرد، به صورت عملیاتی، استحکام و قابلیت اطمینان سیستمهای بانک اطلاعاتی را در برابر پیچیدگیهای احتمالی ارتقا میدهد و فرآیندهای کسبوکار را مقاومتر میسازد.
#مدیریت_بانک_اطلاعاتی #پایداری_سیستم #توسعه_نرمافزار #رکوردهای_ایمن
🟣لینک مقاله:
https://blog.gaborkoos.com/posts/2026-08-01-Beyond-Happy-Path-Engineering-Databases/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Gaborkoos
Beyond Happy Path Engineering: Databases
Databases are where correctness becomes shared state: how invariants break under concurrency, when transactions help and when they don't, why reads go stale, and how to design for retries, migrations, and recovery.
🔵 عنوان مقاله
The Dangers of Postgres Subtransactions
🟢 خلاصه مقاله:
در بانکهای اطلاعاتی مانند PostgreSQL، تراکنشها ممکن است شامل زیربخشهایی باشد که به آنها زیرمعاملات (سابترانزاکشنها) گفته میشود. اما اگر تعداد این زیرمعاملات از حد مشخصی، در حدود ۶۴، تجاوز کند، عملکرد سیستم به شدت کاهش مییابد و ممکن است روند عملیات با کندی مواجه شود. در واقع، هرچه تعداد این زیرمعاملات افزایش یابد، میزان کارایی سیستم کاهش یافته و سرعت پردازش تراکنشها کاهش مییابد.
یک آزمایش ساده با ابزار pgbench نشان میدهد که توان عملیاتی سیستم به طور ناگهانی از ۷۲۰۰ تراکنش در ثانیه (TPS) به تنها ۱۶۰ TPS کاهش مییابد. این کاهش چشمگیر در سرعت، مشکلات جدی برای سرویسهای پایگاه داده به وجود میآورد. حتی وضعیت بدتر میشود؛ در نتیجهی این کاهش عملکرد، یک نسخه کپی تازهسازی شده (رید ریپلیکا) ممکن است درخواستهای جدید را رد کند و ارتباط با سرور را به طور کامل قطع کند. این نشان میدهد که مدیریت زیرمعاملات در PostgreSQL اهمیت زیادی دارد و نادیده گرفتن این نکته میتواند منجر به اختلالات جدی در سرویسهای مبتنی بر پایگاه داده شود.
در نتیجه، حتماً باید مراقب بود که تعداد زیرمعاملات در تراکنشها بیش از حد مجاز نشود، زیرا این امر میتواند کل خوشهی پایگاه داده را مختل کرده و کارایی سیستم را به صورت قابل توجهی کاهش دهد.
#پایگاه_داده #PostgreSQL #بهینهسازی #امنیت
🟣لینک مقاله:
https://planetscale.com/blog/the-dangers-of-postgres-subtransactions
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Dangers of Postgres Subtransactions
🟢 خلاصه مقاله:
در بانکهای اطلاعاتی مانند PostgreSQL، تراکنشها ممکن است شامل زیربخشهایی باشد که به آنها زیرمعاملات (سابترانزاکشنها) گفته میشود. اما اگر تعداد این زیرمعاملات از حد مشخصی، در حدود ۶۴، تجاوز کند، عملکرد سیستم به شدت کاهش مییابد و ممکن است روند عملیات با کندی مواجه شود. در واقع، هرچه تعداد این زیرمعاملات افزایش یابد، میزان کارایی سیستم کاهش یافته و سرعت پردازش تراکنشها کاهش مییابد.
یک آزمایش ساده با ابزار pgbench نشان میدهد که توان عملیاتی سیستم به طور ناگهانی از ۷۲۰۰ تراکنش در ثانیه (TPS) به تنها ۱۶۰ TPS کاهش مییابد. این کاهش چشمگیر در سرعت، مشکلات جدی برای سرویسهای پایگاه داده به وجود میآورد. حتی وضعیت بدتر میشود؛ در نتیجهی این کاهش عملکرد، یک نسخه کپی تازهسازی شده (رید ریپلیکا) ممکن است درخواستهای جدید را رد کند و ارتباط با سرور را به طور کامل قطع کند. این نشان میدهد که مدیریت زیرمعاملات در PostgreSQL اهمیت زیادی دارد و نادیده گرفتن این نکته میتواند منجر به اختلالات جدی در سرویسهای مبتنی بر پایگاه داده شود.
در نتیجه، حتماً باید مراقب بود که تعداد زیرمعاملات در تراکنشها بیش از حد مجاز نشود، زیرا این امر میتواند کل خوشهی پایگاه داده را مختل کرده و کارایی سیستم را به صورت قابل توجهی کاهش دهد.
#پایگاه_داده #PostgreSQL #بهینهسازی #امنیت
🟣لینک مقاله:
https://planetscale.com/blog/the-dangers-of-postgres-subtransactions
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Planetscale
The dangers of Postgres subtransactions — PlanetScale
Subtransactions can slow down your entire PostgreSQL server and break your high availability strategy by keeping new read replicas from accepting connections.
🔵 عنوان مقاله
Leveraging Data Assets features in Airflow 3.0 to optimise resource utilization by more than 30% (11 minute read)
🟢 خلاصه مقاله:
در نسخه جدید Airflow 3.0، ویژگیهای مرتبط با منابع داده به منظور بهبود بهرهوری و کارایی سیستم معرفی شده است. یکی از اهداف اصلی این بهروزرسانی، بهینهسازی استفاده از منابع و کاهش نیاز به زیرساختهای قدرتمند است تا عملیاتهای دادهای با صرفهتر و بدون اختلال انجام شوند. این قابلیتها به کاربران امکان میدهد تا با بهرهگیری بهتر از منابع موجود، راندمان سیستمهای کاری خود را بیش از 30 درصد افزایش دهند.
در نمونهای عملی، تیم هلوداک (Halodoc) با بهرهگیری از امکانات جدید آیرفلو، توانست مجموعهای از وظایف کاری (DAGs) خود را از حالتهای قدیمی و مصرفانرژیبر مانند سنسورهای polling و بارگذاریهای همزمان در Redshift به سمت استفاده از ویژگیهای جدید، یعنی اجزای دارایی (Assets) و عملیات تأخیری (deferrable operators) حرکت دهد. این تغییرات نه تنها باعث کاهش قابل توجهی در مصرف CPU و حافظه در سرورهای کارگر (worker) شد، بلکه قابلیتهای سیستم را در مدیریت بار و خطایابی نیز بهبود بخشید.
در نتیجه، در مجموع 160 وظیفه کاری در این عملیات بهبود یافته، میزان مصرف CPU در سرورهای کارگر از 26.1 درصد به 7.71 درصد کاهش یافت و مصرف حافظه نیز از 49.2 درصد به 30.8 درصد رسید. علاوه بر این، بار پیشفرض بر روی برنامهریز (scheduler) کاهش یافته و خطاهای مربوط به قفل کردن جداول در Redshift، که در فرآیندهای دادهای معمولاً مشکلساز بودند، حدود 38 درصد کمتر شد. این پیشرفتها نشان میدهد که استفاده بهینه از ویژگیهای جدید Airflow، چگونه میتواند منجر به کاهش هزینهها و بهبود کارایی سیستمهای دادهای بزرگ و پیچیده شود.
#هوشمندسازی_داده #مدیریت_عملیات_داده #آیرفلو #بهینهسازی_سیستم
🟣لینک مقاله:
https://blogs.halodoc.io/leveraging-data-assets-features-in-airflow-3-0-to-optimise-resource-utilization-by-more-than-30/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Leveraging Data Assets features in Airflow 3.0 to optimise resource utilization by more than 30% (11 minute read)
🟢 خلاصه مقاله:
در نسخه جدید Airflow 3.0، ویژگیهای مرتبط با منابع داده به منظور بهبود بهرهوری و کارایی سیستم معرفی شده است. یکی از اهداف اصلی این بهروزرسانی، بهینهسازی استفاده از منابع و کاهش نیاز به زیرساختهای قدرتمند است تا عملیاتهای دادهای با صرفهتر و بدون اختلال انجام شوند. این قابلیتها به کاربران امکان میدهد تا با بهرهگیری بهتر از منابع موجود، راندمان سیستمهای کاری خود را بیش از 30 درصد افزایش دهند.
در نمونهای عملی، تیم هلوداک (Halodoc) با بهرهگیری از امکانات جدید آیرفلو، توانست مجموعهای از وظایف کاری (DAGs) خود را از حالتهای قدیمی و مصرفانرژیبر مانند سنسورهای polling و بارگذاریهای همزمان در Redshift به سمت استفاده از ویژگیهای جدید، یعنی اجزای دارایی (Assets) و عملیات تأخیری (deferrable operators) حرکت دهد. این تغییرات نه تنها باعث کاهش قابل توجهی در مصرف CPU و حافظه در سرورهای کارگر (worker) شد، بلکه قابلیتهای سیستم را در مدیریت بار و خطایابی نیز بهبود بخشید.
در نتیجه، در مجموع 160 وظیفه کاری در این عملیات بهبود یافته، میزان مصرف CPU در سرورهای کارگر از 26.1 درصد به 7.71 درصد کاهش یافت و مصرف حافظه نیز از 49.2 درصد به 30.8 درصد رسید. علاوه بر این، بار پیشفرض بر روی برنامهریز (scheduler) کاهش یافته و خطاهای مربوط به قفل کردن جداول در Redshift، که در فرآیندهای دادهای معمولاً مشکلساز بودند، حدود 38 درصد کمتر شد. این پیشرفتها نشان میدهد که استفاده بهینه از ویژگیهای جدید Airflow، چگونه میتواند منجر به کاهش هزینهها و بهبود کارایی سیستمهای دادهای بزرگ و پیچیده شود.
#هوشمندسازی_داده #مدیریت_عملیات_داده #آیرفلو #بهینهسازی_سیستم
🟣لینک مقاله:
https://blogs.halodoc.io/leveraging-data-assets-features-in-airflow-3-0-to-optimise-resource-utilization-by-more-than-30/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Halodoc Blog
Leveraging Data Assets features in Airflow 3.0 to optimise resource utilization by more than 30%
How Halodoc cut Airflow worker CPU by over 70% using Data Assets and the deferrable Redshift operator, plus the bugs we hit upgrading to Airflow 3.2.1 along the way.
🔵 عنوان مقاله
Everyone Records the MySQL Audit Log. Nobody Reads It (4 minute read)
🟢 خلاصه مقاله:
همگی وارد کردن لاگهای نظارتی MySQL را انجام میدهند، اما کمتر کسی به آنها توجه میکند و آنها را مطالعه میکند. این موضوع یکی از چالشهای مشترک در مدیریت پایگاههای داده است، زیرا لاگهای نظارتی اطلاعات ارزشمندی را درباره فعالیتهای سیستم در اختیار مدیران قرار میدهند، اما به دلیل حجم زیاد و پیچیدگیهای فنی، اغلب نادیده گرفته میشوند یا به سختی تحلیل میشوند.
در این راستا، ابزار "DB Trail" راه حلی نوآورانه ارائه میدهد که امکان جستجوی در لاگهای نظارتی MySQL را به شکل موثرتر و کارآمدتر فراهم میکند. این ابزار با اتصال تغییرات رکوردها به شناسه نشست (session)، دستورات SQL و تصاویر قبل از تغییر، ثبت وقایع را قابل جستجو و تحلیل میسازد. بنابراین، مدیران دیتابیس میتوانند با دقت بیشتری فعالیتهای مخرب یا اشتباهات کاربر را پیگیری کنند و پاسخهای قابل استناد در سطح ردیفها دریافت نمایند.
علاوه بر این، DB Trail پاسخهایی با نسبت دادن دقیقتر ارائه میدهد که برای عملیات مخرب یا خطرناک بسیار مفید است. این ابزار قادر است دستورات SQL لغو تراکنش را به صورت خودکار تولید کند تا بتوان دادههای آسیبدیده را برگرداند و وضعیت پیش از خطای رخ داده را بازیابی کرد. این ویژگی، قابل اعتماد بودن و امنیت سیستمهای پایگاه دادههای بزرگ را افزایش میدهد و عملیات بازسازی داده را بسیار سادهتر میکند.
در نتیجه، استفاده از ابزارهایی مانند DB Trail نه تنها روند نظارت بر فعالیتهای MySQL را بهبود میبخشد، بلکه کنترل و امنیت بانکهای اطلاعاتی را نیز تقویت میکند و نقش حیاتی در مدیریت دادههای حساس ایفا میکند.
#مدیریت_پایگاه_داده #امنیت_سیستم #MySQL #نظارت
🟣لینک مقاله:
https://blog.dbtrail.com/everyone-records-the-mysql-audit-log/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Everyone Records the MySQL Audit Log. Nobody Reads It (4 minute read)
🟢 خلاصه مقاله:
همگی وارد کردن لاگهای نظارتی MySQL را انجام میدهند، اما کمتر کسی به آنها توجه میکند و آنها را مطالعه میکند. این موضوع یکی از چالشهای مشترک در مدیریت پایگاههای داده است، زیرا لاگهای نظارتی اطلاعات ارزشمندی را درباره فعالیتهای سیستم در اختیار مدیران قرار میدهند، اما به دلیل حجم زیاد و پیچیدگیهای فنی، اغلب نادیده گرفته میشوند یا به سختی تحلیل میشوند.
در این راستا، ابزار "DB Trail" راه حلی نوآورانه ارائه میدهد که امکان جستجوی در لاگهای نظارتی MySQL را به شکل موثرتر و کارآمدتر فراهم میکند. این ابزار با اتصال تغییرات رکوردها به شناسه نشست (session)، دستورات SQL و تصاویر قبل از تغییر، ثبت وقایع را قابل جستجو و تحلیل میسازد. بنابراین، مدیران دیتابیس میتوانند با دقت بیشتری فعالیتهای مخرب یا اشتباهات کاربر را پیگیری کنند و پاسخهای قابل استناد در سطح ردیفها دریافت نمایند.
علاوه بر این، DB Trail پاسخهایی با نسبت دادن دقیقتر ارائه میدهد که برای عملیات مخرب یا خطرناک بسیار مفید است. این ابزار قادر است دستورات SQL لغو تراکنش را به صورت خودکار تولید کند تا بتوان دادههای آسیبدیده را برگرداند و وضعیت پیش از خطای رخ داده را بازیابی کرد. این ویژگی، قابل اعتماد بودن و امنیت سیستمهای پایگاه دادههای بزرگ را افزایش میدهد و عملیات بازسازی داده را بسیار سادهتر میکند.
در نتیجه، استفاده از ابزارهایی مانند DB Trail نه تنها روند نظارت بر فعالیتهای MySQL را بهبود میبخشد، بلکه کنترل و امنیت بانکهای اطلاعاتی را نیز تقویت میکند و نقش حیاتی در مدیریت دادههای حساس ایفا میکند.
#مدیریت_پایگاه_داده #امنیت_سیستم #MySQL #نظارت
🟣لینک مقاله:
https://blog.dbtrail.com/everyone-records-the-mysql-audit-log/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
dbtrail
Everyone Records the MySQL Audit Log. Nobody Reads It. - dbtrail
Everyone records audit logs. Almost nobody reads them, because reading them means grep on the database server, a cursor with no WHERE clause, or a log pipeline that costs thousands a year. There is a cheaper shape: keep the answer, not the log. And you do…
🔵 عنوان مقاله
Unveiling a 13-Year-Old Postgres Bug in Cascading Replication
🟢 خلاصه مقاله:
در دنیای پایگاههای داده، مشکلات و آسیبپذیریها همواره میتوانند چالشهای جدی ایجاد کنند، مخصوصاً زمانی که مربوط به سیستمهای حیاتی مانند سیستمهای تکرار و همزمانی دادهها باشد. اخیراً یک باگ قدیمی در نسخههایی از پایگاه داده پستگرس کشف شده است که به مدت ۱۳ سال در سیستم باقی مانده و هنوز هم ممکن است در موارد خاص مشکلات جدی ایجاد کند.
این مشکل مرتبط با نسخهی قدیمی پستگرس ۹.۳ است و در زمان عرضهی آن، یک محافظ امنیتی برای تکرار استریم (Streaming Replication) در نظر گرفته شده بود. این محافظ هدف داشت از ارتباط پایگاههای ثانویه (standby) که به صورت زنجیرهوار و سلسلهوار با یکدیگر ارتباط داشتند، در برابر حالتهایی که سیستم به حالت بازیابی آرشیو (archive recovery) برمیگردد، محافظت کند. اما با وجود این محافظ، هنگامی که یک سرور ثانویه پس از سقوط یا خطای سیستم به حالت بازیابی آرشیو برمیگشت، یک مشکل فنی رخ میداد: این محافظ میتوانست در عمل، اتصال سرورهای ثانویه را به سرورهای upstream خود قطع و قفل کند، و این امر مانع از ادامه دریافت دادههای تکرار در حالت اکتیو میشد.
این باگ، با توجه به قدمت بیش از یک دههاش، بهعنوان یکی از ثباتسازهای قدیمی سیستم محسوب میشود، اما نشان میدهد که حتی در سیستمهای پایدار و محبوبی مانند پستگرس، باگهای پنهان و قدیمی هم میتوانند بهراحتی منشأ مشکلات بزرگ شوند، به خصوص در فعالهایی که نیازمند تداوم عملیات و هماهنگی دقیق هستند. در نتیجه، مدیریت و بهروزرسانی منظم سیستمهای پایگاه داده، امری حیاتی است که میتواند از بروز رویدادهای ناخواسته جلوگیری کند و امنیت عملیاتهای حیاتی را تضمین نماید.
این کشف به ما یادآوری میکند که نگهداری و بررسی مداوم سیستمها، حتی آنهایی با سابقهی طولانی، اهمیت بسیار زیادی دارد. با توجه به اینکه این مشکل هنوز در برخی نسخههای قدیمی دیده میشود، توصیه میشود کاربران و مدیران پایگاه داده، سیستمهای خود را بهروز نگه دارند و از بروزرسانیهای امنیتی و اصلاحیهها بهرهمند شوند تا در مقابل چنین آسیبپذیریهایی محافظت شده و بتوانند عملیات خود را بدون مشکل ادامه دهند.
#پایگاهداده #پستگرس #تکرار_و_همزمانی #امنیتاطلاعات
🟣لینک مقاله:
https://www.enterprisedb.com/blog/13-year-old-postgresql-bug-found-running-postgres-kubernetes-cloudnativepg
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Unveiling a 13-Year-Old Postgres Bug in Cascading Replication
🟢 خلاصه مقاله:
در دنیای پایگاههای داده، مشکلات و آسیبپذیریها همواره میتوانند چالشهای جدی ایجاد کنند، مخصوصاً زمانی که مربوط به سیستمهای حیاتی مانند سیستمهای تکرار و همزمانی دادهها باشد. اخیراً یک باگ قدیمی در نسخههایی از پایگاه داده پستگرس کشف شده است که به مدت ۱۳ سال در سیستم باقی مانده و هنوز هم ممکن است در موارد خاص مشکلات جدی ایجاد کند.
این مشکل مرتبط با نسخهی قدیمی پستگرس ۹.۳ است و در زمان عرضهی آن، یک محافظ امنیتی برای تکرار استریم (Streaming Replication) در نظر گرفته شده بود. این محافظ هدف داشت از ارتباط پایگاههای ثانویه (standby) که به صورت زنجیرهوار و سلسلهوار با یکدیگر ارتباط داشتند، در برابر حالتهایی که سیستم به حالت بازیابی آرشیو (archive recovery) برمیگردد، محافظت کند. اما با وجود این محافظ، هنگامی که یک سرور ثانویه پس از سقوط یا خطای سیستم به حالت بازیابی آرشیو برمیگشت، یک مشکل فنی رخ میداد: این محافظ میتوانست در عمل، اتصال سرورهای ثانویه را به سرورهای upstream خود قطع و قفل کند، و این امر مانع از ادامه دریافت دادههای تکرار در حالت اکتیو میشد.
این باگ، با توجه به قدمت بیش از یک دههاش، بهعنوان یکی از ثباتسازهای قدیمی سیستم محسوب میشود، اما نشان میدهد که حتی در سیستمهای پایدار و محبوبی مانند پستگرس، باگهای پنهان و قدیمی هم میتوانند بهراحتی منشأ مشکلات بزرگ شوند، به خصوص در فعالهایی که نیازمند تداوم عملیات و هماهنگی دقیق هستند. در نتیجه، مدیریت و بهروزرسانی منظم سیستمهای پایگاه داده، امری حیاتی است که میتواند از بروز رویدادهای ناخواسته جلوگیری کند و امنیت عملیاتهای حیاتی را تضمین نماید.
این کشف به ما یادآوری میکند که نگهداری و بررسی مداوم سیستمها، حتی آنهایی با سابقهی طولانی، اهمیت بسیار زیادی دارد. با توجه به اینکه این مشکل هنوز در برخی نسخههای قدیمی دیده میشود، توصیه میشود کاربران و مدیران پایگاه داده، سیستمهای خود را بهروز نگه دارند و از بروزرسانیهای امنیتی و اصلاحیهها بهرهمند شوند تا در مقابل چنین آسیبپذیریهایی محافظت شده و بتوانند عملیات خود را بدون مشکل ادامه دهند.
#پایگاهداده #پستگرس #تکرار_و_همزمانی #امنیتاطلاعات
🟣لینک مقاله:
https://www.enterprisedb.com/blog/13-year-old-postgresql-bug-found-running-postgres-kubernetes-cloudnativepg
➖➖➖➖➖➖➖➖
👑 @Database_Academy
EDB
A 13-year-old PostgreSQL bug, found by running Postgres on Kubernetes with CloudNativePG
Every so often, running Postgres differently teaches the project something it couldn't have learned any other way. This is one of those times. A cascading standby reconnect bug that has been sitting in PostgreSQL's streaming replication code since version…
🔵 عنوان مقاله
OpenAI Just Made Analytics 10x Cheaper (6 minute read)
🟢 خلاصه مقاله:
شرکت OpenAI به تازگی تحولی بزرگ در حوزه تحلیلها و تجزیه و تحلیل دادهها ایجاد کرده است که میتواند به شکل قابل توجهی هزینهها را کاهش دهد. نسخه جدید GPT 5.6 Luna این شرکت، با تمرکز بر تحلیلهای عاملمحور و بهرهگیری از مدلهای کوچک و سریع، بازار را دگرگون کرده است. این مدلها به همراه پایگاههای داده تحلیلی کمتاخیر، قادرند پاسخهای SQL بسیار دقیقی را با هزینه کمتر از نیم سنت ارائه دهند، که این امر امکان انجام ارزیابیهای مکرر و گستردهتر را به شکل اقتصادیتر فراهم میکند.
در گذشته، رهبری در این حوزه معمولا به مدلهای بزرگ و پیچیده اختصاص داشت، اما اکنون مزیت اصلی به سمت استفاده از متنهای کسبوکار قوی، ارزیابیهای بدون وابستگی به مدل خاص، و پلتفرمهای داده واکنشپذیر متمرکز شده است. این رویکرد باعث کاهش هزینهها و افزایش سرعت در تحلیل دادهها شده و فرصتهای جدیدی برای کسبوکارهای مختلف فراهم میآورد.
این تغییرات نه تنها هزینههای مربوط به تحلیل و ارزیابی دادهها را بسیار کاهش میدهد، بلکه امکان بهرهبرداری سریعتر و کارآمدتر از دادههای سازمانی را نیز فراهم میکند. استفاده از مدلهای کوچک اما قدرتمند، همراه با زیرساختهای مناسب، در کنار ارزیابیهای جامع و مستقل، نوید آیندهای پررونق برای حوزه هوش مصنوعی و تحلیل دادهها را میدهد.
در نتیجه، OpenAI با این نوآوری، مفهومی جدید در تحلیلهای دادهای ارائه کرده است که میتواند بهرهوری کسبوکارها را افزایش داده و هزینهها را به طور چشمگیری کاهش دهد، و زمینهساز موج جدیدی از توسعه فناوریهای هوش مصنوعی باشد.
#هوش مصنوعی #تحلیل داده #کاهش هزینه #فناوری
🟣لینک مقاله:
https://motherduck.com/blog/openai-just-made-analytics-10x-cheaper/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
OpenAI Just Made Analytics 10x Cheaper (6 minute read)
🟢 خلاصه مقاله:
شرکت OpenAI به تازگی تحولی بزرگ در حوزه تحلیلها و تجزیه و تحلیل دادهها ایجاد کرده است که میتواند به شکل قابل توجهی هزینهها را کاهش دهد. نسخه جدید GPT 5.6 Luna این شرکت، با تمرکز بر تحلیلهای عاملمحور و بهرهگیری از مدلهای کوچک و سریع، بازار را دگرگون کرده است. این مدلها به همراه پایگاههای داده تحلیلی کمتاخیر، قادرند پاسخهای SQL بسیار دقیقی را با هزینه کمتر از نیم سنت ارائه دهند، که این امر امکان انجام ارزیابیهای مکرر و گستردهتر را به شکل اقتصادیتر فراهم میکند.
در گذشته، رهبری در این حوزه معمولا به مدلهای بزرگ و پیچیده اختصاص داشت، اما اکنون مزیت اصلی به سمت استفاده از متنهای کسبوکار قوی، ارزیابیهای بدون وابستگی به مدل خاص، و پلتفرمهای داده واکنشپذیر متمرکز شده است. این رویکرد باعث کاهش هزینهها و افزایش سرعت در تحلیل دادهها شده و فرصتهای جدیدی برای کسبوکارهای مختلف فراهم میآورد.
این تغییرات نه تنها هزینههای مربوط به تحلیل و ارزیابی دادهها را بسیار کاهش میدهد، بلکه امکان بهرهبرداری سریعتر و کارآمدتر از دادههای سازمانی را نیز فراهم میکند. استفاده از مدلهای کوچک اما قدرتمند، همراه با زیرساختهای مناسب، در کنار ارزیابیهای جامع و مستقل، نوید آیندهای پررونق برای حوزه هوش مصنوعی و تحلیل دادهها را میدهد.
در نتیجه، OpenAI با این نوآوری، مفهومی جدید در تحلیلهای دادهای ارائه کرده است که میتواند بهرهوری کسبوکارها را افزایش داده و هزینهها را به طور چشمگیری کاهش دهد، و زمینهساز موج جدیدی از توسعه فناوریهای هوش مصنوعی باشد.
#هوش مصنوعی #تحلیل داده #کاهش هزینه #فناوری
🟣لینک مقاله:
https://motherduck.com/blog/openai-just-made-analytics-10x-cheaper/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
MotherDuck
OpenAI Just Made Analytics 10x Cheaper
Since OpenAI slashed the price of GPT 5.6 Luna by 80% this week, low latency AI-powered answers are finally feasible for less than half a penny per answer, AI and DB costs included.
For data questions, GPT 5.6 Luna is intelligence too cheap to meter.
Well…
For data questions, GPT 5.6 Luna is intelligence too cheap to meter.
Well…