مقدمه

یک دیدگان سنتی که هنوز طرفداران زیادی در عرصه پردازش داده دارد ذخیره دیتاها در قالب دیتابیس های برجسته و سنتی مثل MySQL یا SQL Server هست. اما ماها که تو عصر بیگ دیتا داریم زندگی می کنیم اینو می دونیم با تولید حجم سرسام آور دیتایی که از منابع گوناگون با مقاصد متنوع تولید میشن، ساختار سنتی دیتابیس ها برای خیلی از مسائلی که تو سازمانمون باهاشون سرکار داریم قابل پیاده سازی نیستند. این نیاز ذخیره سازی بیگ دیتا باعث پیدایش نوع جدیدی از دیتابیس ها به نام NoSQL‌ شده  که قبلا در دنیای بیگ دیتا راجع بهشون نوشتم.

این تیپ دیتابیس ها واسه حجم فوق العاده از دیتا که گاها به صورت لحظه ای تولید میشن مناسب هست. تو این دیتابیس ها اصولا مفهوم سنتی جدول، سطر و ستون و ارتباط های پیچیده حذف شده. تصویر ذیل رو ملاحظه کنید. این یه نمونه اسکیمای دیتامُدلِ دیتابیس مانگو دی بی هستش که دیتاهای ما رو در قالب مفهومی بنام Document یا سند ذخیره می کنه.

مهاجرت به دیتابیس های مُدرنِ NoSQL

همه با SQL آشنا هستیم و برامون ساده به نظر میاد اما در واقع SQL خیلی پیچیدست و سخت! تو سیستم های بزرگ مایه دردسرهای زیادی میشه، حتی نوشتن بعضی کوئری ها دانش زیادی میخواد تا درست و بدون خراب کاری کار کنه. اتفاقا NewSQL برای حل اینجور مشکلات تو SQL اومده. برعکس NoSQL سادست و مفاهیم خیلی اولیه و جمع و جوری داره. شما وقتی مدل جدولی SQL داری، مفاهیم پیچیده ریاضی و رابطه ها و نرمال سازی مطرح میشه. توی اکثر NoSQL ها اصن این چیزا نیست و بسیار ساده گرفتن موضوع رو. نقطه نظر دیگه راجع به ACID میشه، کنترل توازی و ACID توی دیتابیس های رابطه ای کارآسونی نیست و شما تنظیمات خاصی که دانش خاص میخواد داری، اما اکثر NoSql ها با دید دیگه ای ACID رو براورده میکنن که ساده تر بشه موضوع.

ابتدای کار، مهاجرت به دیتابیس های NoSQL برای مهندسان داده، دیتابیس کارها و معماران داده باسابقه کار آسونی نبود. تو اطرافیان خودم، دوستان، آشنایان و منتورها افرادی بودند که قریب 15 سال با دیتابیس های سنتی و قدرتمندی مثل Oracle, MySQL, SQL Server کار کرده بودن و DBA سازمان های بزرگ بودند. اونها یه عمر تو صنعت با این مفاهیم اصلی دیتابیس های رابطه ای RDBMS که بر مبنای تئوری جَبر رابطه ای اثر Codd بودن زندگی کرده بودن و مهاجرت به این تیپ دیتابیس ها که از اسیکمای سفت و محکم تبعیت نمی کردن، منطعف بودن، فقط تو قالب جداول و سطرها ذخیره نمیشدن، Join های سنتی توی اون ها معنایی خاصی نداشت یه چالش تلقی می شد، هرچند با توجه به قدرت و سبقه ای که این افراد داشتن می تونستن به این چالش ها فائق بیان.

نیاز به ارتباط و مصالحه SQL و NoSQL در قالب NewSQL

همینطور که پیش می رفت و دیتابیس های NoSQL توی صنعت جا باز کردن و اجتماعات خودشون رو تقویت کردن، توسعه دهنده های ارشد دیتابیس های مبتنی بر SQL سعی می کردن مفاهیم NoSQL رو توی خودشون به عنوان یه آپشن جدید جاساز 🙂 کنن، مثل SQL Server 2017 که امکان گراف دیتابیس رو معرفی کرد. از طرفی دیتابیس های NoSQL هم سعی می کردن خودشون رو بِهبود بودن، مشکلات و Bug هاشون رو برطرف کنن و یه جورایی مصالحه ای با دیتابیس های SQL داشته باشن. اینجا همون نقطه مصالحه فی مابین SQL و NoSQL هاست.

دیتابیس های جدیدی که امروزه با نام NewSQL ساخته شدن به منظور برقراری این مصالحه ساخته شدن. این تیپ دیتابیس ها

1. از مقیاس پذیری افقی پشتیبانی می کنن.
2. با حجم فزاینده بیگ دیتا اوکی هستند.
3. بعضی از مزایای دیتابیس های SQL رو دارن.

همین نوع دیدگاه باعث شد کمپانی های مطرح دنیا مثل Oracle و Microsoft که غول های دیتابیس در دنیا بودن و هستن بخشی قابل توجهی از رویکردشون رو در ذخیره سازی داده به سمت NewSQL سوق بدن و به قولی یه جورایی مهاجرت داشته باشن.

دیتابیس های NoSQL

طبعا نمیشه راهی که سالهای سال SQL رفته رو NoSQL ها چند ساله برن. از جمله دیتابیس های مطرح و آینده دار میشه به  

MemSQL
Clustrix
VoltDB
Pivotal
SAP HANA
NuoDB
Trafodion

اشاره داشت. VoltDB هم مثل Redis دیتا رو بصورت In-Memory نگهداری می کنه. 

مقایسه SQL, NoSQL, NewSQL

تو این قسمت می خوایم به مقایسه ای فی ما بین سه رویکرد SQL, NoSQL, NewSQL داشته باشیم و بیشتر باهاشون دست و پنجه نرم کنیم.

در واقع NewSQL ها در تلاش هستند همزمان Relaltional بودن RDBMS ها و Scalable بودن NoSQL ها را در یک دیتابیس جدید به ارمغان بیارن و این یعنی 

NewSQL = Relational + Scalability

امیدوارم براتون مفید بوده باشه.