مطالعه بیشتر
کدام انبار داده انتخاب میکنید بستگی به میزان دادهای که مدیریت میکنید دارد. این راهنما شما را از گزینههای خود راهنمایی میکند، چه یک استارتاپ کوچک باشید یا یک شرکت بزرگ.
کدام انبار داده باید استفاده کنید؟
کدام انبار داده انتخاب میکنید بستگی به میزان دادهای که مدیریت میکنید دارد. این راهنما شما را از گزینههای خود راهنمایی میکند، چه یک استارتاپ کوچک باشید یا یک شرکت بزرگ.
هنگام راهاندازی یک سیستم تحلیلی برای یک سازمان یا پروژه، نیاز به فهمیدن جایی که داده خود را ذخیره میکنید دارید. در حالی که هیچ راهحل یکاندازهای برای همه وجود ندارد، یک نقشه تقریبی از انتخابهای موجود برای انبار داده به شما میدهیم، با هدف کمک به شما برای پیدا کردن راهحلی که برای بودجه شما، میزان دادهای که انتظار دارید با آن کار کنید، و نیازهای عملکرد شما بهترین است.
در اینجا فهرست انتخابهای ما برای بهترین نرمافزار انبار داده، برای استارتاپهای کوچک به بالا وجود دارد.
1. پایگاه داده اپلیکیشن شما
سادهترین گزینه فقط استفاده از پایگاه داده تولید است که در حال حاضر داده شما را ذخیره میکند، چه یک اپ وب، اپ موبایل، یا اپ دسکتاپ native باشد (و نه پایگاه داده اپلیکیشن خود متابیس).
مثالهای رایج:
| Pros | Cons |
|---|---|
| انبار داده شما از قبل وجود دارد. | Workloadهای تحلیلی ممکن است اپلیکیشن شما را کند کنند. |
| فقط نیاز به برخورد با یک سرور پایگاه داده دارید. | Schema داده اغلب برای تحلیل دشوار استفاده میشود. |
| نیاز به تبدیل داده یا جابجایی آن ندارید. | مقیاسبندی وقتی دو حالت استفاده اساساً متفاوت را متعادل میکنید دشوار میشود. |
استفاده از یک پایگاه داده هم به عنوان پایگاه داده تولید و هم انبار داده شما معمولاً یک مرحله مقدماتی برای اپلیکیشنهای "واقعی" است، اما اگر یک اپلیکیشن کوچک، داخلی، MVP، یا نمونههای اولیه میسازید، دو برابر کردن روی یک پایگاه داده واحد یک انتخاب قابل اجرا است. پس از آماده شدن برای راهاندازی (برای اپلیکیشنهای مصرفکننده)، احتمالاً میخواهید از این تنظیمات به یک انتخاب مقیاسپذیرتر در زیر مهاجرت کنید. اگر هنوز پایگاه دادهای برای اپلیکیشن خود انتخاب نکردهاید، مطمئن شوید از replicaهای خواندنی پشتیبانی میکند، که ما را به گزینه بعدی میرساند:
2. یک replica خواندنی از پایگاه داده اپلیکیشن شما
اگر پایگاه داده اصلی شما از replicaهای خواندنی پشتیبانی میکند، تنبلترین کار بعدی که میتوانید انجام دهید ایجاد یک replica خواندنی از پایگاه داده اصلی خود است، یعنی یک کپی از پایگاه داده تولید شما. همچنین میتوانید یک namespace دیگر برای شامل کردن داده یا رویدادهای شخص ثالث خود تنظیم کنید، و آن را یک برد بنامید.
| Pros | Cons |
|---|---|
| نیاز به مدیریت یک نوع پایگاه داده متفاوت ندارید. | پایگاههای داده بهینه شده برای بارهای تراکنشی معمولاً برای تحلیل بهینه نیستند |
| نیاز به تبدیل داده یا جابجایی آن ندارید. | نیاز به مدیریت یک سرور پایگاه داده دیگر دارید. |
| میتوانید بارهای تحلیلی و تراکنشی را به طور مستقل مقیاس کنید. | Schema داده اغلب برای تحلیل دشوار استفاده میشود. |
معمولاً، پس از شروع جدی گرفتن تحلیل، و مقیاس شما افزایش مییابد (هم در حجم داده و هم در پیچیدگی پرسوجوهای تحلیلی)، مزایای عملکرد قابل توجهی برای حرکت به یک انبار داده اختصاصی وجود دارد.
3. اجرای همان نوع پایگاه داده به عنوان اپلیکیشن شما
اگر مقیاسی ندارید که نیاز به اجرای یک پایگاه داده روی چندین ماشین داشته باشد، میتوانید با استفاده از همان نوع پایگاه داده که برای پایگاه داده اپلیکیشن خود استفاده میکنید به عنوان یک انبار داده تحلیلی اختصاصی (مثلاً، اگر از PostgreSQL برای اپ خود استفاده میکنید، میتوانید از یک پایگاه داده Postgres دیگر برای ذخیره داده تحلیلی خود استفاده کنید) از آن استفاده کنید. این تنظیمات از قبلی متفاوت است به این معنا که این انبار داده فقط یک replica خواندنی از پایگاه داده شما نیست؛ در عوض برای workloadهای تحلیلی تنظیم شده است. این تنظیم شامل پیکربندی تنظیمات پایگاه داده، و تغییر شکل نحوه چیدمان داده شما در جداول برای سریعتر و آسانتر نوشتن پرسوجوهای تحلیلی است.
| Pros | Cons |
|---|---|
| فقط نیاز به مدیریت یک نوع پایگاه داده دارید. | نیاز به مدیریت یک سرور پایگاه داده دیگر دارید. |
| میتوانید بارهای تحلیلی و تراکنشی را به طور مستقل مقیاس کنید. | پایگاههای داده بهینه شده برای بارهای تراکنشی معمولاً برای اهداف تحلیلی بهینه نیستند. |
| میتوانید مدل/ schema داده را برای کار تحلیلی خود بهینه کنید. | نیاز به جابجایی داده دارید (و تبدیل آن). |
| این پایگاههای داده معمولاً به یک node واحد محدود میشوند، که مقیاسپذیری را تحت تأثیر قرار میدهد. |
این تنظیمات میتواند شما را خیلی جلو ببرد. پس از رسیدن به نقطهای که پرسوجوهای رایج دقیقهها یا بیشتر طول میکشند، باید گزینههایی با قدرت بیشتر را ارزیابی کنید.
4. پایگاههای داده تحلیلی مبتنی بر SQL
اینجا جایی است که به پایگاههای داده طراحی شده برای workloadهای تحلیلی میرسیم. تمایزات اصلی بین نرمافزار پایگاه داده "عادی" و پایگاههای داده در نظر گرفته شده برای workloadهای تحلیلی سنگین موازیسازی و فرمت داده هستند. اغلب اصطلاحات پایگاههای داده پردازش تراکنش آنلاین (OLTP) و پایگاههای داده پردازش تحلیلی آنلاین (OLAP) را میبینید. اینها پایگاههای داده OLAP هستند.
تفاوت بین OLAP و OLTP
فقط برای روشن بودن تفاوت بین پایگاههای داده OLAP و OLTP: workloadهای تراکنشی (OLTP) معمولاً خواندنها، نوشتنها، و بهروزرسانیهای کوچک زیادی دارند. این workloadها میتوانند روی یک ماشین واحد خیلی بیشتر از workloadهای تحلیلی برای یک شرکت معین زندگی کنند. در مقابل، workloadهای تحلیلی (OLAP) عملیات خواندن کمتری دارند، اما آن خواندنها مقادیر بسیار بیشتری از داده را لمس میکنند.
- مثال workload تراکنشی: واکشی زمان آخرین ورود یک کاربر واحد برای نمایش آن به آنها در اپ.
- مثال workload تحلیلی: یک پرسوجو برای شمارش تعداد کل ورودهای کاربر در هر روز برای سه ماه گذشته برای ایجاد یک نمودار خطی.
پایگاههای داده تراکنشی معمولاً داده را در فرمت ردیف ذخیره میکنند. به عنوان مثال، بگویید یک جدول با رکوردهای کاربر داریم، با هر رکورد کاربر شامل نام، آدرس، زمان آخرین ورود، و تاریخ تولد آنها. پایگاه داده تراکنشی همه چهار فیلد را در یک واحد ذخیره میکند، که به پایگاه داده امکان بازیابی (یا بهروزرسانی) آن رکورد را خیلی سریع میدهد.
برعکس، پایگاههای داده تحلیلی تمایل به استفاده از ذخیرهسازی ستونی دارند، ذخیره همه نامها با هم، همه زمانهای آخرین ورود با هم، و غیره. ذخیرهسازی ستونی عملیات مثل "میانگین سن پایه کاربری ما چیست؟" را آسان میکند، چون پایگاه داده میتواند همه داده در پایگاه داده به جز ستون تاریخ تولد را نادیده بگیرد. با کاهش مقدار دادهای که پایگاه داده نیاز به اسکن دارد، ذخیرهسازی ستونی به طور چشمگیری عملکرد را برای پرسوجوهای تحلیلی بهبود میبخشد. طرف دیگر این است که ذخیرهسازی ستونی برای workloadهای تراکنشی خیلی عالی نیست.
گزینههای پایگاه داده تحلیلی مبتنی بر SQL میزبانی شده
پایگاههای داده تحلیلی مبتنی بر SQL به عنوان سرویس میتوانند معامله عالی باشند اگر تخصص مدیریت پایگاه داده داخلی زیادی ندارید. این فضا خیلی رقابتی است، پس خرد کلی اینجا این است که فقط باید از گزینهای که ارائهدهنده ابر فعلی شما ارائه میدهد استفاده کنید، اگرچه اگر به این مرحله رسیدهاید، ممکن است زمان خرید برای دیدن اینکه آیا میتوانید معامله بهتری دریافت کنید باشد. چالش اصلی با این انبارهای داده این است که دریافت داده در آنها میتواند پیچیده باشد. عملکرد نسبتاً قابل مقایسه در همه گزینهها است، پس درباره benchmarkهایی که نشان میدهند یک راهحل به طور چشمگیری از دیگران بهتر عمل میکند شکاک باشید.
| Pros | Cons |
|---|---|
| طراحی شده برای پرسوجوهای تحلیلی. | میتواند گران باشد. |
| مقیاسپذیر. | قیمتگذاری بالقوه غیرقابل پیشبینی. |
| تست شده در نبرد. | دریافت داده در آن دردسر است. |
در اینجا برخی از انبارهای داده اصلی وجود دارد:
Redshift - Amazon Web Services
Redshift انبار داده میزبانی شده Amazon Web Service (AWS) است. به طور کلی ارزانترین و آسانترین گزینه کلی است. باید با provisioning دستی خوشهها برخورد کنید، اما قیمتگذاری قابل پیشبینیتری دریافت خواهید کرد، چون شما کسی خواهید بود که زمان ماشین بیشتری "میخرید". اخیراً، AWS instanceهای RA3 را به پیشنهاد Redshift اضافه کرد، که به شما امکان جدا کردن محاسبه و ذخیرهسازی را میدهد، مشابه گزینههایی مثل Big Query و Snowflake. و وقتی با AWS Aqua ترکیب میشود، میتوانید عملکرد را به طور قابل توجهی بهبود بخشید.
BigQuery - Google Cloud Platform
برای مدتی، BigQuery (شناخته شده داخلی و در ادبیات تحقیقاتی به عنوان Dremel) یکی از سلاحهای نیمه مخفی Google بود. سریع است، و به جای پرداخت به ازای هر ماشین (مثل اگر Postgres را روی یک سرور اجرا میکردید) BigQuery زیرساخت را انتزاع میکند، در عوض شما را طبق حجم داده شما و چقدر CPU/IO پرسوجوهای شما استفاده میکنند شارژ میکند. قبلاً از یک گویش سفارشی SQL استفاده میکرد، اما از نسخه 2.0 به Standard SQL تغییر کرده است. BigQuery همچنین قابلیتهای یادگیری ماشین داخلی با BigQuery ML ارائه میدهد. طرف دیگر پرداخت بر اساس محاسبه و ذخیرهسازی این است که قیمتگذاری میتواند کمتر قابل پیشبینی باشد.
Snowflake - در دسترس میزبانی شده، یا روی ارائهدهندگان دیگر
Snowflake یکی از محبوبترین انبارهای داده است. مزایای آن این است که سریع است (برخی ادعا میکنند بهینهسازیهای محاسباتی آنها آنها را سریعترین میکند)، و نیاز به مقیاسبندی Snowflake ندارید، پس نیاز به نگرانی درباره provisioning ماشینها ندارید. طرف منفی این است که گران است.
Vertica - سرویس میزبانی شده یا اجرای خود
Vertica یک نسخه community رایگان محدود به 3 node و 1 TB داده ارائه میدهد، و نسخه تجاری بدون آن محدودیتها به عنوان یک تصویر Docker و از طریق Kubernetes در دسترس است.
پایگاههای داده تحلیلی اختصاصی
انواع مختلفی از راهحلهای پایگاه داده پیچیده (و گران) بهینه شده برای workloadهای تحلیلی وجود دارد. اگر این راهنما را میخوانید، احتمالاً در بازار یک تعامل 6-7 رقمی با یک فروشنده پایگاه داده نیستید.
| Pros | Cons |
|---|---|
| جزء سرویس قوی اگر نیاز به کمک دارید (و میتوانید پرداخت کنید). | گران. |
| برخی با گزینه on prem یا میزبانی شده. | نیاز به مدیریت یک سرور پایگاه داده دیگر دارید. |
| تاریخچه عملیاتی طولانی و تجربه با استقرارهای پیچیده. | معمولاً خیلی پیچیده برای راهاندازی و مدیریت. |
مثالها:
5. فراتر از انبار داده: دریاچههای داده و lakehouseها
اینجا جایی است که تعداد گزینهها شروع به خارج از کنترل شدن میکند. اگر شرکتی هستید که با مقیاس قابل توجهی سروکار دارید، میتوانید ساخت یک pipeline داده اختصاصی که از یک دریاچه داده استفاده میکند را در نظر بگیرید: مکانی که همه داده شما، هم ساختار یافته و هم بدون ساختار، ذخیره میشود. نکته اینجا این است که ساخت یک pipeline حول یک دریاچه داده شامل جمع کردن یک تیم از مهندسان داده (گران) خواهد بود. در این نقطه، اپلیکیشن خود را با رویدادها (مثل باز شدن اپ، کلیک دکمه) instrument میکنید، آن داده را در صورت نیاز تزئین میکنید (مثل اضافه کردن جزئیات مرتبط دیگر به یک رویداد، مثل جزئیات session کاربر)، سپس آن داده پاک شده را در ذخیرهسازی ارزان (مثل S3 (Simple Storage Service) AWS، معمولاً در فرمتی مثل parquet) dump میکنید. این object store دریاچه داده شما است.
کاربران شما به طور کلی دریاچه داده را مستقیماً پرسوجو نمیکنند. در عوض، "ساختار" داده خود را در صورت نیاز با استفاده از عملیات Extract Transform Load (ETL) ایجاد میکنید. از یک موتور پرسوجو مثل Presto برای اجرای پرسوجوهای ETL روی دریاچه داده استفاده میکنید، با هدف سازماندهی داده به جداولی که انواع سؤالهایی که کسبوکار شما میپرسد را پیشبینی میکنند. این موتورهای پرسوجو به شما امکان پرسیدن سؤال از یک object store مثل S3 را میدهند گویی یک پایگاه داده رابطهای است — مثل استفاده از SQL برای پرسوجوی یک سیستم فایل.
میتوانید از directed acyclic graphs (DAGها) برای برنامهریزی و اجرای این ETLها استفاده کنید: Airflow اینجا به کار میآید. ایده با ETLهای شما تولید جداول واقعیت و بعد، و همچنین جداول خلاصه که داده تجمیع شده را فهرست میکنند (تعداد روزانه سفارشها، مدت session متوسط، یا هر چیز دیگر) است. جداول تولید شده توسط ETLها اطلاعات زیادی از منابع متعدد را به هم میبندند که به کسبوکار کمک میکند تصمیم بگیرد (مثلاً، همه چیزهایی که میخواهید درباره یک سفارش، یا یک محصول، و غیره بدانید). مثل ساخت انبارهای داده خود به صورت زنده است.
همچنین میتوانید این جداول ETL را دوباره در دریاچه داده خود dump کنید، یا—اگر واقعاً نیاز به داشبوردهای سریع دارید—در یک پایگاه داده in-memory مثل Druid.
| Pros | Cons |
|---|---|
| میتواند به مجموعه دادههای عظیم مقیاس کند. | مهندسان داده و سرویسهای pipeline گران هستند. |
| انعطافپذیر، نیاز به تعریف schema از قبل ندارید. | پیچیدگی بسیاری از بخشهای متحرک را به عهده میگیرید. |
دریاچه داده و انبار داده ترکیبی به ما data lakehouse داد، معماری که هدف آن ارائه برخی ساختار به دریاچههای داده است، با اهداف کاهش مدیریت و دادن دسترسی مستقیمتر ابزارهای تحلیلی به داده.
برخی ابزارهای محبوب برای کار با تنظیمات دریاچه داده:
- Presto موتور پرسوجوی منبع باز که به شما امکان پرسوجوی یک file store با استفاده از SQL را میدهد
- Athena. سرویس پرسوجوی تعاملی serverless AWS.
- Spark SQL. اجرای پرسوجوهای SQL روی داده در فرمت Parquet یا جداول Hive.
- Azure Data Lake Storage.
- Databricks
- دریاچههای داده روی AWS مرور تنظیمات دریاچه داده.
- Airflow برای برنامهریزی ETLها.
- Druid. پایگاه داده in-memory برای ذخیره جداول ETL شده شما برای پرسوجوهای تحلیلی.
- Pinot پایگاه داده OLAP ساخته شده برای تحلیل بلادرنگ. از LinkedIn بیرون آمد، اکنون تحت Apache.