انواع پایگاه‌های داده

چیزهایی که باید درباره انواع مختلف پایگاه داده و نحوه کار آن‌ها بدانید.

گزینه‌های زیادی پایگاه داده و منبع داده برای در نظر گرفتن هنگام ساخت stack داده شما وجود دارد. در اینجا خلاصه‌ای از بازیگران اصلی که متابیس پشتیبانی می‌کند وجود دارد، چه تازه وارد فضای داده باشید یا فقط نیاز به یادآوری داشته باشید.

اسب‌های کاری همه‌کاره: سیستم‌های مدیریت پایگاه داده رابطه‌ای سنتی

شامل: Microsoft SQL Server، MySQL، Oracle Database، PostgreSQL

همه چهار سیستم مدیریت پایگاه داده رابطه‌ای (RDBMS) این دهه‌ها وجود داشته‌اند، و نیازهای همه‌کاره پایگاه داده — درج رکوردها، خواندن، به‌روزرسانی، حذف رکوردها — را کاملاً خوب مدیریت می‌کنند. از این چهار، MySQL و PostgreSQL منبع باز هستند.

اگر سازمان شما کمبود زمان یا منابع دارد، یا فاقد هر متخصص داده برای ساخت ETLها است، یک سیستم پایگاه داده رابطه‌ای مثل MySQL، Postgres، SQL Server، یا Oracle Database یک گزینه عالی است. سازمان‌های زیادی که از متابیس استفاده می‌کنند این کار را به سادگی با اتصال پایگاه داده رابطه‌ای خود انجام می‌دهند تا بتوانند بلافاصله شروع به دریافت بینش کنند. این پایگاه‌های داده برای استفاده به عنوان پایگاه داده اپلیکیشن برای نرم‌افزار شما به خوبی مناسب هستند. متابیس، نرم‌افزار، می‌تواند از Postgres یا MySQL برای پایگاه داده تولید خود استفاده کند.

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

این چهار سیستم پایگاه‌های داده تراکنشی هستند، و به طور خاص برای پرس‌وجوهای تحلیلی ساخته نشده‌اند. در حالی که می‌توانید پرس‌وجوهای تحلیلی را از طریق هر یک از این چهار موتور انجام دهید، می‌تواند نیاز به سخت‌افزار اضافی زیادی (RAM اضافی، CPUها، و دیسک‌های سریع‌تر) برای همگام شدن با رشد حجم داده شما داشته باشد، و این خیلی سریع گران می‌شود. همانطور که مقیاس می‌کنید و پرس‌وجوهای تحلیلی شما پیچیده‌تر می‌شوند، ممکن است کند اجرا شوند مهم نیست چقدر سخت‌افزار روی مشکل می‌اندازید. در آن نقطه، ممکن است زمان نگاه به فناوری دیگری باشد که به طور خاص برای داده بزرگ و پرس‌وجوهای تحلیلی ساخته شده است.

پرس‌وجوی داده بزرگ: انبارهای داده

شامل: BigQuery، Redshift، Snowflake، Vertica

انبارهای داده به خوبی مجهز برای اجرای پرس‌وجوهای تحلیلی روی مقادیر زیادی داده هستند. محصولاتی مثل BigQuery، AWS Redshift، Snowflake، و Vertica قادر به پردازش داده بزرگ هستند چون توسط تعداد زیادی موتور موازی قدرت می‌گیرند، که پرس‌وجوهای تحلیلی در منابع داده عظیم را خیلی قابل مدیریت‌تر می‌کند. این انبارهای داده هر کدام کمی متفاوت کار می‌کنند، اما وقتی می‌خواهید یک پرس‌وجو اجرا کنید، از آن موازی‌سازی برای تقسیم داده شما و تجمیع نتایج قبل از برگرداندن پرس‌وجوی شما استفاده می‌کنند. این انبارهای داده همچنین به ذخیره‌سازی ستونی (ذخیره داده بر اساس ستون‌ها به جای ردیف‌ها) برای سرعت بخشیدن به عملیات تحلیلی تکیه می‌کنند، چون این پایگاه داده شما را از نیاز به اسکن اطلاعات در ردیف‌هایی که مرتبط با پرس‌وجوی فعلی نیستند آزاد می‌کند.

شما طبق منابع استفاده شده در حین اجرای پرس‌وجوها شارژ می‌شوید، اما درج داده در این انبارها نیز گران می‌شود. اگر سازمان شما نیاز به داده بلادرنگ (یا نزدیک به آن) دارد، یک انبار داده مثل یکی از این‌ها کارآمدترین نیست، چون نیاز به reindex کردن هر زمان که داده جدید اضافه می‌شود دارند، و این زمان می‌برد.

در حالی که BigQuery، Redshift، و Snowflake به طور انحصاری مبتنی بر ابر هستند، Vertica — که منبع باز است — می‌تواند هم در ابر و هم on-prem اجرا شود.

پایگاه‌های داده تحلیلی بلادرنگ

شامل: Druid

پایگاه‌های داده مثل Druid، یک محصول منبع باز، برای سازمان‌هایی که نیاز به پرس‌وجوی داده به محض تولید آن دارند جذاب هستند. با یک پایگاه داده بلادرنگ، می‌توانید پرس‌وجوهای تحلیلی را به محض اینکه داده به موتور داده شما می‌رسد اجرا کنید، بدون پردازش اضافی یا زمان‌های انتظار طولانی.

اگر مدل کسب‌وکار شما به توانایی مهار داده بلادرنگ تکیه می‌کند (مثلاً خدمات مالی یا امنیت اطلاعات)، یک پایگاه داده مثل Druid ارزش کاوش دارد. اما مدیریت pipelineها برای داده بلادرنگ می‌تواند پیچیده شود — چیزهای زیادی می‌تواند بین هر چیزی که داده شما را تولید می‌کند و پردازش آن داده از طریق ابزارهای مختلف در pipeline اشتباه شود. با توجه به پیچیدگی این سیستم‌ها، به خصوص وقتی با مقادیر زیادی داده سروکار دارید، داشتن افراد در دسترس برای نظارت بر پایگاه داده بلادرنگ شما کمک بزرگی خواهد بود.

برای تحلیل ad hoc: پایگاه‌های داده مبتنی بر فایل

شامل: SQLite، H2

SQLite و H2 مشابه یک RDBMS سنتی مثل MySQL یا Postgres هستند — هر دو نوع پایگاه‌های داده رابطه‌ای هستند — اما پایگاه‌های داده مبتنی بر فایل هیچ سروری در سمت پایگاه داده ندارند. به جای هر کدی که برای بهینه‌سازی پایگاه داده شما کار می‌کند، این انواع یک فایل هستند که روی رایانه شما زندگی می‌کنند. اگر از متابیس استفاده می‌کنید، پایگاه داده SQLite خود را در همان مکان سرور متابیس خود ذخیره می‌کنید تا متابیس بتواند برای تحلیل از آن استفاده کند.

پایگاه‌های داده مبتنی بر فایل برای جاسازی و تحلیل ad hoc — چیزهایی مثل پرس‌وجوهای یک‌باره که نیاز به مقادیر زیادی داده بلادرنگ ندارند — به خوبی مناسب هستند. در حالی که SQLite پرکاربردترین پایگاه داده در جهان است (عمدتاً به دلیل سادگی آن)، استفاده از پایگاه‌های داده مبتنی بر فایل برای تحلیل‌های پیچیده محدود است، و یک پایگاه داده مبتنی بر فایل احتمالاً جایی نیست که می‌خواهید داده زنده خود را نگه دارید.

موتورهای پرس‌وجو

شامل: SparkSQL، Presto

موتورهای پرس‌وجو خود پایگاه داده نیستند، بلکه بین داده شما و نتیجه نهایی شما قرار می‌گیرند. SparkSQL و Presto دو موتور منبع باز هستند که می‌توانند داده را از طیف گسترده‌ای از منابع، شامل داده بلادرنگ، ingest و پرس‌وجو کنند.

مثل انبارهای داده ابری بحث شده در بالا، موتورهایی مثل Spark و Presto پرس‌وجوهای تحلیلی را روی مقادیر زیادی داده تقریباً طبق مراحل زیر اجرا می‌کنند:

1. با تقسیم کار به کارهای کوچکتر شروع کنید.
2. پرس‌وجو را موازی کنید — یعنی، آن را به طور همزمان در آن کارهای کوچکتر اجرا کنید.
3. آن نتایج را تجمیع کنید.
4. در نهایت، نتیجه پرس‌وجوی اصلی خود را تحویل دهید.

پایگاه‌های داده مبتنی بر سند

شامل: MongoDB

در حالی که همه گزینه‌های بالا شامل برخی عناصر رابطه‌ای هستند، یک پایگاه داده NoSQL بدون ساختار مثل MongoDB متفاوت کار می‌کند. به جای ذخیره داده در جداول، MongoDB داده را در "مجموعه‌های" سندها ذخیره می‌کند، و به شما امکان پرس‌وجوی آن سندها را می‌دهد، که اغلب فایل‌های JSON هستند. این یعنی سندهایی که در یک مجموعه ذخیره می‌کنید می‌توانند یکسان یا کاملاً نامرتبط باشند، اما راه بومی برای join کردن آن‌ها مثل جداول در یک پایگاه داده رابطه‌ای وجود ندارد.

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