پایگاه های داده یا دیتابیس ابزارهایی هستند که روزانه توسط شرکت ها در انواع مختلف استفاده می شود. آنها ذخیره و تبدیل مقادیر زیادی از داده ها را ممکن می سازند و برای هر تجارت مبتنی بر داده ضروری هستند. اما قبل از اینکه به پایگاه‌های اطلاعاتی امروزی تبدیل شوند، باید راه زیادی را طی می‌کردند. بیایید نگاهی به تاریخچه پایگاه های داده بیاندازیم و یاد بگیریم که SQL و NoSQL چگونه و چرا زنده شده اند.
تاریخچه پایگاه های داده رابطه ای و غیر رابطه ای
ریشه های پایگاه های داده رابطه ای
از آنجایی که ما به عنوان انسان شروع به جمع‌آوری داده‌ها کردیم، به راهی برای ذخیره آن نیز نیاز داشتیم. بنابراین به طور طبیعی، مفهوم پایگاه داده قبل از کامپیوترها مطرح شد. در دنیای کامپیوتر، پایگاه‌های اطلاعاتی در اوایل دهه 60 به وجود آمدند، زمانی که در سال 1962، فرهنگ لغت آکسفورد برای اولین بار اصطلاح «پایگاه داده» را به عنوان یک سیستم نرم‌افزاری که داده‌ها را ذخیره و بازیابی می‌کند، به رسمیت شناخت. اما پایگاه داده های اولیه کاملاً با راه حل هایی که امروز می شناسیم متفاوت بودند.
پایگاه داده های مدرن در دهه 1970 در IBM ظهور کردند، زمانی که دانشمند کامپیوتر، ادگار اف. کاد، نظریه مدل رابطه ای را در مقاله خود با عنوان "مدل رابطه ای داده ها برای بانک های مشترک بزرگ" ارائه کرد. در آن مقاله، ادگار روش جدیدی برای ذخیره داده ها ارائه کرد. ایده کاد این بود که داده ها را در جداول سازماندهی کند که هر جدول اطلاعات موجودات مختلف را ذخیره کند.
هر جدول شامل تعداد ثابتی از ستون‌ها می‌شود که ویژگی‌های موجودیت را توصیف می‌کند، از جمله یک یا چند ویژگی منحصربه‌فرد که برای شناسایی واضح رکوردی به نام کلید اصلی استفاده می‌شود. هر جدول می تواند برای تعریف روابط بین آنها پیوند متقابل داشته باشد. روابط با استفاده از مجموعه ای از دستورالعمل ها بر اساس سیستم ریاضی حساب رابطه ای توصیف شدند.
ریشه های زبان های کوئری ساختاریافته
کوئری از پایگاه های داده بر اساس مدل Codd کار ساده ای بود. ارزش شناسایی ویژگی ها تمام اطلاعات مربوط به آن موجودیت را به ما نشان می دهد. با دانستن اینکه مربوط به کدام جداول است، ما همچنین تمام اطلاعات موجودات مربوط به موجودیت شناخته شده خود را می دانیم.
زبان مورد استفاده برای کار با پایگاه‌های اطلاعاتی رابطه‌ای در اوایل دهه ۷۰ اختراع شد، زمانی که دانشمندان دیگر IBM دونالد دی. چمبرلین و ریموند اف. بویس در مورد نظریه کاد با خبر شدند. آنها زبانی به نام زبان کوئریی ساختاریافته انگلیسی (SEQUEL) توسعه دادند. SEQUEL برای کار با اولین اجرای IBM از مدل Codd طراحی شده است. بعداً در دهه 70، حروف صدادار SEQUEL حذف شدند که منجر به ایجاد زبان کوئری ساختار یافته SQL با صدایی آشنا شد.
در اواخر دهه 70، اوراکل، که در آن زمان نرم‌افزار رابطه‌ای نام داشت، سیستم مدیریت پایگاه داده رابطه‌ای مبتنی بر SQL (RDBMS) خود را توسعه داد. این اولین سیستم پایگاه داده تجاری موجود بر اساس اصول Codd بود. بعداً در دهه 80، ANSI و ISO تلاش های خود را برای استانداردسازی زبان SQL آغاز کردند و پایگاه های داده SQL آماده شدند تا جهان را تحت کنترل خود درآورند.
مدل رابطه ای: اصل ACID چیست؟
ACID مخفف اتمی، قوام، ایزوله و دوام است. اصطلاح ACID در دهه 1980 پس از تحقیقات جیم گری در این زمینه ابداع شد. مجموعه ای از ویژگی های پایگاه داده است که اعتبار داده ها را با وجود خطاهای احتمالی مانند خرابی دیسک، قطع برق و غیره تضمین می کند.
دنباله ای از عملیات پایگاه داده که از قوانین ACID پیروی می کنند تراکنش نامیده می شود.
بیایید نگاهی به هر حرف از این مخفف بیندازیم:
اتمی بودن
این بدان معنی است که تراکنش های موجود در پایگاه داده فقط می توانند با موفقیت یا شکست مواجه شوند. این را می توان به عنوان یک سناریوی همه یا هیچ در نظر گرفت: وقتی یک عنصر از کار می افتد، کل تراکنش با شکست مواجه می شود و پایگاه داده به حالت قبل از شروع تراکنش بازیابی می شود.
ثبات
این به این ویژگی اشاره دارد که داده ها را فقط می توان با توجه به قوانین و محدودیت های تعریف شده در پایگاه داده تغییر داد. سازگاری از خراب شدن پایگاه داده توسط یک تراکنش غیرقانونی جلوگیری می کند اما صحت تراکنش را تضمین نمی کند.
ایزوله
این تضمین می‌کند که تراکنش‌های همزمان پایگاه داده را در همان حالتی که اگر تراکنش‌ها به صورت متوالی اجرا می‌شدند، ترک می‌کنند. ایزوله سعی می کند اطمینان حاصل کند که تنها یک تراکنش برای دسترسی به منابع در هر زمان وجود دارد.
ماندگاری
این عامل تضمین می کند که به محض انجام تراکنش، بدون توجه به اینکه چه اتفاقی می افتد، حتی در صورت خرابی سیستم، متعهد باقی می ماند.
مزایای استفاده از پایگاه داده منطبق با ACID شامل یکپارچگی و قابلیت اطمینان داده است. این قوانین تضمین می کنند که پایگاه داده شما در صورت شکست یک عملیات در یک وضعیت ثابت باقی می ماند. اما تراکنش های ACID کاستی هایی نیز دارند. در مقایسه با رقبای غیر ACID خود، پایگاه‌های اطلاعاتی سازگار با ACID در عملیات خواندن و نوشتن کندتر هستند. این به دلیل مکانیسم قفل آنها است.
بیایید این را در یک سناریوی سریع تصویر کنیم. یک حسابدار باید درآمد 48 ماه گذشته را بداند. شما چک کرده اید و تمام 48 ماه در DB شما ذخیره می شود. در یک DB رابطه ای و مبتنی بر ACID، شما تمام 48 ماه یا هیچ چیز را خواهید داشت. اگر درخواست شما اشتباه است، در یک پایگاه داده NoSql می توانید پنج بار از DB بپرسید و هر نتیجه می تواند تعداد ماه های متفاوتی را به شما بدهد.
این یک واقعیت شناخته شده است که پایگاه های داده SQL مقیاس خوبی ندارند. گاهی اوقات حجم داده ها یا تعداد درخواست ها به پایگاه داده به حدی افزایش می یابد که نمونه فعلی ما کافی نیست. در آن صورت، راه حل ارتقای سرور خواهد بود و امیدواریم که در حال حاضر کار کند.
اکثر پایگاه های داده SQL فقط به صورت عمودی مقیاس می شوند. همچنین گزینه ای برای ایجاد یک نمونه در سرور دیگر و ارتباط بین آنها به نام پیوند وجود دارد. اما پردازش تراکنش ها از طریق شبکه ها یک کار دست و پا گیر است و بر عملکرد کل سیستم تأثیر می گذارد. این به دلیل اصول ACID پایگاه های داده رابطه ای است.
قضیه CAP بیان می کند که ما فقط می توانیم دو گزینه از سه گزینه موجود را انتخاب کنیم. این گزینه ها سازگاری، در دسترس بودن و تحمل پارتیشن هستند.
پایگاه‌های داده سنتی C و A را انتخاب می‌کنند، بنابراین مبادله P - تحمل پارتیشن است. اکثر پایگاه های داده NoSQL از قوانین ACID پیروی نمی کنند، بنابراین می توانند C یا A را به نفع P معامله کنند و با ایجاد یک نمونه جدید از پایگاه داده به صورت افقی مقیاس شوند.
آیا ما همیشه به همه داده ها نیاز داریم تا سازگار باشند؟
هنگام طراحی معماری برای سیستم ما، سازگاری داده ها همیشه ضروری نیست. به عنوان مثال، هنگام ساخت یک موتور جستجو برای یک برنامه تجارت الکترونیک، لازم نیست همیشه جدیدترین داده ها در دسترس کاربران باشد.
بیایید به یک مثال نظری نگاهی بیندازیم:
وقتی آلیس محصول X را جستجو می کند، نیازی به دیدن آخرین ورودی برای آن کوئری ندارد. هنگامی که کوئری با چیزی مرتبط مطابقت ندارد، نتایج مشابهی می تواند برگردانده شود. بیایید تصور کنیم که در حالی که آلیس در جستجوی X است، باب محصول جدیدی را اضافه می کند که با درخواست او مطابقت دارد. برای او نشان داده نمی‌شود، اما وقتی مدتی بعد بازمی‌گردد تا بررسی کند که آیا اکنون در دسترس است و همان محصول را جستجو می‌کند، اکنون برای او نشان داده می‌شود.
این یکی دیگر از موارد "بستگی دارد" است. وقتی ثبات داده ها یک ضرورت نیست، می توانیم آن را به نفع در دسترس بودن و تحمل پارتیشن قربانی کنیم. اما در موارد دیگر داده ها باید سازگار باشند. سپس ما باید سیستم خود را متفاوت طراحی کنیم تا این نیاز را برآورده کنیم.
افزایش داده ها و نیاز به چیزی بیشتر
با دسترسی روزافزون به اینترنت و تغییر به سمت خدمات دیجیتال، حجم داده های ایجاد شده به طور تصاعدی شروع به رشد کرد. در اوایل دهه 2000، اینترنت حدود 500 میلیون کاربر داشت. در اوایل سال 2010، حدود 2 میلیارد کاربر بود و در اوایل سال 2018، تخمین زده شد که حدود 4 میلیارد نفر از اینترنت استفاده می کنند. این حدود 50 درصد از جمعیت جهان است.
این منجر به افزایش گسترده داده های تولید و مصرف شده است. تخمین زده می شود که در سال 2025، حجم داده های جهانی از 175 زتابایت فراتر رود. برای درک این موضوع، یک هارد دیسک یک ترابایتی حدود دو سانتی متر ارتفاع دارد. یک زتابایت یک میلیارد ترابایت است، بنابراین ما به 175 میلیارد هارد دیسک نیاز داریم. این مقدار سه و نیم میلیون کیلومتر خواهد بود، تقریباً نه و نیم برابر فاصله زمین تا ماه.
رویکرد NoSQL
بیشتر این داده ها داده های بدون ساختار هستند. پایگاه داده های SQL برای کار با چنین بارها و انواع داده ها طراحی نشده اند. این منجر به مشکلاتی در عملکرد، مقیاس پذیری و ساختار داده ها شده است.
یکی از راه حل های پیشنهادی که NoSQL (نه تنها SQL) نامیده می شود، کنار گذاشتن مدل رابطه ای و استفاده از فایل های سند مانند بود که اغلب رکوردها را به عنوان یک کل توصیف می کنند، بدون تجزیه داده ها به بخش های اتمی ساختاریافته. راه حل دیگر نگاشت داده ها به جفت های کلید-مقدار(key-value) بود.
پایگاه‌های داده NoSQL نیز از نظر مقیاس‌پذیری، پایگاه‌های داده استاندارد SQL را شکست می‌دهند. DBMS های سنتی به خوبی به صورت افقی مقیاس نمی شوند. در بیشتر مواقع تنها راه حل این است که مقیاس عمودی باشد. پایگاه های داده NoSQL به صورت افقی مقیاس پذیر هستند. به عنوان مثال، در پایگاه های داده مبتنی بر سند، هر سند یک شی مستقل است. این اشیاء را می توان در سرورهای مختلف بدون نیاز به ایجاد پیوند بین آنها ذخیره کرد.
SQL -> NoSQL (r)evolution
همانطور که قبلاً توضیح داده شد، همه چیز با یک مورد استفاده خاص یا از مشاهده اینکه "چیزی اشتباه است" شروع می شود. تنظیم معماری بسته به مورد استفاده ای که فرد می خواهد به آن دست یابد، مهم است. هنگامی که سیستم تحت بار زیاد است، ما معمولاً نمی خواهیم تنها یک نمونه پایگاه داده به همه درخواست ها رسیدگی کند. هنگامی که سیستم خواندنی سنگین است، می‌توانیم چند نمونه فقط خواندنی برای بهینه‌سازی بار هر گره و کاهش تأخیر بین هر خواندن تنظیم کنیم.
هنگامی که سیستم سنگین‌تر از نوشتن است، پیچیده‌تر است، اما در بیشتر مواقع، می‌توانیم سازگاری داده‌ها را عوض کنیم و از یک پایگاه داده توزیع‌شده برای متعادل کردن بار بین گره‌ها و سپس همگام‌سازی داده‌ها استفاده کنیم. همه چیز به زمینه مشکلی که ما سعی در حل آن داریم بستگی دارد.
چگونه می توانیم آن را بهتر انجام دهیم؟
ایده هایی که در زیر توضیح داده شد، پاسخ های تاریخی برای مسائل مشاهده شده بود که از ساده و ساده به پیچیده تر و بیشتر تغییر می کردند.
شاردینگ
ایده اشتراک گذاری، پارتیشن بندی افقی پایگاه داده است. به عبارت دیگر، این تمرین جداسازی ردیف های یک جدول به چندین جدول مختلف است که به عنوان پارتیشن شناخته می شود. هر پارتیشن دارای طرح و ستون های یکسان است اما ردیف های کاملاً متفاوتی نیز دارد. به همین ترتیب، داده های ذخیره شده در هر پارتیشن منحصر به فرد و مستقل از داده های نگهداری شده در پارتیشن های دیگر است.
جذابیت اصلی شاردینگ این است که می تواند به مقیاس افقی کمک کند. Sharding همچنین می تواند با ارائه بیش از یک نقطه دسترسی به پایگاه داده، برنامه را قابل اعتمادتر کند. در صورت خرابی پایگاه داده، احتمالاً فقط یک قطعه را تحت تأثیر قرار می دهد و ممکن است برنامه همچنان با برخی از داده ها از دست رفته اجرا شود. این بسیار بهتر از یک خرابی کل سیستم در مورد معماری پایگاه داده یکپارچه است.
ذخیره سازی ابری - آغاز پردازش مدرن داده ها
رسانه‌های ذخیره‌سازی داده‌ها از زمان معرفی آنها راه زیادی را پیموده‌اند. در حال حاضر، با وجود دستگاه های در دسترس که قادر به ذخیره ترابایت داده هستند، هنوز مشکلاتی در ایجاد مراکز داده وجود دارد.
اولین مسئله این است که HDD ها و SDD ها مقیاس ضعیفی دارند. تنها گزینه برای افزایش فضای ذخیره سازی خرید دیسک های بیشتر و نصب آنها بر روی سرور است. این یک ناراحتی قابل توجه است زیرا دیسک ها فضای زیادی را اشغال می کنند و نسبتاً گران هستند. در برخی موارد، خرید فضای ذخیره‌سازی بیشتر سودآور نیست.
برای حل این مشکل، شرکت ها شروع به ارائه خدمات اجاره فضای دیسک به مشتریان کردند. بنابراین، ابر متولد شد. در سال 2006، آمازون سرویس ذخیره سازی ابری خود S3 را به عنوان بخشی از نمونه کارها مبتنی بر ابر خود راه اندازی کرد. S3 به مشتریان این امکان را می‌دهد تا داده‌های زیادی را بدون نگرانی از کمبود فضا یا خرابی و خرابی ذخیره کنند. S3 به سرعت در صنعت به رسمیت شناخته شد و شروع به ارائه فضای ذخیره سازی برای بسیاری از خدمات فضای دیسک مجازی، مانند Dropbox کرد.
Bigtable
با افزایش سرعت و پهنای باند اینترنت، داده های بیشتری ایجاد و مصرف می شد و با ذخیره سازی ارزان از سوی ارائه دهندگان خدمات، ایده مقیاس افقی قابل اجرا شد. برای چنین راه حل هایی، پایگاه های داده NoSQL مفید هستند. یکی از پیشگامان این فرآیند، گوگل بود که با استفاده از پایگاه داده سفارشی خود به نام Bigtable، با معرفی Google Drive در سال 2012 شروع به ارائه خدمات ذخیره سازی کرد. Bigtable یک پایگاه داده NoSQL با ستون گسترده است که تحت بارهای کاری تحلیلی و عملیاتی بالا کار می کند. برای استفاده به عنوان بخشی از مجموعه پلتفرم ابری Google در دسترس است.
مدل دینام
مدل Dynamo مجموعه‌ای از تکنیک‌ها است که می‌تواند فضای ذخیره‌سازی بسیار در دسترس را بر اساس سیستم ذخیره‌سازی کلید-مقدار ایجاد کند. در آمازون برای کمک به حل مشکلات مقیاس پذیری آنها در سال 2004 توسعه داده شد. اکنون سرویسی بر اساس این اصول به عنوان بخشی از مجموعه خدمات وب آمازون در دسترس است.
اصول در کوتاه مدت عبارتند از:
سیستم باید بتواند به صورت افقی یک گره ذخیره سازی را با کمترین تأثیر بر روی کاربران و خود سیستم مقیاس کند.
هر گره در مدل Dynamo باید وظایف یکسانی داشته باشد. هیچ گره ای نباید وجود داشته باشد که نقش های خاصی را ایفا کند یا مسئولیت های اضافی را بر عهده بگیرد.
گره ها باید غیرمتمرکز باشند و تکنیک های همتا به همتا را بر کنترل متمرکز ترجیح دهند.
توزیع کار باید متناسب با قابلیت های هر سرور باشد. این برای اضافه کردن گره های جدید با ظرفیت بالاتر بدون نیاز به ارتقاء همه هاست ها به یکباره ضروری است. این به ناهمگونی سیستمی که روی آن اجرا می شود متکی است.
رابطه ای و در عین حال مبتنی بر ابر
با گسترش خدمات ابری، پایگاه‌های داده ساده قدیمی SQL که قبلاً در اتاق‌های سرور محلی راه‌اندازی می‌شدند، هنوز فراموش نشده‌اند. همان پایگاه‌های داده مبتنی بر ACID اما مستقر در ابر، تبدیل به موتورهای ذخیره‌سازی و انبار داده‌های پرکاربرد می‌شوند.
AWS Redshift یا GCP BigQuery می‌تواند حجم بسیار بالایی از داده‌های رابطه‌ای را محاسبه کرده و در کمترین زمان آن را به کاربران تحویل دهد. PostgreSQL یکی از محبوب ترین پایگاه های داده SQL است. طیف گسترده ای از ایندکس ها و پشتیبانی بسیار خوب از JSON را ارائه می دهد، از گویش SQL بسیار واضح استفاده می کند و رایگان است.
نمونه عالی دیگر از پایگاه داده های SQL Snowflake است. این به عنوان فضای ذخیره سازی برای ذخیره سازی ابری موجود شما استفاده می شود. این یک DB ذخیره سازی ستونی است، بنابراین هنگام کار با مجموعه داده های بزرگ بسیار کارآمد است. همچنین انعطاف پذیری را برای کاربران به منظور تخصیص توان محاسباتی از سطح کد ارائه می دهد.
ذخیره سازی ستونی
یکی از راه‌های بهبود پایگاه‌های اطلاعاتی رابطه‌ای، به اصطلاح «ذخیره‌سازی ستونی» است. این روش ذخیره داده به این معنی است که در صفحات - جایی که پایگاه داده داده ها را در ردیف ها ذخیره می کند - به جای آن ستون ها را ذخیره می کنیم. چرا این همه تلاش؟ در بیشتر موارد، کاربر فقط چند ستون را درخواست می کند، تقریباً هرگز برای یک سطر کامل. Columnar DB داده ها را فقط از ستون های مشخص شده در قسمت "انتخاب" کوئری پردازش می کند، برخلاف ذخیره سازی مبتنی بر ردیف که از قدرت محاسباتی برای دریافت تمام رکوردها از صفحه استفاده می کند و سپس ستون ها را انتخاب می کند. همچنین DB ستونی می تواند ترتیب رکوردها را تضمین کند (کلید مرتب سازی در Redshift) و در DB های مبتنی بر ردیف، ترتیب رکوردها تصادفی است.
یکی دیگر از مزایای DB های ستونی کمبود ایندکس است. ما فقط دو کلید داریم - کلید مرتب سازی که ترتیب بارگیری را توصیف می کند و کلید توزیع که در آن می توانیم نحوه ذخیره و خواندن داده ها را تنظیم کنیم. همه این گره‌های موازی که با هم کار می‌کنند، پایگاه‌های داده ستونی را به موتور بسیار قدرتمندی برای پایگاه‌های داده تحلیلی تبدیل می‌کنند، به‌ویژه جایی که مقادیر زیادی داده ذخیره می‌شود.
نتیجه
شاید فکر کنید که مشکل افزایش حجم داده ها با چنین مدل ها و ابزارهای عالی به راحتی حل می شود. متاسفانه نزدیک هم نیستیم. جهان کاملا جدیدی از چیزی به نام داده های بزرگ وجود دارد که می توان آن را با حجم 6 ولت، مقدار، تنوع، سرعت، تغییرپذیری و صحت مشخص کرد. البته این موضوع کاملاً متفاوتی است، بنابراین من در اینجا به آن نمی پردازم، اما خوب است بدانید که SQL و NoSQL تنها بخشی از دنیای بزرگ و شگفت انگیز پردازش داده هستند.
منتظر قسمت بعدی باشید که در آن سناریوهای پایگاه داده واقعی و راه ها و ابزارهای ممکن برای دستیابی به بهترین نتایج عملکرد را پوشش خواهیم داد.