🔵 عنوان مقاله
Tinbase: A Supabase-Compatible Backend in a Single Binary
🟢 خلاصه مقاله:
تلبیس (Tinbase) یک سامانه بکاند سازگار با سرویس Supabase است که در قالب یک باینری واحد و مستقل ارائه میشود. این پروژه به عنوان یک آزمایش طراحی شده است تا توسعهدهندگان بتوانند تجربهای مشابه با محیط توسعه Supabase را به صورت محلی و بدون نیاز به Docker داشته باشند. بر خلاف روشهای مرسوم که بسیاری از این ابزارها نیازمند استفاده از کانتینرهای Docker هستند، تلبیس با بهرهگیری از فناوریهای مبتنی بر JavaScript، همچون PGlite و pg-mem، یک سرور پایگاه داده سبک و قابل اجرا در محیطهای توسعه فردی ارائه میدهد.
این سامانه به نوعی مینیوورک لوکال از پایگاه داده PostgreSQL است که به صورت کامل و دقیق، همان APIهای مورد استفاده در سرویسهای اصلی Supabase را دارد. این موضوع به توسعهدهندگان اجازه میدهد که با همان روال و ابزارهای رایج، برنامههای خود را توسعه و آزمایش کنند، بدون آنکه نیاز باشد زیرساختهای سنگین و پیچیده مانند Docker و Kubernetes را بر روی سیستم خود راهاندازی کنند. در نتیجه، کار با تلبیس بسیار سریع، ساده و کارآمد است و فرآیند توسعه را تسهیل میکند.
به طور خلاصه، تلبیس یک ابزار بسیار مؤثر و سبک است که امکان ایجاد محیطهای توسعه محلی مشابه با سرورهای ابری Supabase را فراهم میآورد، و این کار را تنها با یک فایل باینری و بدون نیاز به سرویسهای خارجی انجام میدهد. این پروژه، گزینهای جذاب برای توسعهدهندگان است که به دنبال صرفهجویی در زمان و منابع و تسهیل فرآیند مبتنی بر APIهای استاندارد هستند.
#پیشرفت_توسعه #پایگاه_داده #برنامهنویسی #توسعه_محلی
🟣لینک مقاله:
https://github.com/tinbase/tinbase
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Tinbase: A Supabase-Compatible Backend in a Single Binary
🟢 خلاصه مقاله:
تلبیس (Tinbase) یک سامانه بکاند سازگار با سرویس Supabase است که در قالب یک باینری واحد و مستقل ارائه میشود. این پروژه به عنوان یک آزمایش طراحی شده است تا توسعهدهندگان بتوانند تجربهای مشابه با محیط توسعه Supabase را به صورت محلی و بدون نیاز به Docker داشته باشند. بر خلاف روشهای مرسوم که بسیاری از این ابزارها نیازمند استفاده از کانتینرهای Docker هستند، تلبیس با بهرهگیری از فناوریهای مبتنی بر JavaScript، همچون PGlite و pg-mem، یک سرور پایگاه داده سبک و قابل اجرا در محیطهای توسعه فردی ارائه میدهد.
این سامانه به نوعی مینیوورک لوکال از پایگاه داده PostgreSQL است که به صورت کامل و دقیق، همان APIهای مورد استفاده در سرویسهای اصلی Supabase را دارد. این موضوع به توسعهدهندگان اجازه میدهد که با همان روال و ابزارهای رایج، برنامههای خود را توسعه و آزمایش کنند، بدون آنکه نیاز باشد زیرساختهای سنگین و پیچیده مانند Docker و Kubernetes را بر روی سیستم خود راهاندازی کنند. در نتیجه، کار با تلبیس بسیار سریع، ساده و کارآمد است و فرآیند توسعه را تسهیل میکند.
به طور خلاصه، تلبیس یک ابزار بسیار مؤثر و سبک است که امکان ایجاد محیطهای توسعه محلی مشابه با سرورهای ابری Supabase را فراهم میآورد، و این کار را تنها با یک فایل باینری و بدون نیاز به سرویسهای خارجی انجام میدهد. این پروژه، گزینهای جذاب برای توسعهدهندگان است که به دنبال صرفهجویی در زمان و منابع و تسهیل فرآیند مبتنی بر APIهای استاندارد هستند.
#پیشرفت_توسعه #پایگاه_داده #برنامهنویسی #توسعه_محلی
🟣لینک مقاله:
https://github.com/tinbase/tinbase
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - tinbase/tinbase: Supabase-compatible backend in a single binary — real Postgres with RLS, no Docker. Works with supabase…
Supabase-compatible backend in a single binary — real Postgres with RLS, no Docker. Works with supabase-js unchanged. - tinbase/tinbase
مدیریت backup از database به صورت Self-hosted با رابط کاربری وب. زمانبندی، پشتیبانگیری و بازیابی MySQL، PostgreSQL، MariaDB، Microsoft SQL Server، MongoDB، SQLite و Redis در S3، SFTP یا فضای local storage. پشتیبانی از تونل SSH.
github.com/David-Crty/databasement
<MehrdadLinux/>
github.com/David-Crty/databasement
<MehrdadLinux/>
GitHub
GitHub - David-Crty/databasement: Self-hosted database backup manager with a web UI. Schedule, backup, and restore MySQL, PostgreSQL…
Self-hosted database backup manager with a web UI. Schedule, backup, and restore MySQL, PostgreSQL, MariaDB, Microsoft SQL Server, MongoDB, SQLite & Redis to S3, SFTP, Samba or local storag...
🔵 عنوان مقاله
How to Achieve Pruning When Querying by Non-Partitioned Columns
🟢 خلاصه مقاله:
وقتی در حال انجام پرسوجو بر روی ستونی غیر از ستونهای تقسیمبندی هستید، موضوع بهینهسازی عملکرد و کاهش زمان پاسخدهی اهمیت زیادی دارد. در مواردی که ستون غیرتقسیمبندی با کلید تقسیمبندی ارتباط نزدیکی دارد، ممکن است بتوانید از تکنیکهایی استفاده کنید تا خروجیهای سریعتری دریافت کنید و سیستم را بهتر توسعه دهید. این فرآیند «پران کردن» (pruning) در واقع به معنای محدود کردن بخشهای درگیر در فرضیههای پرسوجو است، که باعث کاهش حجم دادههای پردازش شده میشود.
برای یافتن بهترین روش در این زمینه، ابتدا باید درک کنید که چگونه ارتباط بین ستونهای غیرتقسیمبندی و کلیدهای تقسیمبندی به عملکرد پرسوجو کمک میکند. اگر رابطه قوی وجود داشته باشد، میتوانید با استفاده از استراتژیهایی مانند ایجاد اندیسهای مناسب یا بهرهگیری از قابلیتهای خاص سیستم مدیریت پایگاه داده، به طور مؤثری بخشهای بیارتباط را حذف کنید. این امر منجر به کاسته شدن زمان پاسخ و افزایش سرعت اجرای پرسوجو میشود، بهخصوص در جداول بزرگ.
در کل، بهرهگیری از این تکنیکهای پارامتریک و هوشمندانه در طراحی پایگاه داده باعث میشود که کار شما در بازیابی اطلاعات سریعتر و موثرتر باشد. بنابراین، رعایت بهترین شیوهها و آشنایی با امکانات سیستمهای مدیریت پایگاه داده، کلید موفقیت در حذف قسمتهای بیارتباط و رسیدن به نتایج سریع است.
برای بهبود کارایی فرآیند پرسوجو، نیاز است تا استراتژیهای مورداستفاده را بر اساس ویژگیهای خاص دادهها و نیازهای عملیاتی تنظیم کنید. با این رویکرد، قادر خواهید بود علاوه بر حفظ صحت نتایج، زمان اجرای پرسوجو را نیز به شدت کاهش دهید و عملکرد سیستم خود را ارتقاء بخشید.
#پایگاه_داده #پرسوجو #بهینهسازی #پولن
🟣لینک مقاله:
https://hakibenita.com/postgresql-partition-pruning
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How to Achieve Pruning When Querying by Non-Partitioned Columns
🟢 خلاصه مقاله:
وقتی در حال انجام پرسوجو بر روی ستونی غیر از ستونهای تقسیمبندی هستید، موضوع بهینهسازی عملکرد و کاهش زمان پاسخدهی اهمیت زیادی دارد. در مواردی که ستون غیرتقسیمبندی با کلید تقسیمبندی ارتباط نزدیکی دارد، ممکن است بتوانید از تکنیکهایی استفاده کنید تا خروجیهای سریعتری دریافت کنید و سیستم را بهتر توسعه دهید. این فرآیند «پران کردن» (pruning) در واقع به معنای محدود کردن بخشهای درگیر در فرضیههای پرسوجو است، که باعث کاهش حجم دادههای پردازش شده میشود.
برای یافتن بهترین روش در این زمینه، ابتدا باید درک کنید که چگونه ارتباط بین ستونهای غیرتقسیمبندی و کلیدهای تقسیمبندی به عملکرد پرسوجو کمک میکند. اگر رابطه قوی وجود داشته باشد، میتوانید با استفاده از استراتژیهایی مانند ایجاد اندیسهای مناسب یا بهرهگیری از قابلیتهای خاص سیستم مدیریت پایگاه داده، به طور مؤثری بخشهای بیارتباط را حذف کنید. این امر منجر به کاسته شدن زمان پاسخ و افزایش سرعت اجرای پرسوجو میشود، بهخصوص در جداول بزرگ.
در کل، بهرهگیری از این تکنیکهای پارامتریک و هوشمندانه در طراحی پایگاه داده باعث میشود که کار شما در بازیابی اطلاعات سریعتر و موثرتر باشد. بنابراین، رعایت بهترین شیوهها و آشنایی با امکانات سیستمهای مدیریت پایگاه داده، کلید موفقیت در حذف قسمتهای بیارتباط و رسیدن به نتایج سریع است.
برای بهبود کارایی فرآیند پرسوجو، نیاز است تا استراتژیهای مورداستفاده را بر اساس ویژگیهای خاص دادهها و نیازهای عملیاتی تنظیم کنید. با این رویکرد، قادر خواهید بود علاوه بر حفظ صحت نتایج، زمان اجرای پرسوجو را نیز به شدت کاهش دهید و عملکرد سیستم خود را ارتقاء بخشید.
#پایگاه_داده #پرسوجو #بهینهسازی #پولن
🟣لینک مقاله:
https://hakibenita.com/postgresql-partition-pruning
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Hakibenita
How to Achieve Pruning When Querying by Non-Partitioned Columns in PostgreSQL
Under conventional wisdom, pruning can only be achieved when querying by the partition key. However, if your data follows certain patterns, using some clever tricks you can achieve pruning even when filtering by non-partition key columns.
🔵 عنوان مقاله
pg_re2: Fast, RE2-Powered Regular Expressions in Postgres
🟢 خلاصه مقاله:
در دنیای رایانش، کارایی و سرعت اجرای عملیاتهای پیچیده اهمیت ویژهای دارد، مخصوصاً زمانی که صحبت از عبارات منظم یا همان Regular Expressions باشد. شرکت گوگل با توسعه کتابخانه re2، سعی در ارائه یک روش سریع و قابل پیشبینی برای پردازش این عبارات دارد. بر خلاف رویکرد سنتی مبتنی برBacktracking که ممکن است در موارد خاص زمان اجرای غیرقابل پیشبینی و طولانی به دنبال داشته باشد، re2 هدفش ارائه زمان اجرای ثابت و مطمئن است؛ به همین دلیل است که توسعهدهندگان ترجیح میدهند از آن در پروژههای حساس و بزرگ بهرهمند شوند.
در جدیدترین امکانات و بهروزرسانیها، توسعهدهندگان پایگاه دادههای PostgreSQL توانستند از قابلیتهای re2 بهرهمند شوند تا فرآیند جستجوی الگوهای رشتهای در جداول بزرگ، با سرعت و کارایی بیشتری انجام پذیرد. نمونهای از این کاربردها در پروژههای قدرتمند مانند ClickHouse دیده میشود که نحوه استفاده از re2 درونی PostgreSQL را به نمایش میگذارند. این ادغام نه تنها بهبودهای قابل توجهی در سرعت عملیات جستجو و فیلتر کردن دادهها ایجاد میکند، بلکه اطمینان میدهد که عملیاتهای پیچیده با زمانبندی از پیش مشخص و قابل اعتماد اجرا میشوند. در نهایت، این تکنولوژی به توسعهدهندگان و کاربران کمک میکند تا با اطمینان بیشتری دادههای بزرگ و پیچیده را مدیریت و تحلیل کنند، بدون نگرانی از کندی یا ناپایداری در زمان اجرا.
در نتیجه، استفاده از re2 در PostgreSQL نه تنها بهرهوری سیستمی را افزایش میدهد بلکه امکاناتی را برای توسعهدهندگان فراهم میکند تا بتوانند به راحتی و با اطمینان عملیات جستجوی پیچیده و محدودکننده را در پایگاههای داده خود اجرا کنند. این ترکیب قدرتمند، نویدبخش آیندهای پرکاربرد برای سیستمهای پایگاه داده است که در آن سرعت و پیشبینیپذیری همزمان حفظ میشود.
#پایگاه_داده #تکنولوژی_پایگاه_داده #عبارات_منظم #رایانش
🟣لینک مقاله:
https://clickhouse.com/blog/introducing-pg_re2-regex-in-postgres
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pg_re2: Fast, RE2-Powered Regular Expressions in Postgres
🟢 خلاصه مقاله:
در دنیای رایانش، کارایی و سرعت اجرای عملیاتهای پیچیده اهمیت ویژهای دارد، مخصوصاً زمانی که صحبت از عبارات منظم یا همان Regular Expressions باشد. شرکت گوگل با توسعه کتابخانه re2، سعی در ارائه یک روش سریع و قابل پیشبینی برای پردازش این عبارات دارد. بر خلاف رویکرد سنتی مبتنی برBacktracking که ممکن است در موارد خاص زمان اجرای غیرقابل پیشبینی و طولانی به دنبال داشته باشد، re2 هدفش ارائه زمان اجرای ثابت و مطمئن است؛ به همین دلیل است که توسعهدهندگان ترجیح میدهند از آن در پروژههای حساس و بزرگ بهرهمند شوند.
در جدیدترین امکانات و بهروزرسانیها، توسعهدهندگان پایگاه دادههای PostgreSQL توانستند از قابلیتهای re2 بهرهمند شوند تا فرآیند جستجوی الگوهای رشتهای در جداول بزرگ، با سرعت و کارایی بیشتری انجام پذیرد. نمونهای از این کاربردها در پروژههای قدرتمند مانند ClickHouse دیده میشود که نحوه استفاده از re2 درونی PostgreSQL را به نمایش میگذارند. این ادغام نه تنها بهبودهای قابل توجهی در سرعت عملیات جستجو و فیلتر کردن دادهها ایجاد میکند، بلکه اطمینان میدهد که عملیاتهای پیچیده با زمانبندی از پیش مشخص و قابل اعتماد اجرا میشوند. در نهایت، این تکنولوژی به توسعهدهندگان و کاربران کمک میکند تا با اطمینان بیشتری دادههای بزرگ و پیچیده را مدیریت و تحلیل کنند، بدون نگرانی از کندی یا ناپایداری در زمان اجرا.
در نتیجه، استفاده از re2 در PostgreSQL نه تنها بهرهوری سیستمی را افزایش میدهد بلکه امکاناتی را برای توسعهدهندگان فراهم میکند تا بتوانند به راحتی و با اطمینان عملیات جستجوی پیچیده و محدودکننده را در پایگاههای داده خود اجرا کنند. این ترکیب قدرتمند، نویدبخش آیندهای پرکاربرد برای سیستمهای پایگاه داده است که در آن سرعت و پیشبینیپذیری همزمان حفظ میشود.
#پایگاه_داده #تکنولوژی_پایگاه_داده #عبارات_منظم #رایانش
🟣لینک مقاله:
https://clickhouse.com/blog/introducing-pg_re2-regex-in-postgres
➖➖➖➖➖➖➖➖
👑 @Database_Academy
ClickHouse
Introducing pg_re2, fast, RE2-powered regular expressions in Postgres | ClickHouse
Introducing pg_re2, a Postgres extension that brings ClickHouse's fast RE2-powered regular expressions to Postgres, with benchmarks and pg_clickhouse pushdown integration.
🔵 عنوان مقاله
How Expedia Group Builds AI That Lasts at Scale (8 minute read)
🟢 خلاصه مقاله:
شرکت Expedia Group برای توسعه هوش مصنوعی پایدار و مقیاسپذیر، چارچوبی مبتنی بر اصول مشخصی ایجاد کرده است. یکی از مهمترین اصول این است که هر مدلی که تولید میشود باید به نتیجههای قابل اندازهگیری در کسبوکار مرتبط باشد. این رویکرد باعث میشود که توسعه و بهرهبرداری از مدلهای هوش مصنوعی همواره در راستای اهداف تجاری شرکت باشد و اثربخشی آنها قابل ارزیابی و بهبود مداوم باشد. علاوه بر این، تیمهای توسعهدهنده بر پایه زیرساختهای مشترک و استاندارد ساخته شدهاند، نه بر اساس سیستمهای سفارشی و منفرد، که این امر موجب سهولت در مدیریت، ارتقاء و نگهداری فناوری میشود. در نهایت، برای هر مدل، مسئولانی در بخشهای مختلف از جمله کسبوکار، محصول، هوش مصنوعی و عملیات مشخص شدهاند، که این امر تضمین میکند که توسعه و استقرار هوش مصنوعی به صورت هماهنگ و مسئولانه انجام گیرد. این رویکرد جامع و منسجم، به Expedia امکان میدهد هوش مصنوعی را نه تنها در مقیاس بزرگ، بلکه با دوام و پایدار در آزمون زمان توسعه دهد و از مزایای آن در بهبود تجربه مسافران و افزایش کارایی بهره ببرد.
#هوش_مصنوعی #توسعه_پایدار #تکنولوژی #کسبوکار
🟣لینک مقاله:
https://medium.com/expedia-group-tech/how-expedia-group-builds-ai-that-lasts-at-scale-434677770fe9?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How Expedia Group Builds AI That Lasts at Scale (8 minute read)
🟢 خلاصه مقاله:
شرکت Expedia Group برای توسعه هوش مصنوعی پایدار و مقیاسپذیر، چارچوبی مبتنی بر اصول مشخصی ایجاد کرده است. یکی از مهمترین اصول این است که هر مدلی که تولید میشود باید به نتیجههای قابل اندازهگیری در کسبوکار مرتبط باشد. این رویکرد باعث میشود که توسعه و بهرهبرداری از مدلهای هوش مصنوعی همواره در راستای اهداف تجاری شرکت باشد و اثربخشی آنها قابل ارزیابی و بهبود مداوم باشد. علاوه بر این، تیمهای توسعهدهنده بر پایه زیرساختهای مشترک و استاندارد ساخته شدهاند، نه بر اساس سیستمهای سفارشی و منفرد، که این امر موجب سهولت در مدیریت، ارتقاء و نگهداری فناوری میشود. در نهایت، برای هر مدل، مسئولانی در بخشهای مختلف از جمله کسبوکار، محصول، هوش مصنوعی و عملیات مشخص شدهاند، که این امر تضمین میکند که توسعه و استقرار هوش مصنوعی به صورت هماهنگ و مسئولانه انجام گیرد. این رویکرد جامع و منسجم، به Expedia امکان میدهد هوش مصنوعی را نه تنها در مقیاس بزرگ، بلکه با دوام و پایدار در آزمون زمان توسعه دهد و از مزایای آن در بهبود تجربه مسافران و افزایش کارایی بهره ببرد.
#هوش_مصنوعی #توسعه_پایدار #تکنولوژی #کسبوکار
🟣لینک مقاله:
https://medium.com/expedia-group-tech/how-expedia-group-builds-ai-that-lasts-at-scale-434677770fe9?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
How Expedia Group Builds AI That Lasts at Scale
A framework for how we build, deploy, and evolve AI systems for impact and scale
🔵 عنوان مقاله
pgsavvy: A Vim-Style TUI for Working With Databases
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها و کار با پایگاههای داده، ابزارهای قدرتمند و کاربرپسند نقش بسیار مهمی دارند. یکی از این ابزارها که با هدف تسهیل فرآیند مرور و جستوجوی اطلاعات در پایگاههای داده پستمگراس (Postgres) طراحی شده، برنامهای مبتنی بر رابط کاربری متنی (TUI) است. این برنامه که با زبان برنامهنویسی Go توسعه یافته است، تجربهای مشابه با ویرایشگر متن Vim را در حین کار با دیتابیس فراهم میکند، و کاربران میتوانند از طریق کیبورد و بدون نیاز به رابط گرافیکی، به راحتی به جستوجو و مدیریت دادهها بپردازند.
این برنامه قابلیتهای متنوعی مانند ناوبری سریع و ساده با سبک Vim، تکمیل خودکار کدهای SQL برای صرفهجویی در زمان، و امکان بررسی طرحریزی درختی پرسوجوها (EXPLAIN plans) را فراهم میآورد. با استفاده از این ابزار، کاربران حتی میتوانند مراحل اجرایی هر پرسوجو را به صورت تعاملی بررسی کنند، که در روند بهبود کارایی و رفع مشکلات دیتابیس بسیار مفید است. این امکانات باعث شده است که این برنامه، جایگزینی قدرتمند برای رابطهای کاربری سنتی گرافیکی باشد، مخصوصاً برای توسعهدهندگان و مدیران پایگاه داده که به سرعت و کارایی اهمیت میدهند.
در مجموع، این ابزار با بهرهگیری از طراحی برازنده و امکانات کاربرپسند، راهی سریع و کارآمد برای مدیریت و تحلیل دادهها در محیطهایی مبتنی بر ترمینال فراهم میکند، و توانسته جای خوبی در میان ابزارهای توسعهدهندگان پیدا کند.
#مدیریت_پایگاه_داده #ابزارهای_توسعه #پایگاه_داده #ترمینال
🟣لینک مقاله:
https://github.com/davesavic/pgsavvy
➖➖➖➖➖➖➖➖
👑 @Database_Academy
pgsavvy: A Vim-Style TUI for Working With Databases
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها و کار با پایگاههای داده، ابزارهای قدرتمند و کاربرپسند نقش بسیار مهمی دارند. یکی از این ابزارها که با هدف تسهیل فرآیند مرور و جستوجوی اطلاعات در پایگاههای داده پستمگراس (Postgres) طراحی شده، برنامهای مبتنی بر رابط کاربری متنی (TUI) است. این برنامه که با زبان برنامهنویسی Go توسعه یافته است، تجربهای مشابه با ویرایشگر متن Vim را در حین کار با دیتابیس فراهم میکند، و کاربران میتوانند از طریق کیبورد و بدون نیاز به رابط گرافیکی، به راحتی به جستوجو و مدیریت دادهها بپردازند.
این برنامه قابلیتهای متنوعی مانند ناوبری سریع و ساده با سبک Vim، تکمیل خودکار کدهای SQL برای صرفهجویی در زمان، و امکان بررسی طرحریزی درختی پرسوجوها (EXPLAIN plans) را فراهم میآورد. با استفاده از این ابزار، کاربران حتی میتوانند مراحل اجرایی هر پرسوجو را به صورت تعاملی بررسی کنند، که در روند بهبود کارایی و رفع مشکلات دیتابیس بسیار مفید است. این امکانات باعث شده است که این برنامه، جایگزینی قدرتمند برای رابطهای کاربری سنتی گرافیکی باشد، مخصوصاً برای توسعهدهندگان و مدیران پایگاه داده که به سرعت و کارایی اهمیت میدهند.
در مجموع، این ابزار با بهرهگیری از طراحی برازنده و امکانات کاربرپسند، راهی سریع و کارآمد برای مدیریت و تحلیل دادهها در محیطهایی مبتنی بر ترمینال فراهم میکند، و توانسته جای خوبی در میان ابزارهای توسعهدهندگان پیدا کند.
#مدیریت_پایگاه_داده #ابزارهای_توسعه #پایگاه_داده #ترمینال
🟣لینک مقاله:
https://github.com/davesavic/pgsavvy
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - davesavic/pgsavvy: The lazygit for PostgreSQL. A vim-style terminal UI for browsing, querying, and editing your database…
The lazygit for PostgreSQL. A vim-style terminal UI for browsing, querying, and editing your database without leaving the keyboard. - davesavic/pgsavvy
Forwarded from Linux
لینوس توروالدز، سازنده و مسئول هسته لینوکس، در واکنش به استفاده از هوش مصنوعی برای کدنویسی و چک کردن کدها گفته لینوکس از اون پروژه های ضد هوش مصنوعی نیست و اگر کسی با این قضیه مشکل داره میتونه لینوکس رو فورک کنه یا اینکه بیخیال لینوکس بشه و بره پی کارش!
این قضیه، از استفاده از ابزار هوش مصنوعی Sashiko برای پیدا کردن باگها و مشکلات امنیتی موجود در پچ های لینوکس شروع شد که Laurent Pinchart، یکی از توسعه دهندگان لینوکس، معتقد بود که این ابزار نظراتش رو باید به طور خودکار برای بررسی به توسعه دهندگان لینوکس نفرسته بلکه قبل از اون یک انسان باید اونهارو بررسی کنه و بعد از اینکه مطمئن شد که درست هستن، اونهارو برای بررسی نهایی به توسعه دهندگان لینوکس بفرسته تا اونهارو اصلاح کنن و فشار کاری اونهارو زیاد نکنه.
ولی Roman Gushchin، سازنده این ابزار، معتقده که بررسی هر نظر تولید شده این ابزار توسط یک انسان، کل هدف این ابزار که سریعتر کردن کار توسعه دهندگان لینوکس هست رو زیر سوال میبره و اون رو کند میکنه.
لینوس توروالدز به عنوان تصمیم گیرنده نهایی متن بلند بالایی با لحنی تند در جواب نوشته که حائز اهمیت هست:
میدونم که بعضی از افراد از هوش مصنوعی خوششون نمیاد ولی به عنوان maintainer اصلی پروژه، این یکی از چیزهاییه که من کاملا پاش میاستم و ذره ای ازش کوتاه نمیام.
لینوکس از اون پروژه های ضد هوش مصنوعی نیست و اگر کسی با این قضیه مشکل داره میتونه لینوکس رو فورک کنه یا اینکه بیخیال لینوکس بشه و بره پی کارش.
هوش مصنوعی یک ابزار مثل بقیه ابزارهاست و یک ابزار کاربردی هست. این قضیه ممکنه حتی در یک سال گذشته واضح نبوده باشه ولی کاربردی بودن اون حالا اونقدر واضحه که دیگه جای سوالی باقی نمیمونه.
پیرامون هوش مصنوعی نگرانیها و سوالات زیادی (از جنبه اقتصادی و غیره) وجود داره ولی کاربردی بودن دیگه جزو اون سوالات نیست و هر کسی که در این باره شکی داشته باشه مشخصا از این ابزارها واقعا استفاده نکرده.
بله، این ابزار می تونه تا حدی ازاردهنده هم باشه؛ هم از نظر حجم کاری که روی دوش مسئولان پروژه قرار میده و هم از این زاویه که مدام باگ های خجالت اور پیدا می کنه.
اما راه حل این نیست که سرتون رو داخل خاک قرار بدین و مثل کاری که بعضی افراد انجام میدن، تو سرتون اهنگ بخونین و بگین من صداتو نمیشنوم.
راه حل اینه که مطمئن بشیم این ابزارهای هوش مصنوعی به مسئولان پروژه کمک کنن نه اینکه صرفا برای اونها دردسر و زحمت اضافه به بار بیارن. در این مورد اصلا بحثی وجود نداره.
ما هیچ کسی رو مجبور نمیکنیم که از این ابزارها استفاده کنه و ولی اگر کسی بخواد مخالف استفاده بقیه از اونها بشه، به محکمترین شکل ممکن به اونها بی محلی میکنم و نظراتشون رو نادیده میگیرم.
و نه، هوش مصنوعی کامل و بی نقص نیست. ولی هر کسی که به مشکلات هوش مصنوعی اشاره میکنه، بهتره همزمان یه نگاهی هم به آینه بندازه و خودش رو نشونه بگیره. چون اینجوری هم نیست که هوش طبیعی ما انسانها همیشه تحفه خاصی بوده باشه.
پروژه هسته لینوکس همیشه حول تکنولوژی بوده و خواهد بود. قطعا بعد اجتماعی کار کردن روی پروژه متن باز مهم هست و به افراد انگیزه زیادی برای کار کردن روی پروژه میده اما در نهایت اینها همه مزایای جانبی هستن و هدف اصلی پروژه نیستن.
این پروژه یک نوع پروژه برای مبارزان عدالت اجتماعی نیست، هیچ وقت نبوده و نخواهد بود. ما در جامعه هسته لینوکس به دلایل متعصبانه و ایدئولوژیک روی اون کار نمیکنیم، بلکه به این خاطر روی اون کار میکنیم که در نهایت منجر به تکنولوژی بهتری بشه. بنابراین تصمیمات ما در درجه اول براساس شایستگی و ارزش فنی گرفته میشن و نه از روی ترس از ابزارهای جدید.
🔎 tomshardware
این قضیه، از استفاده از ابزار هوش مصنوعی Sashiko برای پیدا کردن باگها و مشکلات امنیتی موجود در پچ های لینوکس شروع شد که Laurent Pinchart، یکی از توسعه دهندگان لینوکس، معتقد بود که این ابزار نظراتش رو باید به طور خودکار برای بررسی به توسعه دهندگان لینوکس نفرسته بلکه قبل از اون یک انسان باید اونهارو بررسی کنه و بعد از اینکه مطمئن شد که درست هستن، اونهارو برای بررسی نهایی به توسعه دهندگان لینوکس بفرسته تا اونهارو اصلاح کنن و فشار کاری اونهارو زیاد نکنه.
ولی Roman Gushchin، سازنده این ابزار، معتقده که بررسی هر نظر تولید شده این ابزار توسط یک انسان، کل هدف این ابزار که سریعتر کردن کار توسعه دهندگان لینوکس هست رو زیر سوال میبره و اون رو کند میکنه.
لینوس توروالدز به عنوان تصمیم گیرنده نهایی متن بلند بالایی با لحنی تند در جواب نوشته که حائز اهمیت هست:
میدونم که بعضی از افراد از هوش مصنوعی خوششون نمیاد ولی به عنوان maintainer اصلی پروژه، این یکی از چیزهاییه که من کاملا پاش میاستم و ذره ای ازش کوتاه نمیام.
لینوکس از اون پروژه های ضد هوش مصنوعی نیست و اگر کسی با این قضیه مشکل داره میتونه لینوکس رو فورک کنه یا اینکه بیخیال لینوکس بشه و بره پی کارش.
هوش مصنوعی یک ابزار مثل بقیه ابزارهاست و یک ابزار کاربردی هست. این قضیه ممکنه حتی در یک سال گذشته واضح نبوده باشه ولی کاربردی بودن اون حالا اونقدر واضحه که دیگه جای سوالی باقی نمیمونه.
پیرامون هوش مصنوعی نگرانیها و سوالات زیادی (از جنبه اقتصادی و غیره) وجود داره ولی کاربردی بودن دیگه جزو اون سوالات نیست و هر کسی که در این باره شکی داشته باشه مشخصا از این ابزارها واقعا استفاده نکرده.
بله، این ابزار می تونه تا حدی ازاردهنده هم باشه؛ هم از نظر حجم کاری که روی دوش مسئولان پروژه قرار میده و هم از این زاویه که مدام باگ های خجالت اور پیدا می کنه.
اما راه حل این نیست که سرتون رو داخل خاک قرار بدین و مثل کاری که بعضی افراد انجام میدن، تو سرتون اهنگ بخونین و بگین من صداتو نمیشنوم.
راه حل اینه که مطمئن بشیم این ابزارهای هوش مصنوعی به مسئولان پروژه کمک کنن نه اینکه صرفا برای اونها دردسر و زحمت اضافه به بار بیارن. در این مورد اصلا بحثی وجود نداره.
ما هیچ کسی رو مجبور نمیکنیم که از این ابزارها استفاده کنه و ولی اگر کسی بخواد مخالف استفاده بقیه از اونها بشه، به محکمترین شکل ممکن به اونها بی محلی میکنم و نظراتشون رو نادیده میگیرم.
و نه، هوش مصنوعی کامل و بی نقص نیست. ولی هر کسی که به مشکلات هوش مصنوعی اشاره میکنه، بهتره همزمان یه نگاهی هم به آینه بندازه و خودش رو نشونه بگیره. چون اینجوری هم نیست که هوش طبیعی ما انسانها همیشه تحفه خاصی بوده باشه.
پروژه هسته لینوکس همیشه حول تکنولوژی بوده و خواهد بود. قطعا بعد اجتماعی کار کردن روی پروژه متن باز مهم هست و به افراد انگیزه زیادی برای کار کردن روی پروژه میده اما در نهایت اینها همه مزایای جانبی هستن و هدف اصلی پروژه نیستن.
این پروژه یک نوع پروژه برای مبارزان عدالت اجتماعی نیست، هیچ وقت نبوده و نخواهد بود. ما در جامعه هسته لینوکس به دلایل متعصبانه و ایدئولوژیک روی اون کار نمیکنیم، بلکه به این خاطر روی اون کار میکنیم که در نهایت منجر به تکنولوژی بهتری بشه. بنابراین تصمیمات ما در درجه اول براساس شایستگی و ارزش فنی گرفته میشن و نه از روی ترس از ابزارهای جدید.
🔎 tomshardware
❤4
🔵 عنوان مقاله
Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption (7 minute read)
🟢 خلاصه مقاله:
در مسیر توسعه و بهبود زیرساخت دادههای Grab، تیم ما تصمیم گرفت تا جدولهای پارکت Hive در مقیاس پتابایت را به سیستم Apache Iceberg مهاجرت دهد. این انتقال نه تنها سرعت پردازش دادهها را ده برابر افزایش داد، بلکه منجر به کاهش چشمگیر هزینههای روزانه API S3 برای جدولهای عملیاتی شد؛ هزینهها تا ۹۵ درصد کاهش یافت. علاوه بر این، بهرهوری محاسباتی در خطوط پیشبینی ماشینلرنینگ نیز به میزان ۵۰ درصد صرفهجویی داشت، که نشاندهنده تاثیر مثبت این تغییر در کارایی کل سیستم بود.
برای سادهسازی عملیات و افزایش انعطافپذیری، تیم ما یک سیستم سفارشی به نام UnifiedSparkCatalog توسعه داد، که قابلیتهای Iceberg، Delta، Hudi و Hive را در قالب یک رابط واحد و قابل فهم ارائه میدهد. این سیستم با منطق پشتیبانی از حالتهای پشتیبان (fallback) و سازگاری کامل با Hive طراحی شده است، به طوری که تمامی فرآیندهای دادهپژوهی و مدیریت دادهها را آسانتر میکند و از بهرهوری بالایی برخوردار است.
این مسیر نشان داد که با انتخاب فناوریهای مناسب و توسعه راهکارهای یکپارچه، میتوان در مدیریت دادهها در مقیاس بزرگ به نتایج استثنایی دست یافت و فرآیندهای تحلیلی را بهبود بخشید.
#داده #هوش_مصنوعی #پایگاه_داده #توسعه
🟣لینک مقاله:
https://engineering.grab.com/our-journey-to-apache-iceberg-adoption?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption (7 minute read)
🟢 خلاصه مقاله:
در مسیر توسعه و بهبود زیرساخت دادههای Grab، تیم ما تصمیم گرفت تا جدولهای پارکت Hive در مقیاس پتابایت را به سیستم Apache Iceberg مهاجرت دهد. این انتقال نه تنها سرعت پردازش دادهها را ده برابر افزایش داد، بلکه منجر به کاهش چشمگیر هزینههای روزانه API S3 برای جدولهای عملیاتی شد؛ هزینهها تا ۹۵ درصد کاهش یافت. علاوه بر این، بهرهوری محاسباتی در خطوط پیشبینی ماشینلرنینگ نیز به میزان ۵۰ درصد صرفهجویی داشت، که نشاندهنده تاثیر مثبت این تغییر در کارایی کل سیستم بود.
برای سادهسازی عملیات و افزایش انعطافپذیری، تیم ما یک سیستم سفارشی به نام UnifiedSparkCatalog توسعه داد، که قابلیتهای Iceberg، Delta، Hudi و Hive را در قالب یک رابط واحد و قابل فهم ارائه میدهد. این سیستم با منطق پشتیبانی از حالتهای پشتیبان (fallback) و سازگاری کامل با Hive طراحی شده است، به طوری که تمامی فرآیندهای دادهپژوهی و مدیریت دادهها را آسانتر میکند و از بهرهوری بالایی برخوردار است.
این مسیر نشان داد که با انتخاب فناوریهای مناسب و توسعه راهکارهای یکپارچه، میتوان در مدیریت دادهها در مقیاس بزرگ به نتایج استثنایی دست یافت و فرآیندهای تحلیلی را بهبود بخشید.
#داده #هوش_مصنوعی #پایگاه_داده #توسعه
🟣لینک مقاله:
https://engineering.grab.com/our-journey-to-apache-iceberg-adoption?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Grab Tech
Scaling Grab's Data Lake: Our journey to Apache Iceberg adoption
As Grab's Data Lake grew to petabytes, the limitations of Hive Parquet became clear, from catalog latency and small files to manual partition management. This blog shares our journey adopting Apache Iceberg as our default table format: why we chose it, how…
🔵 عنوان مقاله
Cache Layer Architecture: A Practical Guide to Speed & Scale (9 minute read)
🟢 خلاصه مقاله:
در معماری لایه کش، مواجهه با مشکلات در مقیاس بزرگ امری طبیعی است، اما با رعایت استراتژیهای مناسب میتوان این چالشها را مدیریت کرد. یکی از این مشکلات، حملههای سراسری یا همان «استمپید» است که هنگام اتمام اعتبار کلیدهای محبوب رخ میدهد؛ در این وضعیت، تعداد زیادی درخواست همزمان برای همان کلید ارسال میشود که منجر به فشار زیاد بر روی یک نود و کندی در پاسخگویی میگردد. همچنین، کلیدهای پرکار (hot keys) ممکن است باعث بارگذاری زیادی بر روی یک گره خاص شوند، در حالی که دادههای منقضی یا نادرست در نتیجه ریسهای invalidate، میتواند منجر به تکرار درخواستها و ایجاد دادههای قدیمیِ ناایمن شود. علاوه بر این، زمانی که یک مشکل کلی یا انجام نگرفتن بهروزرسانیها باعث خالی شدن کامل کش میشود، این وضعیت به «آوالانچ» یا اوج فشار منجر میگردد، و سیستم پشتصحنه باید با بار کامل و ناگهانی مقابله کند.
برای مقابله با این مشکلات، راهکارهای متعددی توسعه یافته است. مثلاً، استفاده از jitter در استراتژی تعیین مدت زمان TTL (Time To Live) کمک میکند تا درخواستها در زمانهای مختلف به صورت همزمان نرسند، بنابراین فشار روی سرورها کاهش مییابد. همچنین، درخواستها میتواند در هنگام رسیدن به کش همگنسازی شوند، به این معنا که درخواستهای مشابه با هم ادغام شده و به صورت واحد پردازش میشوند، که این کار بهرهوری سیستم را افزایش میدهد. تقسیم کلیدها (key splitting) و بهکارگیری هشینگ ثابت با نودهای مجازی نیز از دیگر روشهای مؤثر هستند که کمک میکنند توزیع یکنواخت درخواستها و دادهها در سراسر گرههای مختلف صورت گیرد، تا از تمرکز بیش از حد بر روی چند نود جلوگیری شود و در نتیجه، سیستم در برابر بارهای ناگهانی مقاومتر باشد.
در نتیجه، با بهکارگیری این استراتژیها، میتوان از تداخل و فشارهای ناخواسته جلوگیری کرد و زیرساختهای کش را در مقیاس بزرگ و پایدار نگه داشت، و در نتیجه سریعتر، قابل اعتمادتر و مقیاسپذیرتر عمل کرد.
#کش #پاسخگویی_سریع #مدیریت_بار #بهینهسازی
🟣لینک مقاله:
https://redis.io/blog/cache-layer-architecture-guide/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Cache Layer Architecture: A Practical Guide to Speed & Scale (9 minute read)
🟢 خلاصه مقاله:
در معماری لایه کش، مواجهه با مشکلات در مقیاس بزرگ امری طبیعی است، اما با رعایت استراتژیهای مناسب میتوان این چالشها را مدیریت کرد. یکی از این مشکلات، حملههای سراسری یا همان «استمپید» است که هنگام اتمام اعتبار کلیدهای محبوب رخ میدهد؛ در این وضعیت، تعداد زیادی درخواست همزمان برای همان کلید ارسال میشود که منجر به فشار زیاد بر روی یک نود و کندی در پاسخگویی میگردد. همچنین، کلیدهای پرکار (hot keys) ممکن است باعث بارگذاری زیادی بر روی یک گره خاص شوند، در حالی که دادههای منقضی یا نادرست در نتیجه ریسهای invalidate، میتواند منجر به تکرار درخواستها و ایجاد دادههای قدیمیِ ناایمن شود. علاوه بر این، زمانی که یک مشکل کلی یا انجام نگرفتن بهروزرسانیها باعث خالی شدن کامل کش میشود، این وضعیت به «آوالانچ» یا اوج فشار منجر میگردد، و سیستم پشتصحنه باید با بار کامل و ناگهانی مقابله کند.
برای مقابله با این مشکلات، راهکارهای متعددی توسعه یافته است. مثلاً، استفاده از jitter در استراتژی تعیین مدت زمان TTL (Time To Live) کمک میکند تا درخواستها در زمانهای مختلف به صورت همزمان نرسند، بنابراین فشار روی سرورها کاهش مییابد. همچنین، درخواستها میتواند در هنگام رسیدن به کش همگنسازی شوند، به این معنا که درخواستهای مشابه با هم ادغام شده و به صورت واحد پردازش میشوند، که این کار بهرهوری سیستم را افزایش میدهد. تقسیم کلیدها (key splitting) و بهکارگیری هشینگ ثابت با نودهای مجازی نیز از دیگر روشهای مؤثر هستند که کمک میکنند توزیع یکنواخت درخواستها و دادهها در سراسر گرههای مختلف صورت گیرد، تا از تمرکز بیش از حد بر روی چند نود جلوگیری شود و در نتیجه، سیستم در برابر بارهای ناگهانی مقاومتر باشد.
در نتیجه، با بهکارگیری این استراتژیها، میتوان از تداخل و فشارهای ناخواسته جلوگیری کرد و زیرساختهای کش را در مقیاس بزرگ و پایدار نگه داشت، و در نتیجه سریعتر، قابل اعتمادتر و مقیاسپذیرتر عمل کرد.
#کش #پاسخگویی_سریع #مدیریت_بار #بهینهسازی
🟣لینک مقاله:
https://redis.io/blog/cache-layer-architecture-guide/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Redis
Cache Layer Architecture: A Practical Guide to Speed & Scale
Learn how cache layers work, where they sit in your architecture, which caching patterns to use, and how to scale across nodes and regions without outages.
🔵 عنوان مقاله
Cloudflare as a Data Platform? (10 minute read)
🟢 خلاصه مقاله:
در ابتدای آزمایشهای اولیه، مشخص شده است که ترکیب R2 و Iceberg میتواند به عنوان یک دریاچه داده سبک و کارآمد عمل کند. این راهکارها به مدیران دادهها امکان میدهد تا دادههای خود را با هزینه کم و کارایی بالا مدیریت کنند، و نقش مهمی در ایجاد یک فضای ذخیرهسازی انعطافپذیر و مقیاسپذیر بازی میکنند. با این حال، در این مرحله هنوز نقطه ضعف اصلی در زمینه سازماندهی و مدیریت روندهای کاری وجود دارد که نیازمند توسعه و بهبود است.
در حال حاضر، هماهنگی و خودکارسازی فرآیندهای کاری، یکی از چالشهای مهم است که باید برطرف شود تا بتوان از این سیستمها به شکل کامل و مؤثر بهرهبرداری کرد. نبود یک سامانه منسجم برای ترتیبدهی و نظارت بر عملیاتهای مختلف، ممکن است باعث کاهش بهرهوری و پیچیدگی در مدیریت دادهها شود. بنابراین، توسعه ابزارها و روشهایی برای اورکستراسیون بهتر، نقش حیاتی در کامل کردن این پلتفرم دادهمحور ایفا میکند.
در مجموع، گرچه آزمایشهای اولیه نویدبخش هستند و نشان میدهند که ترکیب R2 و Iceberg پتانسیل ایجاد یک پلتفرم دادهای سبک و کاربردی را دارد، اما برای رسیدن به یک سیستم کامل و بینقص نیازمند تمرکز بیشتر بر روی بخشهای فرآیندهای کاری و خودکارسازی آنها هستیم. ادامه فعالیت در این مسیر، میتواند آیندهی روشنی برای Cloudflare بهعنوان یک پلتفرم داده نوآورانه رقم بزند.
#داده #پلتفرم_ابری #مدیریت_داده #توسعه_فناوری
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/cloudflare-as-a-data-platform?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Cloudflare as a Data Platform? (10 minute read)
🟢 خلاصه مقاله:
در ابتدای آزمایشهای اولیه، مشخص شده است که ترکیب R2 و Iceberg میتواند به عنوان یک دریاچه داده سبک و کارآمد عمل کند. این راهکارها به مدیران دادهها امکان میدهد تا دادههای خود را با هزینه کم و کارایی بالا مدیریت کنند، و نقش مهمی در ایجاد یک فضای ذخیرهسازی انعطافپذیر و مقیاسپذیر بازی میکنند. با این حال، در این مرحله هنوز نقطه ضعف اصلی در زمینه سازماندهی و مدیریت روندهای کاری وجود دارد که نیازمند توسعه و بهبود است.
در حال حاضر، هماهنگی و خودکارسازی فرآیندهای کاری، یکی از چالشهای مهم است که باید برطرف شود تا بتوان از این سیستمها به شکل کامل و مؤثر بهرهبرداری کرد. نبود یک سامانه منسجم برای ترتیبدهی و نظارت بر عملیاتهای مختلف، ممکن است باعث کاهش بهرهوری و پیچیدگی در مدیریت دادهها شود. بنابراین، توسعه ابزارها و روشهایی برای اورکستراسیون بهتر، نقش حیاتی در کامل کردن این پلتفرم دادهمحور ایفا میکند.
در مجموع، گرچه آزمایشهای اولیه نویدبخش هستند و نشان میدهند که ترکیب R2 و Iceberg پتانسیل ایجاد یک پلتفرم دادهای سبک و کاربردی را دارد، اما برای رسیدن به یک سیستم کامل و بینقص نیازمند تمرکز بیشتر بر روی بخشهای فرآیندهای کاری و خودکارسازی آنها هستیم. ادامه فعالیت در این مسیر، میتواند آیندهی روشنی برای Cloudflare بهعنوان یک پلتفرم داده نوآورانه رقم بزند.
#داده #پلتفرم_ابری #مدیریت_داده #توسعه_فناوری
🟣لینک مقاله:
https://dataengineeringcentral.substack.com/p/cloudflare-as-a-data-platform?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
Cloudflare as a Data Platform?
new kid on the block
🔵 عنوان مقاله
Benchmarking Single Node vs Distributed (5 minute read)
🟢 خلاصه مقاله:
در آزمون عملکرد TPC-H با حجم ۱ ترابایت، زمانی که مشخصات کلی سیستمها همسطح بودند، تفاوت مناطق قابل توجهی مشاهده شد. در این تست، سیستم توزیعشدهی Polars که روی ۳۲ گره قرار داشت، کمی بهتر از یک سرور تکنود m8i.32xlarge عمل کرد؛ اما این برتری تنها در مواردی بود که نوع بار کاری، I/O محور بود. در این نوع کوئریها، شبکهی burst به اوج سرعت ۴۰۰ گیگابیت در ثانیه رسید، در حالی که نود واحد تنها توانایی برقراری ارتباط ماندگار با سرعت ۵۰ گیگابیت در ثانیه داشت. در نتیجه، در این بخش، توان عملیاتی شبکهی بزرگتر باعث شد عملکرد سیستم توزیعشده بهتر باشد.
اما در مقابل، کوئریهایی که رابطههای پیوسته و نیازمند جستوجوهای پیوسته و پیچیده بودند، در سیستم تکنود سریعتر اجرا شدند. این موضوع ناشی از هزینهی بالای جابهجایی دادهها بین گرهها یا همان shuffle بود، بهخصوص زمانی که شبکهی توزیع شده تلاش میکرد این عملیات را مدیریت کند. در چنین مواردی، تکرار عملیات در یک نود واحد، هزینهی مربوط به ارتباط باتری دادهها را کاهش داد و در نتیجه سرعت اجرا بهتر بود.
در مجموع، این نتایج نشان میدهد که انتخاب بین سیستمهای تکنود و توزیعشده باید بر اساس نوع بار کاری و محدودیتهای سختافزاری انجام گیرد، چرا که هر کدام مزایا و معایب خاص خود را دارند.
#پایگاهداده #عملکرد #سیستمهایتوزیعشده #تحلیلپایدار
🟣لینک مقاله:
https://pola.rs/posts/single-node-vs-distributed/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Benchmarking Single Node vs Distributed (5 minute read)
🟢 خلاصه مقاله:
در آزمون عملکرد TPC-H با حجم ۱ ترابایت، زمانی که مشخصات کلی سیستمها همسطح بودند، تفاوت مناطق قابل توجهی مشاهده شد. در این تست، سیستم توزیعشدهی Polars که روی ۳۲ گره قرار داشت، کمی بهتر از یک سرور تکنود m8i.32xlarge عمل کرد؛ اما این برتری تنها در مواردی بود که نوع بار کاری، I/O محور بود. در این نوع کوئریها، شبکهی burst به اوج سرعت ۴۰۰ گیگابیت در ثانیه رسید، در حالی که نود واحد تنها توانایی برقراری ارتباط ماندگار با سرعت ۵۰ گیگابیت در ثانیه داشت. در نتیجه، در این بخش، توان عملیاتی شبکهی بزرگتر باعث شد عملکرد سیستم توزیعشده بهتر باشد.
اما در مقابل، کوئریهایی که رابطههای پیوسته و نیازمند جستوجوهای پیوسته و پیچیده بودند، در سیستم تکنود سریعتر اجرا شدند. این موضوع ناشی از هزینهی بالای جابهجایی دادهها بین گرهها یا همان shuffle بود، بهخصوص زمانی که شبکهی توزیع شده تلاش میکرد این عملیات را مدیریت کند. در چنین مواردی، تکرار عملیات در یک نود واحد، هزینهی مربوط به ارتباط باتری دادهها را کاهش داد و در نتیجه سرعت اجرا بهتر بود.
در مجموع، این نتایج نشان میدهد که انتخاب بین سیستمهای تکنود و توزیعشده باید بر اساس نوع بار کاری و محدودیتهای سختافزاری انجام گیرد، چرا که هر کدام مزایا و معایب خاص خود را دارند.
#پایگاهداده #عملکرد #سیستمهایتوزیعشده #تحلیلپایدار
🟣لینک مقاله:
https://pola.rs/posts/single-node-vs-distributed/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Polars
Benchmarking single node vs distributed
DataFrames for the new era
🔵 عنوان مقاله
plx: Write Stored Functions in PHP, JavaScript, Python, and More
🟢 خلاصه مقاله:
در هفتههای اخیر، توسعهدهندگان پایگاه دادهها شاهد انتشار افزونههای متنوعی بودند که قدرت و قابلیتهای برنامهنویسی را درون ساختارهای پایگاه داده تقویت میکنند. به تازگی، یک افزونه جدید و جذاب عرضه شده است که امکان نوشتن و اجرای توابع ذخیره شده را در زبانهای برنامهنویسی مختلفی مانند PHP، جاوااسکریپت، پایتون، روبی و حتی COBOL فراهم میکند. این ابزار نوآورانه به توسعهدهندگان این امکان را میدهد که کدهای پیچیده و کاربردی را به راحتی در محیط پایگاه داده بنویسند و اجرا کنند، بدون نیاز به مهاجرت به زبانهای برنامهنویسی جداگانه یا استفاده از واسطهای خارجی.
این توسعه، به عنوان یک گام مهم در یکپارچهسازی زبانهای برنامهنویسی مدرن داخل سیستمهای مدیریت پایگاه داده، امکانات جدید و کارآمدی را برای برنامهنویسان فراهم میکند. با این ابزار، نوشتن توابع ذخیره شده در زبانهای مختلف که مورد نیاز پروژههای تخصصی است، بسیار سادهتر و مستقیمتر خواهد شد. این ویژگی به ویژه در پروژههای بزرگ و چندزبانه، که نیازمند هماهنگی و ادغام زبانهای مختلف است، نقش کلیدی ایفا میکند و موجب صرفهجویی در زمان و کاهش خطاهای احتمالی میشود.
در کل، این توسعه نشان میدهد که آینده سیستمهای مدیریت پایگاه داده به سمت انعطافپذیری و قابلیتهای چندزبانه پیش میرود، و توسعهدهندگان اکنون میتوانند با اطمینان بیشتری، کدهای کاربردی خود را مستقیماً درون پایگاه داده اجرا کنند. این قابلیت جدید، یک قدم مؤثر در بهبود کارایی و قابلیت توسعه سیستمهای دادهای است که نیازمند انعطاف و مقیاسپذیری بالا میباشند.
#پایگاه_داده #توسعه_نرمافزار #کد_نویسی #برنامهنویسی
🟣لینک مقاله:
https://github.com/commandprompt/plx
➖➖➖➖➖➖➖➖
👑 @Database_Academy
plx: Write Stored Functions in PHP, JavaScript, Python, and More
🟢 خلاصه مقاله:
در هفتههای اخیر، توسعهدهندگان پایگاه دادهها شاهد انتشار افزونههای متنوعی بودند که قدرت و قابلیتهای برنامهنویسی را درون ساختارهای پایگاه داده تقویت میکنند. به تازگی، یک افزونه جدید و جذاب عرضه شده است که امکان نوشتن و اجرای توابع ذخیره شده را در زبانهای برنامهنویسی مختلفی مانند PHP، جاوااسکریپت، پایتون، روبی و حتی COBOL فراهم میکند. این ابزار نوآورانه به توسعهدهندگان این امکان را میدهد که کدهای پیچیده و کاربردی را به راحتی در محیط پایگاه داده بنویسند و اجرا کنند، بدون نیاز به مهاجرت به زبانهای برنامهنویسی جداگانه یا استفاده از واسطهای خارجی.
این توسعه، به عنوان یک گام مهم در یکپارچهسازی زبانهای برنامهنویسی مدرن داخل سیستمهای مدیریت پایگاه داده، امکانات جدید و کارآمدی را برای برنامهنویسان فراهم میکند. با این ابزار، نوشتن توابع ذخیره شده در زبانهای مختلف که مورد نیاز پروژههای تخصصی است، بسیار سادهتر و مستقیمتر خواهد شد. این ویژگی به ویژه در پروژههای بزرگ و چندزبانه، که نیازمند هماهنگی و ادغام زبانهای مختلف است، نقش کلیدی ایفا میکند و موجب صرفهجویی در زمان و کاهش خطاهای احتمالی میشود.
در کل، این توسعه نشان میدهد که آینده سیستمهای مدیریت پایگاه داده به سمت انعطافپذیری و قابلیتهای چندزبانه پیش میرود، و توسعهدهندگان اکنون میتوانند با اطمینان بیشتری، کدهای کاربردی خود را مستقیماً درون پایگاه داده اجرا کنند. این قابلیت جدید، یک قدم مؤثر در بهبود کارایی و قابلیت توسعه سیستمهای دادهای است که نیازمند انعطاف و مقیاسپذیری بالا میباشند.
#پایگاه_داده #توسعه_نرمافزار #کد_نویسی #برنامهنویسی
🟣لینک مقاله:
https://github.com/commandprompt/plx
➖➖➖➖➖➖➖➖
👑 @Database_Academy
GitHub
GitHub - commandprompt/plx: PostgreSQL extension: write stored functions in Ruby, PHP, JavaScript, or Python dialects that transpile…
PostgreSQL extension: write stored functions in Ruby, PHP, JavaScript, or Python dialects that transpile to plpgsql. - commandprompt/plx
🔵 عنوان مقاله
Nobody Has Cracked Agent Memory (12 minute read)
🟢 خلاصه مقاله:
ساخت حافظه به عنوان یک زنجیرههوشمند نه تنها فرآیندی پیچیده بلکه اهمیت زیادی دارد که نیازمند طراحی هوشمندانه است. در این رویکرد، ابتدا دادهها را در یک انبار داده ذخیره میکنیم تا اطلاعات به صورت منسجم و سازمانیافته نگهداری شوند. سپس با بهرهگیری از فناوریهای مدرن، مانند مدلهای زبانی بزرگ (LLM)، اشیا و عناصر گراف را از این دادهها استخراج میکنیم. این مرحله، نقش حیاتی در شناسایی الگوها و روابط پنهان در اطلاعات دارد. پس از آن، صحت و اعتبار این اشیا را با روشهای معتبر تایید کرده، و در نهایت، با حذف موارد تکراری، دادهها را تمیز مینماییم تا مجموعهای دقیق و قابل اعتماد ایجاد کنیم.
در ادامه، این دادههای تصفیهشده برای پاسخگویی به سؤالات استاندارد و جستوجوی عمیق، از طریق سامانهای به نام MCP، در خدمت کاربران قرار میگیرند. برای این منظور، از پایگاه دادههای MongoDB بهره میگیریم که توانایی جستوجو در متن، بردارها و گرافها را دارا است. اما، برای عملیاتهایی نظیر پیمایش عمیق در ساختارهای گراف یا اجرای منطقهای وابسته به گراف، تنها از پایگاههای داده گراف استفاده میکنیم؛ زیرا این نوع پایگاهها، به ما امکان میدهند تا روابط بسیار پیچیده و عمیق را به آسانی کشف و مدیریت کنیم.
در مجموع، این رویکرد، راهی است برای ساخت حافظهای منسجم و قدرتمند، که میتواند به عنوان یک سیستم شناختی هوشمند در بسترهای مختلف، عمل کرده و به سوالات پیچیده پاسخ دهد، بدون آنکه نیاز به راهحلهای ساده و سطحی باشد. چنین سیستمی، هنوز در مراحل توسعه است و هیچ فرد یا سیستمی تا کنون نتوانسته است به طور کامل آن را شکسته یا انکار کند؛ چرا که فناوری و روشهای کارآمد، همواره در حال پیشرفت است و هر روز امکانات جدیدی به آن افزوده میشود.
#هوش_مصنوعی #ذهن_پژوهی #پایگاهداده_گراف #مدل_زبان_بزرگ
🟣لینک مقاله:
https://www.decodingai.com/p/how-to-implement-a-unified-memory-from-scratch?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Nobody Has Cracked Agent Memory (12 minute read)
🟢 خلاصه مقاله:
ساخت حافظه به عنوان یک زنجیرههوشمند نه تنها فرآیندی پیچیده بلکه اهمیت زیادی دارد که نیازمند طراحی هوشمندانه است. در این رویکرد، ابتدا دادهها را در یک انبار داده ذخیره میکنیم تا اطلاعات به صورت منسجم و سازمانیافته نگهداری شوند. سپس با بهرهگیری از فناوریهای مدرن، مانند مدلهای زبانی بزرگ (LLM)، اشیا و عناصر گراف را از این دادهها استخراج میکنیم. این مرحله، نقش حیاتی در شناسایی الگوها و روابط پنهان در اطلاعات دارد. پس از آن، صحت و اعتبار این اشیا را با روشهای معتبر تایید کرده، و در نهایت، با حذف موارد تکراری، دادهها را تمیز مینماییم تا مجموعهای دقیق و قابل اعتماد ایجاد کنیم.
در ادامه، این دادههای تصفیهشده برای پاسخگویی به سؤالات استاندارد و جستوجوی عمیق، از طریق سامانهای به نام MCP، در خدمت کاربران قرار میگیرند. برای این منظور، از پایگاه دادههای MongoDB بهره میگیریم که توانایی جستوجو در متن، بردارها و گرافها را دارا است. اما، برای عملیاتهایی نظیر پیمایش عمیق در ساختارهای گراف یا اجرای منطقهای وابسته به گراف، تنها از پایگاههای داده گراف استفاده میکنیم؛ زیرا این نوع پایگاهها، به ما امکان میدهند تا روابط بسیار پیچیده و عمیق را به آسانی کشف و مدیریت کنیم.
در مجموع، این رویکرد، راهی است برای ساخت حافظهای منسجم و قدرتمند، که میتواند به عنوان یک سیستم شناختی هوشمند در بسترهای مختلف، عمل کرده و به سوالات پیچیده پاسخ دهد، بدون آنکه نیاز به راهحلهای ساده و سطحی باشد. چنین سیستمی، هنوز در مراحل توسعه است و هیچ فرد یا سیستمی تا کنون نتوانسته است به طور کامل آن را شکسته یا انکار کند؛ چرا که فناوری و روشهای کارآمد، همواره در حال پیشرفت است و هر روز امکانات جدیدی به آن افزوده میشود.
#هوش_مصنوعی #ذهن_پژوهی #پایگاهداده_گراف #مدل_زبان_بزرگ
🟣لینک مقاله:
https://www.decodingai.com/p/how-to-implement-a-unified-memory-from-scratch?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Decodingai
Agent Memory From Scratch
Ingest, query, and serve a unified memory from a single database.
🔵 عنوان مقاله
Greysight (Tool)
🟢 خلاصه مقاله:
گرایسایت ابزاری رایگان و منبع باز است که برای نظارت بر هزینههای سرویس اسنوفلیک طراحی شده است. این ابزار به صورت رایگان در اختیار کاربران قرار میگیرد و بدون نیاز به ذخیرهسازی اطلاعات مشتریان، مصرف منابع مربوط به انبار داده، هوش مصنوعی و ذخیرهسازی را رصد میکند. هدف اصلی گرایسایت ارائه دیدی شفاف و کاملاً منصفانه درباره هزینههای مربوط به فعالیتهای مختلف در سامانه اسنوفلیک است، تا کاربران بتوانند به راحتی و با اطمینان هزینههای خود را کنترل و مدیریت کنند.
این ابزار به ویژه برای سازمانهایی که بر بستر اسنوفلیک فعالیت میکنند، اهمیت زیادی دارد، زیرا امکان نظارت بر هزینهها را فراهم میکند بدون نگرانی درباره حریم خصوصی دادهها. از آنجا که گرایسایت منبع باز است، توسعهدهندگان و مدیران فناوری اطلاعات میتوانند آن را بر اساس نیازهای خاص خود سفارشیسازی کنند و از قابلیتهای پیشرفته آن بهرهمند شوند. در نتیجه، این پروژه نقش مهمی در بهبود مدیریت مالی و بهبود بهرهوری در محیطهای مبتنی بر اسنوفلیک ایفا میکند.
در نهایت، گرایسایت ابزاری ارزشمند است که با رویکرد شفاف و قابل اعتماد خود، هزینههای فنی و عملیاتی در سامانههای ابری را بهبود میبخشد و کاربران را در تصمیمگیریهای مالی یاری میکند.
#مدیریت_هزینه #ابزارهای_منبع_باز #نظارت_بر_هزینه #اسنوفلیک
🟣لینک مقاله:
https://www.greybeam.ai/product/snowflake-observability?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Greysight (Tool)
🟢 خلاصه مقاله:
گرایسایت ابزاری رایگان و منبع باز است که برای نظارت بر هزینههای سرویس اسنوفلیک طراحی شده است. این ابزار به صورت رایگان در اختیار کاربران قرار میگیرد و بدون نیاز به ذخیرهسازی اطلاعات مشتریان، مصرف منابع مربوط به انبار داده، هوش مصنوعی و ذخیرهسازی را رصد میکند. هدف اصلی گرایسایت ارائه دیدی شفاف و کاملاً منصفانه درباره هزینههای مربوط به فعالیتهای مختلف در سامانه اسنوفلیک است، تا کاربران بتوانند به راحتی و با اطمینان هزینههای خود را کنترل و مدیریت کنند.
این ابزار به ویژه برای سازمانهایی که بر بستر اسنوفلیک فعالیت میکنند، اهمیت زیادی دارد، زیرا امکان نظارت بر هزینهها را فراهم میکند بدون نگرانی درباره حریم خصوصی دادهها. از آنجا که گرایسایت منبع باز است، توسعهدهندگان و مدیران فناوری اطلاعات میتوانند آن را بر اساس نیازهای خاص خود سفارشیسازی کنند و از قابلیتهای پیشرفته آن بهرهمند شوند. در نتیجه، این پروژه نقش مهمی در بهبود مدیریت مالی و بهبود بهرهوری در محیطهای مبتنی بر اسنوفلیک ایفا میکند.
در نهایت، گرایسایت ابزاری ارزشمند است که با رویکرد شفاف و قابل اعتماد خود، هزینههای فنی و عملیاتی در سامانههای ابری را بهبود میبخشد و کاربران را در تصمیمگیریهای مالی یاری میکند.
#مدیریت_هزینه #ابزارهای_منبع_باز #نظارت_بر_هزینه #اسنوفلیک
🟣لینک مقاله:
https://www.greybeam.ai/product/snowflake-observability?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
www.greybeam.ai
Greybeam | Greysight - Snowflake cost observability
Greysight is a free, open-source Snowflake cost observability tool by Greybeam. Instantly gain visibility into spend by warehouse, AI, and storage.
🔵 عنوان مقاله
The 90/90 rule for the dashboard dumpster (3 minute read)
🟢 خلاصه مقاله:
در دنیای تحلیل داده، یکی از چالشهای رایج، پدید آمدن تعداد زیادی داشبورد است که مدیریت و بهرهبرداری از آنها را دشوار میکند. این پدیده، که به آن «پراکندهگی داشبورد» گفته میشود، هزینههای زیادی برای سازمانهای دادهمحور دارد. یکی از این هزینهها کاهش اعتماد نسبت به داشبوردهای موجود است؛ چرا که اگر کاربران نتوانند اطلاعات مورد نیاز خود را به راحتی بیابند، اعتمادشان کاهش مییابد. علاوه بر این، پردازشهای بیاساس در انبار داده، که منجر به مصرف بیمورد منابع محاسباتی میشود، از دیگر مشکلات است. همچنین، داشبوردهای قدیمی و بیاستفاده، که دیگر کاربری ندارند، به زبالههای دیجیتال تبدیل میشوند و فضا و منابع سازمان را اشغال میکنند.
مثالی برای این مشکل، نشان میدهد که در یک سازمان، صدها داشبورد ساخته شده است، اما در هر فصل، تنها چند نمونه از آنها مورد استفاده قرار میگیرد؛ در نتیجه، حدود ۹۰ درصد از داشبوردها هیچگاه مورد دسترسی قرار نمیگیرند. این وضعیت، نه تنها هدررفت منابع است، بلکه کارایی سیستمهای تحلیل داده را کاهش میدهد. برای حل این مشکل، پیشنهاد میشود یک قانون ساده و عملی به نام «قاعده ۹۰/۹۰» اجرا شود. بر اساس این قانون، هر داشبورد پس از ۹۰ روز عدم مشاهده، آرشیو میشود؛ و اگر پس از ۹۰ روز دیگر هیچ پاسخ یا فعالیتی از سوی کاربران دریافت نشود، آن را حذف میکنند.
اجرای این قاعده، نه تنها به کاهش هزینهها و بهبود کارایی کمک میکند، بلکه اعتماد کاربران نسبت به داشبوردهای فعال و معتبر را افزایش میدهد. با این روش، سازمانها قادر خواهند بود منابع را بهتر مدیریت کنند و تمرکز خود را بر داشبوردهای مهم و پربار قرار دهند، در عین حال فضای دیجیتال خود را تمیز نگه دارند.
#مدیریت_داشبورد #تحلیل_داده #توسعه_سازمانی #بهبود_کارایی
🟣لینک مقاله:
https://betterthanrandom.substack.com/p/the-9090-rule-for-the-dashboard-dumpster?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The 90/90 rule for the dashboard dumpster (3 minute read)
🟢 خلاصه مقاله:
در دنیای تحلیل داده، یکی از چالشهای رایج، پدید آمدن تعداد زیادی داشبورد است که مدیریت و بهرهبرداری از آنها را دشوار میکند. این پدیده، که به آن «پراکندهگی داشبورد» گفته میشود، هزینههای زیادی برای سازمانهای دادهمحور دارد. یکی از این هزینهها کاهش اعتماد نسبت به داشبوردهای موجود است؛ چرا که اگر کاربران نتوانند اطلاعات مورد نیاز خود را به راحتی بیابند، اعتمادشان کاهش مییابد. علاوه بر این، پردازشهای بیاساس در انبار داده، که منجر به مصرف بیمورد منابع محاسباتی میشود، از دیگر مشکلات است. همچنین، داشبوردهای قدیمی و بیاستفاده، که دیگر کاربری ندارند، به زبالههای دیجیتال تبدیل میشوند و فضا و منابع سازمان را اشغال میکنند.
مثالی برای این مشکل، نشان میدهد که در یک سازمان، صدها داشبورد ساخته شده است، اما در هر فصل، تنها چند نمونه از آنها مورد استفاده قرار میگیرد؛ در نتیجه، حدود ۹۰ درصد از داشبوردها هیچگاه مورد دسترسی قرار نمیگیرند. این وضعیت، نه تنها هدررفت منابع است، بلکه کارایی سیستمهای تحلیل داده را کاهش میدهد. برای حل این مشکل، پیشنهاد میشود یک قانون ساده و عملی به نام «قاعده ۹۰/۹۰» اجرا شود. بر اساس این قانون، هر داشبورد پس از ۹۰ روز عدم مشاهده، آرشیو میشود؛ و اگر پس از ۹۰ روز دیگر هیچ پاسخ یا فعالیتی از سوی کاربران دریافت نشود، آن را حذف میکنند.
اجرای این قاعده، نه تنها به کاهش هزینهها و بهبود کارایی کمک میکند، بلکه اعتماد کاربران نسبت به داشبوردهای فعال و معتبر را افزایش میدهد. با این روش، سازمانها قادر خواهند بود منابع را بهتر مدیریت کنند و تمرکز خود را بر داشبوردهای مهم و پربار قرار دهند، در عین حال فضای دیجیتال خود را تمیز نگه دارند.
#مدیریت_داشبورد #تحلیل_داده #توسعه_سازمانی #بهبود_کارایی
🟣لینک مقاله:
https://betterthanrandom.substack.com/p/the-9090-rule-for-the-dashboard-dumpster?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Substack
The 90/90 rule for the dashboard dumpster
A scream test for your reporting layer
🔵 عنوان مقاله
The Four Horsemen Behind Thousands of Postgres Outages
🟢 خلاصه مقاله:
دو هفته پیش، به پروژهای به نام pgrust اشاره کردیم؛ این پروژه یک بازنویسی از پایگاه داده پرکاربرد Postgres است که با کمک هوش مصنوعی به زبان Rust توسعه یافته است. اکنون، این پروژه توانسته است تمامی تستهای رگرسیون مربوط به Postgres را با موفقیت پشت سر بگذارد و به یک نسخه پایدار و بهبود یافته تبدیل شود. در این مقاله، خالق این پروژه درباره بزرگترین مشکلات و چالشهایی که قصد دارد آنها را با بازنویسی جدید حل کند، توضیح میدهد.
در آغاز، باید به یکی از مهمترین دلایلی که این پروژه را شکل داد اشاره کنیم: مشکلات مربوط به عملکرد و پایداری پایگاه داده در شرایط بارگذاری سنگین و مدیریت حجم گسترده اطلاعات. خرابیها و قطعیهایی که در برخی موارد باعث توقف کامل سیستم میشد، همواره یکی از بزرگترین دردسرهای مدیران سیستم و توسعهدهندگان بود. این مسائل، نه تنها باعث اختلال در عملیات روزمره شد، بلکه اعتماد کاربران و شرکتها را نسبت به این فناوری کاهش داد.
خالق پروژه pgrust معتقد است که مشکل اصلی در ساختار قدیمی و محدودیتهای زبان C، که نسخه اصلی Postgres بر مبنای آن ساخته شده، قرار دارد. استفاده از زبان C، با وجود کارایی بالا، سبب بروز خطاهای حافظه و مشکلات مربوط به مدیریت منابع میشد که در نهایت منجر به ناپایداری سیستم میشد. او تصمیم گرفت با بازنویسی این سیستم در زبان Rust، نه تنها بهبودهای کارایی و امنیت را هدف قرار دهد، بلکه مشکلات رایج مرتبط با خطاهای حافظه و ناپایداریها را نیز رفع کند.
در کنار این موارد، مشکلات مربوط به مقیاسپذیری و مدیریت تراکنشها نیز از دیگر دغدغههایی بود که در مسیر توسعه پروژه وجود داشت. وظایف سنگین و تراکنشهای همزمان در پایگاههای داده قدیمی، باعث کندی پاسخگویی سیستم و افزایش احتمال بروز خطاهای همزمانی میشد. راهکارهای جدید در نسخه بازنویسی شده قرار است این محدودیتها را برطرف و امکان مدیریت بیشتر تراکنشهای همزمان را فراهم کند، که این امر میتواند تاثیر مستقیمی بر بهبود عملکرد و کارایی سیستم داشته باشد.
در مجموع، پروژه pgrust نمونهای است از تلاش برای حل مهمترین مشکلات پایگاه داده Postgres، با امید به اینکه نسخه جدید، سیستم پایدارتر، امنتر و مقیاسپذیرتری را برای کاربران فراهم کند. این تلاش نشان میدهد که با نوآوری و بهرهگیری از فناوریهای نوین، میتوان به سمت توسعه سیستمهایی پیشرفتهتر و کارآمدتر حرکت کرد.
#پایگاه_داده #Postgres #توسعه_نرم_افزار #امنیت
🟣لینک مقاله:
https://malisper.me/the-four-horsemen-behind-thousands-of-postgres-outages/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
The Four Horsemen Behind Thousands of Postgres Outages
🟢 خلاصه مقاله:
دو هفته پیش، به پروژهای به نام pgrust اشاره کردیم؛ این پروژه یک بازنویسی از پایگاه داده پرکاربرد Postgres است که با کمک هوش مصنوعی به زبان Rust توسعه یافته است. اکنون، این پروژه توانسته است تمامی تستهای رگرسیون مربوط به Postgres را با موفقیت پشت سر بگذارد و به یک نسخه پایدار و بهبود یافته تبدیل شود. در این مقاله، خالق این پروژه درباره بزرگترین مشکلات و چالشهایی که قصد دارد آنها را با بازنویسی جدید حل کند، توضیح میدهد.
در آغاز، باید به یکی از مهمترین دلایلی که این پروژه را شکل داد اشاره کنیم: مشکلات مربوط به عملکرد و پایداری پایگاه داده در شرایط بارگذاری سنگین و مدیریت حجم گسترده اطلاعات. خرابیها و قطعیهایی که در برخی موارد باعث توقف کامل سیستم میشد، همواره یکی از بزرگترین دردسرهای مدیران سیستم و توسعهدهندگان بود. این مسائل، نه تنها باعث اختلال در عملیات روزمره شد، بلکه اعتماد کاربران و شرکتها را نسبت به این فناوری کاهش داد.
خالق پروژه pgrust معتقد است که مشکل اصلی در ساختار قدیمی و محدودیتهای زبان C، که نسخه اصلی Postgres بر مبنای آن ساخته شده، قرار دارد. استفاده از زبان C، با وجود کارایی بالا، سبب بروز خطاهای حافظه و مشکلات مربوط به مدیریت منابع میشد که در نهایت منجر به ناپایداری سیستم میشد. او تصمیم گرفت با بازنویسی این سیستم در زبان Rust، نه تنها بهبودهای کارایی و امنیت را هدف قرار دهد، بلکه مشکلات رایج مرتبط با خطاهای حافظه و ناپایداریها را نیز رفع کند.
در کنار این موارد، مشکلات مربوط به مقیاسپذیری و مدیریت تراکنشها نیز از دیگر دغدغههایی بود که در مسیر توسعه پروژه وجود داشت. وظایف سنگین و تراکنشهای همزمان در پایگاههای داده قدیمی، باعث کندی پاسخگویی سیستم و افزایش احتمال بروز خطاهای همزمانی میشد. راهکارهای جدید در نسخه بازنویسی شده قرار است این محدودیتها را برطرف و امکان مدیریت بیشتر تراکنشهای همزمان را فراهم کند، که این امر میتواند تاثیر مستقیمی بر بهبود عملکرد و کارایی سیستم داشته باشد.
در مجموع، پروژه pgrust نمونهای است از تلاش برای حل مهمترین مشکلات پایگاه داده Postgres، با امید به اینکه نسخه جدید، سیستم پایدارتر، امنتر و مقیاسپذیرتری را برای کاربران فراهم کند. این تلاش نشان میدهد که با نوآوری و بهرهگیری از فناوریهای نوین، میتوان به سمت توسعه سیستمهایی پیشرفتهتر و کارآمدتر حرکت کرد.
#پایگاه_داده #Postgres #توسعه_نرم_افزار #امنیت
🟣لینک مقاله:
https://malisper.me/the-four-horsemen-behind-thousands-of-postgres-outages/
➖➖➖➖➖➖➖➖
👑 @Database_Academy
malisper.me
The four horsemen behind thousands of Postgres outages - malisper.me
Postgres is great, but there are some very common problems that people have that can pretty easily lead to outages with Postgres. These aren’t just theoretical issues. From talking to a lot of startups, these are the things that actually cause outages in…
🔵 عنوان مقاله
What is ACID on a Data Lake? (14 minute read)
🟢 خلاصه مقاله:
در دنیای دادههای بزرگ و ذخیرهسازی اطلاعات، مفهوم ACID نقش حیاتی در حفظ صحت و یکپارچگی دادهها ایفا میکند. در انبارهای داده مانند هودی، آیسبرگ و دلتا لیک، این مفاهیم به وسیله افزودن سیستمهای ثبتدستی و عملیات انتشار اتمی به ذخیرهسازی شیء اضافه شده است. این فناوریها اجازه میدهند نوشتن دادهها در چندین فایل به صورت همزمان و همهجانبه انجام شود، اما نتایج نهایی تنها پس از انجام عملیات انتشار اتمی و ثبت تغییرات در متادیتا دیده میشوند. به عبارت دیگر، خوانندگان تنها پس از کامل شدن فرآیند، تصویر ثابتی و مطابق با آخرین وضعیت را مشاهده میکنند که تضمین میکند دادهها در یک وضعیت قابل اعتماد و همراستا باقی میمانند.
این تضمینها، هرچند در سطح هر جدول جداگانه اعمال میشوند، اما عملیات ثبتتغییرات و تراکنشها معمولا در مدت زمان چند ثانیه انجام میپذیرند. نکته مهم اینکه، جداسازی تراکنشها (ایزولاسیون) بر پایه شبیهسازی نمونههای زمانی یا اسنپشاتها است، نه اینکه کاملاً بر اساس روشهای سریالسازی کامل باشد. بنابراین، سیستمها امکان مدیریت همزمانی و سازگاری را فراهم میکنند بدون اینکه پیچیدگیهای تام و کامل تراکنشهای نسل قبلی را متحمل شوند. این رویکرد، راه حلی موثر و کارآمد برای برقراری تعادل میان کارایی و تضمینهای ACID در محیطهای مبتنی بر ذخیرهسازی شیء است.
#دیتا_لِیک #ACID #ذخیره_سازی #تحلیل_داده
🟣لینک مقاله:
https://hudi.apache.org/blog/2026/07/17/what-is-acid-on-a-data-lake/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
What is ACID on a Data Lake? (14 minute read)
🟢 خلاصه مقاله:
در دنیای دادههای بزرگ و ذخیرهسازی اطلاعات، مفهوم ACID نقش حیاتی در حفظ صحت و یکپارچگی دادهها ایفا میکند. در انبارهای داده مانند هودی، آیسبرگ و دلتا لیک، این مفاهیم به وسیله افزودن سیستمهای ثبتدستی و عملیات انتشار اتمی به ذخیرهسازی شیء اضافه شده است. این فناوریها اجازه میدهند نوشتن دادهها در چندین فایل به صورت همزمان و همهجانبه انجام شود، اما نتایج نهایی تنها پس از انجام عملیات انتشار اتمی و ثبت تغییرات در متادیتا دیده میشوند. به عبارت دیگر، خوانندگان تنها پس از کامل شدن فرآیند، تصویر ثابتی و مطابق با آخرین وضعیت را مشاهده میکنند که تضمین میکند دادهها در یک وضعیت قابل اعتماد و همراستا باقی میمانند.
این تضمینها، هرچند در سطح هر جدول جداگانه اعمال میشوند، اما عملیات ثبتتغییرات و تراکنشها معمولا در مدت زمان چند ثانیه انجام میپذیرند. نکته مهم اینکه، جداسازی تراکنشها (ایزولاسیون) بر پایه شبیهسازی نمونههای زمانی یا اسنپشاتها است، نه اینکه کاملاً بر اساس روشهای سریالسازی کامل باشد. بنابراین، سیستمها امکان مدیریت همزمانی و سازگاری را فراهم میکنند بدون اینکه پیچیدگیهای تام و کامل تراکنشهای نسل قبلی را متحمل شوند. این رویکرد، راه حلی موثر و کارآمد برای برقراری تعادل میان کارایی و تضمینهای ACID در محیطهای مبتنی بر ذخیرهسازی شیء است.
#دیتا_لِیک #ACID #ذخیره_سازی #تحلیل_داده
🟣لینک مقاله:
https://hudi.apache.org/blog/2026/07/17/what-is-acid-on-a-data-lake/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
hudi.apache.org
What is ACID on a Data Lake? | Apache Hudi
What ACID means for tables on S3, GCS or ADLS: how table formats like Apache Hudi deliver atomic commits, snapshot isolation and safe concurrent writes.
🔵 عنوان مقاله
Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned (20 minute read)
🟢 خلاصه مقاله:
در دنیای فناوریهای مدرن، ساختن یک ساختار سرویسهای مقیاسپذیر و کارآمد، یکی از مهمترین چالشهای استراتژیک شرکتها به شمار میآید. در این مقاله، به بررسی معماری یکی از پیشرفتهترین نمونههای این ساختار توسط نتفلیکس میپردازیم. این سیستم سه لایهای با بهرهگیری از گزارشهای جریان eBPF، معیارهای برنامهنویسی و ردیابی توزیعی طراحی شده است تا بتواند عملیاتهای پیچیده در سطح سرویس را به صورت موثر مدیریت کند. این معماری، بخشهایی مجزا دارد که وظیفه جمعآوری، حلوفصل و پردازش دادهها را بر عهده دارند و در نهایت یک خط لوله پخش محتوا ایجاد میکنند که امکان جمعبندی، حلوفصل لبههای لود بالنسینگ و نگهداری گراف وابستگی را فراهم میآورد. این سیستم به گونهای طراحی شده است که بتواند در کمترین زمان ممکن، دادههای تحلیلی را ارائه دهد.
در بخش بعدی، به حل یکی از بزرگترین مشکلات این سیستم میپردازیم؛ مشکل نوسان بسیار شدید در بار ترافیک. این نوسان که به دلیل تمرکز ترافیک معتبر بر روی سرویسهای پرکاربرد به وجود میآید، میتواند عملکرد سیستم را تحت تأثیر قرار دهد و منجر به کاهش کیفیت خدمات شود. راهحلی که توسط تیم نتفلیکس اتخاذ شده، شامل توزیع چندمرحلهای بار است. این رویکرد، با تقسیم و توزیع چندگانه درخواستها و بارهای ترافیکی، توانسته است توازن مناسب و کارآمدی را در اجرای عملیاتها برقرار کند و از فشار ناگهانی و شدید بر منابع جلوگیری کند.
در نهایت، این مطالعه نشان میدهد که پاسخ به چالشهای بزرگ در ساختارهای سرویس، نیازمند هوشمندی، طراحی دقیق و کار گروهی است. تجربه نتفلیکس در توسعه این معماری، آموزههای ارزشمندی در زمینههای بهبود قابلیت مقیاسپذیری، کاهش latenc و مدیریت نوسانات بار ارائه میدهد که میتواند الهامبخش دیگر شرکتها در مسیر توسعه سیستمهای نرمافزاری خود باشد.
#ساختار_سرویس #معماری_سیستم #توسعه_پایدار #مدیریت_بار
🟣لینک مقاله:
https://netflixtechblog.com/building-service-topology-at-scale-architecture-challenges-and-lessons-learned-f4b792f3f0d8?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned (20 minute read)
🟢 خلاصه مقاله:
در دنیای فناوریهای مدرن، ساختن یک ساختار سرویسهای مقیاسپذیر و کارآمد، یکی از مهمترین چالشهای استراتژیک شرکتها به شمار میآید. در این مقاله، به بررسی معماری یکی از پیشرفتهترین نمونههای این ساختار توسط نتفلیکس میپردازیم. این سیستم سه لایهای با بهرهگیری از گزارشهای جریان eBPF، معیارهای برنامهنویسی و ردیابی توزیعی طراحی شده است تا بتواند عملیاتهای پیچیده در سطح سرویس را به صورت موثر مدیریت کند. این معماری، بخشهایی مجزا دارد که وظیفه جمعآوری، حلوفصل و پردازش دادهها را بر عهده دارند و در نهایت یک خط لوله پخش محتوا ایجاد میکنند که امکان جمعبندی، حلوفصل لبههای لود بالنسینگ و نگهداری گراف وابستگی را فراهم میآورد. این سیستم به گونهای طراحی شده است که بتواند در کمترین زمان ممکن، دادههای تحلیلی را ارائه دهد.
در بخش بعدی، به حل یکی از بزرگترین مشکلات این سیستم میپردازیم؛ مشکل نوسان بسیار شدید در بار ترافیک. این نوسان که به دلیل تمرکز ترافیک معتبر بر روی سرویسهای پرکاربرد به وجود میآید، میتواند عملکرد سیستم را تحت تأثیر قرار دهد و منجر به کاهش کیفیت خدمات شود. راهحلی که توسط تیم نتفلیکس اتخاذ شده، شامل توزیع چندمرحلهای بار است. این رویکرد، با تقسیم و توزیع چندگانه درخواستها و بارهای ترافیکی، توانسته است توازن مناسب و کارآمدی را در اجرای عملیاتها برقرار کند و از فشار ناگهانی و شدید بر منابع جلوگیری کند.
در نهایت، این مطالعه نشان میدهد که پاسخ به چالشهای بزرگ در ساختارهای سرویس، نیازمند هوشمندی، طراحی دقیق و کار گروهی است. تجربه نتفلیکس در توسعه این معماری، آموزههای ارزشمندی در زمینههای بهبود قابلیت مقیاسپذیری، کاهش latenc و مدیریت نوسانات بار ارائه میدهد که میتواند الهامبخش دیگر شرکتها در مسیر توسعه سیستمهای نرمافزاری خود باشد.
#ساختار_سرویس #معماری_سیستم #توسعه_پایدار #مدیریت_بار
🟣لینک مقاله:
https://netflixtechblog.com/building-service-topology-at-scale-architecture-challenges-and-lessons-learned-f4b792f3f0d8?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned
By Parth Jain, Rakesh Sukumar, Yingwu Zhao, Renzo Sanchez-Silva & Nathan Fisher. A deep dive into the engineering challenges of building a…
🔵 عنوان مقاله
How We Refresh Razorpay's Data Warehouse 10x Faster with Graphs and Indexes (11 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها، سرعت و کارایی همواره عوامل حیاتی برای بهبود عملکرد سیستمها محسوب میشوند. شرکت Razorpay با هدف کاهش زمان بروزرسانی مخزن دادههای خود، تصمیم گرفت راهکارهای نوینی را پیادهسازی کند. در نتیجه، توانست زمان بروزرسانی این مخزن را به طرز چشمگیری، دقیقاً ۹۰ درصد کاهش دهد. این پیشرفت عظیم، با جایگزینی اسکنهای کامل جداول با مسیرهای پیمایش گرافهای جزئی امکانپذیر شد.
راد Razorpay تلاش کرد تا با استفاده از لایه نقرهای، تغییرات روزانه را بر اساس کلید اصلی به شکل دقیق و بدون تکرار شناسایی و تفکیک کند. علاوه بر این، ایندکسهای ثانویه به منظور ذخیره ستونهای پیوست و اطلاعات بخشبندی، از نیاز به اسکنهای جامع جلوگیری کرد و روند بروزرسانیها را تسریع بخشید. در نهایت، با استفاده از پیمایش گرافها، فقط رکوردهای تغییر یافته مورد پردازش قرار گرفتند، و در حین این فرآیند، وابستگیهای مرتبط نیز بررسی و تکمیل شدند تا اطلاعات بهروز و کامل باشند. این رویکردهای نوآورانه در کنار یکدیگر، منجر به بهبود قابل توجه عملکرد سیستمهای دادهای Razorpay شد و نشان داد که ترکیب فناوریهای نوین میتواند کارایی و سرعت را به شکل چشمگیری افزایش دهد.
#مدیریت_داده #پایگاه_داده #تحلیل_داده #فناوری
🟣لینک مقاله:
https://engineering.razorpay.com/how-we-refresh-razorpays-data-warehouse-10x-faster-with-graphs-and-indexes-538abc244703?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
How We Refresh Razorpay's Data Warehouse 10x Faster with Graphs and Indexes (11 minute read)
🟢 خلاصه مقاله:
در دنیای مدیریت دادهها، سرعت و کارایی همواره عوامل حیاتی برای بهبود عملکرد سیستمها محسوب میشوند. شرکت Razorpay با هدف کاهش زمان بروزرسانی مخزن دادههای خود، تصمیم گرفت راهکارهای نوینی را پیادهسازی کند. در نتیجه، توانست زمان بروزرسانی این مخزن را به طرز چشمگیری، دقیقاً ۹۰ درصد کاهش دهد. این پیشرفت عظیم، با جایگزینی اسکنهای کامل جداول با مسیرهای پیمایش گرافهای جزئی امکانپذیر شد.
راد Razorpay تلاش کرد تا با استفاده از لایه نقرهای، تغییرات روزانه را بر اساس کلید اصلی به شکل دقیق و بدون تکرار شناسایی و تفکیک کند. علاوه بر این، ایندکسهای ثانویه به منظور ذخیره ستونهای پیوست و اطلاعات بخشبندی، از نیاز به اسکنهای جامع جلوگیری کرد و روند بروزرسانیها را تسریع بخشید. در نهایت، با استفاده از پیمایش گرافها، فقط رکوردهای تغییر یافته مورد پردازش قرار گرفتند، و در حین این فرآیند، وابستگیهای مرتبط نیز بررسی و تکمیل شدند تا اطلاعات بهروز و کامل باشند. این رویکردهای نوآورانه در کنار یکدیگر، منجر به بهبود قابل توجه عملکرد سیستمهای دادهای Razorpay شد و نشان داد که ترکیب فناوریهای نوین میتواند کارایی و سرعت را به شکل چشمگیری افزایش دهد.
#مدیریت_داده #پایگاه_داده #تحلیل_داده #فناوری
🟣لینک مقاله:
https://engineering.razorpay.com/how-we-refresh-razorpays-data-warehouse-10x-faster-with-graphs-and-indexes-538abc244703?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Medium
How We Refresh Razorpay's Data Warehouse 10x Faster with Graphs and Indexes
Contributors: Utkarsh Koppikar Rohan
🔵 عنوان مقاله
G-Eval, Explained (5 minute read)
🟢 خلاصه مقاله:
در این مقاله، با مفهوم G-Eval آشنا میشویم، روشی نوین برای ارزیابی متنهای آزاد و باز. در این روش، یک مدل زبانی بزرگ (LLM) فرآیند نمرهدهی را بر اساس یک استاندارد مشخص انجام میدهد و مراحل ارزیابی خود را ضمن فرآیند تفکر زنجیرهای (chain-of-thought) تولید مینماید. به جای خواندن یک رقم مستقیم و نقطهگذاری سریع، این سیستم بر احتمالهای سطح توکنها برای هر امتیاز، میانگین وزنی محاسبه میکند که این امر سبب ثبات بیشتر نمرهها نسبت به خروجیهای نمونهبرداری شده میشود. در واقع، به این شکل، ارزیابیها هم دقیقتر و هم قابل اعتمادتر میشوند.
یکی از نکات مهم در این روش، استفاده از مدل داور (judge model) است که از خانوادهای متفاوت با مدل ارزیابی بهره میگیرد. این تنوع در مدلهای مورد استفاده، به کاهش سوگیریهای احتمالی کمک میکند و نتیجههای قابل اعتمادتر تولید مینماید. علاوه بر این، تنظیم معیارها یا همان rubrics باید بر اساس نمونههای برچسبخورده توسط انسان صورت گیرد تا هماهنگی میان ارزیابیهای ماشین و انسان به حداکثر برسد و نتایج میدانی بهتر و دقیقتر شوند.
در نهایت، این روش نشان میدهد که چگونه میتوان ارزیابی متون آزاد را با اطمینان بیشتری انجام داد و از روشهایی بهره گرفت که خروجیهای کمنقص و منسجمتری را ارائه میدهند. استفاده از G-Eval میتواند در زمینههای مختلفی مانند آموزش، توسعه مدلهای هوشمند، و ارزیابی کیفیت محتوای تولید شده بسیار مفید باشد.
#هوش_مصنوعی #ارزیابی_متن #مدل_های_زبانی #یادگیری_ماشینی
🟣لینک مقاله:
https://arpitbhayani.me/blogs/g-eval/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
G-Eval, Explained (5 minute read)
🟢 خلاصه مقاله:
در این مقاله، با مفهوم G-Eval آشنا میشویم، روشی نوین برای ارزیابی متنهای آزاد و باز. در این روش، یک مدل زبانی بزرگ (LLM) فرآیند نمرهدهی را بر اساس یک استاندارد مشخص انجام میدهد و مراحل ارزیابی خود را ضمن فرآیند تفکر زنجیرهای (chain-of-thought) تولید مینماید. به جای خواندن یک رقم مستقیم و نقطهگذاری سریع، این سیستم بر احتمالهای سطح توکنها برای هر امتیاز، میانگین وزنی محاسبه میکند که این امر سبب ثبات بیشتر نمرهها نسبت به خروجیهای نمونهبرداری شده میشود. در واقع، به این شکل، ارزیابیها هم دقیقتر و هم قابل اعتمادتر میشوند.
یکی از نکات مهم در این روش، استفاده از مدل داور (judge model) است که از خانوادهای متفاوت با مدل ارزیابی بهره میگیرد. این تنوع در مدلهای مورد استفاده، به کاهش سوگیریهای احتمالی کمک میکند و نتیجههای قابل اعتمادتر تولید مینماید. علاوه بر این، تنظیم معیارها یا همان rubrics باید بر اساس نمونههای برچسبخورده توسط انسان صورت گیرد تا هماهنگی میان ارزیابیهای ماشین و انسان به حداکثر برسد و نتایج میدانی بهتر و دقیقتر شوند.
در نهایت، این روش نشان میدهد که چگونه میتوان ارزیابی متون آزاد را با اطمینان بیشتری انجام داد و از روشهایی بهره گرفت که خروجیهای کمنقص و منسجمتری را ارائه میدهند. استفاده از G-Eval میتواند در زمینههای مختلفی مانند آموزش، توسعه مدلهای هوشمند، و ارزیابی کیفیت محتوای تولید شده بسیار مفید باشد.
#هوش_مصنوعی #ارزیابی_متن #مدل_های_زبانی #یادگیری_ماشینی
🟣لینک مقاله:
https://arpitbhayani.me/blogs/g-eval/?utm_source=tldrdata
➖➖➖➖➖➖➖➖
👑 @Database_Academy
Arpit Bhayani
G-Eval, Explained
G-Eval is a reference-free evaluation framework that uses large language models to assess the quality of generated text. This article explains how G-Eval works, including rubric-based prompting, chain-of-thought evaluation, and probability-weighted scoring…