وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای دادههای سری زمانی
چند روز پیش یکی از دوستان که روی پروژههای #SCADA در صنایع زیرساختی کار میکند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیقتر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇
سری زمانی یعنی چی؟ 🕒
دادههای #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 و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی
گزینههای عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍
⚡️ دیتابیس ClickHouse
تحلیل سریع و فوقالعاده روی دادههای ستونی. اگر تحلیل پیچیده Real-time میخواید، عالیه.
🔹 مقیاسپذیر افقی
🔹 پشتیبانی از توابع Aggregation
🌀 دیتابیس ScyllaDB / Cassandra
طراحیشده برای نوشتن سریع با تأخیر کم.
اگر مدل دادهی خوبی طراحی کنید، خیلی خوب جواب میده.
🔹 دیتابیس ScyllaDB سریعتر از Cassandra و با مصرف منابع کمتر
✳️ جمعبندی برای شرایط صنعتی با دادههای حجیم:
اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:
🔹 Apache HoraeDB – طراحیشده برای مقیاس بالا + کاردینالیتی بالا
🔹 ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ
🔹 ScyllaDB – اگر اولویت با نوشتن با نرخ بالا و توزیعپذیریه
🤝 دعوت به گفتگو
آیا تجربهای در انتخاب یا مهاجرت از پایگاهدادههای سنتی به TimeSeries DB داشتید؟
کدوم ابزار براتون بهتر جواب داده؟ چه چالشهایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژههای بعدی همه ما کمک کنه. نظراتتون را در بخش کامنت این پست می توانید با سایر دوستان به اشتراک بگذارید.
#SCADA #TimeSeriesDatabase #HoraeDB #ClickHouse #ScyllaDB #InfluxDB #QuestDB #DataEngineering #IoT #HighCardinality #RustLang
چند روز پیش یکی از دوستان که روی پروژههای #SCADA در صنایع زیرساختی کار میکند، سوال جالبی مطرح کرد که باعث شد بشینم و یه بررسی دقیقتر انجام بدم و نتیجه را با شما هم به اشتراک بذارم 👇
«ما دادههای سری زمانی داریم و فعلاً در پایگاهداده #Oracle ذخیره میشن. ولی در پروژههای جدید ممکنه نرخ داده به ۵۰۰ هزار سیگنال در ثانیه برسه. دنبال دیتابیسی هستیم که بتونه این حجم رو مدیریت کنه، تحلیل Real-time بده، و قابلیتهایی مثل میانگینگیری، Sampling، و Backfill رو پشتیبانی کنه.»
سری زمانی یعنی چی؟ 🕒
دادههای #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 و جداسازی بخش محاسبات و پردازش از بخش ذخیره سازی
گزینههای عمومی ولی قدرتمند برای تحلیل داده در مقیاس بالا 🔍
⚡️ دیتابیس ClickHouse
تحلیل سریع و فوقالعاده روی دادههای ستونی. اگر تحلیل پیچیده Real-time میخواید، عالیه.
🔹 مقیاسپذیر افقی
🔹 پشتیبانی از توابع Aggregation
🌀 دیتابیس ScyllaDB / Cassandra
طراحیشده برای نوشتن سریع با تأخیر کم.
اگر مدل دادهی خوبی طراحی کنید، خیلی خوب جواب میده.
🔹 دیتابیس ScyllaDB سریعتر از Cassandra و با مصرف منابع کمتر
✳️ جمعبندی برای شرایط صنعتی با دادههای حجیم:
اگر با سناریوهایی مثل ۵۰۰k در ثانیه، نیاز به واکشی سریع و تحلیل Real-time سروکار دارید، این سه گزینه بیشترین تطابق رو دارن:
🔹 Apache HoraeDB – طراحیشده برای مقیاس بالا + کاردینالیتی بالا
🔹 ClickHouse – برای تحلیل بلادرنگ در مقیاس بزرگ
🔹 ScyllaDB – اگر اولویت با نوشتن با نرخ بالا و توزیعپذیریه
🤝 دعوت به گفتگو
آیا تجربهای در انتخاب یا مهاجرت از پایگاهدادههای سنتی به TimeSeries DB داشتید؟
کدوم ابزار براتون بهتر جواب داده؟ چه چالشهایی داشتید؟👂 شاید این بحث به انتخاب بهتر برای پروژههای بعدی همه ما کمک کنه. نظراتتون را در بخش کامنت این پست می توانید با سایر دوستان به اشتراک بگذارید.
#SCADA #TimeSeriesDatabase #HoraeDB #ClickHouse #ScyllaDB #InfluxDB #QuestDB #DataEngineering #IoT #HighCardinality #RustLang
👍2👏1
چطور تسلا با ClickHouse یک پلتفرم مشاهدهپذیری در مقیاس نجومی ساخت؟
مشاهدهپذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژهای به نام Comet
داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟
👨💻 مهندس ارشد تسلا Alon Tal، میگوید:
«ما به سیستمی نیاز داشتیم که بتونه دهها میلیون ردیف در ثانیه را ingest کنه، سالها داده رو نگه داره، و همچنان real-time پاسخ بده.»
چرا Prometheus کافی نبود؟
🔸 مقیاسپذیری افقی محدود
🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریکها)
🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود
✅ راهحل: ساخت یک سیستم جدید به نام Comet
💡 با استفاده از ClickHouse به عنوان هستهی اصلی، تسلا یک پلتفرم metrics محور ساخت که:
📥 دادهها را از طریق OTLP و Kafka ingest میکند
⚙️ با ETLهای سفارشی دادهها را به شکل ساختیافته وارد ClickHouse میکند
🔄 و مهمتر از همه:
کوئریهای PromQL را به SQL معادل در ClickHouse ترجمه میکند بدون اینکه مهندسان متوجه تفاوت شوند!
🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار میکنند!
💥 مقیاس واقعی؟
یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!
نتیجه؟
🔹 بدون یک خطا
🔹 مصرف ثابت RAM و CPU
🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!
📊 سیستم هنوز هم در حال scale شدن برای تیمهای داخلی تسلاست!
✨ چرا ClickHouse؟
🔹 سرعت بیرقیب در پاسخ به کوئریهای پیچیده
🔹 UDFهای اجرایی برای کوئریهای غیر trivial
🔹 پشتیبانی از PromQL و TraceQL
🔹 نگهداری بلندمدت دادهها با حجم بالا
🔹 و مهمتر از همه: قابلیت اطمینان بالا در مقیاس تسلا!
🔭 آیندهی Comet؟
🔧 پشتیبانی از distributed tracing
🌍 احتمال open-source شدن
🎯 گسترش به دیگر واحدهای عملیاتی در تسلا
📎 جمعبندی
تسلا با پروژهی Comet ثابت کرد که observability در مقیاس سیارهای ممکن است—اگر ابزار مناسب انتخاب شود!
✅ حالا واقعا پرومتئوس حذف شد؟
تسلا Prometheus رو بهطور مستقیم حذف نکرد، ولی:
🌟دیگه از خود Prometheus برای ذخیرهسازی و کوئری استفاده نمیکنه.
🌟 بهجاش، پلتفرمی به نام Comet ساخت که خودش میتونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیکهوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!
🔗 منبع اصلی:
https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse
#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure
مشاهدهپذیری در مقیاس کوادریلیون (هزار بیلیارد) با ClickHouse و پروژهای به نام Comet
داستان تغییر زیرساخت observability تسلا از کجا شروع شد ؟
🔧 چند میلیون خودرو متصل، هزاران زیرسیستم توزیعشده، و گیگافکتوریهایی که شبانهروز داده میفرستند. تسلا در چنین مقیاسی نمیتوانست روی Prometheus حساب باز کند...
👨💻 مهندس ارشد تسلا Alon Tal، میگوید:
«ما به سیستمی نیاز داشتیم که بتونه دهها میلیون ردیف در ثانیه را ingest کنه، سالها داده رو نگه داره، و همچنان real-time پاسخ بده.»
چرا Prometheus کافی نبود؟
🔸 مقیاسپذیری افقی محدود
🔸 وابستگی به یک سرور واحد (ریسک از دست دادن کل متریکها)
🔸 مشکلات نگهداری بلندمدت و زبان کوئری محدود
✅ راهحل: ساخت یک سیستم جدید به نام Comet
💡 با استفاده از ClickHouse به عنوان هستهی اصلی، تسلا یک پلتفرم metrics محور ساخت که:
📥 دادهها را از طریق OTLP و Kafka ingest میکند
⚙️ با ETLهای سفارشی دادهها را به شکل ساختیافته وارد ClickHouse میکند
🔄 و مهمتر از همه:
کوئریهای PromQL را به SQL معادل در ClickHouse ترجمه میکند بدون اینکه مهندسان متوجه تفاوت شوند!
🧠 یعنی داشبوردهای موجود (Grafana، Alertmanager، و...) بدون تغییر کار میکنند!
💥 مقیاس واقعی؟
یک میلیارد ردیف در ثانیه! به مدت ۱۱ روز پیاپی!
نتیجه؟
🔹 بدون یک خطا
🔹 مصرف ثابت RAM و CPU
🔹 بیش از ۱ کوادریلیون رکورد با موفقیت ingest شده!
📊 سیستم هنوز هم در حال scale شدن برای تیمهای داخلی تسلاست!
✨ چرا ClickHouse؟
🔹 سرعت بیرقیب در پاسخ به کوئریهای پیچیده
🔹 UDFهای اجرایی برای کوئریهای غیر trivial
🔹 پشتیبانی از PromQL و TraceQL
🔹 نگهداری بلندمدت دادهها با حجم بالا
🔹 و مهمتر از همه: قابلیت اطمینان بالا در مقیاس تسلا!
🔭 آیندهی Comet؟
🔧 پشتیبانی از distributed tracing
🌍 احتمال open-source شدن
🎯 گسترش به دیگر واحدهای عملیاتی در تسلا
📎 جمعبندی
تسلا با پروژهی Comet ثابت کرد که observability در مقیاس سیارهای ممکن است—اگر ابزار مناسب انتخاب شود!
✅ حالا واقعا پرومتئوس حذف شد؟
تسلا Prometheus رو بهطور مستقیم حذف نکرد، ولی:
🌟دیگه از خود Prometheus برای ذخیرهسازی و کوئری استفاده نمیکنه.
🌟 بهجاش، پلتفرمی به نام Comet ساخت که خودش میتونه PromQL (زبان کوئری Prometheus) رو اجرا کنه و پشت صحنه با کلیکهوس ارتباط بگیره و خروجی بده بدون اینکه واقعاً Prometheus وجود داشته باشه!
🔗 منبع اصلی:
https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse
#ClickHouse #Observability #Tesla #PromQL #DataEngineering #Scalability #TimeSeries #Kafka #DevOps #OpenTelemetry #Infrastructure
ClickHouse
How Tesla built a quadrillion-scale observability platform on ClickHouse
“Data in ClickHouse is better than data anywhere else. No other system lets you slice and dice your data, ask interesting questions, and get answers in an acceptable amount of time. There’s nothing out there that competes with ClickHouse.” Alon Tal, Senio
👍4❤1