خلاصه مقاله فوق با تمامی شکل های استفاده شده در مقاله که مفاهیم اصلی کافکا و نحوه کارکرد داخلی آنرا توضیح میدهد.

‍ پروژه آموزشی : ساخت یک سامانه پردازش جریان به کمک ردپاندا، کلیک‌هوس و سوپرست
اخیرا پستی از یکی از دوستان در لینکدین مشاهده کردم که وظیفه خود دانستم آنرا برای علاقه مندان به انجام پروژه های عملی و کاربردی در دنیای مهندسی داده به اشتراک بگذارم.
آدرس پست اصلی : https://lnkd.in/d6i7Eiti

این پست گزارش یک پروژه انجام شده توسط سایه حجازی Saieh Hejazi است. در چند سال گذشته، سایه با پشتکار و علاقه‌ای ستودنی، مسیر حرفه‌ای خود را از حوزه‌ی هوش تجاری (BI) به‌سمت مهندسی داده گسترش داده است. من در طول این مسیر شاهد یادگیری‌های عمیق، پیگیری‌های فنی، و تلاش‌های مستمر او بوده‌ام.

به‌تازگی، سایه یکی از پروژه‌های مهم و واقعی خود را منتشر کرده که واقعاً برای بسیاری از علاقه‌مندان به یادگیری پایپ‌لاین‌های داده‌ای real-time، الهام‌بخش است:

🎯 Build a Real-Time Data Pipeline with Redpanda, ClickHouse, and Superset


پروژه‌ای کامل، کاربردی، و مبتنی بر ابزارهای مدرن و سریع.

🔧 فلو‌ی اصلی پروژه به این صورت است:

📁 منبع داده‌ها به‌شکل فایل‌هایی (مثلاً CSV یا JSON) است که در یک فولدر مشخص قرار می‌گیرند و از طریق FTP Server قابل دسترسی هستند.

🛠 ابزار Redpanda Connect که یک کتابخانه قدرتمند ingestion بدون کدنویسی است، به‌صورت مداوم این پوشه را مانیتور می‌کند. به‌محض ورود فایل جدید، آن را می‌خواند و محتوای آن را به‌صورت یک پیام (event) وارد Redpanda می‌کند.

🧠 این‌جا، #Redis وارد عمل می‌شود: با استفاده از Redis، برای هر فایل ورودی یا رکورد، یک مکانیسم #deduplication پیاده‌سازی شده تا از ورود چندباره‌ی داده‌ها جلوگیری شود. این کار ریسک رکوردهای تکراری را از بین می‌برد و کیفیت داده را در مرحله‌ی ingestion تضمین می‌کند. این کار البته توسط خود ردپاندا کانکت انجام می شود اما تنظیمات لازم برای این منظور باید انجام شود.

🚀 داده‌هایی که وارد Redpanda شده‌اند، به‌کمک Kafka engine در ClickHouse به‌صورت real-time مصرف می‌شوند و مستقیماً وارد یک جدول تحلیلی می‌گردند.

📊 در نهایت، Apache Superset به این جدول در ClickHouse# متصل است و به‌صورت بلادرنگ (real-time) داشبوردهایی از این داده‌ها ایجاد کرده که تحلیل سریع و قابل مشاهده برای کاربر نهایی را ممکن می‌سازد.



🧰 ابزارهای کلیدی مورد استفاده در این پروژه عبارتند از:

👉 #Redpanda: موتور سریع و سبک استریم داده (جایگزین Kafka)

👉 Redpanda Connect (Benthos سابق): ابزار ingestion بدون کدنویسی برای ارسال/دریافت داده با حجم بالا

👉 #Redis: برای deduplication و جلوگیری از ingest دوباره رکوردها

👉 #ClickHouse: پایگاه‌داده ستونی برای ذخیره و تحلیل سریع داده‌ها

👉 Superset: داشبورد تحلیلی متن‌باز برای نمایش داده‌های real-time


📌 تمامی کدها، کانفیگ‌ها و مستندات راه‌اندازی در این ریپوی گیت‌هاب در دسترس هستند:

https://github.com/saiehhejazi/Project_2

برای سایه عزیز آرزوی موفقیت در آغاز یک دوره نوین تخصصی در دنیای مهندسی داده دارم. مطمئنم این پروژه تنها نقطه‌ی شروع برای دستاوردهای بزرگ‌تر و تأثیرگذارتر در آینده‌ی حرفه‌ای او خواهد بود. 🌟

پ.ن:
سایر دوستان هم اگر پروژه هایی مشابه با این را انجام داده اند که بار آموزشی برای علاقه مندان به مهندسی داده دارد، ممنون میشوم آنرا برای ادمین کانال ارسال کنید تا با سایر علاقه مندان به این حوزه هم به اشتراک گذاشته شود.

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

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

‍ مهندسین یا راهی خواهند یافت یا راهی خواهند ساخت — نمونه‌ای واقعی به نام GlassFlow 👷‍♂️

می‌گویند مهندسین یا راهی خواهند یافت یا راهی خواهند ساخت. پروژه GlassFlow دقیقاً مصداق همین جمله است. وقتی با محدودیت‌هایی در ابزارهایی مثل ClickHouse مواجه می‌شویم — ابزارهایی که با تمام قدرت و کارایی‌شان، در معماری و عملکردشان ضعف‌هایی دارند — بعضی از ما به‌جای منتظر ماندن، خودمان دست به کار می‌شویم و راه‌حل می‌سازیم.

✨ گلس‌فلو یکی از همین راه‌حل‌های هوشمندانه است؛ یک ابزار ساده، سبک و تخصصی برای برطرف کردن مشکلات رایج در مسیر داده از Kafka به ClickHouse.


🚨 مشکل از کجا شروع می‌شود؟
کلیک‌هوس یکی از سریع‌ترین پایگاه‌های داده ستونی در دنیاست، اما در دنیای real-time و Kafka ضعف‌هایی دارد (هر چند در نسخه های اخیر خود سعی کرده است که مشکل داده های تکراری در کافکا را با ذخیره آفست آخرین داده درج شده از هر تاپیک کافکا، به نحوی حل کند - البته باید این قابلیت را فعال کنید):


🔁 کافکا بدون deduplication است
→ حذف داده‌های تکراری در Kafka نیاز به کانکتورهای سفارشی و مدیریت state دارد، که پیچیده و شکننده‌اند.
🐢 عملیات FINAL در ClickHouse کند و پرهزینه است
→ اجرای FINAL برای پاک‌سازی داده‌ها منابع زیادی مصرف می‌کند و برای real-time قابل اتکا نیست.
⛔️ کلیک‌هوس برای Joinهای زنده طراحی نشده
→ داده‌های دیررس پشتیبانی نمی‌شوند و اجرای join بهینه نیست.
🧱 فلینک یا Kafka Streams معماری سنگینی دارند
→ پیاده‌سازی و نگهداری آن‌ها زمان‌بر است و نیاز به تیم فنی پیشرفته دارد، مخصوصاً وقتی بخواهیم به ClickHouse متصل شویم.


✅ گلس‌فلو چه راهی ساخته است؟
گلس‌فلو دقیقاً برای این محدودیت‌ها ساخته شده و با راهکارهای ساده ولی عمیق، همه‌ی این چالش‌ها را حل کرده:
🔑 انجام Deduplication با یک کلیک!
→ فقط کلیدهای اولیه را مشخص کنید و GlassFlow به‌صورت خودکار داده‌های تکراری را در بازه ۷ روزه تشخیص داده و حذف می‌کند.
🔗 انجام Joinهای ساده‌شده
→ فقط فیلدهای لازم را مشخص کنید. GlassFlow تمام logic و state را خودش مدیریت می‌کند.
🕓 ورود داده زمان‌محور، اندازه‌محور یا خودکار
→ ingestion بر اساس زمان یا حجم انجام می‌شود؛ کاملاً قابل تنظیم.
🔌 کانکتور Kafka و ClickHouse مدیریت‌شده
→ توسط تیم GlassFlow توسعه داده شده و نیازی به تنظیمات خاص یا نگهداری ندارد.
📈 مقیاس‌پذیری خودکار با افزایش پارتیشن‌ها
→ هرجا نیاز باشد، Workerهای جدید فعال می‌شوند.
🧠 پردازش حالت‌مند (Stateful) با حافظه کم
→ ذخیره و پردازش سریع در حافظه داخلی، بدون نیاز به معماری پیچیده.
🚀 اجرای سبک، معماری serverless
→ بدون Flink یا Kafka Streams هم می‌توانید جریان‌های پرحجم را دقیق و بدون دردسر پردازش کنید.


❤️ چرا باید GlassFlow را جدی گرفت؟
اگر با ClickHouse و Kafka کار می‌کنید، GlassFlow ابزاری است که:
✔️ داده‌ها را قبل از ورود، پاک‌سازی و join می‌کند
✔️ بار روی ClickHouse را کم می‌کند
✔️ نیاز به FINAL و JOINهای گران را حذف می‌کند
✔️ معماری شما را ساده و مقیاس‌پذیر نگه می‌دارد
✔️ و مهم‌تر از همه، در کمترین زمان قابل راه‌اندازی است 🧰⚡️

با Glassflow داده‌ای که وارد ClickHouse می‌شود، از قبل join و deduplicate شده، یعنی ClickHouse شما سبک‌تر، سریع‌تر و دقیق‌تر خواهد بود — بدون نیاز به ترفندهای پیچیده یا عملیات هزینه‌بر داخل پایگاه داده.

گلس‌فلو نشان می‌دهد که با خلاقیت و نوآوری می‌توان بر محدودیت‌های ابزارهای موجود غلبه کرد.این پروژه نه‌تنها مشکلات خاصی را در ClickHouse حل می‌کند، بلکه الگویی برای توسعه‌دهندگان است تا با ایجاد ابزارهای مکمل، کارایی سیستم‌های موجود را افزایش دهند.

glassflow.dev

‍ وقت آن رسیده که از JSON استاندارد یک گام جلوتر برویم!

اگر تاکنون هنگام نوشتن فایل‌های پیکربندی، با محدودیت‌هایی مثل ممنوعیت کامنت، اجبار به دابل‌کوتیشن یا خطاهای ناشی از کاماهای انتهایی مواجه شده‌اید، شاید زمان آن رسیده باشد که با JSON5 آشنا شوید — نسخه‌ای توسعه‌یافته و انسان‌محور از JSON که برای خوانایی و راحتی توسعه‌دهنده طراحی شده است.

🛠 جی‌سان ۵ - JSON5 چه چیزهایی را ممکن می‌کند؟

✅ پشتیبانی از کامنت‌ها

✅ کلیدهای بدون کوتیشن

✅ رشته‌های تکی (Single-quoted strings)

✅ کاماهای پایانی مجاز (Trailing commas)

✅ پشتیبانی از رشته‌های چندخطی

✅ عددهای هگزادسیمال (Hex)

✅ مقادیر ویژه مثل NaN, Infinity, -Infinity, و +Infinity

✅ عدد با علامت مثبت (مثل +42)

✅ فضای بیشتر برای نوشتن تنظیمات قابل‌فهم برای انسان‌ها


🎯 مناسب برای: فایل‌های تنظیمات پروژه، محیط‌های توسعه، ابزارهای داخلی، و هرجا که خوانایی و سادگی اولویت دارد.

🚫 نه‌چندان مناسب برای: تبادل داده با APIها یا ارتباط میان‌سیستمی — جایی که JSON استاندارد با پشتیبانی وسیع، انتخاب امن‌تری است.

👨‍💻 مقاله پیشنهادی برای مطالعه:

“JSON vs. JSON5: More flexible and human-readable configuration files”

✍🏻 نوشته‌ی Tihomir Manushev

📎 https://freedium.cfd/https://medium.com/@tihomir.manushev/json-vs-json5-7753f5060c90

#JSON #JSON5 #ConfigFiles #DeveloperExperience #DX #SoftwareEngineering #WebDev #CleanCode

‍ چرا UUID7 و ULID گزینه‌های بهتری برای کلیدهای اصلی در پایگاه داده هستند؟
در طراحی پایگاه‌های داده، انتخاب نوع شناسه (ID) یکی از تصمیم‌های کلیدی است که می‌تواند تأثیر زیادی بر عملکرد، مقیاس‌پذیری و امنیت سیستم داشته باشد.
در سناریوهایی مثل سیستم‌های توزیع‌شده، APIهای پرترافیک یا صفحات محصول در وب‌سایت‌ها که نیاز به درج سریع داده و جلوگیری از افشای الگوی رکوردها وجود دارد، استفاده از کلیدهای auto-increment معمولاً گزینه مناسبی نیست. چون:
⛔️باعث قفل شدن جدول در شرایط همزمانی بالا می‌شود،
⛔️امکان حدس زدن تعداد یا ترتیب رکوردها را فراهم می‌کند.

💡 راه‌حل سنتی چیست؟
استفاده از UUID (نسخه ۴) به‌عنوان کلید اصلی مزایای خوبی دارد: یکتایی جهانی بدون نیاز به هماهنگی بین سرورها، مناسب برای محیط‌های توزیع‌شده، و جلوگیری از افشای الگوهای داده. اما یک مشکل جدی دارد.
🔍 چرا UUID تصادفی (مثلاً UUIDv4) در دیتابیس‌ها عملکرد خوبی ندارد؟
اکثر پایگاه‌های داده رابطه‌ای مانند PostgreSQL، MySQL و SQL Server برای ایندکس‌گذاری — مخصوصاً روی کلید اصلی — از ساختاری به‌نام B-Tree (Balanced Tree) استفاده می‌کنند.
این ساختار کمک می‌کند:
✳️جستجوی کلیدها با پیچیدگی O(log n) انجام شود (سریع و مقیاس‌پذیر)،
✳️داده‌ها به‌صورت مرتب نگه داشته شوند،
✳️ و درج، حذف یا به‌روزرسانی به‌شکل کارآمد مدیریت شود.
اما مشکل از جایی شروع می‌شود که کلیدهایی با ترتیب تصادفی (مثل UUIDv4) در جدول وارد می‌شوند.

📉 چه اتفاقی می‌افتد؟
وقتی داده‌های زیادی با کلید تصادفی وارد جدول می‌شوند:
⛔️ دیتابیس نمی‌تواند آن‌ها را در انتهای ساختار درختی اضافه کند (مثل auto-increment IDs)،
⛔️ باید آن‌ها را بین صفحات مختلف B-Tree پراکنده کند،
⛔️ این پراکندگی باعث عملیات مکرر Page Split (شکستن صفحات)، جابه‌جایی نودها و بازچینش ساختار درختی می‌شود.

🧨 نتیجه؟
🧱کند شدن محسوس عملیات درج (INSERT)،
🧱 مصرف بالای I/O و حافظه،
🧱 کاهش عملکرد کلی سیستم در سناریوهای پرترافیک.

✅ راه‌حل‌های مدرن: UUID7 و ULID
برای رفع این مشکلات، دو استاندارد جدید معرفی شده‌اند:
🔹 استاندارد ULID (Lexicographically sortable): ترکیبی از timestamp و داده تصادفی
🔹 استاندارد UUIDv7: نسخه‌ای از UUID با ترتیب زمانی، سازگار با استاندارد UUID

مزیت اصلی این دو چیست؟
🔸 با حفظ یکتایی و امنیت، کلیدها به‌صورت ترتیبی در ایندکس درج می‌شوند.
🔸 این یعنی:
✅کاهش شدید Page Split و پراکندگی
✅بهبود درج‌های پرترافیک
✅جست‌وجوی سریع‌تر بر اساس بازه‌های زمانی

📊 چه زمانی از هرکدام استفاده کنیم؟
اگر خوانایی و طول کوتاه‌تر مهم است → ULID
اگر سازگاری با UUID استاندارد اهمیت دارد → UUIDv7

📐 قالب ULID
قالب ULID یک رشته ۲۶ نویسه‌ای است که با Crockford’s Base32 کدگذاری می‌شود (حروف I, L, O, U حذف شده‌اند تا اشتباه نشوند).
→ طول: ۲۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ مثال: 01AN4Z07BY79KA1307SR9X4MV3

📐 قالب UUIDv7
→ نمایش به‌صورت استاندارد UUID در مبنای ۱۶ (hex) با خط تیره
→ طول شامل خط تیره: ۳۶ نویسه - کاراکترهای ابتدایی مهرزمان هستند.
→ قالب: 8-4-4-4-12
→ مثال: 017f45e0-7e1a-7a3f-8bbc-4dbf7e6d9c3a
→ طول بدون خط تیره: ۳۲ نویسه hex

بنابراین UUID7 طول بیشتری نسبت به ULID دارد اما چون با استاندارد UUID سازگاراست، برای سیستم‌های موجود گزینه بهتری است.

#Database #Backend #DistributedSystems #UUID #ULID #PostgreSQL #SystemDesign #Performance #مهندسی_داده

شرکت DoorDash چگونه پلتفرم پردازش بلادرنگ خود را با Iceberg متحول کرد؟

شرکت DoorDash برای پردازش رویدادهای بلادرنگ خودش، یک پلتفرم استریم داخلی توسعه داده که امکان تصمیم‌گیری سریع و هوشمند را برای تیم‌های تجاری فراهم می‌کند.
در ساعات اوج فعالیت، این پلتفرم با حجم بالایی از داده روبه‌رو می‌شود — بیش از ۳۰ میلیون پیام در هر ثانیه، معادل حدود ۵ گیگابایت داده در ثانیه که از سمت مشتریان، رانندگان (Dashers)، فروشندگان و اپلیکیشن‌های داخلی DoorDash ارسال می‌شود.

ساختار اولیه به این صورت بود:
🧱دریافت و بافر داده‌ها با Kafka
🧱پردازش با Apache Flink
🧱ذخیره در Amazon S3
🧱 در نهایت، انتقال داده‌ها به Snowflake از طریق یک پایپ‌لاین به نام Snowpie

اما این معماری در عمل با چند مشکل جدی مواجه شد:
⛔️هزینه‌های بالای Snowflake
⛔️دوبار نوشتن داده‌ها (هم در S3 و هم در Snowflake)
⛔️وابستگی به یک فروشنده خاص ( Snowflake)

برای حل این چالش‌ها، DoorDash تصمیم گرفت به سراغ Apache Iceberg برود تا زیرساخت داده‌ای بلادرنگ خود را بازطراحی کند؛ راه‌حلی متن‌باز، مقیاس‌پذیر و مستقل از فروشنده.
خلاصه آنرا در PDF الصاق شده مشاهده کنید👆

‍ اوج بلوغ تیم‌های مهندسی داده: محیط Staging و چک‌لیست تغییرات دیتابیس 🔴

وقتی یه دستور ساده می‌تونه کل سیستم رو بخوابونه!

چند روز پیش یکی از دوستان تماس گرفت و گفت روی یک جدول بزرگ در ClickHouse دستور OPTIMIZE FINAL زده. جدول مربوط به دیتای اصلی سیستمشون بوده و چند میلیارد رکورد داشته. نتیجه؟ تمام CPUها پر شدن، کوئری‌های عادی از کار افتادن و سیستم عملاً فلج شده. 🧨

اتفاقی که شاید برای خیلی از ما آشنا باشه. ولی پشت این اتفاق، یک نکته خیلی مهم هست:

🧑‍💻 ما باید عادت کنیم مثل مهندسان نرم‌افزار، محیط‌های جدا برای تست و اجرا داشته باشیم.

🚫 داده‌های حساس و عملیاتی هیچ‌وقت نباید محل آزمایش باشن.


اینا چند تا نکته‌ کلیدی هستن که هر مهندس داده باید رعایت کنه:

🔹 محیط staging جداگانه داشته باشیم که شبیه production باشه (نه لزوماً با همون حجم دیتا)

🔹 دیتا رو نمونه‌گیری (sample) کنیم و روی کپی‌ها تست کنیم، نه روی دیتای اصلی

🔹 دستورات سنگین مثل OPTIMIZE, VACUUM, یا REINDEX رو اول روی محیط تست اجرا کنیم

🔹 حتماً از ابزارهای مانیتورینگ، لاگ‌گیری و EXPLAIN استفاده کنیم قبل از اجرای کوئری‌های پرهزینه 📊



✨ جادوی چک‌لیست 📝

قبل از اجرای هر عملیات دیتابیسی سنگین، باید یه چک‌لیست ساده ولی جدی داشته باشیم:

✅ تست انجام شده؟

✅ دیتای درگیر چقدره؟

✅ منابع مورد نیاز؟

✅ توقف اضطراری یا rollback چطوریه؟

✅ مانیتور فعال هست؟

✅ روی staging امتحان شده؟

چک‌لیست‌ها نه فقط جلوی اشتباهات انسانی رو می‌گیرن، بلکه فرهنگ مسئولیت‌پذیری، نظم و آرامش به تیم می‌دن. 🧠

حتی برای بدترین سناریوها، اگر از قبل فکر شده باشه، می‌شه از فاجعه جلوگیری کرد. 🚨

چک‌لیست‌ها تو مهندسی داده جادو می‌کنن.

#مهندسی_داده #DataEngineering #ClickHouse #StagingMatters #ChecklistMagic #DatabaseOps #ProductionReady

شرکت OpenAI چگونه کلاستر های کافکای خود را پایدار کرد و توان عملیاتی خود را ۲۰ برابر کرد؟ 🚀

در یک سال گذشته، OpenAI توان عملیاتی Kafka را در بیش از ۳۰ خوشه، بیست برابر افزایش داد و به پایداری خیره‌کننده ۹۹.۹۹۹٪ (پنج ۹) دست یافت.  در ادامه، به سه بخش کلیدی این تحول می‌پردازیم:

🟩 ۱. گروه‌بندی خوشه‌ها (Cluster Groups)

چالش: با بیش از ۳۰ خوشه Kafka در محیط‌های متفاوت (هر کدام با تنظیمات مخصوص، احراز هویت‌های پراکنده و قوانین فایروال خاص خود)، استفاده از سیستم بسیار پیچیده شده بود. کاربران نمی‌دانستند برای ذخیره یا خواندن داده باید به کدام خوشه متصل شوند و سؤالات مکرری مثل «تاپیک X کجاست؟» زمان توسعه را تلف می‌کرد. اگر یکی از خوشه‌ها از کار می‌افتاد، کاربران باید به‌صورت دستی به خوشه دیگری مهاجرت می‌کردند، که هم وقت‌گیر بود و هم مستعد خطا.

راه‌حل: OpenAI خوشه‌ها را به شکل گروه‌های خوشه‌ای درآورد؛ یعنی مجموعه‌ای از خوشه‌ها که در یک منطقه جغرافیایی قرار دارند (مثلاً آمریکا یا اروپا) و با هم یک گروه منطقی را تشکیل می‌دهند. کاربران حالا با «تاپیک‌های منطقی» کار می‌کنند که به‌صورت خودکار به تاپیک‌های فیزیکی در خوشه‌های مختلف همان گروه متصل می‌شوند. این ساختار، زیرساخت پیچیده را از دید کاربران پنهان می‌کند و در صورت خرابی یک خوشه، خوشه‌های دیگر گروه جایگزین می‌شوند.

🟨 ۲. پراکسی تولیدکننده : Prism

چالش: پیش از این، هر اپلیکیشنی که داده تولید می‌کرد، مستقیماً به Kafka متصل می‌شد. این مدل باعث ایجاد تا ۵۰ هزار اتصال همزمان به هر بروکر می‌شد که منجر به مصرف شدید حافظه و کاهش پایداری می‌گردید. همچنین، توسعه‌دهندگان باید تنظیمات پیچیده‌ای مانند لیست بروکرها، پورت‌ها، و احراز هویت را به‌صورت دستی انجام می‌دادند. اگر یک خوشه از دسترس خارج می‌شد، برنامه‌ها باید دستی به خوشه دیگری متصل می‌شدند، که منجر به خطا و قطعی می‌شد.

راه‌حل: OpenAI یک پراکسی به نام Prism ایجاد کرد که با استفاده از gRPC به‌عنوان واسط ارتباطی، پیچیدگی Kafka را از کاربران پنهان می‌سازد. برنامه‌ها فقط داده را به Prism می‌فرستند و Prism مسئول هدایت آن به بروکرهای مناسب است. در صورت خرابی یک خوشه، داده‌ها به‌طور خودکار به خوشه‌های دیگر گروه ارسال می‌شود.

🟧 ۳. پراکسی مصرف‌کننده : uForwarder

چالش: مصرف‌کنندگان Kafka هم با مشکلاتی مشابه روبه‌رو بودند. برنامه‌ها باید به‌صورت دستی تنظیمات Kafka، انتخاب خوشه، مدیریت offset و احراز هویت را انجام می‌دادند. این فرآیند زمان‌بر و مستعد خطا بود. از طرف دیگر، مدل pull سنتی Kafka برای خواندن داده‌ها، موجب تأخیر و محدودیت در مصرف همزمان می‌شد. در صورت خرابی خوشه‌ها، اتصال مجدد مصرف‌کنندگان به صورت دستی نیاز بود، که کارآمد نبود.

راه‌حل: OpenAI از uForwarder (یک پروژه متن‌باز از Uber) بهره گرفت که مدل مصرف را از pull به push تغییر می‌دهد. در این مدل، uForwarder خودش داده‌ها را از Kafka دریافت کرده و به اپلیکیشن‌ها تحویل می‌دهد. این پراکسی ویژگی‌های پیشرفته‌ای دارد مثل: بازارسال خودکار، صف پیام‌های ناموفق (DLQ)، مصرف همزمان از چند خوشه، و موازی‌سازی پیشرفته. همچنین از مشکلاتی مثل Head-of-Line Blocking جلوگیری می‌کند.

نتیجه: مصرف‌کنندگان می‌توانند بدون دانش خاصی از Kafka داده‌ها را دریافت کنند؛ توسعه آسان‌تر، پایداری بالاتر و عملکرد مقیاس‌پذیرتر حاصل شد.

منبع:
https://lnkd.in/dVpS5ZaD

https://virgool.io/divarengineering/-bhwoaodprld6
سفر تکامل نقشه‌ی دیوار: داستان مهندسی پشت نمایش هوشمند میلیون‌ها آگهی
وقتی به دنبال خانه یا ملک می‌گردید، «کجا بودن» آن شاید اولین و مهم‌ترین سؤالی باشد که به ذهنتان می‌رسد. در پلتفرمی مثل دیوار که روزانه هزاران آگهی املاک در آن ثبت می‌شود، نمایش این حجم از اطلاعات مکانی به شکلی کارآمد و قابل فهم، یک چالش بزرگ است. ما در دیوار مسیری پر فراز و نشیب را برای بهبود نمایش آگهی‌ها روی نقشه طی کرده‌ایم؛ از نمایش ساده‌ی نقطه‌ای تا سیستم‌های هوشمند کلاستربندی داینامیک. این مقاله داستان این تکامل فنی و تصمیم‌هایی است که در این راه گرفته‌ایم. هدف ما نه تنها ارائه‌ی یک تجربه‌ی کاربری روان، بلکه ساخت زیرساختی پایدار و مقیاس‌پذیر برای آینده‌ی نقشه‌ی دیوار بوده است.
——-
این مقاله خواندنی را از آدرس بالا مطالعه کنید .

‍ معرفی افزونه رسمی PostgreSQL برای Visual Studio Code — توسط مایکروسافت 🐘
🔔 مناسب برای توسعه‌دهندگان، مهندسان داده، و همه‌ی علاقه‌مندان به PostgreSQL

مایکروسافت به‌تازگی نسخه‌ی پیش‌نمایش افزونه رسمی PostgreSQL برای VS Code را منتشر کرده است. این افزونه با هدف ساده‌سازی تجربه کار با PostgreSQL در محیط VS Code طراحی شده و تلاش می‌کند فرایندهایی مانند نوشتن، اجرای کوئری، مشاهده ساختار دیتابیس، و حتی رفع باگ را برای کاربران ساده‌تر، هوشمندتر و سریع‌تر کند.

📊 زمینه‌سازی و ضرورت این ابزار:
بر اساس نظرسنجی‌های توسعه‌دهندگان (StackOverflow، GitHub، Stripe Atlas Reports)، بیش از نیمی از زمان کاری توسعه‌دهندگان صرف کارهای تکراری یا تغییر کانتکست بین ابزارهای مختلف (IDE، PgAdmin، ترمینال، ابزارهای مانیتورینگ و...) می‌شود. افزونه جدید PostgreSQL با هدف رفع این چالش‌ها، یک محیط یکپارچه و هوشمند در خود VS Code فراهم می‌کند.

🎯 قابلیت‌های کلیدی این افزونه:

1. 🧠 پشتیبانی از GitHub Copilot با دستور @pgsql
✨افزونه به‌صورت کامل با GitHub Copilot مجتمع شده است و از دستورات مخصوص @pgsql پشتیبانی می‌کند:
✨نوشتن و بازنویسی کوئری‌های SQL با زبان طبیعی (انگلیسی)
✨دریافت پیشنهادات بهینه‌سازی کوئری
✨توضیح عملکرد کوئری‌های پیچیده
✨تولید کوئری‌های چندمرحله‌ای: مثلاً "یک دیتابیس بساز، جدول بساز، PostGIS فعال کن، داده درج کن"
✨استفاده از حالت "Chat Agent" برای تعامل طبیعی‌تر با Copilot به‌صورت گفت‌وگویی

2. 📜 تاریخچه کامل کوئری‌ها (Query History)
یکی از ویژگی‌های بسیار مفید این افزونه، ثبت خودکار تاریخچه تمام کوئری‌های اجراشده است. می‌توانید به‌راحتی کوئری‌های قبلی را مرور، ویرایش، یا دوباره اجرا کنید. حتی پس از بستن و باز کردن مجدد VS Code، تاریخچه کوئری‌ها حفظ می‌شود.

3. 🧭 مرورگر دیتابیس (Database Explorer)
این قابلیت به شما اجازه می‌دهد ساختار دیتابیس (جداول، ویوها، ایندکس‌ها، توابع و ...) را به‌صورت گرافیکی مرور کرده و بدون نیاز به نوشتن کوئری، عملیات‌هایی مانند ایجاد، ویرایش یا حذف انجام دهید.

4. 🧾 هوش مصنوعی در نوشتن SQL (SQL IntelliSense)
✨تکمیل خودکار اسامی جداول و ستون‌ها
✨نمایش خطاهای سینتکسی حین نوشتن
✨فرمت خودکار کوئری‌ها (با قابلیت شخصی‌سازی)
✨پشتیبانی از توضیح خط به خط کوئری‌ها با استفاده از Copilot

5. 🗺 نمایش گرافیکی جداول
با یک کلیک می‌توانید ساختار دیتابیس را به‌صورت گرافیکی (ERD) مشاهده کرده و روابط بین جداول را تحلیل کنید.

6. 🔐 احراز هویت ایمن
اگر از Azure Database for PostgreSQL استفاده می‌کنید، امکان احراز هویت با Azure Entra ID (بدون نیاز به ذخیره پسورد) فراهم شده است — مناسب برای سازمان‌هایی با الزامات امنیتی خاص.

7. 🔄 مدیریت چندین اتصال (Multi-Profile)
می‌توانید چندین پروفایل اتصال (مثلاً PostgreSQL روی لوکال، Docker، Cloud) تعریف کرده و به‌راحتی بین آن‌ها سوییچ کنید. حتی امکان اتصال مستقیم به دیتابیس‌های Azure از طریق "Browse Azure" نیز فراهم است.

📦 نحوه نصب افزونه :

افزونه PostgreSQL را سرچ کرده، افزونه آبی رنگ و مدرنی که متعلق به مایکروسافت هست را نصب کنید.

✨ افزونه GitHub Copilot را نیز فعال کنید تا از ویژگی‌های @pgsql بهره ببرید


📘 مستندات کامل: https://techcommunity.microsoft.com/blog/adforpostgresql/announcing-a-new-ide-for-postgresql-in-vs-code-from-microsoft/4414648

‍ معرفی DuckLake: ساده‌سازی Lakehouse با قدرت SQL

🔍 فرض کنید می‌خواهیم رفتار کاربران روی یک فروشگاه آنلاین را تحلیل کنیم. آمار کلی مثل نرخ کلیک، نرخ تبدیل و زمان حضور را در پایگاه‌داده ذخیره می‌کنیم — اما داده‌های ریز و حجیم مثل تک‌تک کلیک‌های کاربران روی محصولات را به صورت خام ذخیره می‌کنیم، بدون اینکه دیتابیس‌های عملیاتی را سنگین کنیم. این داده‌های خام به شکلی بهینه ذخیره می‌شوند که هر زمان نیاز داشتیم بتوانیم روی آن‌ها کوئری اجرا کنیم و تحلیل عمیق‌تری داشته باشیم.

🧠 این همان فلسفه‌ی #Lakehouse است:

ترکیب بهترین ویژگی‌های Data Lake (انعطاف و مقیاس‌پذیری) و Data #Warehouse (ساختارمندی و قابلیت تحلیل)

اما واقعیت این است که #Lakehouse ها در عمل با پیچیدگی‌هایی همراه هستند:
برای هر جدول، باید اطلاعاتی مانند schema، نسخه‌ها، تغییرات، پارتیشن‌بندی و ... در فراداده‌ها نگه داشته شود. این یعنی نیاز به سیستم‌های اضافی کاتالوگ‌ها، متادیتا‌ها و گاهی سرویس‌‌های اضافی برای مدیریت نسخه‌ها

اما : چرا وقتی به هر حال به یک دیتابیس نیاز داریم (برای کاتالوگ)، از ابتدا همه چیز را در SQL مدیریت نکنیم؟

📢 امروز #DuckDB با معرفی #DuckLake، پاسخی جسورانه و منطقی به این سوال داده است.

✅ اما سوال اصلی : DuckLake چیست؟

استاندارد DuckLake یک فرمت Open Table جدید برای معماری Lakehouse است که:

داده‌ها را در قالب‌های باز مانند Parquet در Blob Storage ذخیره می‌کند؛

اما تمام فراداده‌ها (metadata)، snapshotها، schemaها و آمار را در یک پایگاه داده SQL ساده (مثل PostgreSQL یا خود DuckDB) مدیریت می‌کند.

🔍 چرا DuckLake یک تغییر بنیادین است؟

1. سادگی واقعی

برخلاف Iceberg و Delta که برای یک append ساده، باید چندین فایل JSON و Avro ایجاد یا به‌روز کرد، در DuckLake همه چیز فقط چند query ساده SQL است.
نیازی به لایه‌ی اضافه‌ی catalog server یا فایل‌های اضافی نیست. فقط یک دیتابیس و فایل‌های Parquet.

2. مدیریت تراکنش‌پذیر (ACID) واقعی

تغییرات در جدول‌ها، snapshotها و آمار ستون‌ها در یک تراکنش واحد SQL انجام می‌شود. این یعنی:
📌atomic commitها؛
📌پشتیبانی از تغییرات پیچیده و multi-table؛
📌 بدون ترس از ناسازگاری فایل‌ها در blob storage.

3. سازگاری، مقیاس‌پذیری و سرعت
می‌توانید DuckLake را با DuckDB روی لپ‌تاپ اجرا کنید یا با PostgreSQL روی کلاود.
برخلاف ساختارهای فایل‌محور، پردازش‌ها سریع‌تر، قابل کش‌شدن و قابل مشاهده‌اند.
محدود به هیچ vendor خاصی نیستید؛ جابه‌جایی آسان است.

🏗 یک نگاه به معماری DuckLake:

📁 داده‌ها → Parquet روی S3 یا هر blob store

📚 فراداده → SQL Tables روی DuckDB/PostgreSQL/...

🔁 عملیات → فقط SQL transactions ساده با DuckDB

🧠 چرا مهم است؟

در حالی که بسیاری از معماری‌های داده در مسیر «Lakehouse» پیچیدگی‌های جدیدی اضافه می‌کنند، DuckLake مسیر را به عقب برمی‌گرداند و از یک حقیقت ساده دفاع می‌کند:

وقتی که به هر حال از یک دیتابیس استفاده می‌کنیم، چرا بقیه‌ی بخش‌ها را هم در همان قالب SQL مدیریت نکنیم؟

📌 نتیجه‌گیری

استاندارد DuckLake نه فقط یک فرمت جدید، بلکه بازاندیشی دوباره‌ای است در طراحی Lakehouse — مبتنی بر اصل «سادگی، مقیاس‌پذیری، سرعت». اگر به دنبال آینده‌ای پایدارتر، قابل نگهداری‌تر و بدون vendor lock-in برای lakehouse هستید، DuckLake را جدی بگیرید.

📎 مطالعه‌ی کامل مقاله: https://duckdb.org/2025/05/27/ducklake.html

#DuckDB #DuckLake #DataEngineering #Lakehouse #OpenFormats #SQL #Parquet #PostgreSQL

‍ معرفی Supabase: فراتر از یک پایگاه داده؛ جعبه‌ابزاری کامل برای توسعه اپلیکیشن‌ها

در یکی دو سال اخیر، نام Supabase بارها به گوشم خورده بود.

در ابتدا تصور می‌کردم با یک سرویس آنلاین برای میزبانی #PostgreSQL طرف هستیم؛ یک دیتابیس ساده و کاربردی برای مدیریت داده.

اما وقتی کنجکاو شدم و بررسی بیشتری انجام دادم، متوجه شدم ماجرا بسیار فراتر از یک پایگاه داده است.

🧰 سوپابیس در واقع یک چارچوب متن‌باز و یکپارچه برای توسعه سریع اپلیکیشن‌هاست؛ ابزاری که تمامی نیازهای بک‌اند، از دیتابیس گرفته تا API و احراز هویت و ذخیره فایل را به‌صورت آماده در اختیار توسعه‌دهندگان قرار می‌دهد.

📦 همین جامع‌بودن و سادگی استفاده، مخصوصاً برای تیم‌های کوچک یا استارتاپ‌هایی که در حال تبدیل ایده به محصول هستند، باعث شد تصمیم بگیرم تجربه‌ام را از کشف این ابزار و همچنین داستان شکل‌گیری آن، با شما به اشتراک بگذارم—به‌ویژه حالا که #Supabase با جذب ۲۰۰ میلیون دلار سرمایه در آوریل ۲۰۲۵، به ارزش‌گذاری ۲ میلیارد دلاری رسیده است.



💡 نقطه شروع: وقتی یک ایده جذاب دارید...

✨ فرض کنید یک ایده خلاقانه برای اپلیکیشن در ذهن دارید.

با کمک ابزارهای طراحی یا همکاری با یک توسعه‌دهنده فرانت‌اند، رابط کاربری را به‌سرعت می‌سازید.

اما به‌محض اینکه به بخش بک‌اند می‌رسید، چالش‌های واقعی آغاز می‌شوند:

🚫 طراحی دیتابیس، نوشتن APIها، پیاده‌سازی احراز هویت، مدیریت فایل‌ها و...

⚙️ در این شرایط، #Supabase مانند یک راه‌حل آماده و قابل‌اعتماد و سریع وارد میدان می‌شود.

اصلا شعار این پلتفرم هم همین است : «در یک آخر هفته بساز؛ برای میلیون‌ها کاربر آماده شو.»



🧬 سوپابیس چگونه متولد شد؟

سوپابیس در سال ۲۰۲۰ توسط Paul Copplestone و Ant Wilson تأسیس شد؛

دو توسعه‌دهنده که از ساخت مکرر بک‌اندهای تکراری و زمان‌بر خسته شده بودند.

🔥 در آن زمان Firebase محصول مطرحی بود، اما به دلیل ساختار بسته‌اش، گزینه جذابی برای جامعه متن‌باز محسوب نمی‌شد.

🔓 ایده Supabase: نسخه‌ای متن‌باز از Firebase، با تکیه بر قدرت PostgreSQL 💪



🛠 چه امکاناتی Supabase را متمایز می‌کند؟

Supabase یک جعبه‌ابزار کامل برای توسعه‌ی بک‌اند است، شامل:

✅ پستگرس قدرتمند (با JSONB، جست‌وجوی متنی و اکستنشن‌ها)

✅ داشتن APIهای خودکار (REST و GraphQL)

✅ سیستم احراز هویت یکپارچه (ورود با Google، GitHub و...)

✅ فضای ذخیره‌سازی فایل امن و مقیاس‌پذیر

✅ پشتیبانی از داده‌های بلادرنگ (Realtime)

✅ رابط گرافیکی برای مدیریت داده‌ها

✅ توابع لبه Edge Functions و replication در مقیاس جهانی

✅ کاملاً متن‌باز و قابل‌نصب روی هر سروری



🌍 چرا Supabase تا این حد محبوب شده است؟

📊 بیش از ۲ میلیون توسعه‌دهنده در حال استفاده

📦 بیش از ۳.۵ میلیون دیتابیس فعال

🏢 استفاده توسط شرکت‌هایی مثل Mozilla، GitHub، OpenAI



✨ دلایل محبوبیت:

⚡️ راه‌اندازی سریع

🌱 جامعه بزرگ متن‌باز (۸۰K+ ستاره در GitHub)

🧠 سازگاری با نیازهای AI و داده‌های برداری

💸 حمایت سرمایه‌گذاران معتبر (Y Combinator, Accel و...)



🤖 سوپابیس و آینده هوش مصنوعی

سوپابیس در حال آماده‌سازی زیرساختی مناسب برای نسل بعدی اپلیکیشن‌های AI است:

🧠 توابع لبه - Edge Functions

🕒 زمان‌بندی با Cron

🧭 جست‌وجوی برداری


🧩 سخن آخر : قدرت متن‌باز در برابر غول‌ها

💥 رسیدن به ارزش ۲ میلیارد دلاری فقط در چند سال نشان می‌دهد که قدرت جامعه و ابزارهای بازمتن در حال شکل‌دادن به آینده توسعه بک‌اند هستند.

مخزن کد پروژه : https://lnkd.in/gpdbXFWv

مرتبط با پست بالا 👆👆👆

چگونه با ClickHouse زیرساخت کمپین بازاریابی شخصی‌سازی‌شده اسنپ! مارکت را طراحی کردیم؟ 🎯

این مقاله ترجمه ای است از :

https://medium.com/@prmbas/clickhouse-in-the-wild-an-odyssey-through-our-data-driven-marketing-campaign-in-q-commerce-93c2a2404a39

در جریان طراحی و اجرای کمپین «سوپرسنج» در اسنپ! مارکت، هدف ما خلق تجربه‌ای متفاوت و هوشمندانه برای میلیون‌ها کاربر بود؛ تجربه‌ای که با تحلیل رفتار خرید واقعی مشتریان و بهره‌گیری از الگوریتم‌های یادگیری ماشین و هوش مصنوعی، به‌شکل شخصی و سرگرم‌کننده ارائه می‌شد.

برای رسیدن به این هدف، طراحی یک زیرساخت داده‌ای مقیاس‌پذیر و تحلیلی ضروری بود؛ زیرساختی که بتواند حجم بالایی از داده‌های سفارش، محصول، رفتار مشتری و تعاملات کمپین را در زمان محدود پردازش کند. ما تصمیم گرفتیم از #ClickHouse به‌عنوان موتور پردازش تحلیلی اصلی استفاده کنیم.

📦 کمپین سوپرسنج: شخصیت خرید شما چیست؟

سوپرسنج یک کمپین خلاقانه و داده‌محور بود که با الهام از تست‌های #MBTI، پرتره‌ای طنز و شخصی‌سازی‌شده از کاربران اسنپ! مارکت ارائه می‌داد. این پرتره با تحلیل واقعی رفتار خرید مشتریان و به‌کمک هوش مصنوعی تولید می‌شد.

اجزای اصلی کمپین:

🧑‍💼 پروفایل شخصی: آمارهایی مثل تاریخ اولین سفارش، مجموع کوپن‌های استفاده‌شده و مسافت طی‌شده توسط پیک‌ها

🧠 تست شخصیت خرید: تخصیص تیپ‌های شخصیتی بر اساس رفتار خرید (مثلاً «تنقلاتی راحت‌طلب» یا «قهوه‌دوست اقتصادی»)

🤖 محتوای طنز با هوش مصنوعی: تولید دیالوگ و داستان کوتاه بر اساس داده‌های مشتری، با استفاده از LLMها


🔧 ساختار فنی: معماری چندلایه پردازش داده

برای پشتیبانی از چنین تجربه‌ای، ما لایه‌های مختلفی از پردازش داده را در نظر گرفتیم:

🟫 لایه برنز : داده‌های خام شامل سفارش‌ها، اطلاعات کاربران، و متادیتاهای مربوط به محصولات در بازه‌ای چهارساله

🟪 لایه نقره: پردازش‌های تحلیلی میانی با استفاده از SQL و Python، ذخیره‌شده به‌شکل فایل‌های Parquet

🟨 لایه طلا : خروجی نهایی شامل برچسب‌های شخصیتی، آمار اختصاصی، و JSONهایی که به مدل‌های زبانی برای تولید متن تزریق می‌شد

⚠️ چالش فنی: جوین‌های سنگین و مصرف بالای حافظه

در مراحل اولیه، از الگوریتم پیش‌فرض Join در ClickHouse استفاده کردیم. اما با رشد داده‌ها و افزایش پیچیدگی کوئری‌ها، مصرف حافظه سر به فلک کشید و در مواردی منجر به کرش شد.

برای حل این مشکل، با بررسی دقیق مستندات ClickHouse و رفتارهای کوئری، به الگوریتم partial_merge مهاجرت کردیم.

‍‍‍-- changing join algorithm in the current CLI session
SET join_algortim = 'partial_merge';

-- data easlity stored in a parquet file
-- default path: /var/lib/clickhouse/user_files
INSERT INTO FUNCTION file('temp_data.parquet', Parquet)
SELECT *
FROM [db1].[table1] AS t1
LEFT JOIN [db2].[table2] AS t2 ON t1.[column1] = t2.[column2];

✅ نتیجه:

💥پایداری بیشتر در کوئری‌های سنگین

💥کاهش چشمگیر استفاده از RAM

💥حذف نیاز به ایجاد جداول staging برای ترکیب داده‌ها


🚀 قابلیت‌های ویژه ClickHouse که بهره‌برداری کردیم:

🌱 خواندن مستقیم فایل‌های Parquet از مسیرهای محلی و شبکه‌ای

🌱 توابع تحلیلی سطح بالا مانند argMax, groupArray, corr, toStartOfInterval

🌱 پشتیبانی بومی از JSON و آرایه‌ها برای ذخیره داده‌های ساخت‌یافته در فرمت نیمه‌ساخت‌یافته

🌱 اتصال Real-time به داشبورد Grafana برای مشاهده نتایج و رفتار کمپین در زمان اجرا

📈 نتیجه نهایی

کمپین سوپرسنج با مشارکت بیش از ۱۰۰ هزار کاربر در مدتی کوتاه، به‌عنوان یکی از موفق‌ترین کمپین‌های داده‌محور در صنعت تجارت الکترونیک ایران شناخته شد. این موفقیت تنها به دلیل طراحی خلاقانه و محتوای طنز نبود؛ بلکه به لطف یک زیرساخت داده‌ای دقیق، سریع، و بومی‌سازی‌شده به دست آمد — زیرساختی که علی‌رغم نبود زیرساخت‌های ابری بین‌المللی، بر پایه ابزارهای متن‌باز مانند ClickHouse توسعه یافت و در مقیاس وسیع به‌کار گرفته شد.

‍ اگر #SQLite با فضای ابری ترکیب می‌شد چه می‌شد؟

تصور کنید مثل همیشه می‌خواهید سریع یک ایده را پیاده کنید. مثلاً یک اپ ساده که قیمت گوشی‌ها یا لپ‌تاپ‌ها را از سایت‌هایی مثل دیجی‌کالا، ترب و زومیت جمع می‌کند، تحلیل‌هایی انجام می‌دهد (مثل ارزان‌ترین فروشنده یا نمودار تغییرات قیمت در یک ماه گذشته) و نتایج را در یک رابط وب یا اپلیکیشن موبایل ساده نمایش می‌دهد.

خب طبیعتاً در مراحل اولیه، هیچ‌کس نمی‌خواهد دردسر راه‌اندازی پایگاه داده سنگین مثل PostgreSQL، MongoDB یا مدیریت یک REST API کامل را به جان بخرد. ترجیح می‌دهید همه‌چیز ساده باشد؛ دقیقاً مثل تجربه کار با #SQLite: یک فایل دیتابیس کنار برنامه، بدون نیاز به سرور، بدون کانفیگ پیچیده.

اما یک مشکل هست: اگر بخواهید چند برنامه (مثل یک crawler، یک سرویس API ساده، و یک رابط کاربری React) همزمان از همان دیتابیس استفاده کنند، دیگر فایل لوکال #SQLite کافی نیست. چون این فایل فقط در یک جاست — روی دیسک محلی. پس یا باید سرور راه بیندازید، یا دنبال راهی باشید که این فایل دیتابیس لوکال، روی فضای ابری باشد و همه‌ اپ‌ها انگار از همان فایل مشترک می‌خوانند.

🎯 اینجاست که #SlateDB وارد می‌شود.

📦 دیتابیس #SlateDB: دیتابیس تعبیه‌شده بدون دیسک، نوشته‌شده با Rust . این دیتابیس مثل SQLite ساده و سبک است، اما با یک تفاوت مهم:

📂 به جای نوشتن روی دیسک، همه‌چیز مستقیماً روی فضای ابری مثل Amazon S3 یا سرویس‌های داخلی مثل پارس‌پک، آروان‌کلاد یا ستون ذخیره می‌شود.

💡 یعنی برنامه شما همچنان مثل SQLite ساده و سریع است، ولی انگار همه‌ اپ‌ها به یک دیتابیس مشترک روی ابر وصل‌اند.

🔍 برگردیم به مثال: تحلیل قیمت گوشی‌ها در بازار ایران - با SlateDB:

✅نیازی به پایگاه‌داده مرکزی ندارید.

✅کراولر فقط داده‌ها را در #SlateDB ذخیره می‌کند.

✅همه اپ‌ها همزمان از همان #SlateDB - یعنی همان فضای استوریج، داده‌ها را می‌خوانند.

✅اگر Crawler یا اپ‌ها روی سرورهای مختلف باشند، فقط کافی است دسترسی به S3 مشترک داشته باشند.

✅بدون نیاز به تعریف API پیچیده یا سرور مرکزی.


🚀 چرا SlateDB انتخاب خوبی است؟

✅ سادگی: مثل SQLite، می‌توانید آن را مستقیماً داخل برنامه (embed) کنید.

📦 مقیاس‌پذیری: با تکیه بر #ObjectStorage، نیاز به شارد یا ریپلیکیشن ندارید؛ خود فضا مقیاس‌پذیر است.

🧩 بدون نیاز به سرور: دیگر لازم نیست دیتابیس جداگانه راه‌اندازی و مدیریت کنید.

👥 پشتیبانی از خوانندگان متعدد: چند اپ یا سرویس می‌توانند همزمان بدون مشکل داده‌ها را بخوانند.


💡 معماری بدون دیسک: آینده دیتابیس‌های سبک و ابری

در الگوی #ZeroDiskArchitecture، برنامه‌ها دیگر نیازی به دیسک محلی ندارند و مستقیماً داده‌ها را روی فضاهای ابری مانند S3 می‌نویسند. این رویکرد با حذف پیچیدگی سرورها، راهی ساده، مقیاس‌پذیر و مقرون‌به‌صرفه برای ساخت اپ‌های serverless، edge-based، و مخصوصاً crawlerهای توزیع‌شده و IoT ارائه می‌دهد.

🎯 دیتابیس#SlateDB نمونه‌ای عملی از این ترند است — دیتابیسی سبک و بدون سرور که مانند SQLite در برنامه embed می‌شود، اما داده‌ها را روی فضای ابری نگه می‌دارد.

⚠️ محدودیت‌های SlateDB

🖊 تک‌نویسنده: فقط یک نویسنده همزمان مجاز است؛ برای نوشتارهای موازی، باید از صف پیام یا پارتیشن‌بندی استفاده شود.

🐢 تأخیر نوشتن: latency نوشتن به دلیل استفاده از Object Storage بین ۵۰ تا ۱۰۰ میلی‌ثانیه است.

🔒 نبود تراکنش (فعلاً): قابلیت‌هایی مثل snapshot isolation هنوز در حال توسعه هستند.