‍ داستان تولد یک Graph Engine متفاوت: آشنایی با PuppyGraph🐾

تصور کنید داده‌های شما در دیتابیس‌های کلاسیک رابطه‌ای مثل #PostgreSQL یا در دیتالِیک‌هایی مثل #Snowflake یا #Iceberg ذخیره شده‌اند.

حجم داده‌ها بالاست، اتصال‌ها پیچیده‌اند، و شما به‌عنوان مهندس داده می‌خواهید تحلیل‌های ارتباطی اجرا کنید:

مثل کشف مسیرهای غیرمستقیم بین کاربران، تشخیص حلقه‌های تراکنشی، یا تحلیل وابستگی در جریان داده.

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

عملیات #ETL سنگین و زمان‌بر ⏳

نیاز به زیرساخت گراف مستقل ⚙️

مشکلات همگام‌سازی داده بین دو سیستم 🔄


💡 اینجا PuppyGraph وارد می‌شود

پاپی‌گراف یک Graph Query Engine مدرن و سریع است که با یک رویکرد ساده و انقلابی کار می‌کند:

«به‌جای انتقال داده به یک گراف‌دیتابیس، چرا گراف را همان‌جا که داده هست اجرا نکنیم؟»


🔍 چه چیزی PuppyGraph را متفاوت می‌کند؟

✅ بدون ETL: مستقیماً روی منابع داده‌ای مانند PostgreSQL، MySQL، Snowflake، Delta Lake یا Iceberg کار می‌کند.

✅ بدون کپی داده: داده در محل خود باقی می‌ماند، PuppyGraph فقط آن را گرافی تفسیر می‌کند.

✅ اجرای سریع کوئری‌های چندهاپی: حتی 10-hop traversal در کمتر از چند ثانیه، روی میلیاردها لبه.

✅ سازگار با زبان‌های گراف استاندارد: از Gremlin و Cypher برای کوئری استفاده کنید، درست مثل Neo4j.

✅ معماری مقیاس‌پذیر و توزیع‌شده: طراحی‌شده برای محیط‌های تحلیلی مدرن، با تفکیک compute و storage.


🎯 چه کاربردهایی دارد؟

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

✅ کشف تقلب در تراکنش‌ها یا شبکه‌های مالی

✅ تحلیل رفتار کاربران و مسیرهای ارتباطی آن‌ها

✅ درک ساختارهای وابستگی در خطوط داده یا سیستم‌ها

✅ تحلیل شبکه‌های سازمانی، صنعتی یا IoT

✅ ساخت گراف مفهومی از داده‌های پراکنده بدون زیرساخت جدید


🧪 تجربه کار با PuppyGraph

راه‌اندازی آن ساده است: با Docker یا روی Databricks و AWS در کمتر از ۱۰ دقیقه آماده کار می‌شود.

تنها کاری که باید بکنید تعریف اسکیمای گرافی با چند خط JSON است—و بعد می‌توانید همان داده‌ای را که همیشه با SQL کوئری می‌کردید، این‌بار از منظر گراف ببینید و تحلیل کنید.


🐶 چرا اسمش PuppyGraph است؟

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

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


💼 و اما : وضعیت لایسنس و نسخه‌ها

نسخه رایگان و متن‌باز PuppyGraph با نام Developer Edition در دسترس است، اما این نسخه تنها از یک نود پشتیبانی می‌کند و برای محیط‌های کوچک و تستی مناسب است.

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


#GraphAnalytics #DataEngineering #GraphDatabase #PuppyGraph

‍ بررسی تغییرات پایگاه‌های داده در نظرسنجی Stack Overflow 2025📊

نظرسنجی سالانه Stack Overflow برای سال 2025 منتشر شده و یافته‌های قابل‌توجهی را در خصوص روند استفاده از پایگاه‌های داده در میان توسعه‌دهندگان حرفه‌ای ارائه می‌دهد.

آدرس نظر سنجی :

Technology | 2025 Stack Overflow Developer Survey

در این پست نگاهی خواهیم داشت به وضعیت پستگرس‌کیوال (PostgreSQL)، رشدهای چشمگیر و همچنین کاهش‌ها و غیبت‌های معنادار. 🚀

🏆 پستگرس PostgreSQL: ادامه‌ سلطه با رشد پایدار

پستگرس با ثبت رشد ۱۰٪ نسبت به سال گذشته و رسیدن به نرخ استفاده ۵۵.۶٪، جایگاه نخست خود را در میان پایگاه‌های داده محبوب حفظ کرده است. از سال ۲۰۲۳، این پایگاه داده به‌عنوان "مطلوب‌ترین" (۴۶.۵٪) و "تحسین‌شده‌ترین" (۶۵.۵٪) گزینه نزد توسعه‌دهندگان شناخته می‌شود. 😍


🔍 دلایل اصلی محبوبیت PostgreSQL:

✅انعطاف‌پذیری بالا: پشتیبانی از داده‌های رابطه‌ای و غیررابطه‌ای مانند JSON.

✅جامعه متن‌باز قدرتمند: توسعه مداوم و اسناد جامع.

✅عملکرد مناسب برای سناریوهای پیچیده: پاسخ‌گویی به بارهای کاری سنگین و ساختارهای داده پیشرفته.

📈 پایگاه‌های داده با رشد چشمگیر

🎯 ردیس: با رشد ۱۰٪ به ۲۸٪ رسید و با عبور از MongoDB به رتبه پنجم صعود کرد. ⚡️ همچنین Valkey نیز با ۲.۵٪ ورود قابل‌توجهی به صحنه داشت.

🎯 الستیک سرچ: با افزایش ۵٪، به نرخ استفاده ۱۶.۷٪ رسید؛ رشدی معنادار برای این موتور جستجوی داده.

🎯 دیتابیس DuckDB: با دو برابر شدن سهم خود به ۳.۲٪، توجه‌ها را به سمت خود جلب کرده است.

🎯 خدمات ابری Supabase: از ۴.۱٪ به ۶٪ رسید و برای نخستین‌بار وارد جمع ۱۲ پایگاه داده برتر شد. 🎉

این رشد نشان‌دهنده‌ی پذیرش سریع این گزینه‌ی نوظهور به‌عنوان یک راهکار جایگزین و سبک برای پروژه‌های مدرن است.


📉 پایگاه‌های داده با کاهش استفاده

⚠️ مای اسکیوال MySQL: با کاهش جزئی به ۴۰.۵٪، روندی آهسته اما قابل مشاهده را تجربه کرده است.

⚠️مانگودی بی MongoDB: با رسیدن به ۲۴٪، افتی کمتر از پیش‌بینی‌ها داشته، اما جایگاه خود را در رقابت از دست داده است.


❌ غایب بزرگ

کلیک هوس: غیبت کامل این پایگاه داده تحلیلی از لیست نهایی، جای تعجب دارد. آیا این نتیجه‌ خطایی در داده‌هاست یا نشانه‌ای از کاهش استفاده که بعید به نظر می رسد؟ 🤔


🌟 تمایل توسعه‌دهندگان به یادگیری PostgreSQL

یکی از نکات جالب این گزارش، تمایل بالای کاربران Redis و MongoDB به یادگیری PostgreSQL است. این روند نشان می‌دهد مهارت در پایگاه‌های داده رابطه‌ای همچنان یکی از مزیت‌های کلیدی در مسیر حرفه‌ای توسعه‌دهندگان است. 📈


💡 چرا این موضوع تمایل به استفاده از پستگرس اهمیت دارد؟

انتخاب پایگاه داده مناسب، مستقیماً بر عملکرد، مقیاس‌پذیری و آینده‌پژوهی پروژه‌ها تأثیر می‌گذارد. PostgreSQL با ترکیبی از عملکرد قدرتمند، انعطاف‌پذیری بالا و جامعه پشتیبان گسترده، همچنان انتخاب نخست بسیاری از تیم‌های توسعه است.

#StackOverflow2025 #PostgreSQL #Database #توسعه_نرم‌افزار #فناوری #دیتابیس #تحلیل_داده

‍ عامل‌های هوشمند در مهندسی داده؛ مسیر نوین اتوماسیون و بهینه‌سازی زیرساخت‌ها 🤖

به دنبال راهکاری برای بررسی خودکار متریک‌های Prometheus و ارزیابی دقیق آن‌ها به کمک عامل‌های هوشمند بودم که به سایت

https://mseep.ai

برخوردم — ( تصویر پست از نتیجه یک جستجو در این سایت برداشته شده است).

با کمال تعجب دیدم که تعداد قابل توجهی MCP Server برای ابزارهای مختلف حوزه مهندسی داده در دسترس است و چه پتانسیل بزرگی در این حوزه نهفته است.


🤖 سوال: MCP Server چیست و چرا مهم است؟

سرورهای #MCP امکان اتصال عامل‌های هوشمند به ابزارهای مختلف را فراهم می‌کنند تا بتوان داده‌های لحظه‌ای را در اختیار عامل‌های هوشمند قرار داد و امکان اجرای دستورات مختلف را روی این ابزارها به این عامل هوشمند داد. حالا ما می‌توانیم با این سرورهای واسط، کارهای تکراری و زمان‌بر در حوزه زیرساخت و مهندسی داده را به صورت خودکار و هوشمند انجام دهیم. این فناوری در مهندسی داده می تواند تغییرات بنیادین ایجاد کند.

نسخه آموزشی سریع این فناوری را از این آدرس دانلود کنید :

https://t.iss.one/bigdata_ir/424


🔍 قابلیت‌های کاربردی عامل‌های هوشمند

با بهره‌گیری از این سرورها و عامل‌های هوشمند می‌توانید کارهای زیر را به راحتی اتوماسیون کنید:

✅پایش و تحلیل مداوم متریک‌های #Prometheus

✅بررسی و تفسیر خودکار لاگ‌ها و خطاها

✅تحلیل کوئری‌های کند در #PostgreSQL و بهینه‌سازی ایندکس‌ها

✅نظارت بر داشبوردهای Grafana و واکنش سریع به شرایط بحرانی

....


⚙️ چطور شروع کنیم؟

📌نصب MCP Server مناسب از منابعی مانند mseep.ai

📌نوشتن پرامپت‌های کاربردی مثل:

🎯«هر یک ساعت کوئری‌های کند را بررسی کن»

🎯«در صورت بروز خطا پیامک یا اطلاع در تلگرام بفرست»

🎯«خودکار عملیات ری‌ایندکس را انجام بده»

📌تعریف زمان‌بندی اجرای اتوماتیک


🚀شروع ساده‌تر با ابزارهای کم‌کد مانند #N8N

ابزارهای کم‌کد و بدون کد مانند #N8N این فرایند را به شدت آسان می‌کنند و امکان استفاده از نودهای هوش مصنوعی را فراهم می‌آورند تا بدون نیاز به برنامه‌نویسی سنگین، اتوماسیون پیشرفته بسازید.


🌟 نگاهی به آینده مهندسی داده

هوش مصنوعی نه تنها در اتوماسیون روتین بلکه در حوزه‌های گسترده‌تری مانند طراحی مدل‌های داده، مستندسازی، رفع خطا و حتی طراحی و اجرای پایپ‌لاین‌های داده نقش مهمی ایفا خواهد کرد. ابزارهایی مثل #Kestra و Bento نمونه‌های موفقی هستند که با توصیف‌های متنی (#YAML) امکان ساخت و اجرای ورک‌فلوهای داده‌ای را به سادگی فراهم می‌کنند.

‍ آغاز به کار رسمی مدرسه مهندسی داده سپهرام

با افتخار اعلام می‌کنم که وب‌سایت https://sepahram.ir به عنوان اولین مدرسه کاربردی مهندسی داده در ایران راه‌اندازی شد. هدف ما ارائه آموزش‌های عملی و پروژه‌محور در حوزه #مهندسی_داده برای جامعه فارسی‌زبان است.

🔰 شروع فعالیت مدرسه با برگزاری دوره نوین:
✨ مبانی مهندسی داده ✨


در این دوره، مفاهیم پایه و ابزارهای اصلی مهندسی داده به شکلی کاملاً عملی آموزش داده می‌شود، شامل:

🗄 پایگاه داده‌ها و طراحی اولیه با #PostgreSQL

🛠 آشنایی با #Airflow برای مدیریت و زمان‌بندی جریان‌های داده

⚡️ پردازش داده‌های عظیم با #ApacheSpark

🔄 پردازش جریان‌های داده در #Kafka

📊 آشنایی عملیاتی با #ClickHouse برای تحلیل سریع و بلادرنگ داده‌ها

🧊 کار با #ApacheIceberg به عنوان نسل جدید فرمت‌های جدولی و مدیریت داده در مقیاس بزرگ


🎯 برای تضمین یادگیری گام‌به‌گام و مؤثر:

- هر درس شامل چند آزمون کوتاه و مفهومی است.

- برای دریافت گواهینامه پایان دوره، انجام و تحویل یک پروژه عملی و کاربردی الزامی است. جزئیات این پروژه در صفحه دوره ذکر شده است.


💬 در صورت بروز مشکل در مسیر آموزشی یا هنگام انجام آزمون‌ها، می‌توانید از طریق پیام‌رسان‌های تلگرام، واتساپ یا بله با حساب پشتیبانی مدرسه مهندسی داده سپهرام در ارتباط باشید:

📌 شناسه پشتیبانی: @sepahram_ir

🙌 به عنوان موسس و مدرس اصلی این مدرسه، امیدوارم سپهرام گامی مؤثر در جهت توانمندسازی جامعه فارسی‌زبان در مسیر حرفه‌ای مهندسی داده باشد.

🔗 جزئیات بیشتر و ثبت‌نام:

https://sepahram.ir/courses/intro-to-data-engineering

کانال رسمی سپهرام :

https://t.iss.one/sepahram_school

‍ ورکشاپ جدید مدرسه مهندسی داده سپهرام - آشنایی با ساختار فیزیکی پستگرس منتشر شد!

در ادامه‌ی کارگاه‌های عملی مدرسه مهندسی داده سپهرام، این‌بار به سراغ سازوکار ذخیره‌سازی فیزیکی داده‌ها در #PostgreSQL رفتیم.

در این جلسه با اجرای #PostgreSQL نسخه ۱۸ در محیط Docker، ساختار درونی ذخیره داده‌ها را از نزدیک بررسی کردیم.

خلاصه اینکه : ✨فایل‌های داده در پستگرس از واحدهایی به نام Page (یا Block) تشکیل می‌شوند؛ هر Page معمولاً ۸ کیلوبایت حجم دارد و کوچک‌ترین بخش قابل خواندن یا نوشتن در دیسک است.

✨ هر Page شامل اطلاعات مدیریتی، اشاره‌گرهای رکوردها، فضای خالی، و خود داده‌هاست. هنگام درج یا به‌روزرسانی رکورد، #PostgreSQL بر اساس فضای خالی موجود تصمیم می‌گیرد که داده را در همان Page یا Page جدید ذخیره کند. این رفتار در عمل، پایه‌ی مفهومی به نام Heap است - یعنی ذخیره‌سازی بدون ترتیب خاص.

✨در کارگاه دیدیم که با به‌روزرسانی رکوردها، نسخه‌های جدید در انتهای Page درج می‌شوند و نسخه‌های قبلی تا اجرای فرآیند VACUUM در فایل باقی می‌مانند. همچنین با تعیین fillfactor=70 برای جدول users2، مشاهده کردیم که چگونه فضای آزاد در Page باعث درج نسخه‌های جدید در همان Page می‌شود.


📘 آنچه در این کارگاه انجام دادیم:

🔰راه‌اندازی PostgreSQL 18 با Docker

🔰بررسی ساختار پوشه‌های base و global و مفهوم OID

🔰درج و به‌روزرسانی داده‌ها و تحلیل رفتار Pageها

🔰بررسی عملی Heap و نقش پارامتر fillfactor


📺 فیلم کامل ورکشاپ در یوتیوب مدرسه:

🔗 https://youtu.be/H3ET3i7XsXw

💾 فایل‌ها و اسکریپت‌ها در گیت‌هاب سپهرام:

👉 https://github.com/sepahram-school/workshops

دوره در حال برگزاری پستگرس : https://sepahram.ir/courses/postgresql

‍ لیک‌هوس در مسیر بلوغ: نگاهی به نسخه جدید #RisingWave و ادغام عمیق آن با #Iceberg

در دنیای امروز که هر سازمان مجموعه‌ای از سرویس‌ها و جریان‌های داده‌ای متنوع دارد، نیاز به بستری متمرکز برای ذخیره و مدیریت «خودِ داده‌ها» بیش از همیشه احساس می‌شود: بستری مستقل از ابزارها و موتورهای پردازشی، جایی که داده‌ها به‌صورت خام و ساخت‌یافته نگهداری شوند.

این معماری نه‌تنها نظم داده‌ها را تضمین می‌کند، بلکه بستر ایده‌آلی برای توسعه سامانه‌های هوش مصنوعی و مدل‌های یادگیری ماشین فراهم می‌سازد؛ زیرا داده‌های تمیز و استاندارد، پایه‌ی هر سیستم هوشمند هستند.

📌 اینجا همان جایی است که مفهوم #Lakehouse اهمیت خود را نشان می‌دهد: ترکیبی از داده‌های ساخت‌یافته‌ی خام به همراه یک استاندارد سازمان‌دهی مانند #ApacheIceberg که باعث می‌شود داده‌ها در مقیاس وسیع قابل ذخیره‌سازی، مدیریت و تحلیل باشند.

🚀با این حال، فناوری‌هایی چون Iceberg هنوز در مدیریت متادیتا، snapshotها و عملیات نگهداری، چالش‌هایی دارند. در همین نقطه است که نسخه‌ی جدید #RisingWave v2.6 می‌تواند فرآیند به کارگیری و مدیریت لیک‌هوس را تسهیل کند ✨


⚡️ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper = ترکیب برنده!

✅ در این نسخه، RisingWave، به‌عنوان یک پایگاه داده جریانی سازگار با #PostgreSQL، به‌صورت بومی با Iceberg ادغام شده است. داده‌ها به‌صورت لحظه‌ای از #Kafka دریافت، در RisingWave پردازش، و سپس به شکل استاندارد در Lakehouse ذخیره می‌شوند.

✅این ارتباط از طریق #Lakekeeper برقرار می‌شود: یک #REST Catalog استاندارد که رابط رسمی میان RisingWave و Iceberg است.

✅ کتابخانه Lakekeeper علاوه بر مدیریت متادیتا و کنترل دسترسی‌ها (با پشتیبانی از #OpenFGA)، امکان راه‌اندازی و تنظیم #Lakehouse را به‌دلخواه شما فراهم می‌کند؛ مثلاً با استفاده از #MinIO یا هر فایل‌سیستم دیگر.

✅ سپس RisingWave با تنظیمات شما و در «لیک‌هوس شما» شروع به درج داده‌ها می‌کند.

✅ داده‌های غیرجریانی سازمان نیز می‌توانند با ابزارهایی مانند #ApacheSpark یا #PyIceberg به این بستر منتقل شوند تا یک Lakehouse کامل شکل گیرد: جایی که RisingWave بخش داده‌های جریانی را مدیریت می‌کند.

این ترکیب، از نظر فنی استاندارد و از نظر معماری، منعطف و آینده‌نگر است.

همچنین، عملیات نگهداشت و بهینه‌سازی داده‌ها مستقیماً در خود RisingWave انجام می‌شود، و بار سنگین مدیریت #Lakehouse از دوش تیم‌های داده برداشته می‌شود. 💪

🧠 ویژگی‌های کلیدی نسخه‌ی RisingWave ۲.۶

🔰 پشتیبانی از داده‌های برداری (Vector) برای جست‌وجوی شباهت

🔰حالت جدید Copy-on-Write برای snapshotهای تمیزتر در Iceberg

🔰دستور VACUUM FULL برای پاک‌سازی و فشرده‌سازی داده‌ها

🔰سازگاری کامل با #Lakekeeper REST Catalog

🔰تنوع sinkهای جدید برای #Snowflake، #Redshift، #Elasticsearch

🔰حالت Memory-Only برای پردازش‌های فوق‌سریع


🎥 به‌زودی ویدیویی منتشر می‌کنم که در آن ساخت یک #Lakehouse عملی با

#MinIO + #Lakekeeper + #Spark + #Trino + #StarRocks

را گام‌به‌گام بررسی می‌کنیم. 🚀

به باور من، مسیر آینده‌ی زیرساخت‌های داده به‌سمتی پیش می‌رود که #Lakehouse بستر اصلی ذخیره و تحلیل داده‌ها شود،

و ترکیب #RisingWave + #ApacheIceberg + #Lakekeeper یکی از گزینه‌های خوب سازمانی برای شروع این مسیر است. 🌟

‍ وقتی Kafka ساده‌تر، سریع‌تر و سبک‌تر می‌شود: آشنایی با Redpanda در دوره تخصصی کافکا 🎥

در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن Kafka یعنی Redpanda آشنا می‌شویم.

در این ویدیو که به‌صورت کارگاهی و کاملاً عملی برگزار شده است، مراحل زیر را گام‌به‌گام انجام می‌دهیم 👇

🔹 راه‌اندازی یک کلاستر تک‌نودی از Redpanda به همراه Redpanda Console

🔹 اجرای دو رابط کاربری معروف دنیای Kafka یعنی AKHQ و Kafka-UI (Kafbat) و بررسی سازگاری کامل آن‌ها با Redpanda

🔹 کار با ابزار خط فرمان rpk برای مدیریت کلاستر و پیکربندی‌ها

🔹 ساخت یک پایپ‌لاین واقعی با Redpanda Connect و زبان Bloblang برای پردازش فایل‌های CSV

🔹 و در نهایت، اجرای PostgreSQL CDC با استفاده از Kafka Connect + Debezium برای همگام‌سازی بلادرنگ داده‌ها

این بخش از دوره، دیدی جامع از توانایی‌های Redpanda در دنیای استریم دیتا و جایگاه آن در اکوسیستم Kafka ارائه می‌دهد.

📺 ویدیو کامل این کارگاه را می‌توانید از طریق لینک زیر در یوتیوب مشاهده کنید:

👉 🔗 https://youtu.be/nu_L4OSRUZc

🎓 این ویدیو بخشی از دوره آموزش تخصصی Kafka از مدرسه مهندسی داده سپهرام (Sepahram) است.

برای مشاهده دوره‌ها به آدرس زیر مراجعه کنید:

🌐 https://sepahram.ir/courses/

📢 کانال رسمی سپهرام در تلگرام:

📬 https://t.iss.one/sepahram_school

🔖 #Kafka #Redpanda #StreamingData #DataEngineering #Debezium #PostgreSQL #KafkaConnect #RealTimeData #Sepahram #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده

‍ وقتی SQL هم حلقه For دارد! نگاهی به Lateral Join در PostgreSQL

اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع JOIN‌های معمول در SQL مثل INNER JOIN و LEFT JOIN آشنا هستید.

اما یکی از جوین‌هایی که کمتر درباره‌اش صحبت می‌شود و در عین حال بسیار مفید و کاربردی محسوب می‌شود، LATERAL JOIN است.

بیایید با یک مثال شروع کنیم 👇

فرض کنید یک جدول از محصولات دارید و می‌خواهید برای هر محصول، آمارهایی مثل:

🔰 مجموع کل فروش،

🔰حجم فروش،

🔰تعداد مشتریان منحصربه‌فرد،

🔰و میانگین فروش

در سه ماه گذشته را به‌دست آورید (به تفکیک ماه).

اگر بخواهید این کار را با زبان‌هایی مثل Python یا JavaScript انجام دهید، معمولاً یک حلقه (for) روی تمام محصولات اجرا می‌کنید و درون آن، برای هر محصول، محاسبات آماری مربوط به فروش را انجام می‌دهید.

در واقع، یک حلقه بیرونی برای محصولات و یک حلقه داخلی برای فروش‌های هر محصول دارید. در SQL هم می‌توان دقیقاً همین رفتار را شبیه‌سازی کرد: با استفاده از LATERAL JOIN.

اینجاست که Lateral مثل یک پل ارتباطی عمل می‌کند:

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

به همین دلیل معمولاً از CROSS JOIN LATERAL استفاده می‌کنیم، چون شرط اتصال درون زیرکوئری و با WHERE تعریف می‌شود و در اینجا Inner Join معنا نخواهد داشت.

💫 نتیجه این رهیافت

می‌توانید به‌سادگی کوئری‌هایی بنویسید که مثلاً:

🌟 «ده محصول پرفروش هر کتگوری» را پیدا کند،

🌟یا برای هر مشتری، آخرین تراکنش ثبت‌شده‌اش را نمایش دهد،

🌟یا حتی تحلیل‌های زمانی و Top-N را مستقیماً داخل SQL انجام دهد: بدون نیاز به کدهای پیچیده و توابع پنجره‌ای


🎥 برای آشنایی دقیق‌تر با این مفهوم، یک ویدئوی آموزشی حدود ۴۰ دقیقه‌ای آماده کرده‌ام که در آن، با مثال‌های واقعی و کاربردی نحوه‌ی استفاده از LATERAL JOIN را گام‌به‌گام توضیح داده‌ام.

🔗 لینک مشاهده ویدئو در یوتیوب:

👉 https://youtu.be/vVc2EewTSQU


💡 در این ویدئو یاد موارد زیر را به صورت عملی مرور می‌کنیم:

✅ایده‌ی اصلی و کاربرد LATERAL JOIN

✅تفاوت آن با جوین‌های معمول

✅نوشتن کوئری‌های Top-N per Group

✅تحلیل داده‌های واقعی (مشتریان، فروش، زمان)

✅و نکات مهم برای بهینه‌سازی عملکرد کوئری


📚 این ویدئو بخشی از دوره‌ی PostgreSQL Practical Course در مدرسه مهندسی داده سپهرام است.

👉 https://sepahram.ir/courses


#PostgreSQL #SQL #DataEngineering #Database #LateralJoin #Sepahram #BigData #PostgresTutorial #Analytics