م
معرفی DuckLake v1.0؛ وقتی Lakehouse سریعتر و چابکتر میشود! 
چند سالی است که تب داغ معماری لیکهوس (Lakehouse) همه جا را گرفته است. در این مدت، اکوسیستم بزرگی از پروژهها، فرمتها (مثل Iceberg، Hudi و Delta Lake) و کاتالوگهای مختلف حول آن شکل گرفته است. حتی ابزارهای قدرتمندی مثل ClickHouse، StarRocks و PostgreSQL هم افزونههایی برای کار با این فرمتها ارائه کردهاند تا دادهها به شکل خام، اما قابل جستجو و آپدیت، ذخیره شوند.
وقتی به سراغ معماری لیکهوس میرویم، جداول ما در واقع مجموعهای از فایلها و پوشهها در یک ساختار منظم روی فضای ذخیرهسازی هستند. در این معماری، اطلاعات متادیتا (مانند نام و نوع ستونها، لیست فایلهای مرتبط با هر جدول و همچنین تاریخچه و نسخههای مختلف یک جدول پس از عملیات حذف، اضافه یا آپدیت) بر اساس استانداردهای ذکر شده، به صورت فایل ذخیره میشوند. برای مدیریت و کاوش در میان این فایلهای متادیتا و تسهیل دسترسی موتورهای پردازشی به دادهها، سامانههایی به نام «کاتالوگ» (Catalog) شکل گرفتند.
اما یک چالش بزرگ در این میان وجود دارد: اصرار بر ذخیره همهچیز (از جمله متادیتا) به صورت فایل! وقتی نرخ ورود و تغییر دادهها بالا میرود، ذخیره متادیتا به این شکل باعث تولید انبوهی از فایلهای کوچک (Small Files) میشود. این مسئله در کنار نیاز به استقرار و مدیریت یک لایه سرویس جدید به نام کاتالوگ، به یکی از چالشهای اصلی سامانههای فعلی تبدیل شده و هزینه سربار (overhead) سنگینی از نظر پیچیدگی و افت عملکرد به تیمها تحمیل میکند.
اینجا بود که داکلیک (DuckLake) با یک سوال ساده اما هوشمندانه متولد شد: چرا باید متادیتا را هم به صورت فایل خام ذخیره کنیم و این همه هزینه بپردازیم؟ بیایید این بخش حیاتی را به جایی که به آن تعلق دارد برگردانیم: یک پایگاه داده رابطهای (SQL) سریع و قابل اعتماد!
داکلیک (DuckLake) دقیقاً چیست و معماری آن چگونه است؟
داکلیک یک فرمت استاندارد Lakehouse است که بر پایه همین ایده ساده و قدرتمند ساخته شده و ب*خش ذخیره دادههای آن کاملا منطبق بر استاندارد آیسبرگ است. معماری داکلیک از دو لایه مجزا تشکیل شده است:
لایه داده (Data Layer): ذخیره دادهها در قالب فایلهای تغییرناپذیر (Immutable) Parquet روی Object Storage (مثل S3). لایه متادیتا (Metadata Layer): نقطه قوت اصلی داکلیک! تمام متادیتا در یک پایگاه داده رابطهای (SQL) مانند PostgreSQL، SQLite یا خود DuckDB ذخیره میشود.
نتیجه این معماری: داکلیک کاتالوگ را در دل خود دارد و نیازی به مدیریت کاتالوگهای خارجی سنگین (مثل AWS Glue یا Unity Catalog) ندارید.
چرا داکلیک؟ (مقایسه با Apache Iceberg و حل معمای فایلهای کوچک)
همانطور که پیشتر اشاره کردیم، با وجود ابزارهای قدرتمندی مثل Iceberg، داکلیک دقیقاً روی پاشنه آشیل این معماری دست میگذارد. در سیستمهایی مانند آیسبرگ، زمانی که حجم و سرعت ورود داده بالاست، اصرار بر ذخیره متادیتا به صورت فایل منجر به تولید انبوهی از فایلهای کوچک (Small Files) میشود. اسکن کردن این فایلهای متعدد روی شبکه برای یافتن محل دقیق دادهها، فرآیندی کند و زمانبر است.
برای رفع این چالش در معماریهای رایج، از عملیاتی به نام فشردهسازی (Compaction) استفاده میشود که باید به صورت منظم اجرا شده تا فایلهای کوچک متادیتا را تجمیع، یکپارچه و مرتب کند. اما مسئله اینجاست که خود این عملیات نگهداری، به شدت پرهزینه است، منابع سیستم را درگیر میکند و گاهی اجرای آن ساعتها طول میکشد!
اما در داکلیک، از آنجایی که متادیتا از همان ابتدا درون یک پایگاه داده SQL ذخیره میشود، این صورتمسئله به طور کامل پاک شده است! با حذف مشکل تولید فایلهای کوچک متادیتا و در نتیجه عدم نیاز به عملیات سنگین Compaction برای آنها، داکلیک کوئریهای کاتالوگ را به جای صدها میلیثانیه، تنها در چند میلیثانیه (۱۰ تا ۱۰۰ برابر سریعتر) و با کمترین درگیری منابع انجام میدهد.
کدام را انتخاب کنیم؟ آیسبرگ: برای دادههای مقیاس پتابایت (Petabyte-scale)، سازمانهای بزرگ و استفاده همزمان از چندین موتور پردازشی مختلف. DuckLake: برای دادههای زیر ۱۰۰ ترابایت، تیمهای کوچکتر که سادگی، سرعت و کاهش هزینهها برایشان اولویت دارد.
پیاده سازی این روش مدیریت لیکهوس در نسخه های اخیر DuckDB (با فعالسازی افزونههای مرتبط)انجام شده است.
جمع بندی: داکلیک یک تغییر پارادایم نیست، بلکه یک بازگشت به اصول مهندسی داده است. این ابزار با تکیه بر سرعت و قدرت اثباتشدهی پایگاههای داده رابطهای، راه حلی ارائه میدهد که برای اکثر سازمانها مقرونبهصرفهتر، سریعتر و بسیار سادهتر است.
چند سالی است که تب داغ معماری لیکهوس (Lakehouse) همه جا را گرفته است. در این مدت، اکوسیستم بزرگی از پروژهها، فرمتها (مثل Iceberg، Hudi و Delta Lake) و کاتالوگهای مختلف حول آن شکل گرفته است. حتی ابزارهای قدرتمندی مثل ClickHouse، StarRocks و PostgreSQL هم افزونههایی برای کار با این فرمتها ارائه کردهاند تا دادهها به شکل خام، اما قابل جستجو و آپدیت، ذخیره شوند.
وقتی به سراغ معماری لیکهوس میرویم، جداول ما در واقع مجموعهای از فایلها و پوشهها در یک ساختار منظم روی فضای ذخیرهسازی هستند. در این معماری، اطلاعات متادیتا (مانند نام و نوع ستونها، لیست فایلهای مرتبط با هر جدول و همچنین تاریخچه و نسخههای مختلف یک جدول پس از عملیات حذف، اضافه یا آپدیت) بر اساس استانداردهای ذکر شده، به صورت فایل ذخیره میشوند. برای مدیریت و کاوش در میان این فایلهای متادیتا و تسهیل دسترسی موتورهای پردازشی به دادهها، سامانههایی به نام «کاتالوگ» (Catalog) شکل گرفتند.
اما یک چالش بزرگ در این میان وجود دارد: اصرار بر ذخیره همهچیز (از جمله متادیتا) به صورت فایل! وقتی نرخ ورود و تغییر دادهها بالا میرود، ذخیره متادیتا به این شکل باعث تولید انبوهی از فایلهای کوچک (Small Files) میشود. این مسئله در کنار نیاز به استقرار و مدیریت یک لایه سرویس جدید به نام کاتالوگ، به یکی از چالشهای اصلی سامانههای فعلی تبدیل شده و هزینه سربار (overhead) سنگینی از نظر پیچیدگی و افت عملکرد به تیمها تحمیل میکند.
اینجا بود که داکلیک (DuckLake) با یک سوال ساده اما هوشمندانه متولد شد: چرا باید متادیتا را هم به صورت فایل خام ذخیره کنیم و این همه هزینه بپردازیم؟ بیایید این بخش حیاتی را به جایی که به آن تعلق دارد برگردانیم: یک پایگاه داده رابطهای (SQL) سریع و قابل اعتماد!
داکلیک (DuckLake) دقیقاً چیست و معماری آن چگونه است؟
داکلیک یک فرمت استاندارد Lakehouse است که بر پایه همین ایده ساده و قدرتمند ساخته شده و ب*خش ذخیره دادههای آن کاملا منطبق بر استاندارد آیسبرگ است. معماری داکلیک از دو لایه مجزا تشکیل شده است:
لایه داده (Data Layer): ذخیره دادهها در قالب فایلهای تغییرناپذیر (Immutable) Parquet روی Object Storage (مثل S3). لایه متادیتا (Metadata Layer): نقطه قوت اصلی داکلیک! تمام متادیتا در یک پایگاه داده رابطهای (SQL) مانند PostgreSQL، SQLite یا خود DuckDB ذخیره میشود. نتیجه این معماری: داکلیک کاتالوگ را در دل خود دارد و نیازی به مدیریت کاتالوگهای خارجی سنگین (مثل AWS Glue یا Unity Catalog) ندارید.چرا داکلیک؟ (مقایسه با Apache Iceberg و حل معمای فایلهای کوچک)
همانطور که پیشتر اشاره کردیم، با وجود ابزارهای قدرتمندی مثل Iceberg، داکلیک دقیقاً روی پاشنه آشیل این معماری دست میگذارد. در سیستمهایی مانند آیسبرگ، زمانی که حجم و سرعت ورود داده بالاست، اصرار بر ذخیره متادیتا به صورت فایل منجر به تولید انبوهی از فایلهای کوچک (Small Files) میشود. اسکن کردن این فایلهای متعدد روی شبکه برای یافتن محل دقیق دادهها، فرآیندی کند و زمانبر است.
برای رفع این چالش در معماریهای رایج، از عملیاتی به نام فشردهسازی (Compaction) استفاده میشود که باید به صورت منظم اجرا شده تا فایلهای کوچک متادیتا را تجمیع، یکپارچه و مرتب کند. اما مسئله اینجاست که خود این عملیات نگهداری، به شدت پرهزینه است، منابع سیستم را درگیر میکند و گاهی اجرای آن ساعتها طول میکشد!
اما در داکلیک، از آنجایی که متادیتا از همان ابتدا درون یک پایگاه داده SQL ذخیره میشود، این صورتمسئله به طور کامل پاک شده است! با حذف مشکل تولید فایلهای کوچک متادیتا و در نتیجه عدم نیاز به عملیات سنگین Compaction برای آنها، داکلیک کوئریهای کاتالوگ را به جای صدها میلیثانیه، تنها در چند میلیثانیه (۱۰ تا ۱۰۰ برابر سریعتر) و با کمترین درگیری منابع انجام میدهد.
کدام را انتخاب کنیم؟
آیسبرگ: برای دادههای مقیاس پتابایت (Petabyte-scale)، سازمانهای بزرگ و استفاده همزمان از چندین موتور پردازشی مختلف. DuckLake: برای دادههای زیر ۱۰۰ ترابایت، تیمهای کوچکتر که سادگی، سرعت و کاهش هزینهها برایشان اولویت دارد. پیاده سازی این روش مدیریت لیکهوس در نسخه های اخیر DuckDB (با فعالسازی افزونههای مرتبط)انجام شده است. جمع بندی: داکلیک یک تغییر پارادایم نیست، بلکه یک بازگشت به اصول مهندسی داده است. این ابزار با تکیه بر سرعت و قدرت اثباتشدهی پایگاههای داده رابطهای، راه حلی ارائه میدهد که برای اکثر سازمانها مقرونبهصرفهتر، سریعتر و بسیار سادهتر است.۱۲:۴۶
ایجنتهای هوش مصنوعی در مهندسی داده – ظهور استانداردها و اکوسیستم مهارتها
این مطلب، بخش اول از یک مقاله سه قسمتی درباره نقش ایجنتهای هوش مصنوعی (AI Agents) در مهندسی داده است. در این بخش به مفاهیم پایه، استانداردها و اکوسیستم فعلی میپردازیم. در بخشهای دوم و سوم، وارد کدهای عملیاتی و نحوه استفاده روزمره از این ابزارها در محیط کار خواهیم شد.
هوش مصنوعی در سال ۲۰۲۶ به بلوغ اولیه و پذیرش سازمانی رسیده است. طی دو سال گذشته، از سیستمهای مبتنی بر مدلهای زبانی بزرگ (LLM) به سامانههای مبتنی بر عاملهای هوشمند رسیدهایم. در دنیای مهندسی داده هم همسو با این جریان، یک انقلاب خاموش در حال وقوع است: تبدیل ایده مبهم «دستیار هوشمند» به ابزارهای کاربردی و قابل استفاده مجدد که میتوانند کوئریها را بهینهسازی کنند، ساختار دیتابیسها را طراحی کنند و پایپلاینهای داده را مدیریت نمایند. بیایید این گرایش سال را دقیقتر با هم بررسی کنیم.
از چتباتها تا ایجنتهایی که واقعا کار میکنند!
برای درک بهتر نحوه کار ایجنتها، بیایید به مشکل چتباتهای اولیه نگاه کنیم. دستیارهای اولیه در توضیح دادن مفاهیم (مثلاً انواع JOIN در SQL) عملکرد خوبی داشتند، اما نمیتوانستند کارها را در محیط واقعی شما انجام دهند.
دلیل این امر ساده است : یک ایجنت هوش مصنوعی به خودی خود نمیتواند مستقیماً به یک ابزار خارجی (مثل دیتابیس شما) متصل شود. برای این کار، ما به یک رابط، یک کانکتور و یک زبان استاندارد نیاز داریم تا ایجنت بتواند با دنیای بیرون ارتباط برقرار کند.
اینجا سه مفهوم کلیدی وارد میدان میشوند:
- پروتکل ارتباطی و ابزارها (MCP): از آنجا که ایجنت نمیتواند مستقیم به دیتابیس وصل شود، به یک پل ارتباطی نیاز دارد. پروتکل Model Context Protocol (MCP) دقیقاً همین کار را بر عهده میگیرد. این پروتکل یک استاندارد باز است که به عنوان یک کانکتور عمل میکند و به ایجنت اجازه میدهد به ابزارهای خارجی متصل شود و کارهایی مثل «اجرای یک کوئری» یا «خواندن یک فایل از سرور» را انجام دهد.- فریمورکهای ایجنت: هماهنگکنندههایی مانند LangChain یا AutoGen که حافظه و برنامهریزی ایجنت را مدیریت میکنند تا بداند در حال انجام چه کاری است.- مهارتهای ایجنت (Skills): حالا فرض کنید ایجنت به کمک MCP به دیتابیس متصل شد؛ از کجا باید بداند که چطور یک کار کاملاً تخصصی را انجام دهد؟ مثلاً چگونه ایندکسهای PostgreSQL را بهبود دهد یا چه ساختاری برای طراحی دیتابیس ClickHouse مناسبتر است؟ اینجاست که ما با فایلهای مهارت (معمولاً با فرمت skill.md) به کمک ایجنت میآییم. در این فایلها، ما دستورالعملهای تخصصی را تعریف میکنیم و به ایجنت میگوییم: «اگر کاربر دنبال اصلاح ایندکسهاست، دقیقاً باید این مراحل را طی کنی».
نگاهی گذرا به ساختار یک مهارت (Skill)برای اینکه تصور بهتری از یک "مهارت" داشته باشید، در اینجا بخش کوچکی از یک فایل skill.md برای بهینهسازی دیتابیس را میبینیم (در بخش دوم به طور مفصل به آن خواهیم پرداخت):
---
دو مرجع تخصصی برای یافتن و مرور اسکیلها
با گسترش این مفاهیم، مکانهایی برای اشتراکگذاری این مهارتها شکل گرفتهاند. در حال حاضر دو مرجع تخصصی اصلی (دو وب سایت) برای یافتن و مرور اسکیلها وجود دارند:
- سایت skill.sh: توسط Vercel در اوایل سال ۲۰۲۶ راهاندازی شد و یک هاب مرکزی برای کشف و نصب مهارتهای استاندارد است. - سایت agentskill.sh: یک مرجع تخصصی تحت مدیریت جامعه کاربری (Community-curated) که در حال حاضر شامل بیش از ۵۴۶ مهارت مختص کارهای مهندسی داده است.
ادامه در پست بعدی
این مطلب، بخش اول از یک مقاله سه قسمتی درباره نقش ایجنتهای هوش مصنوعی (AI Agents) در مهندسی داده است. در این بخش به مفاهیم پایه، استانداردها و اکوسیستم فعلی میپردازیم. در بخشهای دوم و سوم، وارد کدهای عملیاتی و نحوه استفاده روزمره از این ابزارها در محیط کار خواهیم شد.
هوش مصنوعی در سال ۲۰۲۶ به بلوغ اولیه و پذیرش سازمانی رسیده است. طی دو سال گذشته، از سیستمهای مبتنی بر مدلهای زبانی بزرگ (LLM) به سامانههای مبتنی بر عاملهای هوشمند رسیدهایم. در دنیای مهندسی داده هم همسو با این جریان، یک انقلاب خاموش در حال وقوع است: تبدیل ایده مبهم «دستیار هوشمند» به ابزارهای کاربردی و قابل استفاده مجدد که میتوانند کوئریها را بهینهسازی کنند، ساختار دیتابیسها را طراحی کنند و پایپلاینهای داده را مدیریت نمایند. بیایید این گرایش سال را دقیقتر با هم بررسی کنیم.
از چتباتها تا ایجنتهایی که واقعا کار میکنند!
برای درک بهتر نحوه کار ایجنتها، بیایید به مشکل چتباتهای اولیه نگاه کنیم. دستیارهای اولیه در توضیح دادن مفاهیم (مثلاً انواع JOIN در SQL) عملکرد خوبی داشتند، اما نمیتوانستند کارها را در محیط واقعی شما انجام دهند.
دلیل این امر ساده است : یک ایجنت هوش مصنوعی به خودی خود نمیتواند مستقیماً به یک ابزار خارجی (مثل دیتابیس شما) متصل شود. برای این کار، ما به یک رابط، یک کانکتور و یک زبان استاندارد نیاز داریم تا ایجنت بتواند با دنیای بیرون ارتباط برقرار کند.
اینجا سه مفهوم کلیدی وارد میدان میشوند:
- پروتکل ارتباطی و ابزارها (MCP): از آنجا که ایجنت نمیتواند مستقیم به دیتابیس وصل شود، به یک پل ارتباطی نیاز دارد. پروتکل Model Context Protocol (MCP) دقیقاً همین کار را بر عهده میگیرد. این پروتکل یک استاندارد باز است که به عنوان یک کانکتور عمل میکند و به ایجنت اجازه میدهد به ابزارهای خارجی متصل شود و کارهایی مثل «اجرای یک کوئری» یا «خواندن یک فایل از سرور» را انجام دهد.- فریمورکهای ایجنت: هماهنگکنندههایی مانند LangChain یا AutoGen که حافظه و برنامهریزی ایجنت را مدیریت میکنند تا بداند در حال انجام چه کاری است.- مهارتهای ایجنت (Skills): حالا فرض کنید ایجنت به کمک MCP به دیتابیس متصل شد؛ از کجا باید بداند که چطور یک کار کاملاً تخصصی را انجام دهد؟ مثلاً چگونه ایندکسهای PostgreSQL را بهبود دهد یا چه ساختاری برای طراحی دیتابیس ClickHouse مناسبتر است؟ اینجاست که ما با فایلهای مهارت (معمولاً با فرمت skill.md) به کمک ایجنت میآییم. در این فایلها، ما دستورالعملهای تخصصی را تعریف میکنیم و به ایجنت میگوییم: «اگر کاربر دنبال اصلاح ایندکسهاست، دقیقاً باید این مراحل را طی کنی».
نگاهی گذرا به ساختار یک مهارت (Skill)برای اینکه تصور بهتری از یک "مهارت" داشته باشید، در اینجا بخش کوچکی از یک فایل skill.md برای بهینهسازی دیتابیس را میبینیم (در بخش دوم به طور مفصل به آن خواهیم پرداخت):
---
name: postgres-fast-tuning
description: Detect and resolve common slow query issues in PostgreSQL
---
**Role:** You are a senior data engineer with deep expertise in Postgres optimization.
**Step 1:** First, call the database MCP tool and execute the query with `EXPLAIN ANALYZE`.
**Step 2:** If you observe a `Sequential Scan` on large tables, suggest creating an Index.
دو مرجع تخصصی برای یافتن و مرور اسکیلها
با گسترش این مفاهیم، مکانهایی برای اشتراکگذاری این مهارتها شکل گرفتهاند. در حال حاضر دو مرجع تخصصی اصلی (دو وب سایت) برای یافتن و مرور اسکیلها وجود دارند:
- سایت skill.sh: توسط Vercel در اوایل سال ۲۰۲۶ راهاندازی شد و یک هاب مرکزی برای کشف و نصب مهارتهای استاندارد است. - سایت agentskill.sh: یک مرجع تخصصی تحت مدیریت جامعه کاربری (Community-curated) که در حال حاضر شامل بیش از ۵۴۶ مهارت مختص کارهای مهندسی داده است.ادامه در پست بعدی
۱۷:۵۰
۱۷:۵۵
کشف گنجینهای از مهارتها در مراجع تخصصی--- ادامه مقاله از پست قبلی
---- با جستجو در مراجعی مانند skill.sh و agentskill.sh به مهارتهای متنوعی در حوزه مهندسی داده برمیخوریم. هماکنون پروژههای برجستهای در این پلتفرمها حضور دارند که هر کدام برای یک کار تخصصی و رفع چالشهای روزانه مدیریت دادهها طراحی شدهاند :
مهارت `clickhouse-io`: برای پیادهسازی بهترین روشها (Best Practices) در بارهای کاری تحلیلی و تیونینگ حرفهای دیتابیس ClickHouse. مهارت `spark-optimization`: جهت بهینهسازی عملکرد آپاچی اسپارک (شامل مفاهیم پیچیدهای مثل پارتیشنبندی استاندارد، کش کردن و مدیریت بهینه Shuffle). مهارت `airflow-dag-patterns`: برای پیادهسازی الگوهای DAG پایدار، مطمئن و آماده برای محیط واقعی (Production). مهارت `dbt-transformation-patterns`: برای سازماندهی اصولی مدلها، معماری تستنویسی و استراتژیهای افزایشی (Incremental). مهارت `supabase-postgres-best-practices`: جهت بهبود چشمگیر عملکرد، ارتقای امنیت و طراحی صحیح اسکیما در پستگرس. حضور بازیگران بزرگی مثل ClickHouse، dbt، Supabase و DataHub در این پلتفرمها نشان میدهد که توسعه این مهارتهای اختصاصی دیگر یک آزمایش سرگرمکننده نیست، بلکه مسیر قطعی آینده صنعت مهندسی داده است. این موضوع برای مهندسان داده چه معنایی دارد؟نقش مهندس داده به سرعت در حال تغییر از "نوشتن دستی تمامی اسکریپتها" به "گزینش، ترکیب و اعتبارسنجی" مهارتهای ایجنتها است. به زودی شما زمان بیشتری را صرف تعریف گاردریلها (Guardrails - چارچوبهای ایمنی) و تست خروجیها خواهید کرد تا درگیری با کدهای تکراری و بهینهسازیهای سطح پایین.پدیده جذاب ماجرا اینجاست: دانشی تخصصی که زمانی تنها در ذهن یک مهندس داده ارشد (Senior Engineer) قفل شده بود، حالا قابل استفاده مجدد شده است! خود این فایلهای تشریح مهارت (skill.md) یک رفرنس و راهنمای بسیار مفید و خلاصه برای مهندسان هستند. حتی اگر از ایجنتهای هوش مصنوعی استفاده نکنید، خواندن یک فایل اسکیل که توسط متخصصان همان دیتابیس نوشته شده، دقیقاً مانند در دست داشتن یک چکلیست طلایی برای انجام بینقص تسکهای روزمره است.
نکته : در یک سال گذشته، مطالب بسیار زیادی درباره دو ضلع دیگر توسعه عاملهای هوشمند (یعنی MCP Serverها و فریمورکها) منتشر شده است. با توجه به تمرکز این نوشته بر موضوع بررسی و توسعه «مهارتهای مرتبط با مهندسی داده»، در اینجا به آن دو مبحث نپرداختیم؛ اما تلاش میکنیم در نوشتارهای جداگانه، این موارد را نیز با نگاهی تخصصی به حوزه مهندسی داده، بسیار دقیقتر بررسی کنیم.
در بخش دوم این نوشتار:یک مهارت واقعی را کالبدشکافی خواهیم کرد: مهارت بهینهسازی عملکرد PostgreSQL از تیم Supabase. با ما همراه باشید!۱۷:۵۵
اما یه سوال: وقتی اینترنت بینالملل نداریم، چطور Skillها را پیدا کنیم؟
یکی از چالشهای این روزها این است که دسترسی به برخی سایتهای مرجع مثل skill.sh یا agentskill.sh ممکن است محدود باشد. اما هنوز هم چند راه ساده وجود دارد که بتوانید مهارتها و Skillهای مرتبط با مهندسی داده را پیدا و بررسی کنید.
راهکار اول: جستجو در GitHub
بخش بزرگی از Skillها و مجموعههای آنها در ریپازیتوریهای GitHub جمعآوری شدهاند. معمولاً این لیستها با عنوانهایی مثل awesome agent skills یا awesome ai agents منتشر میشوند.
برای شروع میتوانید این چند ریپو شناختهشده را بررسی کنید:
VoltAgent/awesome-agent-skills یک مجموعه بزرگ و بازبینیشده از بیش از 1000 مهارت رسمی و جامعهمحور برای ایجنتهای هوش مصنوعی.
sickn33/antigravity-awesome-skills کتابخانهای بسیار بزرگ با بیش از 1300 مهارت و مجموعهای از workflowهای آماده برای ایجنتها.
Sec-Dome/Awesome-Skills مجموعهای از صدها مهارت تأییدشده در حوزههای مختلف مثل توسعه نرمافزار، امنیت و اتوماسیون.
با مرور این ریپازیتوریها میتوانید به تعداد زیادی skill.md واقعی دسترسی پیدا کنید و ببینید هر مهارت چگونه طراحی شده است.
راهکار دوم: استفاده از DeepSeek به عنوان دستیار وب
دیپسیک یک هوش مصنوعی مولد چینی است که در حال حاضر سایت آن در ایران باز و اپ آن هم قابل نصب است و میتواند نقش یک دستیار جستجوی وب را برای شما بازی کند.
ترفند ساده این است که از DeepSeek بخواهید به جای شما در این سایتها جستجو کند.
مثلاً میتوانید بپرسید:
از سایت skills.sh مهارتهای مرتبط با PostgreSQL را برایم لیست کن.
بعد از اینکه لیست را گرفتید، میتوانید ادامه بدهید:
مهارت مربوط به PostgreSQL optimization را کامل برایم نمایش بده و اگر نکته مهمی در آن هست توضیح بده.
_به این شکل DeepSeek میتواند متن کامل Skillها را استخراج کند، خلاصه کند و حتی نکات تکمیلی به آن اضافه کند؛ در واقع مثل یک دستیار تحقیقاتی برای مرور مهارتها عمل میکند_.
نتیجه این است که حتی در شرایط محدودیت اینترنت هم میتوانید همچنان به دانش و تجربهای که داخل این Skillها جمع شده دسترسی داشته باشید.
در پست بعدییک Skill واقعی از تیم Supabase را بررسی میکنیم که برای بهینهسازی عملکرد PostgreSQL طراحی شده است.
یکی از چالشهای این روزها این است که دسترسی به برخی سایتهای مرجع مثل skill.sh یا agentskill.sh ممکن است محدود باشد. اما هنوز هم چند راه ساده وجود دارد که بتوانید مهارتها و Skillهای مرتبط با مهندسی داده را پیدا و بررسی کنید.
راهکار اول: جستجو در GitHubبخش بزرگی از Skillها و مجموعههای آنها در ریپازیتوریهای GitHub جمعآوری شدهاند. معمولاً این لیستها با عنوانهایی مثل awesome agent skills یا awesome ai agents منتشر میشوند.
برای شروع میتوانید این چند ریپو شناختهشده را بررسی کنید:
VoltAgent/awesome-agent-skills یک مجموعه بزرگ و بازبینیشده از بیش از 1000 مهارت رسمی و جامعهمحور برای ایجنتهای هوش مصنوعی. sickn33/antigravity-awesome-skills کتابخانهای بسیار بزرگ با بیش از 1300 مهارت و مجموعهای از workflowهای آماده برای ایجنتها. Sec-Dome/Awesome-Skills مجموعهای از صدها مهارت تأییدشده در حوزههای مختلف مثل توسعه نرمافزار، امنیت و اتوماسیون.با مرور این ریپازیتوریها میتوانید به تعداد زیادی skill.md واقعی دسترسی پیدا کنید و ببینید هر مهارت چگونه طراحی شده است.
راهکار دوم: استفاده از DeepSeek به عنوان دستیار وبدیپسیک یک هوش مصنوعی مولد چینی است که در حال حاضر سایت آن در ایران باز و اپ آن هم قابل نصب است و میتواند نقش یک دستیار جستجوی وب را برای شما بازی کند.
ترفند ساده این است که از DeepSeek بخواهید به جای شما در این سایتها جستجو کند.
مثلاً میتوانید بپرسید:
از سایت skills.sh مهارتهای مرتبط با PostgreSQL را برایم لیست کن.
بعد از اینکه لیست را گرفتید، میتوانید ادامه بدهید:
مهارت مربوط به PostgreSQL optimization را کامل برایم نمایش بده و اگر نکته مهمی در آن هست توضیح بده.
_به این شکل DeepSeek میتواند متن کامل Skillها را استخراج کند، خلاصه کند و حتی نکات تکمیلی به آن اضافه کند؛ در واقع مثل یک دستیار تحقیقاتی برای مرور مهارتها عمل میکند_.
نتیجه این است که حتی در شرایط محدودیت اینترنت هم میتوانید همچنان به دانش و تجربهای که داخل این Skillها جمع شده دسترسی داشته باشید. در پست بعدییک Skill واقعی از تیم Supabase را بررسی میکنیم که برای بهینهسازی عملکرد PostgreSQL طراحی شده است.۲۱:۴۰
این هم از بات دانلود از یوتیوب و SoudCloud در بله . چی بگیم والا ... 🥸 @opendoorbot. خدایا خودت کمک کن که اگر استفاده هم کردیم، به این شکل از دسترسی به اینترنت، عادت نکنیم
۱۰:۳۹
معرفی یک جایگزین بومی و مطمئن برای گوگلدرایو در روزهای اختلال اینترنت
این روزها با توجه به محدودیتها و قطعیهای مکرر اینترنت بینالملل، دسترسی به فضاهای ذخیرهسازی ابری جهانی مانند «گوگل درایو» یا «دراپباکس» با چالشهای زیادی مواجه شده است. از طرفی، پیامرسانها نیز به دلیل محدودیت در حجم آپلود و عدم امکان دستهبندی مناسب، گزینه ایدهآلی برای آرشیو و اشتراکگذاری فایلهای تخصصی و حجیم نیستند.
در این شرایط، استفاده از یک سرویس ذخیرهسازی ابری بومی که روی شبکهی داخلی (اینترانت) با سرعت و پایداری بالا در دسترس باشد، یک نیاز ضروری برای تیمها، دانشجویان و جامعه تخصصی است.
سامانه «ابرهمراهی» (Abrehamrahi.ir) یکی از گزینههای بسیار مناسب و کاربردی در این زمینه است که امکانات کاملی را با قیمتی بسیار عالی ارائه میدهد.
چرا ابرهمراهی میتواند یک انتخاب هوشمندانه باشد؟
۱۰ گیگابایت فضای رایگان اولیه: با ثبتنام در سایت، بلافاصله ۱۰ گیگابایت فضای ذخیرهسازی کاملاً رایگان در اختیار شما قرار میگیرد تا بتوانید سرویس را بهخوبی تست و برای نیازهای اولیه خود استفاده کنید. تعرفههای بهشدت مقرونبهصرفه: هزینههای ارتقای فضا در این سرویس فوقالعاده اقتصادی است. بهعنوان مثال، برای خرید ۵۰ گیگابایت فضا به مدت ۳ ماه، تنها ۴۰ هزار تومان (حتی کمتر از هزینه خرید یک بسته چیپس و پفک!) پرداخت میکنید و خرید ۲۰۰ گیگابایت فضای ۳ ماهه، تنها ۷۰ هزار تومان برایتان هزینه خواهد داشت. سرعت بالا و بدون قطعی: به دلیل میزبانی در داخل کشور، حتی در زمان قطعی اینترنت بینالملل، آپلود و دانلود فایلها با بالاترین سرعت ممکن انجام میشود. اشتراکگذاری آسان با لینک اختصاصی: شما میتوانید برای فایلها و پوشههای خود لینک دانلود زماندار یا موقت بسازید. جالبتر اینکه، گیرندهی لینک برای دانلود فایل هیچ نیازی به ثبتنام و ساخت اکانت در سایت ندارد. دسترسی همهجانبه: علاوه بر نسخه وب، ابرهمراهی دارای اپلیکیشن اختصاصی اندروید است که مدیریت فایلها را در موبایل بسیار ساده میکند. امنیت و بازیابی اطلاعات: فایلهای شما با امنیت بالا نگهداری میشوند. همچنین در صورت حذف اشتباه، فایلها تا یک ماه در سطل زباله اکانت شما باقی مانده و قابل بازگردانی هستند. امکان گزارشگیری: پنل کاربری به شما امکان میدهد گزارشهای دقیقی از میزان دانلود و آپلود روزانه فایلهای خود داشته باشید.
اگر برای پیشبرد پروژههای تیمی، اشتراکگذاری فایلهای کاری یا نگهداری از اطلاعات مهم خود به دنبال یک فضای امن، سریع و همیشه در دسترس هستید، پیشنهاد میکنم همین الان اکانت رایگان خود را بسازید.
لینک ورود و ثبتنام: https://abrehamrahi.ir
این روزها با توجه به محدودیتها و قطعیهای مکرر اینترنت بینالملل، دسترسی به فضاهای ذخیرهسازی ابری جهانی مانند «گوگل درایو» یا «دراپباکس» با چالشهای زیادی مواجه شده است. از طرفی، پیامرسانها نیز به دلیل محدودیت در حجم آپلود و عدم امکان دستهبندی مناسب، گزینه ایدهآلی برای آرشیو و اشتراکگذاری فایلهای تخصصی و حجیم نیستند.
در این شرایط، استفاده از یک سرویس ذخیرهسازی ابری بومی که روی شبکهی داخلی (اینترانت) با سرعت و پایداری بالا در دسترس باشد، یک نیاز ضروری برای تیمها، دانشجویان و جامعه تخصصی است.
سامانه «ابرهمراهی» (Abrehamrahi.ir) یکی از گزینههای بسیار مناسب و کاربردی در این زمینه است که امکانات کاملی را با قیمتی بسیار عالی ارائه میدهد.
چرا ابرهمراهی میتواند یک انتخاب هوشمندانه باشد؟
۱۰ گیگابایت فضای رایگان اولیه: با ثبتنام در سایت، بلافاصله ۱۰ گیگابایت فضای ذخیرهسازی کاملاً رایگان در اختیار شما قرار میگیرد تا بتوانید سرویس را بهخوبی تست و برای نیازهای اولیه خود استفاده کنید. تعرفههای بهشدت مقرونبهصرفه: هزینههای ارتقای فضا در این سرویس فوقالعاده اقتصادی است. بهعنوان مثال، برای خرید ۵۰ گیگابایت فضا به مدت ۳ ماه، تنها ۴۰ هزار تومان (حتی کمتر از هزینه خرید یک بسته چیپس و پفک!) پرداخت میکنید و خرید ۲۰۰ گیگابایت فضای ۳ ماهه، تنها ۷۰ هزار تومان برایتان هزینه خواهد داشت. سرعت بالا و بدون قطعی: به دلیل میزبانی در داخل کشور، حتی در زمان قطعی اینترنت بینالملل، آپلود و دانلود فایلها با بالاترین سرعت ممکن انجام میشود. اشتراکگذاری آسان با لینک اختصاصی: شما میتوانید برای فایلها و پوشههای خود لینک دانلود زماندار یا موقت بسازید. جالبتر اینکه، گیرندهی لینک برای دانلود فایل هیچ نیازی به ثبتنام و ساخت اکانت در سایت ندارد. دسترسی همهجانبه: علاوه بر نسخه وب، ابرهمراهی دارای اپلیکیشن اختصاصی اندروید است که مدیریت فایلها را در موبایل بسیار ساده میکند. امنیت و بازیابی اطلاعات: فایلهای شما با امنیت بالا نگهداری میشوند. همچنین در صورت حذف اشتباه، فایلها تا یک ماه در سطل زباله اکانت شما باقی مانده و قابل بازگردانی هستند. امکان گزارشگیری: پنل کاربری به شما امکان میدهد گزارشهای دقیقی از میزان دانلود و آپلود روزانه فایلهای خود داشته باشید.اگر برای پیشبرد پروژههای تیمی، اشتراکگذاری فایلهای کاری یا نگهداری از اطلاعات مهم خود به دنبال یک فضای امن، سریع و همیشه در دسترس هستید، پیشنهاد میکنم همین الان اکانت رایگان خود را بسازید.
لینک ورود و ثبتنام: https://abrehamrahi.ir۸:۵۳
آموزش راهاندازی رپلیکیشن فیزیکی در PostgreSQL (روش Log-Shipping)
چرا به رپلیکیشن در پستگرس نیاز داریم؟امروزه ردپای PostgreSQL را تقریباً در هر معماری مدرنی میبینیم و به دیتابیس پیشفرض و دمدستی بسیاری از استارتاپها و پروژههای نرمافزاری تبدیل شده است. اما با رشد سیستم و افزایش اهمیت دادهها، اتکا به یک سرور منفرد ریسک بسیار بالایی دارد. یکی از مهمترین مهارتهایی که برای داشتن و مدیریت یک کلاستر کوچک پستگرس به آن نیاز داریم، برقراری رپلیکیشن (Replication) دیتا بین سرور اصلی (Primary) و یک سرور بکاپ یا رپلیکا است. این کار نهتنها به توزیع بار پردازشی کمک میکند، بلکه تضمین میکند در صورت خرابی سرور اصلی، یک دیتابیس جایگزین آمادهبهکار داشته باشید (High Availability).
در این آموزش چه میبینیم؟در این ویدیوی آموزشی، راهاندازی رپلیکیشن فیزیکی در پستگرس را با استفاده از روش پایه و مهم Log-Shipping با جزئیات کامل و به صورت کاملاً عملی یاد میگیرید. در این آموزش به کمک Docker یک کلاستر Primary/Replica میسازیم، Base Backup میگیریم، Replication Lag را تست میکنیم و در نهایت فرآیند Failover (ارتقای سرور جایگزین به اصلی) را شبیهسازی میکنیم.
این فیلم آموزشی، بخشی از دوره جامع «پستگرس کاربردی» در مدرسه مهندسی داده سپهرام است.
لینکهای دسترسی و مشاهده:نکته: در این آموزش از pgCLI استفاده شده است که با دستور 'pip install pgcli` به سادگی نصب میشود.
مشاهده فیلم کامل در آپارات:https://www.aparat.com/v/ctst0l6
دانلود فایلهای تمرینی و کدهای کارگاه:https://abrehamrahi.ir/o/public/6fGGxNLA/
مشاهده سایر دورههای مدرسه مهندسی داده سپهرام:https://sepahram.ir/courses
— — — — — — — — — —عضویت در کانالهای مهندسی داده: تلگرام: https://t.me/bigdata_ir بله: ble.ir/join/Dym3th99Dj
آموزش راهاندازی رپلیکیشن فیزیکی در PostgreSQL (روش Log-Shipping) چرا به رپلیکیشن در پستگرس نیاز داریم؟امروزه ردپای PostgreSQL را تقریباً در هر معماری مدرنی میبینیم و به دیتابیس پیشفرض و دمدستی بسیاری از استارتاپها و پروژههای نرمافزاری تبدیل شده است. اما با رشد سیستم و افزایش اهمیت دادهها، اتکا به یک سرور منفرد ریسک بسیار بالایی دارد. یکی از مهمترین مهارتهایی که برای داشتن و مدیریت یک کلاستر کوچک پستگرس به آن نیاز داریم، برقراری رپلیکیشن (Replication) دیتا بین سرور اصلی (Primary) و یک سرور بکاپ یا رپلیکا است. این کار نهتنها به توزیع بار پردازشی کمک میکند، بلکه تضمین میکند در صورت خرابی سرور اصلی، یک دیتابیس جایگزین آمادهبهکار داشته باشید (High Availability). در این آموزش چه میبینیم؟در این ویدیوی آموزشی، راهاندازی رپلیکیشن فیزیکی در پستگرس را با استفاده از روش پایه و مهم Log-Shipping با جزئیات کامل و به صورت کاملاً عملی یاد میگیرید. در این آموزش به کمک Docker یک کلاستر Primary/Replica میسازیم، Base Backup میگیریم، Replication Lag را تست میکنیم و در نهایت فرآیند Failover (ارتقای سرور جایگزین به اصلی) را شبیهسازی میکنیم. این فیلم آموزشی، بخشی از دوره جامع «پستگرس کاربردی» در مدرسه مهندسی داده سپهرام است. لینکهای دسترسی و مشاهده:نکته: در این آموزش از pgCLI استفاده شده است که با دستور 'pip install pgcli` به سادگی نصب میشود. مشاهده فیلم کامل در آپارات:https://www.aparat.com/v/ctst0l6 دانلود فایلهای تمرینی و کدهای کارگاه:https://abrehamrahi.ir/o/public/6fGGxNLA/ مشاهده سایر دورههای مدرسه مهندسی داده سپهرام:https://sepahram.ir/courses— — — — — — — — — —عضویت در کانالهای مهندسی داده:
تلگرام: https://t.me/bigdata_ir بله: ble.ir/join/Dym3th99Dj۲۲:۲۲
۲۲:۲۲
ایجنتهای هوش مصنوعی در مهندسی داده: معرفی Agent Skills و بررسی موردی بهینهسازی PostgreSQL
سال ۲۰۲۵ نقطه عطفی در رواج هوش مصنوعی و بهکارگیری عملیاتی آن در حوزههای مختلف بود؛ از گسترش ابزارها و MCP Serverها گرفته تا توسعه استانداردهای عاملهای هوشمند. اما یکی از تأثیرگذارترین اتفاقات، معرفی و استانداردسازی مفهوم “مهارت” (Skill) برای عاملهای هوشمند و راهاندازی وبسایت مرجع agentskills.io توسط بزرگان هوش مصنوعی دنیا بود که به سادهترین حالت ممکن، وظایف تخصصی را به کارهای روزانه یک عامل هوشمند اضافه میکند.
در واقع، این مهارتها، فشردهِ تمام دانش و تجربیات یک متخصص خبره (مانند بهینهسازی کوئریها، طراحی دیتابیس و مدیریت ایندکسها) را مستند کرده و در اختیار عامل های هوشمند و به تبع آن ، در اختیار مهندسین داده قرار میدهند. با این کار یعنی داشتن دسترسی به انواع مهارت ها، انگار همیشه یک دستیار ارشد برای هر کاری در حوزه های فنی و بخصوص زیرساخت داده در کنار خود دارید! و میتوانید این مهارت ها را به دستیاران هوشمند خود اضافه کرده، آنها را ویرایش و سفارشی سازی کنید تا کارهای روزانه شما را سرعت و بهبود بخشند .
در بخش دوم این مقاله، از مباحث تئوری عبور کرده و کاربرد این ایجنتهای هوشمند دارای مهارت های تخصصی را در مدیریت زیرساختهای داده به صورت عملی با واکاوی مهارتهای منتشر شده وبسایت Supabase در بهینه سازی و مدیریت پستگرس ، بررسی کردهایم.
نکات کلیدی این مطلب:
آشنایی با استاندارد باز Agent Skills و تفاوت آن با پروتکل MCP
بررسی عملی مهارت استاندارد Supabase برای PostgreSQL (کالبدشکافی فایل SKILL.md)
بررسی دو مهارت کاربردی بهینهسازی (تجمیع دانش تخصصی مدیریت ایندکسها و کوئریها)
آموزش نحوه فعالسازی Skillها در محیطهای توسعه مانند Cursor و VS Code (GitHub Copilot)
اگر میخواهید بدانید چگونه کارهای پیچیده و زمانبر دیتابیس را به ایجنتهای متخصص بسپارید، این مقاله برای شماست!
برای مطالعه مطلب کامل روی لینک زیر کلیک کنید:
https://www.bigdata.ir?p=9045
آدرس کانال مهندسی داده در تلگرام: https://t.me/bigdata_ir
در پیام رسان بله: ble.ir/join/Dym3th99Dj
آموزشهای تخصصی مهندسی داده: https://sepahram.ir/courses
ایجنتهای هوش مصنوعی در مهندسی داده: معرفی Agent Skills و بررسی موردی بهینهسازی PostgreSQLسال ۲۰۲۵ نقطه عطفی در رواج هوش مصنوعی و بهکارگیری عملیاتی آن در حوزههای مختلف بود؛ از گسترش ابزارها و MCP Serverها گرفته تا توسعه استانداردهای عاملهای هوشمند. اما یکی از تأثیرگذارترین اتفاقات، معرفی و استانداردسازی مفهوم “مهارت” (Skill) برای عاملهای هوشمند و راهاندازی وبسایت مرجع agentskills.io توسط بزرگان هوش مصنوعی دنیا بود که به سادهترین حالت ممکن، وظایف تخصصی را به کارهای روزانه یک عامل هوشمند اضافه میکند.
در واقع، این مهارتها، فشردهِ تمام دانش و تجربیات یک متخصص خبره (مانند بهینهسازی کوئریها، طراحی دیتابیس و مدیریت ایندکسها) را مستند کرده و در اختیار عامل های هوشمند و به تبع آن ، در اختیار مهندسین داده قرار میدهند. با این کار یعنی داشتن دسترسی به انواع مهارت ها، انگار همیشه یک دستیار ارشد برای هر کاری در حوزه های فنی و بخصوص زیرساخت داده در کنار خود دارید! و میتوانید این مهارت ها را به دستیاران هوشمند خود اضافه کرده، آنها را ویرایش و سفارشی سازی کنید تا کارهای روزانه شما را سرعت و بهبود بخشند .
در بخش دوم این مقاله، از مباحث تئوری عبور کرده و کاربرد این ایجنتهای هوشمند دارای مهارت های تخصصی را در مدیریت زیرساختهای داده به صورت عملی با واکاوی مهارتهای منتشر شده وبسایت Supabase در بهینه سازی و مدیریت پستگرس ، بررسی کردهایم.
نکات کلیدی این مطلب:
آشنایی با استاندارد باز Agent Skills و تفاوت آن با پروتکل MCP بررسی عملی مهارت استاندارد Supabase برای PostgreSQL (کالبدشکافی فایل SKILL.md) بررسی دو مهارت کاربردی بهینهسازی (تجمیع دانش تخصصی مدیریت ایندکسها و کوئریها) آموزش نحوه فعالسازی Skillها در محیطهای توسعه مانند Cursor و VS Code (GitHub Copilot)اگر میخواهید بدانید چگونه کارهای پیچیده و زمانبر دیتابیس را به ایجنتهای متخصص بسپارید، این مقاله برای شماست!
برای مطالعه مطلب کامل روی لینک زیر کلیک کنید: https://www.bigdata.ir?p=9045 آدرس کانال مهندسی داده در تلگرام: https://t.me/bigdata_ir در پیام رسان بله: ble.ir/join/Dym3th99Dj آموزشهای تخصصی مهندسی داده: https://sepahram.ir/courses۱۶:۵۵
۱۶:۵۵
تکامل SQLite: چرا Turso در عصر AI و Edge متولد شد؟
همه ما با SQLite خاطره داریم؛ همان دیتابیس تکفایلی، سبک و دوستداشتنی که بدون هیچگونه تنظیماتی، در کسری از ثانیه آماده به کار میشد. اما وقتی به دنیای ایجنتهای هوش مصنوعی، معماریهای SaaS Multi-Tenant و اپلیکیشنهای توزیعشده در لبه (Edge) میرسیم، بزرگترین نقطه قوت SQLite به نقطه ضعف آن تبدیل میشود: محدودیت تکنویسنده (Single-Writer Bottleneck).
داستان Turso دقیقاً از همین نقطه شروع شد. تیم سازنده با درک این محدودیتها، یک تصمیم جسورانه گرفتند: بازنویسی کامل هسته SQLite با زبان Rust. هدف، حفظ روح سادگی SQLite و در عین حال حل چالشهای بنیادی آن برای نیازهای امروز بود. نتیجه، دیتابیسی است که همان حس آشنای SQLite را دارد، اما با قابلیتهایی که پیش از این غیرممکن به نظر میرسید.
جادوی Turso در عمل چیست؟ 🪄
پروژه Turso در هسته خود، یک موتور دیتابیس درونفرایندی (In-Process) است که با SQLite سازگاری کامل دارد و کاملاً متنباز (Open Source) است. اما چه چیزی آن را متمایز میکند؟
نوشتن همزمان (Concurrent Writes) با MVCCخداحافظی با خطای معروف `SQLITE_BUSY`! به لطف پیادهسازی کنترل همزمانی چندنسخهای (MVCC)، چندین سرویس یا کاربر میتوانند بهصورت همزمان و بدون تداخل در دیتابیس بنویسند. این ویژگی توان عملیاتی نوشتن را به شدت افزایش داده و Turso را برای سیستمهای Real-time Ingestion ایدهآل میکند.
همگامسازی توزیعشده با Embedded Replicasبا استفاده از libSQL (فورک متنباز SQLite که پایه Turso است)، میتوانید دیتابیس خود را به هر موقعیت جغرافیایی، از جمله سرورهای شخصی خودتان، Replicate کنید. خواندن اطلاعات از نزدیکترین Replica با تأخیر نزدیک به صفر انجام میشود و عملیات نوشتن بهصورت ناهمگام (Async) با دیتابیس مرکزی همگام میگردد.
جستجوی برداری بومی (Native Vector Search)بدون نیاز به دیتابیس جداگانه برای Vector Search! تورسو از نوع داده `vector` و توابع SQL برای جستجوی شباهت پشتیبانی میکند. ترکیب دیتابیس رابطهای و برداری در یک فایل واحد، راهحلی بینظیر برای ساخت اپلیکیشنهای RAG و سیستمهای Recommendation است.
معماری میلیونها دیتابیسبه هر کاربر، ایجنت یا Task، یک دیتابیس ایزوله بدهید! این معماری به شما اجازه میدهد تا میلیونها دیتابیس مجزا را مدیریت کنید؛ یک تغییر بازی بزرگ برای SaaS Multi-Tenant، سیستمهای Multi-Agent و Sharding افقی.
یک قدم فراتر: فایل سیستم برای ایجنتها با AgentFS
تیم Turso پس از دیتابیس، به سراغ نیاز ایجنتهای هوش مصنوعی به یک فایل سیستم ایزوله رفت: AgentFS.این لایه فایل سیستم متنباز، کاملاً روی دیتابیس Turso پیادهسازی شده و یک فضای ذخیرهسازی ساختاریافته، قابل ممیزی و قابل حمل برای ایجنتها فراهم میکند.
همه چیز در AgentFS حول یک فایل SQLite میچرخد (شامل یک فایل سیستم مجازی مشابه POSIX، ذخیرهساز Key-Value و یک مسیر ممیزی برای دیباگ). از آنجایی که Turso نسخه WebAssembly (WASM) نیز دارد، ایجنت شما حتی در محیط مرورگر هم میتواند از ابزارهایی مثل `git` یا `mkdir` استفاده کند و تمام تغییرات در یک فایل SQLite ذخیره میشود!
جمعبندی
تورسو (Turso) ثابت میکند که برای مقیاسپذیری و همگامی با فناوریهای مدرن مثل AI و Edge Computing، همیشه نیازی به معماریهای پیچیده و دیتابیسهای سنگین نیست. گاهی تکامل یک ابزار ساده و اثباتشده مثل SQLite، بهترین پاسخ به پیچیدهترین نیازهای مهندسی داده است.
برای مطالعه مستندات، آشنایی بیشتر و شروع کار، حتماً به وبسایت رسمی Turso سر بزنید: http://turso.tech/
همچنین مخازن رسمی و متنباز این پروژه در گیتهاب برای بررسی فنی در دسترس هستند: موتور دیتابیس Rust: github.com/tursodatabase/turso فایل سیستم ایجنتها: github.com/tursodatabase/agentfs
#Turso #SQLite #OpenSource #DataEngineering #DistributedSystems #VectorDatabase #AI #Rust #AgentFS #SelfHosting #مهندسی_داده
همه ما با SQLite خاطره داریم؛ همان دیتابیس تکفایلی، سبک و دوستداشتنی که بدون هیچگونه تنظیماتی، در کسری از ثانیه آماده به کار میشد. اما وقتی به دنیای ایجنتهای هوش مصنوعی، معماریهای SaaS Multi-Tenant و اپلیکیشنهای توزیعشده در لبه (Edge) میرسیم، بزرگترین نقطه قوت SQLite به نقطه ضعف آن تبدیل میشود: محدودیت تکنویسنده (Single-Writer Bottleneck).
داستان Turso دقیقاً از همین نقطه شروع شد. تیم سازنده با درک این محدودیتها، یک تصمیم جسورانه گرفتند: بازنویسی کامل هسته SQLite با زبان Rust. هدف، حفظ روح سادگی SQLite و در عین حال حل چالشهای بنیادی آن برای نیازهای امروز بود. نتیجه، دیتابیسی است که همان حس آشنای SQLite را دارد، اما با قابلیتهایی که پیش از این غیرممکن به نظر میرسید.
جادوی Turso در عمل چیست؟ 🪄
پروژه Turso در هسته خود، یک موتور دیتابیس درونفرایندی (In-Process) است که با SQLite سازگاری کامل دارد و کاملاً متنباز (Open Source) است. اما چه چیزی آن را متمایز میکند؟
نوشتن همزمان (Concurrent Writes) با MVCCخداحافظی با خطای معروف `SQLITE_BUSY`! به لطف پیادهسازی کنترل همزمانی چندنسخهای (MVCC)، چندین سرویس یا کاربر میتوانند بهصورت همزمان و بدون تداخل در دیتابیس بنویسند. این ویژگی توان عملیاتی نوشتن را به شدت افزایش داده و Turso را برای سیستمهای Real-time Ingestion ایدهآل میکند. همگامسازی توزیعشده با Embedded Replicasبا استفاده از libSQL (فورک متنباز SQLite که پایه Turso است)، میتوانید دیتابیس خود را به هر موقعیت جغرافیایی، از جمله سرورهای شخصی خودتان، Replicate کنید. خواندن اطلاعات از نزدیکترین Replica با تأخیر نزدیک به صفر انجام میشود و عملیات نوشتن بهصورت ناهمگام (Async) با دیتابیس مرکزی همگام میگردد. جستجوی برداری بومی (Native Vector Search)بدون نیاز به دیتابیس جداگانه برای Vector Search! تورسو از نوع داده `vector` و توابع SQL برای جستجوی شباهت پشتیبانی میکند. ترکیب دیتابیس رابطهای و برداری در یک فایل واحد، راهحلی بینظیر برای ساخت اپلیکیشنهای RAG و سیستمهای Recommendation است. معماری میلیونها دیتابیسبه هر کاربر، ایجنت یا Task، یک دیتابیس ایزوله بدهید! این معماری به شما اجازه میدهد تا میلیونها دیتابیس مجزا را مدیریت کنید؛ یک تغییر بازی بزرگ برای SaaS Multi-Tenant، سیستمهای Multi-Agent و Sharding افقی.یک قدم فراتر: فایل سیستم برای ایجنتها با AgentFS
تیم Turso پس از دیتابیس، به سراغ نیاز ایجنتهای هوش مصنوعی به یک فایل سیستم ایزوله رفت: AgentFS.این لایه فایل سیستم متنباز، کاملاً روی دیتابیس Turso پیادهسازی شده و یک فضای ذخیرهسازی ساختاریافته، قابل ممیزی و قابل حمل برای ایجنتها فراهم میکند.
همه چیز در AgentFS حول یک فایل SQLite میچرخد (شامل یک فایل سیستم مجازی مشابه POSIX، ذخیرهساز Key-Value و یک مسیر ممیزی برای دیباگ). از آنجایی که Turso نسخه WebAssembly (WASM) نیز دارد، ایجنت شما حتی در محیط مرورگر هم میتواند از ابزارهایی مثل `git` یا `mkdir` استفاده کند و تمام تغییرات در یک فایل SQLite ذخیره میشود!
جمعبندی تورسو (Turso) ثابت میکند که برای مقیاسپذیری و همگامی با فناوریهای مدرن مثل AI و Edge Computing، همیشه نیازی به معماریهای پیچیده و دیتابیسهای سنگین نیست. گاهی تکامل یک ابزار ساده و اثباتشده مثل SQLite، بهترین پاسخ به پیچیدهترین نیازهای مهندسی داده است.
برای مطالعه مستندات، آشنایی بیشتر و شروع کار، حتماً به وبسایت رسمی Turso سر بزنید: http://turso.tech/همچنین مخازن رسمی و متنباز این پروژه در گیتهاب برای بررسی فنی در دسترس هستند:
موتور دیتابیس Rust: github.com/tursodatabase/turso فایل سیستم ایجنتها: github.com/tursodatabase/agentfs#Turso #SQLite #OpenSource #DataEngineering #DistributedSystems #VectorDatabase #AI #Rust #AgentFS #SelfHosting #مهندسی_داده
۱۸:۵۲
معرفی نسخه نوین SQlite برای دنیای ایجنت ها
۱۹:۰۱
بازگشت پادشاه! نسخه دوم کتاب افسانهای DDIA منتشر شد
برای سالها، کتاب «Designing Data-Intensive Applications» (DDIA) نوشته مارتین کلبمان، حکم «انجیل» را برای مهندسین داده و سیستمهای توزیعشده داشت. اما دنیای امروز با ۹ سال پیش (زمان انتشار نسخه اول) تفاوت چشمگیری کرده است!
بهتازگی نسخه دوم این شاهکار، با همراهی کریس ریکومینی (خالق Apache Samza) منتشر شده است. این نسخه صرفاً یک آپدیت جزئی نیست؛ بلکه بازنویسیِ کاملِ مفاهیم زیرساخت داده برای عصر Cloud و AI است.
چه چیزهایی در نسخه جدید تغییر کرده است؟
خداحافظی رسمی با MapReduce: این فناوری دیگر مرده است! تمرکز نسخه جدید کاملاً بر روی معماریهای Cloud-Native، Object Storage (مثل S3) و فریمورکهای مدرنی چون Spark، Flink و Kafka است.
ورود مقتدرانه به عصر AI: اضافه شدن مباحثی مثل DataFrameها و Vector Embeddings تا نشان دهد مدلهای داده برای تغذیه پایپلاینهای ML چطور باید طراحی شوند.
اعتبارسنجی سیستمها (System Validation): نقطه ضعف نسخه اول جبران شد! یک فصل کاملاً جدید و هیجانانگیز که به شما یاد میدهد چگونه با روشهای رسمی(Formal Methods)، مهندسی آشوب(Chaos Engineering) و شبیهسازی ریاضی، درستی سیستم توزیعشده خود را تحت فشار بالا اثبات کنید.
نگاه عمیقتر به Stream Processing: با حضور ریکومینی، مفاهیم پردازش جریانی، معماریهای Lambda و Kappa و ادغام Batch و Stream با استانداردهای ۲۰۲۶ بهروز شدهاند.
چرا هر مهندس دادهای باید این کتاب را بخواند؟
ما در کار روزمره مدام با Spark یا Kafka کار میکنیم، اما آیا میدانیم دقیقاً پشت صحنه آنها چه میگذرد؟ چرا دیتابیسهای مدرن مثل TiDB از LSM-Tree استفاده میکنند در حالی که PostgreSQL روی B-Tree مانده است؟
این کتاب شما را از یک «استفادهکنندهٔ ابزار» به یک «طراح معماری» ارتقا میدهد تا بتوانید Tradeoffها (مثل مقیاسپذیری در برابر سازگاری) را به درستی تحلیل کنید.
به قول جی کِرپس (خالق کافکا):
«این کتاب پلی است بین تئوری سیستمهای توزیعشده و مهندسی عملی. ای کاش ده سال پیش وجود داشت تا مجبور نبودم اشتباهات را خودم تجربه کنم.»
اگر در سال ۲۰۲۶ دغدغه طراحی سیستمهای دادهای قابل اتکا و مقیاسپذیر را دارید، خواندن نسخه دوم DDIA یک ضرورت حرفهای است. کتاب را از پست قبلی می توانید دانلود کنید .لینک دانلود کتاب از سایت ابرهمراهی : https://abrehamrahi.ir/o/public/8kNH9epf
برای سالها، کتاب «Designing Data-Intensive Applications» (DDIA) نوشته مارتین کلبمان، حکم «انجیل» را برای مهندسین داده و سیستمهای توزیعشده داشت. اما دنیای امروز با ۹ سال پیش (زمان انتشار نسخه اول) تفاوت چشمگیری کرده است!
بهتازگی نسخه دوم این شاهکار، با همراهی کریس ریکومینی (خالق Apache Samza) منتشر شده است. این نسخه صرفاً یک آپدیت جزئی نیست؛ بلکه بازنویسیِ کاملِ مفاهیم زیرساخت داده برای عصر Cloud و AI است.
چه چیزهایی در نسخه جدید تغییر کرده است؟ خداحافظی رسمی با MapReduce: این فناوری دیگر مرده است! تمرکز نسخه جدید کاملاً بر روی معماریهای Cloud-Native، Object Storage (مثل S3) و فریمورکهای مدرنی چون Spark، Flink و Kafka است. ورود مقتدرانه به عصر AI: اضافه شدن مباحثی مثل DataFrameها و Vector Embeddings تا نشان دهد مدلهای داده برای تغذیه پایپلاینهای ML چطور باید طراحی شوند. اعتبارسنجی سیستمها (System Validation): نقطه ضعف نسخه اول جبران شد! یک فصل کاملاً جدید و هیجانانگیز که به شما یاد میدهد چگونه با روشهای رسمی(Formal Methods)، مهندسی آشوب(Chaos Engineering) و شبیهسازی ریاضی، درستی سیستم توزیعشده خود را تحت فشار بالا اثبات کنید. نگاه عمیقتر به Stream Processing: با حضور ریکومینی، مفاهیم پردازش جریانی، معماریهای Lambda و Kappa و ادغام Batch و Stream با استانداردهای ۲۰۲۶ بهروز شدهاند. چرا هر مهندس دادهای باید این کتاب را بخواند؟ما در کار روزمره مدام با Spark یا Kafka کار میکنیم، اما آیا میدانیم دقیقاً پشت صحنه آنها چه میگذرد؟ چرا دیتابیسهای مدرن مثل TiDB از LSM-Tree استفاده میکنند در حالی که PostgreSQL روی B-Tree مانده است؟
این کتاب شما را از یک «استفادهکنندهٔ ابزار» به یک «طراح معماری» ارتقا میدهد تا بتوانید Tradeoffها (مثل مقیاسپذیری در برابر سازگاری) را به درستی تحلیل کنید.
به قول جی کِرپس (خالق کافکا):
«این کتاب پلی است بین تئوری سیستمهای توزیعشده و مهندسی عملی. ای کاش ده سال پیش وجود داشت تا مجبور نبودم اشتباهات را خودم تجربه کنم.»
اگر در سال ۲۰۲۶ دغدغه طراحی سیستمهای دادهای قابل اتکا و مقیاسپذیر را دارید، خواندن نسخه دوم DDIA یک ضرورت حرفهای است. کتاب را از پست قبلی می توانید دانلود کنید .لینک دانلود کتاب از سایت ابرهمراهی : https://abrehamrahi.ir/o/public/8kNH9epf
۱۳:۳۰
واکاوی یک مهاجرت: چرا Apache Doris جایگزین ترکیب ClickHouse و Elasticsearch شد؟
امروزه دیتابیسهای تحلیلی (OLAP) برای کوئریهای پیچیده و گزارشگیری سریع استاندارد شدهاند. ClickHouse سریعترین گزینه برای تحلیل عددی و Elasticsearch بهترین ابزار جستجوی متنی است. ترکیب این دو در نگاه اول یک معماری برنده به نظر میرسد، اما در مقیاسهای کلان میتواند به کابوس عملیاتی تبدیل شود.
Kwai (رقیب تیکتاک با ۴۰۰ میلیون کاربر فعال روزانه) کار را با همین معماری دوگانه آغاز کرد: - ClickHouse برای تحلیل عددی عملکرد تبلیغات - Elasticsearch برای جستجوی متنی محتوای تبلیغات
همه چیز عالی بود تا زمانی که حجم دادهها به تریلیونها سطر رسید و روزانه ۳۰۰ میلیون سطر جدید تولید میشد.
وقتی معماری رویایی به کابوس تبدیل میشود- گلوگاه Join: ارتباط دو سیستم از طریق جدول خارجی (External Table) در ClickHouse به Elasticsearch، با رشد دادهها به گلوگاهی خفهکننده تبدیل شد. هر Join بین دو سیستم کاملاً متفاوت، کندی شدید و سربار غیرقابل تحمل ایجاد میکرد. - کابوس بهروزرسانیهای لحظهای: صنعت تبلیغات پویاست؛ بودجه و وضعیت کمپینها مدام تغییر میکند. ClickHouse ذاتاً برای دادههای تغییرناپذیر طراحی شده و نبود پشتیبانی بومی از این تغییرات لحظهای، مدیریت را به بنبست کشاند. 🧊
اینجا بود که Apache Doris (و فورک تجاری آن، StarRocks) به داد Kwai رسید. 🦸️️
یک معماری متمایز: تحلیل با بهروزرسانی آنیدقیقاً نقطهضعف ClickHouse را پوشش میداد: پشتیبانی بومی از UPSERT (ترکیب Update و Insert). دوریس میتواند میلیونها رکورد را در لحظه تغییر دهد، بدون افت سرعت و بدون نیاز به فرآیندهای پیچیده بازسازی داده.
یک پلتفرم برای تمام نیازهادوریس با یکپارچهسازی قابلیتهای کلیدی، نیاز به سیستمهای مجزا را از بین برد:۱. JSON: ذخیره و جستجوی سریع دادههای نیمهساختاریافته در کنار دادههای عددی. ۲. جستجوی تماممتن: ایندکسهای داخلی قدرتمند، عملاً کار Elasticsearch را انجام میدهند و Kwai را از کلاستر جداگانه ES بینیاز کردند. ۳. یکپارچگی با دریاچه داده: موتور کوئری دوریس میتواند مستقیماً روی فایلهای Parquet در Data Lake کوئری بزند و با دادههای داخلی خود Join کند، بدون نیاز به انتقال کل دادهها.
جمعبندی: بهترین ابزارها لزوماً بهترین ترکیب را نمیسازندتجربه Kwai یک درس مهندسی مهم دارد: استفاده همزمان از بهترین ابزارهای هر حوزه، در مقیاسهای تریلیونی تضمین موفقیت نیست. نحوه یکپارچگی سیستمها و نیاز به پویایی دادههاست که تعیینکننده میشود. موفقیت در مهندسی داده نیازمند ذهنیتی پویاست؛ معماری بهینه یک مقصد نهایی نیست، بلکه مسیری پیوسته از تکامل و انتخابهای هوشمندانه است.
امروزه دیتابیسهای تحلیلی (OLAP) برای کوئریهای پیچیده و گزارشگیری سریع استاندارد شدهاند.
ClickHouse سریعترین گزینه برای تحلیل عددی و Elasticsearch بهترین ابزار جستجوی متنی است. ترکیب این دو در نگاه اول یک معماری برنده به نظر میرسد، اما در مقیاسهای کلان میتواند به کابوس عملیاتی تبدیل شود. Kwai (رقیب تیکتاک با ۴۰۰ میلیون کاربر فعال روزانه) کار را با همین معماری دوگانه آغاز کرد: - ClickHouse برای تحلیل عددی عملکرد تبلیغات - Elasticsearch برای جستجوی متنی محتوای تبلیغات
همه چیز عالی بود تا زمانی که حجم دادهها به تریلیونها سطر رسید و روزانه ۳۰۰ میلیون سطر جدید تولید میشد.
وقتی معماری رویایی به کابوس تبدیل میشود
- گلوگاه Join: ارتباط دو سیستم از طریق جدول خارجی (External Table) در ClickHouse به Elasticsearch، با رشد دادهها به گلوگاهی خفهکننده تبدیل شد. هر Join بین دو سیستم کاملاً متفاوت، کندی شدید و سربار غیرقابل تحمل ایجاد میکرد. - کابوس بهروزرسانیهای لحظهای: صنعت تبلیغات پویاست؛ بودجه و وضعیت کمپینها مدام تغییر میکند. ClickHouse ذاتاً برای دادههای تغییرناپذیر طراحی شده و نبود پشتیبانی بومی از این تغییرات لحظهای، مدیریت را به بنبست کشاند. 🧊اینجا بود که Apache Doris (و فورک تجاری آن، StarRocks) به داد Kwai رسید. 🦸
️️یک معماری متمایز: تحلیل با بهروزرسانی آنی
دقیقاً نقطهضعف ClickHouse را پوشش میداد: پشتیبانی بومی از UPSERT (ترکیب Update و Insert). دوریس میتواند میلیونها رکورد را در لحظه تغییر دهد، بدون افت سرعت و بدون نیاز به فرآیندهای پیچیده بازسازی داده. یک پلتفرم برای تمام نیازها
دوریس با یکپارچهسازی قابلیتهای کلیدی، نیاز به سیستمهای مجزا را از بین برد:۱. JSON: ذخیره و جستجوی سریع دادههای نیمهساختاریافته در کنار دادههای عددی. ۲. جستجوی تماممتن: ایندکسهای داخلی قدرتمند، عملاً کار Elasticsearch را انجام میدهند و Kwai را از کلاستر جداگانه ES بینیاز کردند. ۳. یکپارچگی با دریاچه داده: موتور کوئری دوریس میتواند مستقیماً روی فایلهای Parquet در Data Lake کوئری بزند و با دادههای داخلی خود Join کند، بدون نیاز به انتقال کل دادهها. جمعبندی: بهترین ابزارها لزوماً بهترین ترکیب را نمیسازند
تجربه Kwai یک درس مهندسی مهم دارد: استفاده همزمان از بهترین ابزارهای هر حوزه، در مقیاسهای تریلیونی تضمین موفقیت نیست. نحوه یکپارچگی سیستمها و نیاز به پویایی دادههاست که تعیینکننده میشود. موفقیت در مهندسی داده نیازمند ذهنیتی پویاست؛ معماری بهینه یک مقصد نهایی نیست، بلکه مسیری پیوسته از تکامل و انتخابهای هوشمندانه است. ۱۷:۰۹
واکاوی یک مهاجرت: چرا Apache Doris جایگزین ترکیب ClickHouse و Elasticsearch شد؟
۱۷:۱۱