#prometheus monitor and solation and solution // Prometheus - Monitoring system & time series database #monitoring @unixmens
یکی از ابزارهای مانیتورینگ #prometheus می باشد در اینجا به بررسی چند موارد از أن خواهیم پرداخت
کاربرد این ابزار بیشتر برای مانیتورینگ Cloud, SaaS/openstack می باشد و با زبان برنامه نویسی go نوشته شده است ، پس باید انتظار سریع تر بودن را داشت
برای نمونه #zabbix با زبان c نوشته شده و پایداری بیشتری داره
#زبیکس بیس آن همانظور که گفته شد از C هست و web gui ان با php ولی #prometheus کلا با زبان go می باشد
در واقع #prometheus متن باز می باشد
کاربرد این ابزار بیشتر برای مانیتورینگ Cloud, SaaS/openstack می باشد و با زبان برنامه نویسی go نوشته شده است ، پس باید انتظار سریع تر بودن را داشت
برای نمونه #zabbix با زبان c نوشته شده و پایداری بیشتری داره
#زبیکس بیس آن همانظور که گفته شد از C هست و web gui ان با php ولی #prometheus کلا با زبان go می باشد
در واقع #prometheus متن باز می باشد
در واقع #zabbix از پایگاه داده های رابطه ای استفاده می کند RDBMS (MySQL, PostgreSQL, Oracle, sqlite) ولی #prometheus از پایگاه داده توکار خودش استفاده میکند
دوستی سوال و چالشی مطرح کرده بود :
و پاسخ من به این جالش و سوال :
سوال :
وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی
چند روز پیش یکی از دوستان که روی پروژه‌های #SCADA در صنایع زیرساختی کار میکند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیق‌تر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇
«ما داده‌های سری زمانی داریم و فعلاً در پایگاه‌داده #Oracle ذخیره می‌شن. ولی در پروژه‌های جدید ممکنه نرخ داده به ۵۰۰ هزار سیگنال در ثانیه برسه. دنبال دیتابیسی هستیم که بتونه این حجم رو مدیریت کنه، تحلیل Real-time بده، و قابلیت‌هایی مثل میانگین‌گیری، Sampling، و Backfill رو پشتیبانی کنه.»
سری زمانی یعنی چی؟ 🕒
داده‌های hashtag#TimeSeries معمولاً از سنسورها یا لاگ سیستم‌ها میان و بر اساس زمان مرتب می‌شن. ذخیره و تحلیل این داده‌ها با پایگاه‌داده‌های سنتی خیلی وقتا سخت یا ناکارآمده.
چالش مهم: کاردینالیتی بالا 🧠
در دیتابیس‌های سری زمانی، ستون‌هایی مثل Tag یا Label ممکنه میلیون‌ها مقدار یکتا داشته باشن (High Cardinality). مثلاً هر سنسور یا دستگاه یه شناسه خاص داره. دیتابیس‌هایی مثل #InfluxDB یا #Prometheus در این شرایط دچار مشکل می‌شن، چون ایندکس‌گذاری معکوس (Inverted Index) براشون گرونه.
بررسی گزینه‌های جدی برای ذخیره و تحلیل داده‌های سری زمانی 🧪
✅ #TimescaleDB
بر پایه‌ی PostgreSQL، آشنا برای خیلی از تیم‌ها، ولی مقیاس‌پذیری افقی محدود داره.
✅ #InfluxDB
معروف‌ترین دیتابیس سری زمانی، ولی در حجم و کاردینالیتی بالا ممکنه کم بیاره.
🔹 زبان اختصاصی Flux، نسخه Cloud و OSS
✅ #QuestDB
سریع و سبک، با پشتیبانی از SQL و تحلیل‌های ساده Real-time.
🔹 مناسب پروژه‌های سبک تا متوسط
🚀 Apache #HoraeDB
طراحی شده با زبان Rust برای کار با داده‌های سری زمانی با کاردینالیتی بالا.
🔹 از تکنیک scan+prune به جای inverted index استفاده می‌کنه.
🔹 طراحی مدرن : Cloud-native و مقیاس‌پذیر
🔹 هنوز incubating ولی بسیار جذاب
🔹 معماری Zero-Disk و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی
ر.ک : https://lnkd.in/dJVkZ-SF
سایر گزینه‌های عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍
⚡️ #ClickHouse
تحلیل سریع و فوق‌العاده روی داده‌های ستونی. اگر تحلیل پیچیده Real-time می‌خواید، عالیه.
🔹 مقیاس‌پذیر افقی
🔹 پشتیبانی از توابع Aggregation
🌀 #ScyllaDB / Apache #Cassandra
طراحی‌شده برای نوشتن سریع با تأخیر کم.
اگر مدل داده‌ی خوبی طراحی کنید، خیلی خوب جواب می‌ده.
🔹 ScyllaDB سریع‌تر از Cassandra و با مصرف منابع کمتر
✳️ جمع‌بندی برای شرایط صنعتی با داده‌های حجیم:
اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:
🔹 Apache #HoraeDB – طراحی‌شده برای مقیاس بالا + کاردینالیتی بالا
🔹 #ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ
🔹 #ScyllaDB – اگر اولویت با نرخ نوشتن بالا و توزیع‌پذیریه
🤝 دعوت به گفتگو
آیا تجربه‌ای در انتخاب یا مهاجرت از پایگاه‌داده‌های سنتی به TimeSeries DB داشتید؟
کدوم ابزار براتون بهتر جواب داده؟ چه چالش‌هایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژه‌های بعدی همه ما کمک کنه.
پاسخ من :
چند نکته :
HoraeDB
معماری جداگانه compute/storage و زبان Rust واقعاً آینده داره
استفاده از Scan + Prune به‌جای inverted index برای کاردینالیتی بالا یه نوآوری مهمه.
با اینکه هنوز در incubation هست، ولی فلسفه‌ی طراحی‌اش کاملاً منطبق با نیازهای edge+cloud و ورودی سنگینه.
مناسب هست اگر: تیم حاضر به تجربه‌گرایی و مشارکت در پروژه‌های جدید باشه. برای پروژه‌های حیاتی بهتره تست سنگین قبل از Prod انجام بشه.
۲. ClickHouse
اگر خروجی شما به‌شدت تحلیلی (مثلاً KPIهای تولید، سلامت تجهیز، alert real-time) هست، این انتخاب عالیه.
فشرده‌سازی ستونی، پردازش سریع و پشتیبانی از JOIN باعث شده برای Time Series OLAP بی‌رقیب باشه.
پشتیبانی از Materialized Views + TTL + AggregatingMergeTree خیلی کمک‌کننده است.
اما نکته :
مناسب هست اگر: تحلیل سنگین‌تر از نوشتنه. داده‌ها append-only باشن و latency تحلیل پایین مهم باشه.
و پاسخ من به این جالش و سوال :
سوال :
وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی
چند روز پیش یکی از دوستان که روی پروژه‌های #SCADA در صنایع زیرساختی کار میکند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیق‌تر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇
«ما داده‌های سری زمانی داریم و فعلاً در پایگاه‌داده #Oracle ذخیره می‌شن. ولی در پروژه‌های جدید ممکنه نرخ داده به ۵۰۰ هزار سیگنال در ثانیه برسه. دنبال دیتابیسی هستیم که بتونه این حجم رو مدیریت کنه، تحلیل Real-time بده، و قابلیت‌هایی مثل میانگین‌گیری، Sampling، و Backfill رو پشتیبانی کنه.»
سری زمانی یعنی چی؟ 🕒
داده‌های hashtag#TimeSeries معمولاً از سنسورها یا لاگ سیستم‌ها میان و بر اساس زمان مرتب می‌شن. ذخیره و تحلیل این داده‌ها با پایگاه‌داده‌های سنتی خیلی وقتا سخت یا ناکارآمده.
چالش مهم: کاردینالیتی بالا 🧠
در دیتابیس‌های سری زمانی، ستون‌هایی مثل Tag یا Label ممکنه میلیون‌ها مقدار یکتا داشته باشن (High Cardinality). مثلاً هر سنسور یا دستگاه یه شناسه خاص داره. دیتابیس‌هایی مثل #InfluxDB یا #Prometheus در این شرایط دچار مشکل می‌شن، چون ایندکس‌گذاری معکوس (Inverted Index) براشون گرونه.
بررسی گزینه‌های جدی برای ذخیره و تحلیل داده‌های سری زمانی 🧪
✅ #TimescaleDB
بر پایه‌ی PostgreSQL، آشنا برای خیلی از تیم‌ها، ولی مقیاس‌پذیری افقی محدود داره.
✅ #InfluxDB
معروف‌ترین دیتابیس سری زمانی، ولی در حجم و کاردینالیتی بالا ممکنه کم بیاره.
🔹 زبان اختصاصی Flux، نسخه Cloud و OSS
✅ #QuestDB
سریع و سبک، با پشتیبانی از SQL و تحلیل‌های ساده Real-time.
🔹 مناسب پروژه‌های سبک تا متوسط
🚀 Apache #HoraeDB
طراحی شده با زبان Rust برای کار با داده‌های سری زمانی با کاردینالیتی بالا.
🔹 از تکنیک scan+prune به جای inverted index استفاده می‌کنه.
🔹 طراحی مدرن : Cloud-native و مقیاس‌پذیر
🔹 هنوز incubating ولی بسیار جذاب
🔹 معماری Zero-Disk و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی
ر.ک : https://lnkd.in/dJVkZ-SF
سایر گزینه‌های عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍
⚡️ #ClickHouse
تحلیل سریع و فوق‌العاده روی داده‌های ستونی. اگر تحلیل پیچیده Real-time می‌خواید، عالیه.
🔹 مقیاس‌پذیر افقی
🔹 پشتیبانی از توابع Aggregation
🌀 #ScyllaDB / Apache #Cassandra
طراحی‌شده برای نوشتن سریع با تأخیر کم.
اگر مدل داده‌ی خوبی طراحی کنید، خیلی خوب جواب می‌ده.
🔹 ScyllaDB سریع‌تر از Cassandra و با مصرف منابع کمتر
✳️ جمع‌بندی برای شرایط صنعتی با داده‌های حجیم:
اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:
🔹 Apache #HoraeDB – طراحی‌شده برای مقیاس بالا + کاردینالیتی بالا
🔹 #ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ
🔹 #ScyllaDB – اگر اولویت با نرخ نوشتن بالا و توزیع‌پذیریه
🤝 دعوت به گفتگو
آیا تجربه‌ای در انتخاب یا مهاجرت از پایگاه‌داده‌های سنتی به TimeSeries DB داشتید؟
کدوم ابزار براتون بهتر جواب داده؟ چه چالش‌هایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژه‌های بعدی همه ما کمک کنه.
پاسخ من :
چند نکته :
HoraeDB
معماری جداگانه compute/storage و زبان Rust واقعاً آینده داره
استفاده از Scan + Prune به‌جای inverted index برای کاردینالیتی بالا یه نوآوری مهمه.
با اینکه هنوز در incubation هست، ولی فلسفه‌ی طراحی‌اش کاملاً منطبق با نیازهای edge+cloud و ورودی سنگینه.
مناسب هست اگر: تیم حاضر به تجربه‌گرایی و مشارکت در پروژه‌های جدید باشه. برای پروژه‌های حیاتی بهتره تست سنگین قبل از Prod انجام بشه.
۲. ClickHouse
اگر خروجی شما به‌شدت تحلیلی (مثلاً KPIهای تولید، سلامت تجهیز، alert real-time) هست، این انتخاب عالیه.
فشرده‌سازی ستونی، پردازش سریع و پشتیبانی از JOIN باعث شده برای Time Series OLAP بی‌رقیب باشه.
پشتیبانی از Materialized Views + TTL + AggregatingMergeTree خیلی کمک‌کننده است.
اما نکته :
مناسب هست اگر: تحلیل سنگین‌تر از نوشتنه. داده‌ها append-only باشن و latency تحلیل پایین مهم باشه.