دیتابیس های SQL

مزایا

1. رفع اشکالات در طول سالیان جاری
2. کارآمدی بسیار بالا
3. کاملا شناخته شده
4. توانایی انجام عملیات های پیچیده
5. داشتن ابزارهای متنوع

معایب

1. محدودیت سخت افزاری
2. عدم تحمل خطا
3. عدم توانایی مقیاس پذیری افقی
4. هزینه بالا
5. عدم پشتیبانی از داده های Sparse: فرض کنید بخواهید یک ماتریس 100000000 در 10000000 را در SQL ذخیره کنید که فقط 1000 نقطه آن Fill شده است و ما بقی Null هستند. تصور کنید چه فشاری قرار است سرور متحمل شود.
6. عدم پشتیبانی از داده های بدون ساختار
7. تحمل هدررفت زمان زیاد در صورت تغییر ارتباطات و کلیدهای اصلی در جداول

دیتابیس های NoSQL

در واقع NoSQL نگاه جدیدی به فرآیند ذخیره سازی داده دارد که داده ها را بصورت Key:Value ذخیره می کند. در اینجا ما بسیاری از امکانات SQL را نداریم. Foreign Key نداریم. دیتای ما غالبا De-Normalized می باشد، مساله ای که ما در SQL در نقطه مقابلش تلاش می کردیم که داده را در سطوح مختلف از 1NF تا … نرمالسازی کنیم. Secondary Key موجود نیست و مفهوم Transaction عملا ملغی است و مهمترین نکته اینکه فیت محیط های Distribute می باشند.

1. خب Join معنای خاصی ندارد اما ممکن است بعضی دیتابیس ها امکان Join را به ما بدهند اما با امکانات Join که در امثال دیتابیس های اوراکل و SQL Server و MySQL می بینیم متفاوت است.
2. افزونگی فراوان داریم
3. معمولا حداقل Replica Factor = 3 می باشد.
4. امکان ذخیره سازی داده های Sparse فراهم است.
5. بصورت پیش فرض از کلاستر استفاده می کنند اما ممکن است به صورت Single Server هم پیاده سازی شوند.
6. به منظور صرفه جویی در مصرف هزینه که Affordability داشته باشیم از Commodity Hardware استفاده می کنیم. (کامپیوترهای ارزان قیمت)
7. قابلیت مقیاس پذیری بصورت افقی را دارند.

تئوری CAP 

یک تئوری به نام CAP داریم که می گوید هر سامانه داده ای که طراحی کنیم روی یکی از ضلع های این مثلث قرار می گیرد.

در این بین RDBMS ها AC دارند که به ترتیب به محض اینکه یک Request روی داده می زنیم در لحظه مشخص Response مون رو می گیریم و به محض اینکه داده رو نوشتیم قابلیت خواندن پیدا می کند. سیستم هایی مثل Amazon Dynamo و دیتابیس هایی که از روی اون ساخته شدن مثل Cassandra، هم AP دارند. Availability صدردصد دارند به همراه Partition Tolerance اما Consistency بصورت صدردصد ندارند. بعنوان مثال یه کلاینت که Write می کند کلاینت بعدی ممکن است دیتای قدیمی را مشاهده کند. البته Consistency در Cassandra قابل تنظیم است و می تونیم بگیم Partition Consistency نمی خوایم و و Full Consistency می خوایم. اگر این کارو کنیم انگار این دیتابیس رو نابود کردیم!!! و دیگه قابل استفاده نیست.  (ما نمی تونیم خاصیت ذاتی یک موجودیت رو دستخوش تغییراتمون کنیم). امثال BigTable و HBase که از روی اون ساخته شدن دارای Consistency و Partition Tolerance هستند اما در رابطه با دیتابیس HBase باید گفت فاقد Availability است یعنی ممکن است کلاینت به دیتابیس مراجعه کند و پیغام Retry را مشاهده کند چرا که شاید سرورش Down باشد.