راهنمای NoSQL برای توسعه دهندگان

اگر روند توسعه Backend و Big Data را دنبال می‌کنید، احتمالاً در سال‌های اخیر متوجه سروصدای پایگاه‌های داده NoSQL شده‌اید. برخی از افراد از این رویکرد به پایگاه داده الهام می گیرند، در حالی که برخی دیگر فکر می کنند که نوعی ترفند در آن پنهان است: مدل های داده در آنها مانند پایگاه های داده رابطه ای معمولی نیست، رابط های برنامه نویسی برنامه غیرعادی هستند، و برنامه ها اغلب نامفهوم هستند. در این مقاله من به شما خواهم گفت که چرا آنها در وهله اول ایجاد شدند، این پایگاه های داده NoSQL، چه مشکلاتی را حل می کنند و چرا به طور ناگهانی به پایگاه های داده مختلف زیادی نیاز است. اگر با NoSQL تازه کار هستید، ممکن است به بخش آخر مقاله، که انواع پایگاه داده NoSQL را فهرست می کند که به نظر من ارزش کاوش در ابتدا برای به دست آوردن درک کامل از این زمینه را دارند، علاقه مند باشید.

چرا ناگهان به یک پایگاه داده جدید نیاز داریم؟

ممکن است تعجب کنید که بپرسید: چه مشکلی در پایگاه داده های رابطه ای وجود دارد؟ نکته این است که آنها سال ها واقعاً خوب کار کردند، اما اکنون مشکلی وجود دارد که دیگر نمی توانند از عهده آن برآیند. بر اساس برخی پیش بینی ها، در سال 2018 بشریت 50000 گیگابایت داده در ثانیه تولید خواهد کرد. این حجم عظیمی از داده است! ذخیره سازی و جابجایی آن یک چالش مهندسی جدی است. بدتر از آن این است که این حجم به طور مداوم در حال افزایش است. همانطور که مشخص است، پایگاه های داده رابطه ای برای کار با حجم بسیار زیادی از داده ها مناسب نیستند. آنها برای اجرا بر روی یک دستگاه طراحی شده اند، و اگر می خواهید درخواست های بیشتری را انجام دهید، تنها گزینه خرید رایانه ای با رم بیشتر و پردازنده قوی تر است. متأسفانه، تعداد پرس و جوهایی که یک ماشین می تواند انجام دهد محدود است و برای کار توزیع شده در چندین ماشین، به فناوری پایگاه داده متفاوتی نیاز داریم. البته، برخی از خوانندگان در این مرحله می خندند و می گویند که دو روش پرکاربرد برای استفاده از چندین ماشین در مورد یک پایگاه داده رابطه ای وجود دارد: Replication و Sharding. این درست است، اما این روش ها برای مقابله با وظایف ما کافی نیست. Read Replication تکنیکی است که در آن هر به‌روزرسانی پایگاه داده به ماشین‌های دیگری که فقط می‌توانند درخواست‌های خواندن را رسیدگی کنند، منتشر می‌شود. در این حالت، تمام تغییرات توسط یک سرور انجام می شود که گره اصلی نامیده می شود، در حالی که سرورهای دیگر، که replicas خوانده می شوند، تنها کپی هایی از داده ها را نگهداری می کنند. کاربر می تواند از هر یک از ماشین ها بخواند، اما داده ها را فقط از طریق گره اصلی تغییر دهد. این یک روش راحت و بسیار محبوب است، اما فقط به شما امکان می دهد درخواست های خواندنی بیشتری را پردازش کنید و به هیچ وجه مشکل پردازش حجم مورد نیاز داده را حل نمی کند. Sharding یکی دیگر از روش های محبوب است که از چندین نمونه از یک پایگاه داده رابطه ای استفاده می کند. هر یک از آنها عملیات نوشتن و خواندن را برای بخشی از داده ها انجام می دهد. اگر یک پایگاه داده اطلاعات مشتریان را ذخیره کند، به عنوان مثال، با استفاده از اشتراک گذاری، یک ماشین می تواند تمام درخواست های مشتریانی را که نامشان با A شروع می شود، رسیدگی کند، ماشین دیگری می تواند تمام داده ها را برای مشتریانی که نامشان با B شروع می شود و غیره ذخیره کند. اگرچه اشتراک گذاری به شما امکان می دهد داده های بیشتری را ضبط کنید، مدیریت چنین پایگاه داده ای یک کابوس واقعی است: شما باید داده ها را در بین ماشین ها تراز کنید و کلاستر را در هر دو جهت در صورت نیاز مقیاس کنید. اگرچه از نظر تئوری ساده به نظر می رسد، اما درست کردن آن بسیار چالش برانگیز است.

آیا پایگاه داده های رابطه ای قابل بهبود هستند؟

فکر می کنم شما قبلاً به این باور رسیده اید که پایگاه داده های رابطه ای برای حجم داده های تولید شده در دنیای مدرن مناسب ترین نیستند. اگرچه، ممکن است هنوز تعجب کنید که چرا هیچکس هنوز یک پایگاه داده رابطه ای "بهتر" ایجاد نکرده است که بتواند به طور موثر در چندین ماشین اجرا شود. ممکن است به نظر برسد که این فناوری به سادگی هنوز توسعه نیافته است و پایگاه داده های رابطه ای توزیع شده خیلی زود ظاهر می شوند. افسوس که این اتفاق نخواهد افتاد. این از نظر ریاضی غیرممکن است و هیچ کاری نمی توان در مورد آن انجام داد. برای درک اینکه چرا اینطور است، باید به قضیه CAP (معروف به قضیه بروئر) نگاه کنید. در سال 1999 ثابت شد، و بیان می کند که یک پایگاه داده توزیع شده که بر روی چندین ماشین اجرا می شود، می تواند سه ویژگی زیر را داشته باشد: سازگاری - هر عملیات خواندن، نتایج آخرین عملیات نوشتن متناظر را برمی گرداند. اگر سیستم سازگار باشد، پس از نوشتن داده‌های جدید، خواندن داده‌های قدیمی که قبلاً رونویسی شده‌اند غیرممکن است. در دسترس بودن ( A vailability) - یک سیستم توزیع شده می تواند در هر زمان درخواست دریافتی را سرویس دهد و پاسخی بدون خطا برگرداند. تحمل پارتیشن - پایگاه داده همچنان به درخواست های خواندن و نوشتن پاسخ می دهد حتی زمانی که برخی از سرورهای آن به طور موقت قادر به برقراری ارتباط با یکدیگر نیستند. این خرابی موقت، شکست اتصال شبکه نامیده می شود و می تواند ناشی از عوامل مختلفی باشد، از مشکلات فیزیکی شبکه به دلیل کندی سرور گرفته تا آسیب فیزیکی به تجهیزات شبکه. همه این ویژگی‌ها مطمئناً مفید هستند، و ما واقعاً یک پایگاه داده می‌خواهیم که همه آنها را ترکیب کند. هیچ توسعه‌دهنده‌ی عاقلی نمی‌خواهد، مثلاً، دسترسی را بدون دریافت چیزی در ازای آن، رها کند. متأسفانه، قضیه CAP همچنین بیان می‌کند که نگهداری هر سه ویژگی به طور همزمان غیرممکن است. درک این امر ممکن است آسان نباشد، اما ممکن است. اول، اگر به یک پایگاه داده توزیع شده نیاز داریم، باید «تحمل قطع ارتباط» داشته باشد. در این مورد حتی بحث هم نمی شود. قطع ارتباط همیشه اتفاق می افتد و پایگاه داده ما باید با وجود این کار کند. حال بیایید درک کنیم که چرا نمی توانیم به ثبات و در دسترس بودن دست پیدا کنیم. تصور کنید ما یک پایگاه داده ساده داریم که روی دو ماشین اجرا می شود: A و B. هر کاربری می تواند در هر یک از ماشین ها بنویسد، پس از آن داده ها در ماشین دیگر کپی می شوند. حال تصور کنید که این ماشین ها به طور موقت قادر به برقراری ارتباط با یکدیگر نیستند و ماشین B قادر به ارسال یا دریافت داده ها به ماشین A نیست. اگر در این مدت زمان ماشین B یک درخواست خواندن از مشتری دریافت کند، دو گزینه دارد:

1. داده های محلی خود را پس بگیرید، حتی اگر جدیدترین آنها نباشد. در این مورد، اولویت به در دسترس بودن داده می شود (برای بازگرداندن حداقل برخی از داده ها، حتی موارد قدیمی).
2. خطای بازگشت در این مورد، سازگاری ترجیح داده می شود: مشتری داده های قدیمی را دریافت نمی کند، اما به هیچ وجه هیچ داده ای را دریافت نخواهد کرد.

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

پایگاه داده های NoSQL چگونه ثبات و در دسترس بودن را متعادل می کنند؟

ممکن است به نظر شما برسد که اگر پایگاه داده NoSQL را انتخاب کنید، همیشه یا برخی از داده های قدیمی و یا در صورت بروز هر گونه خرابی با خطا مواجه خواهید شد. در عمل، در دسترس بودن و سازگاری به هیچ وجه تنها گزینه های موجود نیستند. طیف گسترده ای از گزینه ها برای انتخاب شما در دسترس است. پایگاه داده های رابطه ای این گزینه ها را ندارند، اما NoSQL به شما اجازه می دهد تا اجرای پرس و جو را به روشی مشابه کنترل کنید. به هر طریقی، آنها به شما اجازه می دهند هنگام انجام عملیات نوشتن یا خواندن در پایگاه داده NoSQL دو پارامتر را تنظیم کنید: W - چند ماشین در خوشه باید ذخیره داده را هنگام انجام عملیات نوشتن تأیید کنند . هرچه تعداد ماشین‌هایی که داده‌های خود را در آن‌ها می‌نویسید بیشتر باشد، خواندن جدیدترین داده‌ها در عملیات خواندن بعدی آسان‌تر خواهد بود، اما همچنین زمان بیشتری طول می‌کشد. R - از چند ماشین می خواهید داده ها را بخوانید . در یک سیستم توزیع‌شده، توزیع داده‌ها به همه ماشین‌ها در یک خوشه ممکن است مدتی طول بکشد، بنابراین برخی از سرورها آخرین داده‌ها را خواهند داشت در حالی که برخی دیگر با تاخیر مواجه می‌شوند. هر چه تعداد ماشین هایی که داده ها از آنها خوانده می شود بیشتر باشد، شانس خواندن داده های فعلی بیشتر است. بیایید به یک مثال عملی نگاه کنیم. اگر پنج کامپیوتر در کلاستر خود دارید و تصمیم دارید که داده ها را فقط در یک کامپیوتر بنویسید و سپس داده ها را از یک کامپیوتر انتخاب شده به طور تصادفی بخوانید، احتمال اینکه داده های قدیمی را بخوانید 80 درصد است. از سوی دیگر، این کار از حداقل منابع استفاده خواهد کرد. بنابراین اگر داده‌های قدیمی برای شما خوب است، گزینه بدی نیست. در این حالت، پارامترهای W و R برابر با 1 هستند. از سوی دیگر، اگر داده‌ها را برای هر پنج ماشین در یک پایگاه داده NoSQL بنویسید، می‌توانید داده‌ها را از هر ماشینی بخوانید و تضمین می‌کنید که هر بار داده‌های به‌روز دریافت کنید. انجام همان عملیات روی تعداد بیشتری از ماشین ها زمان بیشتری می برد، اما اگر اطلاعات به روز برای شما مهم است، می توانید این گزینه را انتخاب کنید. در این حالت، W = R = 5. حداقل تعداد خواندن و نوشتن مورد نیاز برای سازگاری پایگاه داده چقدر است؟ در اینجا یک فرمول ساده وجود دارد: R + W ≥ N + 1 ، که در آن N تعداد ماشین‌های موجود در خوشه است. این بدان معنی است که با پنج سرور، می توانید R = 2 و W = 4، یا R = 3 و W = 3، یا R = 4 و W = 2 را انتخاب کنید. نوشته شده است، خواندن همیشه حداقل از یک دستگاه با داده های به روز انجام می شود. سایر پایگاه‌های داده مانند DynamoDB محدودیت‌های متفاوتی دارند و فقط اجازه نوشتن یکنواخت را می‌دهند. هر قطعه داده در سه سرور ذخیره می شود و زمانی که هر داده ای نوشته می شود، در دو تا از سه ماشین نوشته می شود. اما هنگام خواندن داده ها، می توانید یکی از دو گزینه را انتخاب کنید:

1. خواندن کاملاً سازگار، که در آن داده ها از دو دستگاه از سه دستگاه خوانده می شوند و همیشه آخرین داده های نوشته شده را برمی گرداند.
2. یک خواندن ثابت نهایی، که در آن یک ماشین به طور تصادفی انتخاب می شود که از آن داده ها را بخواند. با این حال، این ممکن است به طور موقت داده های قدیمی را بازگرداند.

چرا تعداد زیادی پایگاه داده NoSQL وجود دارد؟

اگر آخرین اخبار در زمینه توسعه نرم افزار را دنبال کنید، احتمالاً در مورد بسیاری از پایگاه های داده NoSQL مختلف مانند MongoDB، DynamoDB، Cassandra، Redis و بسیاری دیگر شنیده اید. شاید از خود بپرسید: چرا به تعداد زیادی پایگاه داده NoSQL مختلف نیاز داریم؟ دلیل آن ساده است: اینکه پایگاه داده های مختلف NoSQL برای حل مشکلات مختلف طراحی شده اند. به همین دلیل است که تعداد پایگاه های داده رقیب بسیار زیاد است. پایگاه داده های NoSQL به چهار دسته اصلی تقسیم می شوند:

پایگاه های اطلاعاتی سند گرا

این پایگاه‌های داده توانایی ذخیره اسناد تودرتو پیچیده را فراهم می‌کنند، در حالی که بیشتر پایگاه‌های داده رابطه‌ای فقط از ردیف‌های یک بعدی پشتیبانی می‌کنند. این ویژگی در بسیاری از موارد می تواند مفید باشد، برای مثال زمانی که لازم است اطلاعات یک کاربر با چندین آدرس در سیستم ذخیره شود. هنگام استفاده از یک پایگاه داده سند گرا، در این مورد می توانید به سادگی یک شی پیچیده حاوی آرایه ای از آدرس ها را ذخیره کنید، در حالی که در یک پایگاه داده رابطه ای باید دو جدول ایجاد کنید: یکی برای اطلاعات کاربر و دیگری برای آدرس ها. پایگاه داده های سند گرا فاصله بین مدل شی و مدل داده را پر می کنند. برخی از پایگاه‌های داده رابطه‌ای، مانند PostgreSQL، اکنون از ذخیره‌سازی سند گرا نیز پشتیبانی می‌کنند، اما اکثر پایگاه‌های داده رابطه‌ای هنوز فاقد این قابلیت هستند.

پایگاه های داده کلید/مقدار

پایگاه داده های کلید/مقدار معمولاً ساده ترین مدل NoSQL را پیاده سازی می کنند. در اصل، آنها یک جدول هش توزیع شده را در اختیار شما قرار می دهند که به شما امکان می دهد داده ها را در یک کلید مشخص بنویسید و با استفاده از آن دوباره آن را بخوانید. پایگاه داده های کلید/مقدار بسیار مقیاس پذیر هستند و تأخیر قابل توجهی کمتری نسبت به سایر پایگاه های داده دارند.

پایگاه داده های نموداری

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

پایگاه های داده ستونی

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

کدام پایگاه داده را باید انتخاب کنید؟

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

چگونه قرار است این همه را یاد بگیرید؟

با تعداد زیادی پایگاه داده ، یادگیری همه آنها می تواند یک کار غیرممکن به نظر برسد. خبر خوب: شما مجبور نیستید این کار را انجام دهید. تنها چند نوع اساسی از پایگاه داده NoSQL وجود دارد، و اگر نحوه کار آنها را بدانید، درک بقیه بسیار آسان تر خواهد بود. همچنین، برخی از پایگاه های داده NoSQL بسیار بیشتر از سایرین استفاده می شوند، بنابراین بهتر است تلاش خود را بر روی محبوب ترین راه حل ها متمرکز کنید. در اینجا لیستی از رایج ترین پایگاه داده های NoSQL استفاده می شود که فکر می کنم باید نگاهی به آن بیندازید:

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


2. DynamoDB . اگر از خدمات وب آمازون (AWS) استفاده می کنید، بهتر است درباره DynamoDB اطلاعات بیشتری کسب کنید. این یک پایگاه داده بسیار قابل اعتماد، مقیاس پذیر، با تاخیر کم با مجموعه ویژگی های غنی و یکپارچه سازی با بسیاری از خدمات AWS دیگر است. بهترین بخش این است که لازم نیست خودتان آن را مستقر کنید. راه اندازی یک خوشه DynamoDB مقیاس پذیر که می تواند هزاران پرس و جو را مدیریت کند، تنها چند کلیک فاصله دارد. اگر این مورد علاقه شماست، می توانید نگاهی به این دوره بیندازید .


3. Neo4j . رایج ترین پایگاه داده گراف. این یک راه حل مقیاس پذیر و پایدار مناسب برای کسانی است که می خواهند از یک مدل داده گراف استفاده کنند. اگر می خواهید بیشتر بدانید، با این دوره شروع کنید .


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

در سال 2018 با NoSQL

پایگاه های داده NoSQL یک زمینه وسیع و به سرعت در حال رشد هستند. آنها به شما این امکان را می‌دهند که مقادیری از داده‌هایی را که قبلاً تصور نمی‌شد ذخیره و پردازش کنید، اما هزینه‌ای دارد. این پایگاه‌های اطلاعاتی بسیاری از ویژگی‌هایی که در پایگاه‌های داده رابطه‌ای با آن‌ها آشنا هستید را ندارند، و راه‌اندازی برای استفاده از آن‌ها ممکن است دشوار باشد. اما هنگامی که آنها را به دست آوردید، می توانید پایگاه داده های مقیاس پذیر و توزیع شده ای ایجاد کنید که می تواند حجم شگفت انگیزی از درخواست های خواندن و نوشتن را مدیریت کند، که می تواند بسیار مهم باشد زیرا حجم داده های بزرگتر و بیشتری تولید می شود. اصل: https://simpleprogrammer.com/guide-nosql-software-developers/