بله | کانال مهندسی داده - کانال رسمی سایت BigData.ir

۲۵ اردیبهشت

معرفی OpenCode - دستیار رایگان و متن باز کدنویسی با هوش مصنوعی با مدل‌های رایگان
امروزه و با تداوم محدودیت‌ها و قطعی اینترنت در ایران، استفاده از مدل‌های هوش مصنوعی، به‌خصوص به‌عنوان دستیاران کدنویسی و توسعه، بسیار سخت و هزینه‌بر شده است. امروز در لینکدین پستی راجع به ابزار OpenCode دیدم. نکته‌ای که به‌شدت توجهم را جلب کرد، پشتیبانی این ابزار از مدل رایگان جدید DeepSeek بود. با توجه به اینکه این هوش مصنوعی چینی، که الحق مدل خوب و باکیفیتی هم هست، در ایران باز و بدون مشکل در دسترس است، آن را تست کردم و تصمیم گرفتم تجربه کار با آن را با شما نیز به اشتراک بگذارم.
در ادامه به بررسی ویژگی‌های این ابزار کاربردی می‌پردازیم:

معرفی OpenCodeOpenCode یک دستیار کدنویسی متن‌باز و رایگان (تحت مجوز MIT) است که هیچ وابستگی به یک شرکت خاص (Vendor Lock-in) ندارد. این یعنی می‌توانید از هر مدل هوش مصنوعی (متن‌باز، اختصاصی یا محلی) در آن آزادانه استفاده کنید.
از جمله مدل‌های رایگانی که در OpenCode پشتیبانی می‌شوند:

DeepSeek V4 Flash Free

MiniMax M2.5 Free

Nemotron 3 Super Free

Qwen3.6 Plus Free(همچنین از بیش از ۷۵ مدل دیگر نیز پشتیبانی می‌کند)

نسخه دسکتاپ و نحوه استفاده در کنار VS Codeنسخه دسکتاپ این ابزار به‌تازگی برای ویندوز، مک و لینوکس منتشر شده و استفاده از آن را برای کاربران بسیار ساده‌تر کرده است. نکته مهم این است که OpenCode در حال حاضر امکانات کامل یک محیط توسعه (IDE) را ندارد و ابزارهایی مثل دیباگر یا مدیریت گیت در آن تعبیه نشده است.
بهترین تجربه کاربری:پیشنهاد می‌شود از OpenCode در کنار VS Code استفاده کنید. می‌توانید پرامپت‌ها و درخواست‌های خود را در ایجنت OpenCode وارد کنید و سپس کدهای تولید شده، بررسی تغییرات، اجرا و کامیت را در محیط VS Code انجام دهید. (البته OpenCode یک افزونه رسمی برای VS Code نیز دارد که دسترسی به کانتکست فایل‌ها و یکپارچگی را بسیار راحت‌تر می‌کند).
---

لینک‌های مفید:- وب‌سایت رسمی: opencode.ai- گیت‌هاب پروژه: github.com/anomalyco/opencode

دانلود مستقیم نسخه ویندوز OpenCode Desktop (BETA):https://abhm.ir/yLNFVvدانلود از گیت‌هاب پروژه : https://github.com/anomalyco/opencode/releases

ویدئوی معرفی کوتاه و تست ابزار:https://www.aparat.com/v/uype77f

۱۱

۴۵۴

۱۵:۳۰

معرفی OpenCode - دستیار رایگان و متن باز کدنویسی با مدل های رایگان هوش مصنوعی

۴۷۰

۱۵:۳۱

۲۷ اردیبهشت

شاید برای برخی که نیاز به دانلود فایل از آنسوی مرزها دارند گره گشا باشد .

۴۶۵

۱۴:۱۷

۲۹ اردیبهشت

از DeepSeek تا Quack: وقتی رویای DuckDB توزیع‌شده به واقعیت پیوست

اوایل سال 2025، زمانی که DeepSeek به عنوان یک هوش مصنوعی چینی تازه‌وارد و قدرتمند غوغایی به پا کرد و توجه جهانی را به سمت چین و پیشرفت آن در حوزه هوش مصنوعی جلب نمود، برای مهندسین داده، پایپ‌لاینی که به آن‌ها قدرت آموزش روی این حجم عظیم از داده را داده بود، یک درس بزرگ داشت. آن‌ها بدون استفاده از چارچوب‌های پردازش کلان داده موجود مانند اسپارک و تنها ترکیب یک سیستم فایل اختصاصی و DuckDB (که یک دیتابیس تک‌فایلی تحلیلی سریع و قوی است) و اجرای موازی هزاران نسخه از آن‌ها روی داده‌های مختلف، به نتایج بسیار قابل توجهی رسیده بودند. (Smallpond را می ‌توانید جستجو کنید)
استفاده‌ی خلاقانه‌ی تیم DeepSeek از این دیتابیس به عنوان محور پردازش‌های محلی روی هر نود- که اساساً یک دیتابیس تک‌فایلی مشابه SQLite اما مختص داده‌های تحلیلی و گزارش‌گیری‌های سریع است - برای مهندسین داده بسیار جذاب و جالب توجه بود. با این حال، اینکه چطور دیتابیسی که کاملاً ایزوله کار می‌کند توانسته این بار بزرگ پردازشی را بردارد، جای تعجب داشت . چون DuckDB ذاتاً یک دیتابیس درون‌فرآیندی (In-process) و تک‌کاربره بود و تجمیع خروجی آنها، احتمالا برای تیم دیپ سیک یک چالش بزرگ بوده است.
این ایده که بتوان نمونه‌های DuckDB را به یک سرور مرکزی متصل کرد تا یک دیتابیس واحد تشکیل دهند، با توجه به ماهیت تک‌فایلی بودن آن تا مدت‌ها غیرممکن به نظر می‌رسید. اما امروز، در اواسط سال 2026، این نیاز پاسخ داده شده است.

تولد Quack: عبور از محدودیت‌ها

اخیراً در کنفرانس AI Council 2026، هانس مولهایزن (Hannes Mühleisen)، خالق DuckDB، از پروژه‌ای به نام Quack پرده برداشت. این پروتکل، DuckDB را از یک ابزار محلی به یک سیستم مدیریت پایگاه داده کلاینت-سرور ارتقا می‌دهد؛ تحولی دقیقاً مشابه کاری که Turso با SQLite کرد.

مشکل اصلی چه بود؟ معضل In-process بودناز زمان معرفی، DuckDB به عنوان یک موتور تحلیلی ستونی (Columnar) محبوبیت بالایی پیدا کرد. اما این معماری تک‌فایلی به رغم سادگی زیاد آن برای کاربردهای روزانه، یک محدودیت فنی بزرگ داشت:

در هر لحظه، تنها یک فرآیند (Process) حق نوشتن روی فایل دیتابیس را داشت.اگر چندین فرآیند به‌طور همزمان قصد نوشتن داده داشتند، فایل قفل (Lock) می‌شد. کواک، راه حلی برای این معضل بود.

پروتکل Quack چیست؟
کواک Quack پروتکل رسمی RPC (Remote Procedure Call) برای DuckDB است که سه قابلیت کلیدی را به ارمغان می‌آورد:1. سرور مرکزی: اجرای یک نمونه از DuckDB به عنوان سرور اصلی.2. اتصال چند کلاینت: اتصال سایر نمونه‌های DuckDB به عنوان کلاینت به این سرور.3. خواندن و نوشتن همزمان: رفع محدودیت دسترسی همزمان چند فرآیند.
معماری فنی در یک نگاه:

️ مبتنی بر HTTP: عبور روان ترافیک از فایروال‌ها، لودبالانسرها و پشتیبانی مستقیم از مرورگرها (DuckDB-Wasm).

️ فرمت باینری بومی: استفاده از فرمت سریالیزاسیون داخلی DuckDB (مشابه WAL) و حذف کامل سربارِ تبدیل داده‌ها.

️ حداقل Round Trip: اجرای هر کوئری تنها با یک رفت‌وبرگشت در شبکه پس از Handshake اولیه.

چرا Quack برای مهندسان داده اهمیت دارد؟

۱. معماری DuckLake و نقش Quack به عنوان پروکسی مرکزیبا Quack، ساخت یک Lakehouse مرکزی فوق‌سبک با معماری "پردازش توزیع‌شده + ذخیره‌سازی متمرکز" ممکن می‌شود:

️ پردازش در لبه: کلاینت‌های ETL (مثل توابع Serverless یا کانتینرها) داده‌های خام را به صورت محلی پردازش می‌کنند.

️ ارسال دسته‌ای: وقتی حجم داده‌ها در یک کلاینت به حد مشخصی رسید (مثلاً 10000 رکورد)، از طریق Quack به سرور مرکزی ارسال می‌شود.

️ سرور مرکزی (پروکسی): سرور Quack ترافیک را دریافت کرده، هم‌زمانی را با MVCC مدیریت می‌کند و داده‌ها را درون DuckDB خود یا فرمت‌هایی مانند Iceberg روی Object Storage می‌نویسد.

️ خواندن همزمان: در همان زمان، داشبوردهای BI می‌توانند بدون قفل شدن دیتابیس، کوئری‌های تحلیلی خود را روی سرور اصلی DuckDB اجرا کنند.

۲. پردازش در کنار داده (Compute Near Data)فرض کنید یک دیتاست 500 گیگابایتی روی سرور دارید و می‌خواهید آن را از طریق یک لپ‌تاپ معمولی تحلیل کنید. با Quack، کوئری شما به سرور ارسال می‌شود، پردازش‌های سنگین روی سرور انجام می‌گیرد و فقط نتیجه نهایی به لپ‌تاپ بازمی‌گردد.


import duckdb
con = duckdb.connect()
# اتصال به سرور مرکزی
con.execute("ATTACH 'quack://bigserver:9494' AS remote")
result = con.execute("""
    SELECT customer_id, sum(amount) 
    FROM remote.transactions 
    GROUP BY 1 
    ORDER BY 2 DESC LIMIT 10
""").fetchdf()

۲۸۷

۸:۵۴

‍ ادامه مقاله بالا

۳. پشتیبانی از بارهای کاری تراکنشی (OLTP) و درج‌های سریعکاربرد دیگر Quack، امکان پردازش هزاران تراکنش در ثانیه برای سناریوهایی مانند جمع‌آوری لاگ‌ها، ثبت رویدادها (Event Sourcing) و دریافت لحظه‌ای داده‌ها (Real-time Ingestion) است.

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

️شفاف‌سازی: Quack قرار نیست جایگزین دیتابیس‌های رابطه‌ای (مانند PostgreSQL) برای بک‌اند اپلیکیشن‌های پیچیده با آپدیت‌های ردیفی مداوم و قفل‌های پیچیده شود؛ تمرکز اصلی آن بر درج‌های سریع و پیوسته (Append-only / High-throughput Inserts) است.

بنچمارک‌ها و عملکرد
در تست‌های اولیه برای انتقال 60 میلیون ردیف داده (TPC-H)، نتایج قابل توجهی ثبت شده است:

سیستم Quack: زمان اجرا 4.94 ثانیه

سیستم Arrow Flight: زمان اجرا تقریباً 17 ثانیه (Quack حدود 3.5 برابر سریع‌تر است)

سیستم PostgreSQL: زمان اجرا تقریباً 158 ثانیه (Quack حدود 32 برابر سریع‌تر است)

وضعیت فعلی و محدودیت‌ها
در حال حاضر، پروتکل Quack در وضعیت بتا (در DuckDB v1.5.2) قرار دارد. نسخه پایدار آن در سپتامبر 2026 به همراه DuckDB v2.0 منتشر خواهد شد و پلتفرم MotherDuck نیز از آن به عنوان یک Endpoint پشتیبانی خواهد کرد.
محدودیت‌های فعلی (نسخه بتا):

️ ارتباطات پیش‌فرض شبکه روی HTTP است (بدون رمزنگاری).

️ احراز هویت فعلاً تنها با یک توکن اشتراکی ساده انجام می‌شود.

️ عدم پشتیبانی از کنترل دسترسی مبتنی بر نقش (RBAC).

جمع‌بندی
پروتکل Quack، پاسخ عملی به رویای توزیع‌پذیری DuckDB است که از زمان مشاهده معماری دیپ‌سیک در ذهن مهندسین داده شکل گرفته بود. این ابزار، DuckDB را از یک موتور پردازش محلی به یک معماری کلاینت-سرور مدرن ارتقا می‌دهد و راهکاری کارآمد برای ساخت Lakehouse مرکزی و جمع‌آوری داده‌های لحظه‌ای ارائه می‌کند، بدون آنکه درگیر پیچیدگی سیستم‌های سنگین‌وزن شویم.

۲۸۳

۸:۵۷

کواک: راه حلی ساده برای مقیاس پذیر کردن DuckDB

۳۳۸

۸:۵۸

۳۰ اردیبهشت

‍آیا همچنان MongoDB انتخاب اول در پردازش JSON است؟ نتایج JSONBench چیز دیگری می‌گوید!
بیش از 10 سال از زمانی که #MongoDB در 2 سال متوالی به عنوان دیتابیس سال DBengines شناخته شد و در کنار #Elasticsearch در اوج قرار داشت می‌گذرد. امروزه اگر بخواهیم با داده‌های #JSON با حجم بالا کار کنیم، شاید گزینه‌های خیلی بهتر و موثرتری وجود داشته باشند.کلیک‌هاوس که یکی از رایج‌ترین دیتابیس‌های تحلیلی است، در کنار ابزار #ClickBench، وب‌سایت و ابزار #JSONBench‌ را هم راه‌اندازی کرده است تا به صورت کاملا شفاف بتوانیم عملکرد دیتابیس‌های مختلف را در پردازش JSON مقایسه کنیم. https://jsonbench.com/

بیایید نگاهی سریع به مکانیزم کار این وب‌سایت، نتایج فعلی آن و درس‌هایی که برای ما مهندسین داده دارد بیندازیم:

بنچمارک JSONBench چیست و چگونه کار می‌کند؟این ابزار یک معیار (Benchmark) متن‌باز و استاندارد برای سنجش عملکرد پایگاه‌های داده در پردازش تحلیلی داده‌های JSON است. مکانیزم آن بر اساس 4 اصل کلیدی است:

️ داده واقعی: استفاده از 1 میلیارد رویداد واقعی از شبکه اجتماعی Bluesky.

️ قابلیت بازتولید: خودکارسازی تمام مراحل با اسکریپت‌های Shell و دسترسی عمومی به داده‌ها.

️ پرس‌وجوهای هدفمند: اجرای 5 کوئری تحلیلی (SQL) با پیچیدگی‌های متفاوت روی داده‌های نیمه‌ساختاریافته.

️ شفافیت و انصاف: ارزیابی سیستم‌ها با تنظیمات پیش‌فرض و انتشار تمام نتایج خام در گیت‌هاب.

تفسیر نتایج (تا ۳۰ اردیبهشت 1405):نتایج برای مقیاس 1 میلیارد سند، پرده از یک شکاف عمیق بین نسل جدید و دیتابیس‌های سنتی برمی‌دارد:
۱. رهبران جدید پردازش JSON: سیستم‌های تحلیلی ستونی مانند ClickHouse، #Starrocks و #Apache #Doris عملکردی استثنایی دارند. به عنوان مثال، ClickHouse با بهینه‌ترین حجم ذخیره‌سازی (92.72 گیگابایت)، کوئری‌ها را در کسری از ثانیه پردازش می‌کند.۲. جایگاه #Elasticsearch: با وجود قدرت بالا در جستجو، در تحلیل‌های تجمیعی سنگین حدود 14.6x کندتر از سریع‌ترین گزینه است و حجم ذخیره‌سازی آن تقریباً 4x بیشتر است.۳. زنگ خطر برای سیستم‌های سنتی (#MongoDB و #PostgreSQL): - دیتابیس MongoDB با وجود کارایی نسبتاً خوب در فشرده‌سازی، در پردازش کوئری‌ها تقریباً 1218x کندتر از #ClickHouse است.- دیتابیس #PostgreSQL با وجود تطبیق‌پذیری بالا، برای این دسته از تحلیل‌ها بیش از 5600x کندتر بوده و حجم ذخیره‌سازی بسیار بالایی (615 گیگابایت) را اشغال می‌کند.

نتیجه‌گیری:نتایج JSONBench نشان می‌دهد که باید در انتخاب‌های سنتی خود تجدیدنظر کنیم! برتری 1000x تا 5000x دیتابیس‌های جدید، یک بهبود ساده نیست؛ بلکه یک «تغییر پارادایم» از معماری سطری به ستونی در بارهای کاری تحلیلی است که نادیده گرفتن آن به قیمت افت شدید کارایی تمام می‌شود.

سخن آخر و پیشنهاد عملی:

کلیک‌هاوس (ClickHouse): بهترین گزینه برای ذخیره لاگ و داده‌های بدون تغییر.

دوریس و استارراکز (Apache Doris & Starrocks): ایده‌آل برای اجرای کوئری‌های سنگین JSON همزمان با آپدیت داده‌ها.

الستیک‌سرچ (Elasticsearch): مناسب فقط زمانی که به پردازش‌های تخصصی متنی نیاز دارید.

مانگو (MongoDB): نمی‌دانم… شاید بماند برای وقتی دیگر!

کانال مهندسی داده در تلگرام: https://ble.ir/data_engineeringدوره‌های مهندسی داده : https://sepahram.ir/courses

۱۰

۳۰۱

۱۲:۴۰

آیا همچنان مانگو دی بی سلطان پردازش جی سان و داده های Document Oriented است ؟

۳۴۲

۱۲:۴۱

۱ خرداد

چرا monday.com دیتابیس‌های MySQL، Redis و Cassandra را کنار گذاشت و یک لایه سرویس‌دهی مبتنی بر DuckDB ساخت؟در دنیای زیرساخت داده، در حال ورود به نسل جدیدی از سامانه‌ها هستیم که بر محور دیتابیس‌های سبک و معماری‌های ساده اما بسیار مؤثر شکل می‌گیرند. یکی از نمونه‌های مهندسی‌شده و جذاب این روند، ماجرای مهاجرت عظیم شرکت monday.com engineering از #MySQL به #DuckDB و ارائه یک راهکار هوشمند برای حل مسئله هم‌زمانی و سرویس‌دهی به کاربران است. هرچند این معماری برای monday.com که یک پلتفرم مدیریت پروژه است، سفارشی‌سازی شده، اما درس‌های بسیار مهمی برای ما به عنوان مهندسین داده دارد.

ابتدا ببینیم معماری قبلی چه بود و چرا با چالش مواجه شد؟یک تریلیون جدول داینامیک، میلیون‌ها سازمان (Tenant) و ده‌ها میلیارد سطر در حال تغییر مداوم؛ دیتابیس #MySQL هرگز برای چنین بار کاری (Workload) طراحی نشده بود. ذخیره داده‌های کاربران در یک Row-store مانند #MySQL (آن هم با ذخیره داده‌ها در قالب #JSON که انعطاف پذیری لازم را به کاربران برای تولید انواع بوردهای سفارشی می‌داد) باعث می‌شد تا گزارش ها به شدت کند شوند. همچنین مشکل همسایه پر سر و صدا (Noisy-neighbor) در جداول اشتراکی باعث افت شدید کارایی شده بود.

راهکار هوشمندانه mondayDB 3برای حل این مشکل و با توجه به اینکه هر یوزر و سازمان، دیتابیس و Boardهای خودش را باید ذخیره می‌کرد، monday.com تصمیم گرفت به جای ایجاد یک دیتابیس مرکزی و اشتراکی، استک قدیمی (#MySQL + #Redis + #Cassandra) را کنار بگذارد و داده‌های هر شرکت را در فایل‌های #DuckDB مختص به همان شرکت نگه دارد.
آن‌ها معماری Sync-then-query را پیاده‌سازی کردند که جادوی آن در اجزای زیر نهفته است:

ایزوله‌سازی با #DuckDB: اختصاص فایل‌های مجزا به هر Board که مشکل جداول اشتراکی را برای همیشه حل کرد.

جداسازی خواندن و نوشتن (#CQRS): استفاده از یک WAL توزیع‌شده و خارجی (بستر #Kafka) برای دریافت و مدیریت تغییرات داده‌ها که امکان کار همزمان کاربران را بر روی بوردها فراهم می‌کند.

تکنیک Sync-then-query: گره‌های خواندن، فایل DuckDB را از کش محلی (NVMe) یا Object Storage (مانند S3) می‌خوانند، تغییرات لحظه‌ای را از WAL روی آن اعمال (Sync) کرده و سپس کوئری را در همان لحظه اجرا می‌کنند.

مسیریابی هوشمند: استفاده از الگوریتم Weighted Rendezvous Hashing برای هدایت درخواست‌ها به گره‌هایی که فایل مربوطه را از قبل در کش خود دارند.
نتایج شگفت‌انگیز این معماری:

بارگذاری بردهای بزرگ: 20 سریع‌تر

کوئری‌های تجمیعی (Aggregations): 48 سریع‌تر

کاهش ۴۰ تا ۶۰ درصدی هزینه‌های زیرساخت

️ خواندن داده‌های همیشه تازه با تأخیر تک‌رقمی در مقیاس میلی‌ثانیه
مهم‌تر از همه، این معماری اکنون به فونداسیون لایه AI شرکت تبدیل شده است و امکان اجرای Semantic Retrieval، RAG و Agentic Querying را مستقیماً روی داده‌های عملیاتی فراهم کرده است. جالب است بدانید که این تیم موفق شد این مهاجرت عظیم را برای بیش از ۱ میلیون سازمان بدون هیچ‌گونه قطعی انجام دهد!
این تجربه نشان می‌دهد که گاهی باید چشم‌ها را شست و جور دیگر نگاه‌ کرد. گاهی، حتی DuckDB‌ تک فایلی، می‌تواند شرکت عظیمی مثل Monday.com را مقیاس‌پذیر کند و صرف استفاده از دیتابیس‌های رایج، کلید حل همه مسایل دنیای مدرن داده نیست.

مطالعه مقاله کامل در مدیوم: https://medium.com/p/2ee975d3180cمقاله فارسی در سایت مهندسی داده : http://bigdata.ir/?p=9075

۳۲۳

۱۵:۲۰

معماری جدید شرکت Monday.com از MySQL+Redis+Cassandra به DuckDB

۳۲۳

۱۵:۲۱

import duckdb con = duckdb.connect() # اتصال به سرور مرکزی con.execute("ATTACH 'quack://bigserver:9494' AS remote") result = con.execute(""" SELECT customer_id, sum(amount) FROM remote.transactions GROUP BY 1 ORDER BY 2 DESC LIMIT 10 """).fetchdf()