در گذشته بیشتر داده های مربوط به اپلیکیشن های وب در بانک‌های اطلاعاتی رابطه ای از قبیل SQL Server ذخیره می‌شدند. اما نکته بسیار مهم اینکه استفاده کردن از بانک‌های اطلاعاتی رابطه ای و SQL Server تنها گزینه پیش روی ما نیست. در این درس قرار است در رابطه با دیگر روش های ذخیره کردن داده ها در برنامه های Asp.Net Core صحبت کنیم.
استفاده کردن از بانک های اطلاعاتی NoSQL
بانک های اطلاعاتی NoSQL از قبیل MongoDB یک روش متفاوت را برای ذخیره کردن آبجکت ها در دیتابیس دارند. دقت کنید که در بانک‌های اطلاعاتی رابطه ای یک آبجکت در قالب یک جدول و یا چندین جدول ذخیره شده و پروپرتی های مختلف مربوط به آن در قالب field ها و یا ستون های جداول ذخیره سازی می شوند. این موضوع در بانک‌های اطلاعاتی NoSQL متفاوت است. در بانک‌های اطلاعاتی NoSQL یک object graph کامل serialize شده و نتایج در بانک اطلاعاتی ذخیره می‌گردند. در رابطه با serialize کردن آبجکت ها می توانید از بسته ی آموزش ویدئویی سریالیزیشن در سی شارپ استفاده کنید. مزیت‌های استفاده کردن از این روش سادگی و Performance بالای آن است. ذخیره کردن یک آپدیت تک serialize شده به مراتب ساده تر از تجزیه کردن یک آبجکت به چندین جدول و relationship می باشد. علاوه بر این موضوع در ذخیره کردن داده ها به طور رابطه‌ای و در بانک‌های اطلاعاتی از قبیل SQL Server اغلب نیاز است که در بازیابی اطلاعات، دستورات پیوند لحاظ بشوند که از لحاظ Performance بسیار ضعیف عمل می کند. علاوه بر این موضوع به بروزرسانی کردن داده های مربوط به جداول نیز می‌تواند کارایی کمی را داشته باشد. این در حالی است که بازیابی کردن و سپس deserialize کردن یک آبجکت تک از یک بانک اطلاعاتی NoSQL که بر اساس کلید کار می کند به مراتب سریعتر و همچنین آسان تر می باشد. از این جهت بانک‌های اطلاعاتی NoSQL نسبت به بانک‌های اطلاعاتی رابطه ای از قبیل SQL Server امروز در بسیاری از برنامه های نوشته شده برای دنیای وب مورد استفاده قرار می گیرند. علاوه بر این موضوع عدم وجود lock و یا ماهیت ترنزکشن ها و یا حتی وجود نداشتن یک schema یک شکل باعث می‌شود تا بانک‌های اطلاعاتی NoSQL بتوانند در ماشین های مختلف به صورت کاملا مقیاس پذیر مورد استفاده قرار بگیرند و از دیتاست های بسیار بزرگ پشتیبانی کنند.
با این وجود بانک‌های اطلاعاتی رابطه ای نسبت به بانک‌های اطلاعاتی NoSQL مزیت های بیشماری دارند. برای مثال در بانک‌های اطلاعاتی رابطه ای از مفهوم normalization به منظور ایجاد کردن consistency و جلوگیری کردن از تکراری بودن داده ها استفاده می شود. این موضوع باعث می‌شود تا حجم بانک اطلاعاتی به مراتب کاهش پیدا کند و تعداد دستورات آپدیت بر روی داده های مشترک در دیتابیس کمتر بشود. در یک بانک اطلاعاتی جداول می توانند با یکدیگر رابطه داشته باشند و از همین جهت تغییر در هر جدول می‌تواند بازتاب خود را در جدولی که با آن در ارتباط هستند ثبت کند. این موضوع می‌تواند و به روزرسانی کردن و حتی بازیابی کردن داده ها به مراتب بهتر باشد. از طرفی در بانک‌های اطلاعاتی NoSQL به دلیل عدم وجود هیچ گونه رابطه ای و البته Serialize شدن object graphs به طور کامل گاهی ممکن است که برای به روز رسانی کردن نیاز باشد که آبجکت های متعددی را به روز رسانی کنیم تا داده‌ها به صورت یک شکل و یا Consistent دربیایند. این موضوع به مراتب Performance کمتری نسبت به بانک‌های اطلاعاتی رابطه ای خواهد داشت. علاوه بر این موجود در بانک های اطلاعاتی رابطه ای موضوعاتی از قبیل relational integrity با لحاظ کردن قوانینی از قبیل foreign key ها نیز پیاده سازی خواهد شد بانک‌های اطلاعاتی NoSQL چنین مفاهیم و قیودی را بر روی داده های خود نخواهند داشت.
یکی دیگر از پیچیدگی‌های بانک‌های اطلاعاتی NoSQL مکانیسم versioning می باشد. زمانی که پروپرتی های مربوط به یک آبجکت تغییر می کنند نمی توان از ورژن های قبلی آن آبجکت استفاده کرد و یا حتی آنها را Deserialized نمود بنابراین تمامی آبجکت های از قبل موجود می بایست که به روز رسانی بشوند تا schema مربوط به ورژن جدید آن آبجکت را دریافت کند. این موضوع در بانک‌های اطلاعاتی رابطه نیز اتفاق می‌افند. در بانک‌های اطلاعاتی رابطه ای تغییرات schema گاهی نیازمند ارسال update script ها و همچنین گاهی نیازمند بروز رسانی کردن اسکریپت ها و mapping ها می باشد. با این وجود تعداد رکوردهایی که می بایست در بانک‌های اطلاعاتی نویسی NoSQL به روزرسانی بشوند به مراتب بیشتر از تعداد رکوردهای نیازمند به روز رسانی در بانک‌های اطلاعاتی رابطه هستند. دلیل این موضوع نیز در این است که بانک‌های اطلاعاتی NoSQL دارای حجم زیادی از داده های تکراری می باشند.
موضوع دیگر اینکه که در بانک‌های اطلاعاتی NoSQL می توان چندین ورژن مختلف از آبجکت ها را ذخیره سازی کرد. این قضیه در بانک‌های اطلاعاتی رابطه ای که schema آنها به طور یک شکل و غیر قابل تغییر است امکان پذیر نخواهد بود. در چنین شرایطی برنامه باید در رابطه با وجود ورژن های مختلف و یا قدیمی تر از آبجکت ها مکانیزم مناسبی را اتخاذ کند و این موضوع خود باعث افزایش پیچیدگی برنامه خواهد شد.
مورد آخر اینکه که بانک‌های اطلاعاتی NoSQL اغلب مفاهیم ACID را در بانک‌های اطلاعاتی پیاده سازی نمی‌کنند. این موضوع باعث می‌شود تا بانک‌های اطلاعاتی NoSQL نسبت به بانک های اطلاعاتی رابطه ای Performance و Scalability بالاتری داشته باشند. به طور کلی از بانک‌های اطلاعاتی NoSQL در شرایطی استفاده می‌کنیم که دیتاست و آبجکت ها بسیار حجیم و بزرگ هستند و نمی‌توانند در ساختار نرمال شده بانک‌های اطلاعاتی رابطه ای ذخیره شوند. علاوه بر این موارد شما می توانید در یک نرم‌افزار هم از بانک‌های اطلاعاتی رابطه ای استفاده کنید و هم در کنار آنها از بانک‌های اطلاعاتی NoSQL بهره مند شوید. عبارت دیگر نرم افزار بر اساس نیازمندیهای که تعریف می‌کند می‌تواند در جایگاه صحیح از هر کدام از این دو گزینه بهره مند شود.
بررسی بانک اطلاعاتی Azure Cosmos DB
یک مثال بسیار مناسب برای بانک‌های اطلاعاتی NoSQL که برنامه نویسان فریم ورک .Netمی توانند از آن استفاده کنند Azure Cosmos DB می باشد. با استفاده از Azure Cosmos DB شما می توانید یک بانک اطلاعاتی مبتنی بر Cloud و از لحاظ schema کاملا انعطاف پذیر را دریافت کنید. Performance ،Azure Cosmos DB بسیار بالایی دارد و از قابلیت هایی از قبیل Availability بالا و elastic scaling و global distribution بهره مند می باشد. علیرغم اینکه بانک اطلاعاتی Azure Cosmos DB یک بانک اطلاعاتی NoSQL به حساب می‌آید، برنامه نویسان می توانند با دستورات و قابلیت‌های SQL به صورتی کاملاً آزادانه بر روی داده های JSON خود کار کنند. تمامی Resource های موجود در بانک اطلاعاتی Azure Cosmos DB در قالب فایل های JSON ذخیره می‌شوند. دو واژه بسیار مهم در کار کردن با Azure Cosmos DB را بهتر است که بشناسید. واژه items نمایانگر Resource هایی هستند که در اختیار شما قرار می گیرد و در واقع شامل متادیتا در رابطه با داکیومنت های مربوط به بانک اطلاعاتی NoSQL خواهند بود. واژه بعدی feeds است که در واقع به معنی مجموعه‌ای از آیتم ها خواهد بود. برای درک هر چه بهتر ارتباط ماهیت های مختلف در Azure Cosmos DB می توانید از تصویر زیر بهره مند شوید. به تصویر زیر نگاه کنید:
زبان پرس و جوی داده ها در Azure Cosmos DB بسیار ساده اما قدرتمند است. با استفاده از این زبان شما می توانید فایل های JSON خود را مورد پرس و جو قرار بدهید. زبان پرس و جوی Azure Cosmos DB زیر مجموعه از ANSI SQL می باشد و یکپارچگی کامل آبجکت ها و آرایه ها و object construction و function invocation و دیگر مفاهیم مربوط به JavaScript را شامل می‌شود.
دیگر گزینه‌های ذخیره‌سازی کردن داده ها
علاوه بر بانک‌های اطلاعاتی Relational و NoSQL که تا به اینجای کار بررسی شده‌اند، برنامه های نوشته شده با Asp.Net Core می‌توانند از سرویس Azure Storage به منظور ذخیره کردن داده های خود در قالب ها و فایلهای مبتنی بر Cloud که به صورت کاملا انعطاف پذیر و مقیاس پذیر عمل می‌کنند نیز بهره‌مند شوند. سرویس Azure Storage کاملاً Scalable و یا مقیاس پذیر است و از این جهت شما می توانید با حجم بسیار ناچیزی از داده‌ها کار را آغاز کرده و به مرور تا حد چندصد ترابایت داده را ذخیره سازی کنید. سطح ذخیره سازی کنید. سرویس Azure Storage به طور کلی از چهار نوع داده پشتیبانی می کند که لیست آنها را در قسمت زیر برای شما قرار داده ایم:
- از Blob Storage به منظور ذخیره کردن داده های متنی بدون ساختار و یا حتی ذخیره کردن داده های باینری مورد استفاده قرار می‌گیرد. واژه دیگری که به جای Blob Storage استفاده می‌شود object storage است.
- از Table Storage برای ذخیره کردن دیتاست های ساختارمند مورد استفاده قرار می‌گیرد.
- از Queue Storage به منظور ذخیره کردن پیام های مبتنی بر Queue مورد استفاده قرار می گیرند.
- از File Storage به منظور برقرار کردن دسترسی به فایل ها به صورت مشترک بین virtual machine های Azure و برنامه‌های on-premise پشتیبانی می‌شود.