‍ وقتی پای ۵۰۰هزار سیگنال در ثانیه وسط است ⚡️: انتخاب پایگاه داده برای داده‌های سری زمانی

چند روز پیش یکی از دوستان که روی پروژه‌های #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

‍ شمارش بازدیدها و اکشن‌های کاربر با فناوری‌های مدرن داده

در پست قبلی درباره روش‌های کلاسیک شمارش بازدید محصولات یا تماشای ویدئو صحبت کردم.

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

به‌طور خلاصه گفتیم که در بار ترافیکی بالا، بهتر است بازدیدها را در حافظه نگهداری و جمع‌بندی کرده، سپس در بازه‌های زمانی مشخص وارد دیتابیس کنیم. همچنین به رویکرد پیشرفته‌تری با Kafka + Flink برای ایجاد بافر و بروزرسانی دوره‌ای دیتابیس اشاره شد.

اما امروز می‌خواهیم به سراغ راهکارهای مدرن‌تر برویم. پیشرفت‌های اخیر در استک‌های داده، امکانات جدیدی برای ما فراهم کرده که فقط محدود به شمارش ساده نیستند.

🎯 هدف ما فقط شمارش نیست!

آنچه امروز اهمیت دارد، ذخیره‌سازی دقیق تمام اکشن‌های کاربر است.

چرا؟

✅برای شخصی‌سازی تجربه کاربری بر اساس رفتار هر فرد

✅برای تحلیل عمیق روی محصولات یا ویدئوها و بهبود تجربه کاربران

پس راهکار ایده‌آل باید هم شمارش و هم ذخیره‌سازی کامل داده‌ها را پوشش دهد.


🛠 سه راهکار مدرن برای شمارش و ذخیره اکشن‌ها

1️⃣ استفاده از Cassandra / ScyllaDB و قابلیت Distributed Counter

🎯برای هر کاربر و هر محصول، یک جدول بازدید ایجاد می‌کنیم

🎯هر اکشن را در هر دو جدول ذخیره می‌کنیم (مدل داده این دیتابیس‌ها بر اساس Query طراحی می‌شود)

🎯شمارش اکشن‌ها با Distributed Counter انجام می‌شود

🎯امکان تعریف شمارنده برای بازه‌های زمانی مختلف (ساعتی، روزانه و...) وجود دارد

✅مزیت اصلی: مقیاس‌پذیری بالا و سرعت فوق‌العاده


2️⃣ ذخیره خام داده‌ها در قالب Apache Iceberg با AutoMQ

🎯جایگزین Kafka سنتی با AutoMQ

🎯 پیام رسان AutoMQ که دقیقا منطبق بر استاندارد کافکا است، پیام‌ها را مستقیماً در Iceberg ذخیره می‌کند

🎯شمارش با Flink + Redis انجام می‌شود

🎯امکان تحلیل بعدی رفتار کاربران با ابزارهایی مثل ClickHouse یا Spark

✅مزیت اصلی: فشار کمتر روی دیتابیس اصلی و نگهداری داده‌های خام برای تحلیل‌های آینده

3️⃣ استفاده از دیتابیس جریانی RisingWave – سریع، مدرن و چندکاره 🚀

دیتابیس RisingWave یک دیتابیس جریانی (Streaming Database) است که با استاندارد PostgreSQL توسعه یافته و از SQL به‌عنوان زبان اصلی پردازش داده‌های جریانی استفاده می‌کند.

📌 ویژگی‌ها و مزایا:

🎯شمارش و پردازش جریانی با SQL ساده → ایجاد Materialized Viewها برای شمارش بازدیدها و اکشن‌ها در لحظه

🎯ذخیره اکشن‌ها در S3 و Iceberg → امکان نگهداری داده‌های خام برای تحلیل‌های آینده

🎯سرعت بالا به لطف Rust → هسته سیستم با زبان Rust نوشته شده و از مزایای کارایی و مصرف کم منابع بهره می‌برد

🎯پشتیبانی از Sinkهای متنوع → خروجی مستقیم به دیتابیس‌ها، سیستم‌های پیام‌رسان، S3، Kafka و...

🎯پردازش رویدادهای پیچیده → اجرای Queryهای تحلیلی پیشرفته بر روی جریان داده بدون نیاز به ابزار جداگانه

✅ نتیجه؟

با RisingWave می‌توان علاوه بر شمارش بازدید و اکشن‌ها، بسیاری از پردازش‌های هم‌زمان و تحلیل‌های اولیه را نیز انجام داد، بدون نیاز به زیرساخت پیچیده و چندلایه.

📌 جمع‌بندی

این سه راهکار نسبت به روش‌های سنتی و حتی رویکرد Kafka + Flink، مدرن‌تر هستند و از فناوری‌های جدید حوزه داده بهره می‌برند.

اگر در حال طراحی یا ارتقای بخش شمارش بازدید و اکشن‌ها هستید، پیشنهاد می‌کنم این گزینه‌ها را نیز بررسی کنید.

#DataEngineering #StreamingData #RealTimeAnalytics #Kafka #Flink #Iceberg #ClickHouse #RisingWave #ScyllaDB #BigData #UserAnalytics #TechInnovation #RustLang #SQL