ما در داتین به‌دنبال همکاری متخصص و پرانگیزه هستیم تا در نقش کارشناس ارشد زیرساخت کلان داده تیم پایگاه داده را همراهی کند. کارشناس ارشد زیرساخت کلان داده در داتین با پذیرفتن مسئولیت‌های زیر به پیش‌برد اهداف تیم کمک می‌کند:
- نصب و راه اندازی دیتابیس های NoSQL ای مثل Cassandra, elastic
- نصب و راه اندازی دیتابیس PostgreSQL
- نصب و راه اندازی Kafka
- راه اندازی کلاسترینگ و HA
- مانیتورینگ دیتابیس ها
دانش و مهارت های مورد نیاز:
- آشنا با مفاهیم NoSQL , SQL
- آشنا با مفاهیم دیتابیس های NoSQL ای نظیر elastic, Arangodb , Cassandra
- آشنا با مفاهیم دیتابیس PostgreSQL
- آشنا با مفاهیم Partitioning و Sharding
- آشنا با مفاهیم HA . کلاسترینگ و Replica Set
- آشنا با سیستم عامل Linux , windows Server
نکات حائز اهمیت:
محیط کاری پویا و یادگیری بالا
کار تیمی
- نصب و راه اندازی دیتابیس های NoSQL ای مثل Cassandra, elastic
- نصب و راه اندازی دیتابیس PostgreSQL
- نصب و راه اندازی Kafka
- راه اندازی کلاسترینگ و HA
- مانیتورینگ دیتابیس ها
دانش و مهارت های مورد نیاز:
- آشنا با مفاهیم NoSQL , SQL
- آشنا با مفاهیم دیتابیس های NoSQL ای نظیر elastic, Arangodb , Cassandra
- آشنا با مفاهیم دیتابیس PostgreSQL
- آشنا با مفاهیم Partitioning و Sharding
- آشنا با مفاهیم HA . کلاسترینگ و Replica Set
- آشنا با سیستم عامل Linux , windows Server
نکات حائز اهمیت:
محیط کاری پویا و یادگیری بالا
کار تیمی
❤1
نسل جدید سامانه‌های مدیریت دیتابیس؛ شروع یک مسیر تازه
فرض کنید یک دستیار هوش مصنوعی داشتید که:
👌متریک‌های دیتابیس را دائم بررسی می‌کرد،
👌کوئری‌های غیر‌بهینه را شناسایی و بهبود می‌داد،
👌ایندکس‌های قدیمی را بازسازی می‌کرد،
👌روند مصرف منابع را در بازه‌های زمانی تحلیل می‌کرد،
👌و حتی وقتی نزدیک به کمبود منابع بودید، پیشاپیش هشدار می‌داد.
دقیقاً همین تصویری است که نسل جدید سامانه‌های مدیریت دیتابیس در حال ساخت آن است.
🧩 چالش‌های امروز در مدیریت دیتابیس
ابزارهای مدیریتی سنتی دیتابیس، بیشتر ناظر هستند تا کنش‌گر.
وقتی Query کند میشود یا ترافیک بالا می‌رود، این ابزارها معمولاً پس از وقوع مشکل هشدار می‌دهند، آن هم دیر، دستی و پرهزینه.
در بسیاری از سازمان‌ها، هنوز هم:
⚠️شناسایی کوئری‌های کند به صورت دستی انجام میشود،
⚠️بهینه‌سازی ایندکس‌ها فراموش یا به تعویق می‌افتد،
⚠️تنظیم منابع سخت‌افزاری نیازمند دخالت مستقیم DBA است،
⚠️و تصمیم‌های بهبود عملکرد، بدون تحلیل روند بلندمدت گرفته میشود.
در حالی که نیاز امروز تیم‌های داده، سامانه‌ای است که بتواند:
✨ پیش از بروز خطا، الگوهای خطر را شناسایی کند،
✨خودش پیشنهاد اصلاح یا بهبود بدهد (و حتی اجرا کند)،
✨از رفتار دیتابیس در طول زمان یاد بگیرد و هوشمندتر شود،
✨و در نهایت، مدیریت را از حالت واکنشی به پیش‌فعال و خودکار تبدیل کند.
⚙️ معرفی : Incerto : کوپایلوت واقعی دیتابیس
یکی از نمونه‌های پیشرو این نسل تازه، پلتفرم Incerto است که نسخه دسکتاپ آن برای ویندوز و سایر سیستم‌عامل‌ها در دسترس است و امکانات رایگان آن برای تک‌کاربر، کافی و بسیار کار راه‌انداز است.
https://incerto.in
سامانه‌ای که خود را «Real Co-Pilot for Databases» می‌نامد و عملاً مثل یک همکار هوشمند در کنار DBA یا Data Engineer قرار می‌گیرد.
🧠 ویژگی‌های کلیدی آن شامل:
✅ تشخیص خودکار بیش از ۱۰۰ نوع مشکل در محیط‌های تولیدی
✅ بهینه‌سازی خودکار کوئری‌ها با کمک AI و بازخورد انسانی
✅ پشتیبانی از چندین نوع DBMS در یک محیط
✅ تحلیل بار کاری و پیشنهاد تنظیمات منابع
✅ تبدیل زبان طبیعی به وظیفه دیتابیسی («ایندکس‌های بلااستفاده را حذف کن»، «منابع این سرور را بررسی کن»)
✅ یادگیری مستمر از رفتار دیتابیس‌ها برای بهبود تصمیم‌ها
💡 نتیجه؟ صرفه‌جویی چشمگیر در زمان، کاهش خطای انسانی و تمرکز بیشتر تیم‌ها بر تحلیل و تصمیم‌سازی به جای نگهداری روزمره.
🚀 از پایش تا خودکارسازی
ابزارهایی مثل Incerto تنها یک محصول نیستند؛ بلکه نشانه‌ی تحولی بزرگ‌ترند:
🌟 حرکت از پایش و هشدار به درک، پیش‌بینی و اقدام.
🌟از ابزارهای کمکی به عامل‌های هوشمند وظیفه‌گرا (Agentic Systems).
شاید در آینده‌ای نه‌چندان دور، مدیریت دیتابیس‌ها هم مثل رانندگی، از «کوپایلوت» به «اتوپایلوت» برسد البته با قابلیت Human-in-the-Loop؛ یعنی هر جا نیاز به قضاوت انسانی باشد، سیستم صبر کند تا کارشناس تأیید کند و پس از آن، اکشن به‌صورت خودکار اجرا شود.
✨ به نظر شما آیا زمان آن رسیده که مدیریت دیتابیس‌ها را هم به دست دستیارهای هوش مصنوعی بسپاریم؟
فرض کنید یک دستیار هوش مصنوعی داشتید که:
👌متریک‌های دیتابیس را دائم بررسی می‌کرد،
👌کوئری‌های غیر‌بهینه را شناسایی و بهبود می‌داد،
👌ایندکس‌های قدیمی را بازسازی می‌کرد،
👌روند مصرف منابع را در بازه‌های زمانی تحلیل می‌کرد،
👌و حتی وقتی نزدیک به کمبود منابع بودید، پیشاپیش هشدار می‌داد.
دقیقاً همین تصویری است که نسل جدید سامانه‌های مدیریت دیتابیس در حال ساخت آن است.
🧩 چالش‌های امروز در مدیریت دیتابیس
ابزارهای مدیریتی سنتی دیتابیس، بیشتر ناظر هستند تا کنش‌گر.
وقتی Query کند میشود یا ترافیک بالا می‌رود، این ابزارها معمولاً پس از وقوع مشکل هشدار می‌دهند، آن هم دیر، دستی و پرهزینه.
در بسیاری از سازمان‌ها، هنوز هم:
⚠️شناسایی کوئری‌های کند به صورت دستی انجام میشود،
⚠️بهینه‌سازی ایندکس‌ها فراموش یا به تعویق می‌افتد،
⚠️تنظیم منابع سخت‌افزاری نیازمند دخالت مستقیم DBA است،
⚠️و تصمیم‌های بهبود عملکرد، بدون تحلیل روند بلندمدت گرفته میشود.
در حالی که نیاز امروز تیم‌های داده، سامانه‌ای است که بتواند:
✨ پیش از بروز خطا، الگوهای خطر را شناسایی کند،
✨خودش پیشنهاد اصلاح یا بهبود بدهد (و حتی اجرا کند)،
✨از رفتار دیتابیس در طول زمان یاد بگیرد و هوشمندتر شود،
✨و در نهایت، مدیریت را از حالت واکنشی به پیش‌فعال و خودکار تبدیل کند.
⚙️ معرفی : Incerto : کوپایلوت واقعی دیتابیس
یکی از نمونه‌های پیشرو این نسل تازه، پلتفرم Incerto است که نسخه دسکتاپ آن برای ویندوز و سایر سیستم‌عامل‌ها در دسترس است و امکانات رایگان آن برای تک‌کاربر، کافی و بسیار کار راه‌انداز است.
https://incerto.in
سامانه‌ای که خود را «Real Co-Pilot for Databases» می‌نامد و عملاً مثل یک همکار هوشمند در کنار DBA یا Data Engineer قرار می‌گیرد.
🧠 ویژگی‌های کلیدی آن شامل:
✅ تشخیص خودکار بیش از ۱۰۰ نوع مشکل در محیط‌های تولیدی
✅ بهینه‌سازی خودکار کوئری‌ها با کمک AI و بازخورد انسانی
✅ پشتیبانی از چندین نوع DBMS در یک محیط
✅ تحلیل بار کاری و پیشنهاد تنظیمات منابع
✅ تبدیل زبان طبیعی به وظیفه دیتابیسی («ایندکس‌های بلااستفاده را حذف کن»، «منابع این سرور را بررسی کن»)
✅ یادگیری مستمر از رفتار دیتابیس‌ها برای بهبود تصمیم‌ها
💡 نتیجه؟ صرفه‌جویی چشمگیر در زمان، کاهش خطای انسانی و تمرکز بیشتر تیم‌ها بر تحلیل و تصمیم‌سازی به جای نگهداری روزمره.
🚀 از پایش تا خودکارسازی
ابزارهایی مثل Incerto تنها یک محصول نیستند؛ بلکه نشانه‌ی تحولی بزرگ‌ترند:
🌟 حرکت از پایش و هشدار به درک، پیش‌بینی و اقدام.
🌟از ابزارهای کمکی به عامل‌های هوشمند وظیفه‌گرا (Agentic Systems).
شاید در آینده‌ای نه‌چندان دور، مدیریت دیتابیس‌ها هم مثل رانندگی، از «کوپایلوت» به «اتوپایلوت» برسد البته با قابلیت Human-in-the-Loop؛ یعنی هر جا نیاز به قضاوت انسانی باشد، سیستم صبر کند تا کارشناس تأیید کند و پس از آن، اکشن به‌صورت خودکار اجرا شود.
✨ به نظر شما آیا زمان آن رسیده که مدیریت دیتابیس‌ها را هم به دست دستیارهای هوش مصنوعی بسپاریم؟
incerto.in
Incerto - Agentic AI That Solves All Database Problems
Gain full visibility into your database performance with real-time monitoring and intelligent insights.
❤3👍1
Forwarded from عکس نگار
💫 آنچه خوبان همه دارند، تو تنها داری: معرفی OpenObserve
بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (#Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های بعد، ابزارهایی چون #VictoriaMetrics و #Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.
اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
🚀 OpenObserve (O2)
openobserve.ai
در بررسی اولیه، با مجموعه‌ای از قابلیت‌ها و معماری چندلایه و آینده‌نگر روبه‌رو شدم که در عین سادگی و کارایی، عمق فنی قابل توجهی دارد.
اینکه پلتفرم کاملاً با زبان Rust نوشته شده است، تنها یکی از دلایل جذابیت آن است؛ چراکه Rust هم‌زمان سرعت، ایمنی حافظه و بهره‌وری بالا را تضمین می‌کند.
🧩 معماری مدرن و الهام‌گرفته از نسل جدید سیستم‌های داده
پروژه #OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با #duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده میشود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل #Parquet.
نتیجه‌ی این معماری چندلایه، سیستمی است که هم بسیار سریع و مقیاس‌پذیر است، هم از نظر هزینه و نگهداری به‌صرفه و ساده باقی می‌ماند.
⚙️ آنچه در بررسی اولیه توجه من را جلب کرد
🔰 امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد
🔰 پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران
🔰 معماری Stateless با مقیاس‌پذیری افقی آسان
🔰 قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch
🔰 پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob
🔰 کوئری با SQL، PromQL و VRL
🔰 سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه
🔰 طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ
⚡ عملکرد و مقیاس
در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.
🌍 جامعه و مسیر رشد
این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.
🧭 دعوت از تیم‌های DevOps و SRE
اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.
کانال مهندسی داده:
https://t.iss.one/bigdata_ir
بیش از یک دهه پیش، مسیر من در دنیای مشاهده‌پذیری زیرساخت‌ها (#Observability) با پشته‌ی کلاسیک ELK (Elasticsearch, Logstash, Kibana) آغاز شد.
در سال‌های بعد، ابزارهایی چون #VictoriaMetrics و #Signoz را نیز تجربه کردم، هر یک با ویژگی‌هایی ارزشمند در حوزه‌ی متریک‌ها، لاگ‌ها و تریس‌ها.
اما در این مسیر، اخیراً با پلتفرمی مواجه شدم که به نظرم می‌رسد حرف تازه‌ای برای گفتن دارد:
🚀 OpenObserve (O2)
openobserve.ai
در بررسی اولیه، با مجموعه‌ای از قابلیت‌ها و معماری چندلایه و آینده‌نگر روبه‌رو شدم که در عین سادگی و کارایی، عمق فنی قابل توجهی دارد.
اینکه پلتفرم کاملاً با زبان Rust نوشته شده است، تنها یکی از دلایل جذابیت آن است؛ چراکه Rust هم‌زمان سرعت، ایمنی حافظه و بهره‌وری بالا را تضمین می‌کند.
🧩 معماری مدرن و الهام‌گرفته از نسل جدید سیستم‌های داده
پروژه #OpenObserve از Apache Parquet به‌عنوان فرمت ذخیره‌سازی ستونی و از DataFusion Query Engine برای اجرای مستقیم کوئری‌ها استفاده می‌کند. (دیتافیوژن مشابه با #duckdb است که با زبان rust توسعه یافته و متعلق به بنیاد آپاچی است)
این طراحی نشان‌دهنده‌ی حرکت آگاهانه به سمت همان معماری‌ای است که در نسل جدید سیستم‌های داده دیده میشود:
> جداسازی کامل لایه‌ی ذخیره‌سازی (Storage Layer) از لایه‌ی محاسبات (Compute Layer)
و تعامل از طریق فرمت‌های باز، ستونی و بهینه مثل #Parquet.
نتیجه‌ی این معماری چندلایه، سیستمی است که هم بسیار سریع و مقیاس‌پذیر است، هم از نظر هزینه و نگهداری به‌صرفه و ساده باقی می‌ماند.
⚙️ آنچه در بررسی اولیه توجه من را جلب کرد
🔰 امکان Full-Stack Observability برای Logs، Metrics و Traces در یک بستر واحد
🔰 پشتیبانی از Session Replay و Real User Monitoring (RUM) برای تحلیل تجربه‌ی واقعی کاربران
🔰 معماری Stateless با مقیاس‌پذیری افقی آسان
🔰 قابلیت High Compression (~40×) و هزینه‌ی ذخیره‌سازی تا ۱۴۰× کمتر از Elasticsearch
🔰 پشتیبانی از ذخیره‌سازی در S3، MinIO، GCS و Azure Blob
🔰 کوئری با SQL، PromQL و VRL
🔰 سیستم Observability Pipelines برای پردازش، پالایش و غنی‌سازی داده‌ها در لحظه
🔰 طراحی High Availability و Clustering برای نیازهای سازمانی بزرگ
⚡ عملکرد و مقیاس
در بنچمارک داخلی، OpenObserve توانسته است ۱ پتابایت داده را در کمتر از ۲ ثانیه کوئری بگیرد، عددی که حتی برای سیستم‌های تحلیلی مدرن نیز قابل توجه است.
معماری Stateless Node آن امکان گسترش افقی بدون پیچیدگی Replication یا وابستگی داده را فراهم می‌کند.
🌍 جامعه و مسیر رشد
این پروژه‌ی متن‌باز اکنون بیش از ۱۶٬۰۰۰ ستاره در GitHub دارد و توسط جامعه‌ای فعال از متخصصان DevOps، SRE و مهندسان داده توسعه می‌یابد.
مستندات رسمی و نمونه‌های کاربردی در openobserve.ai/docs در دسترس است.
🧭 دعوت از تیم‌های DevOps و SRE
اگر در زمینه‌ی DevOps، SRE، Data Platform یا Observability فعالیت می‌کنید، پیشنهاد می‌کنم OpenObserve را از نزدیک بررسی کنید.
ترکیب زبان Rust، طراحی چندلایه‌ی مبتنی بر Parquet و DataFusion، و مجموعه‌ی کامل قابلیت‌ها از Session Replay تا Alerting و Metrics Analysis
آن را به یکی از جامع‌ترین و آینده‌نگرترین پلتفرم‌های مشاهده‌پذیری حال حاضر تبدیل کرده است.
کانال مهندسی داده:
https://t.iss.one/bigdata_ir
👍2🙏1
Forwarded from مدرسه مهندسی داده سپهرام
وقتی 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 #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده
در بخش تازه‌ای از دوره آموزش تخصصی کافکا در مدرسه مهندسی داده سپهرام، با یکی از جایگزین‌های قدرتمند و مدرن 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 #مدرسه_مهندسی_داده #کافکا #داده_جاری #مهندسی_داده
❤7👍2
Forwarded from مدرسه مهندسی داده سپهرام
وقتی 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
اگر در حوزه نرم‌افزار، تحلیل داده یا دیتابیس کار می‌کنید، احتمالاً با انواع 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
❤8👍2