OLTP در برابر OLAP و دنیای داده تحلیلی — طراحی سیستم نرم‌افزاری

دیتابیس اصلی تو برای «ثبت سفارش» ساخته شده، نه برای «مجموع فروش هر شهر در ۹۰ روز گذشته». این دو الگوی دسترسی آن‌قدر متفاوت‌اند که دو خانواده متفاوت تکنولوژی ساخته‌اند: OLTP سطرمحور برای تراکنش، OLAP ستون‌محور برای تحلیل.

	OLTP	OLAP
کوئری نمونه	«سفارش ۸۱۲۳ را بده»، «موجودی را کم کن»	«میانگین سبد خرید بر اساس ماه و منطقه»
الگو	نقطه‌ای، کوچک، میلیون‌ها بار در روز	اسکن میلیون‌ها سطر، چند بار در روز/ساعت
چیدمان	سطرمحور (رکوردها کنار هم)	ستون‌محور (مقادیر هر ستون کنار هم)
نمونه	PostgreSQL ،MySQL	ClickHouse ،BigQuery ،Snowflake ،Redshift ،Druid

چرا ستون‌محور برای تحلیل سلطه دارد

کوئری تحلیلی معمولاً ۳ ستون از ۵۰ ستون را روی میلیون‌ها سطر می‌خواند؛ چیدمان ستونی فقط همان ۳ ستون را از دیسک می‌خواند — I/O ده‌ها برابر کمتر.
مقادیر هم‌نوع کنار هم فشرده عالی می‌شوند (RLE ،dictionary)؛ ستونِ «شهر» با ۱۰۰ مقدار متمایز تقریباً هیچ فضایی نمی‌گیرد.
Parquet فرمت استاندارد فایل ستونی روی Data Lake است؛ ClickHouse/Druid/Pinot موتورهای کوئری ستونی برای تحلیل نزدیک-بلادرنگ‌اند.
Trade-off: به‌روزرسانیِ یک سطر در چیدمان ستونی گران است — به همین دلیل OLAP برای داده append-mostly و تاریخی است، نه تراکنش زنده.

مدل‌سازی برای تحلیل: Star Schema

در دنیای OLTP نرمال‌سازی را یاد گرفتی؛ در دنیای تحلیل برعکس: یک جدول Fact مرکزی (رویدادها: سفارش، کلیک) با کلیدهای خارجی به چند جدول Dimension پهن (کاربر، محصول، زمان، منطقه). کوئری تحلیلی = فیلتر روی dimension ها + تجمیع روی fact. این مدل را Star Schema می‌گویند و فهمش ساده است چون شبیه همان چیزی است که مدیر می‌پرسد: «فروش (fact) بر اساس شهر و ماه (dimensions)».

Warehouse در برابر Lakehouse

Data Warehouse

داده تمیز و مدل‌شده برای تحلیل (schema-on-write)؛ گران ولی سریع و قابل‌اعتماد: Snowflake ،BigQuery.

Data Lake

رسوب خام روی Object Storage (schema-on-read)؛ ارزان و منعطف ولی بدون نظم به Data Swamp تبدیل می‌شود.

Lakehouse

ترکیب: فایل‌های باز روی Object Storage + لایه تراکنش/متادیتا (Iceberg ،Delta Lake) — هم انعطاف lake، هم ACID و پرفورمنس warehouse.

جریان کلی داده تحلیلی: رویدادها → Kafka → (مصرف استریمی برای داشبورد زنده) + (رسوب به Lake/Warehouse برای تحلیل سنگین). این همان «یک منبع، دو سرعت» فصل ۴ است — و حالا می‌دانی سمت دوم دقیقاً با چه تکنولوژی‌هایی ساخته می‌شود.

به زبان ساده

دیتابیس تراکنشی (OLTP) برای ثبت سریع رویدادهای کوچک است و دیتابیس تحلیلی (OLAP) برای اسکن میلیون‌ها سطر و گزارش؛ شکل چیدمان داده در این دو برعکس هم است.

مثال واقعی

صندوق فروشگاه فقط «فروش جدید» را سریع ثبت می‌کند (OLTP)؛ مدیر آخر ماه می‌خواهد «مجموع فروش هر شهر» را ببیند — این سؤال روی کپی ستونی (OLAP) جواب می‌گیرد، نه روی صندوق.