دوستی سوال و چالشی مطرح کرده بود :
و پاسخ من به این جالش و سوال :
سوال :
وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی
چند روز پیش یکی از دوستان که روی پروژه‌های #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 تحلیل پایین مهم باشه.
مفهوم Time Series چیه؟
داده‌های سری زمانی، داده‌هایی هستن که به ترتیب زمان ثبت می‌شن؛ مثلاً داده‌های سنسورها، لاگ سیستم‌ها، یا حتی قیمت ارز توی بازار. نکته‌ی کلیدی اینه که زمان، محور اصلی تحلیله.
چالش‌های این نوع داده‌ها:
نرخ بالای ورود داده (High Ingestion Rate)
تحلیل لحظه‌ای (Real-time Analytics)
کاردینالیتی بالا؛ یعنی میلیون‌ها سنسور یا دستگاه یکتا
نیاز به توابع خاص مثل average، sampling، downsampling، backfill و غیره
تکنولوژی‌هایی که مطرحن:
۱. InfluxDB
یکی از معروف‌ترین‌ها، خیلی راحت راه می‌افته ولی تو کاردینالیتی بالا و ورودی خیلی زیاد کم میاره.
۲. TimescaleDB
بر پایه PostgreSQL، اگه تیم آشنا با SQL باشه عالیه. اما مقیاس‌پذیری افقی محدوده.
۳. QuestDB
سریع و جمع‌وجوره، برای پروژه‌های سبک تا متوسط خیلی خوبه.
۴. ClickHouse
اگه تحلیل پیچیده و سریع real-time بخوایم، این عالیه. بیشتر به درد data analytics می‌خوره.
۵. HoraeDB
جدید و خیلی پیشرفته‌ست، برای داده‌های سری زمانی با کاردینالیتی بالا طراحی شده. با Rust نوشته شده، cloud-native و zero-disk هم هست، یعنی بخش ذخیره‌سازی و محاسبات جداست. هنوز نوپاست ولی آینده‌داره.
۶. ScyllaDB / Cassandra
برای write-heavy عالی‌ان. اگر مدل داده رو خوب طراحی کنیم، می‌تونه حجم بسیار بالای داده رو سریع ذخیره کنه.
مثال در DevOps Metrics :
۱. average (میانگین)
کاربرد:
محاسبه‌ی میانگین زمان پاسخ (Average Response Time)
محاسبه‌ی میانگین زمان استقرار (Average Deployment Time)
تحلیل Load average روی سرورها
مثال:
فرض کن Prometheus از endpoint اپلیکیشن، latency را برمی‌دارد:
avg_over_time(http_request_duration_seconds[5m])
میانگین زمان پاسخ‌گویی در ۵ دقیقه‌ی گذشته را محاسبه می‌کند.
📉 ۲. sampling (نمونه‌برداری)
کاربرد:
کاهش داده‌های ذخیره‌شده در زمان طولانی
بررسی نمای کلی بدون بار زیاد روی سیستم
ایجاد alertها بدون چک کردن ۱۰۰٪ داده‌ها
مثال:
در ابزارهای مانیتورینگ مثل Datadog یا NewRelic، به‌جای بررسی تمام ترافیک، تنها 10٪ نمونه‌برداری می‌شود:
Sampling rate = 0.1 (10% of total traffic)
⬇️ ۳. downsampling (کاهش نرخ داده‌های زمانی)
کاربرد:
نمایش داشبوردهای گرافانا با سرعت بالا
نگهداری long-term metrics (مثلاً ۱ سال اخیر، فقط داده ساعتی)
کاهش بار حافظه/دیسک برای داده‌های time-series
مثال با Prometheus:
avg_over_time(cpu_usage[1h])
داده‌های دقیقه‌ای CPU را به داده‌های ساعتی تبدیل می‌کند (میانگین هر ساعت).
در Grafana هم می‌تونیم تنظیم کنیم که هر بار فقط 1 نقطه در هر 5 دقیقه نمایش داده بشه، نه همه‌ی 1000 داده‌ی خام.
🧩 ۴. backfill (پر کردن داده‌ی گمشده با مقادیر آینده)
کاربرد:
وقتی سرویس مانیتورینگ قطع شده و بعداً reconnect می‌شود
بازیابی گراف‌ها برای تحلیل گذشته (retroactive metrics)
مثال:
فرض کن alertها با داده‌های ناقص کار نمی‌کنن. پس از reconnect شدن agent مانیتورینگ، سیستم مقدار بعدی رو backward propagate می‌کنه:
If data at 10:00 is missing,
use 10:01 value to fill 10:00 slot (backfill)
در ابزارهایی مثل VictoriaMetrics، InfluxDB و TimescaleDB، backfill یکی از ابزارهای مهم در pre-processing داده‌هاست.
✨ ترکیب کاربردها در سناریوی واقعی
🔧 فرض: داری latency یک microservice رو در Grafana نشون می‌دی و باید alert بذاری که وقتی latency بیش از ۵۰۰ms شد، هشدار بده.
برای اینکه سیستم نترکه از انبوه داده، چه می‌کنی؟
با sampling فقط 10٪ داده رو بررسی می‌کنی
با downsampling گراف رو روی میانگین 1 دقیقه‌ای می‌ذاری
با average داده‌های noisy رو صاف می‌کنی
اگر داده‌ای نبود، backfill یا forward fill می‌کنی که alertها skip نشن
#database #time #series #bigdata #InfluxDB #ScyllaDB #Cassandra #ClickHouse #QuestDB #TimescaleDB #HoraeDB
https://t.me/unixmens
داده‌های سری زمانی، داده‌هایی هستن که به ترتیب زمان ثبت می‌شن؛ مثلاً داده‌های سنسورها، لاگ سیستم‌ها، یا حتی قیمت ارز توی بازار. نکته‌ی کلیدی اینه که زمان، محور اصلی تحلیله.
چالش‌های این نوع داده‌ها:
نرخ بالای ورود داده (High Ingestion Rate)
تحلیل لحظه‌ای (Real-time Analytics)
کاردینالیتی بالا؛ یعنی میلیون‌ها سنسور یا دستگاه یکتا
نیاز به توابع خاص مثل average، sampling، downsampling، backfill و غیره
تکنولوژی‌هایی که مطرحن:
۱. InfluxDB
یکی از معروف‌ترین‌ها، خیلی راحت راه می‌افته ولی تو کاردینالیتی بالا و ورودی خیلی زیاد کم میاره.
۲. TimescaleDB
بر پایه PostgreSQL، اگه تیم آشنا با SQL باشه عالیه. اما مقیاس‌پذیری افقی محدوده.
۳. QuestDB
سریع و جمع‌وجوره، برای پروژه‌های سبک تا متوسط خیلی خوبه.
۴. ClickHouse
اگه تحلیل پیچیده و سریع real-time بخوایم، این عالیه. بیشتر به درد data analytics می‌خوره.
۵. HoraeDB
جدید و خیلی پیشرفته‌ست، برای داده‌های سری زمانی با کاردینالیتی بالا طراحی شده. با Rust نوشته شده، cloud-native و zero-disk هم هست، یعنی بخش ذخیره‌سازی و محاسبات جداست. هنوز نوپاست ولی آینده‌داره.
۶. ScyllaDB / Cassandra
برای write-heavy عالی‌ان. اگر مدل داده رو خوب طراحی کنیم، می‌تونه حجم بسیار بالای داده رو سریع ذخیره کنه.
مثال در DevOps Metrics :
۱. average (میانگین)
کاربرد:
محاسبه‌ی میانگین زمان پاسخ (Average Response Time)
محاسبه‌ی میانگین زمان استقرار (Average Deployment Time)
تحلیل Load average روی سرورها
مثال:
فرض کن Prometheus از endpoint اپلیکیشن، latency را برمی‌دارد:
avg_over_time(http_request_duration_seconds[5m])
میانگین زمان پاسخ‌گویی در ۵ دقیقه‌ی گذشته را محاسبه می‌کند.
📉 ۲. sampling (نمونه‌برداری)
کاربرد:
کاهش داده‌های ذخیره‌شده در زمان طولانی
بررسی نمای کلی بدون بار زیاد روی سیستم
ایجاد alertها بدون چک کردن ۱۰۰٪ داده‌ها
مثال:
در ابزارهای مانیتورینگ مثل Datadog یا NewRelic، به‌جای بررسی تمام ترافیک، تنها 10٪ نمونه‌برداری می‌شود:
Sampling rate = 0.1 (10% of total traffic)
⬇️ ۳. downsampling (کاهش نرخ داده‌های زمانی)
کاربرد:
نمایش داشبوردهای گرافانا با سرعت بالا
نگهداری long-term metrics (مثلاً ۱ سال اخیر، فقط داده ساعتی)
کاهش بار حافظه/دیسک برای داده‌های time-series
مثال با Prometheus:
avg_over_time(cpu_usage[1h])
داده‌های دقیقه‌ای CPU را به داده‌های ساعتی تبدیل می‌کند (میانگین هر ساعت).
در Grafana هم می‌تونیم تنظیم کنیم که هر بار فقط 1 نقطه در هر 5 دقیقه نمایش داده بشه، نه همه‌ی 1000 داده‌ی خام.
🧩 ۴. backfill (پر کردن داده‌ی گمشده با مقادیر آینده)
کاربرد:
وقتی سرویس مانیتورینگ قطع شده و بعداً reconnect می‌شود
بازیابی گراف‌ها برای تحلیل گذشته (retroactive metrics)
مثال:
فرض کن alertها با داده‌های ناقص کار نمی‌کنن. پس از reconnect شدن agent مانیتورینگ، سیستم مقدار بعدی رو backward propagate می‌کنه:
If data at 10:00 is missing,
use 10:01 value to fill 10:00 slot (backfill)
در ابزارهایی مثل VictoriaMetrics، InfluxDB و TimescaleDB، backfill یکی از ابزارهای مهم در pre-processing داده‌هاست.
✨ ترکیب کاربردها در سناریوی واقعی
🔧 فرض: داری latency یک microservice رو در Grafana نشون می‌دی و باید alert بذاری که وقتی latency بیش از ۵۰۰ms شد، هشدار بده.
برای اینکه سیستم نترکه از انبوه داده، چه می‌کنی؟
با sampling فقط 10٪ داده رو بررسی می‌کنی
با downsampling گراف رو روی میانگین 1 دقیقه‌ای می‌ذاری
با average داده‌های noisy رو صاف می‌کنی
اگر داده‌ای نبود، backfill یا forward fill می‌کنی که alertها skip نشن
#database #time #series #bigdata #InfluxDB #ScyllaDB #Cassandra #ClickHouse #QuestDB #TimescaleDB #HoraeDB
https://t.me/unixmens