در قسمت 1، ظهور پایگاه‌های داده بدون سرور، از سری «پایگاه‌های داده برای توسعه‌دهندگان فرانت‌اند»، در مورد موانع و تله‌های مقیاس‌گذاری و نگهداری پایگاه‌های داده‌تان صحبت کردیم. ما از جایگزین‌های ساده‌تر و تخصصی‌تر مانند سیستم‌های مدیریت محتوا و صفحات گسترده به پایگاه‌های داده خود میزبان و در نهایت به پایگاه‌های داده بدون سرور رفتیم.
امروز به عمق سوراخ خرگوش می رویم. ما مفاهیمی را بررسی خواهیم کرد تا شما را مجهز کنیم تا نظرات خود را در مورد اینکه کدام نوع پایگاه داده با نیازهای خاص شما مطابقت دارد داشته باشید. و این مهم است که از قبل تاکید کنید: هیچ پاسخ درستی وجود ندارد. هر پایگاه داده دارای مجموعه ای از معاوضه ها و مزایای خاص خود است. اگر چیزی شبیه یک راه حل “یک اندازه مناسب” به نظر می رسد، مراقب باشید: ممکن است چیزی را از دست بدهید!
آناتومی یک پایگاه داده
قبل از شروع، مهم است که تأکید کنیم آنچه که ما به طور کلی به عنوان “پایگاه های داده” از آن یاد می کنیم در واقع “سیستم های مدیریت پایگاه داده (DBMS)” DBMS قطعه ای از نرم افزار است که کاربر را قادر می سازد تا به صورت ارگونومیک تری اطلاعات را در مجموعه ای از داده ها بنویسد، بخواند، حذف کند یا به روز کند. برای این سری، ما عمدتا بر روی DBMS های رابطه ای و غیر رابطه ای تمرکز خواهیم کرد. انواع دیگری نیز وجود دارد که همگی بر اساس ساختار داده‌هایشان طبقه‌بندی می‌شوند، اما رابطه‌ای و غیررابطه‌ای برای توسعه وب با هر معیاری رایج‌ترین آنها هستند.
هر دو رابطه ای (R) و DBMS غیر رابطه ای (NR). برای قسمت هایی که آنها را تشکیل می دهند اصطلاحات مختلفی دارند. چنین مؤلفه‌هایی در تعریف تقریباً قابل تعویض هستند، و به همین دلیل است که معمولاً می‌توانید از برنامه‌نویسی بشنوید که به سند (اصطلاح NR) به عنوان «جدول» اشاره می‌کند که ساختار معادل رابطه‌ای آن است. از گیج کردن آنها نترسید. آنها اغلب به اندازه کافی ظاهر می شوند تا این اضافه بار شناختی به سرعت با استفاده از بین برود. علاوه بر این، هنگامی که با تفاوت‌های هر ساختار داده بیشتر آشنا شدید، احتمالاً متوجه خواهید شد نباید به جای یکدیگر استفاده شود زیرا تفاوت هایی بین آنها وجود دارد. اما در حال حاضر و به خاطر سادگی، بیایید روی شباهت ها تمرکز کنیم:
- طرحواره
این توصیف پایگاه داده (مانند یک طرح اولیه) است که چشم انداز پایگاه داده را در یک زبان پشتیبانی شده توصیف می کند. این مورد مورد نیاز پایگاه‌های داده رابطه‌ای است، و اگرچه توسط DBMS غیر رابطه‌ای مورد نیاز نیست، بسیاری از رابط‌ها امکان تعریف آن را نیز فراهم می‌کنند. - جداول (R/NR)، مجموعه ها (NR)
این ساختار داده های منطقی است که مرتب نشده است. یک مثال مرتبط از این می تواند یک جدول صفحه گسترده یا یک گروه (مجموعه) از اشیاء JSON باشد. - پایگاه های داده (R/NR)
این گروه بندی منطقی داده ها است. شما جداول خود را در پایگاه داده ها (پایگاه داده کاربر، پایگاه داده فاکتورها) و اسناد خود را در فهرست ها بر اساس نحوه پرس و جو در آنها گروه بندی می کنید.
کلیدها و ستونها
برای استفاده از یک مثال آشناتر، بیایید یک شی JSON را به عنوان مثال در نظر بگیریم:
{
"name": "Atila"
"role": "DX Engineer at Xata"
}
با توجه به JSON، یک ستون با جفت کلید-مقدار (ستون نام دارد ارزش “Atila”)، و کلید از همان معنای کلید JSON پیروی می کند نام به مقدار “Atila” دسترسی خواهد داشت.
یک جدول دارای ستون هایی است و نام هر ستون تعیین کننده کلیدی است که با آن می توانید به یک مقدار در یک رکورد دسترسی داشته باشید.
علاوه بر تعریف فوق، انواع خاصی از کلیدها وجود دارد. چنین کلیدهایی نقش ویژه ای در طرحواره پایگاه داده شما و نحوه تعامل شما با داده های خود دارند. اینها را عاقلانه تعریف کنید: هر تغییر حداقلی در آنها را می توان تغییری قطعی در لایه داده شما در نظر گرفت.
- کلیدهای منحصر به فرد (بریتانیا)
کلیدهایی که بین رکوردهای روی میز منحصر به فرد هستند. آنها هم قبول می کنندnull. - کلیدهای اصلی (PK)
این یک نوع خاص از کلید منحصر به فرد است. فقط یک کلید اصلی در هر جدول می تواند وجود داشته باشد و هرگز نمی تواند باشدnull(کلیدهای اصلی همیشه در نظر گرفته می شوندrequired). کلیدهای اصلی نیز به طور پیش‌فرض ایندکس می‌شوند و به پرسش‌هایی که می‌خواهند مقدار را فیلتر کنند، کمک می‌کنند. - کلیدهای خارجی (FK)
هنگامی که یک رابطه بین جداول وجود دارد، کلیدها به عنوان کلیدهای خارجی در جدول خارجی نشان داده می شوند.
مثال کلید خارجی: اگر هر کدام author در یک نویسندگان جدول دارد posts (و نوشته ها جدول دیگری است) post.title FK در خواهد بود نویسندگان. و محل اتصال بین نویسندگان و نوشته ها a نامیده می شود رابطه.
نقشه برداری DBMS شما
هنگامی که به ساختارهای داده های مختلف نگاه می کنید و DBMS خود را انتخاب می کنید، آماده هستید تا اولین اتصال را از لایه داده خود به لایه برنامه خود بکشید. و ناگهان متوجه شدید که آوردن داده ها از پایگاه داده به سمت کلاینت (یا حتی در برخی موارد به API سمت سرور) کار چندان ساده ای نیست.
در اینجا ORM (نگاشت رابطه ای شی) و ODM (نگاشت سند شی) به تجربه توسعه دهنده شما کمک می کند. پریسما احتمالاً پرکاربردترین ORM در حال حاضر است، در حالی که مانگوس دارای بزرگترین پایگاه کاربر ODM است. مهم است که توجه داشته باشید که آنها برای اتصال به پایگاه های داده الزامی نیستند. با این حال، اگر مراقب نحوه ساخت پرس‌و‌جوهای خود باشید (برخی موارد خاص می‌توانند مشکلات عملکردی را در حساب انتزاع ارائه دهند)، زندگی شما را آسان‌تر می‌کنند و واکشی یا نوشتن داده‌ها را بسیار ارگونومیک‌تر می‌کنند.
وقتی صحبت از پایگاه داده های بدون سرور می شود، نیاز به آنها کمی مشکوک تر می شود. و این به این دلیل است که بسیاری از این پایگاه‌های داده یک کیت توسعه نرم‌افزار (SDK) با پشتیبانی رسمی را در اختیار کاربران قرار می‌دهند. مسافت پیموده شده شما بسته به SDK متفاوت خواهد بود، اما آنها تمایل دارند که ویژگی بزرگی با ORM ها و ODM ها همپوشانی داشته باشند، به خصوص در پایگاه داده هایی که لایه داده را در پشت یک API نگه می دارند.Xata، مثلا). به این ترتیب، نیازی به نگرانی در مورد ترجمه پرس و جوهای خود نخواهید داشت و می توانید ارگونومی معادل بین SDK و ORM را درخواست کنید.
مفاهیم رایج
در این قسمت از سری ما، یاد می گیریم که هنگام انتخاب پشته برای لایه های داده خود به دنبال چه چیزی باشیم. درک مفاهیم رایج در مورد نگهداری و انتخاب یک DBMS ضروری است (از اینجا به بعد، ما دوباره به آنها به عنوان “پایگاه های داده” اشاره می کنیم تا با بقیه جهان سازگاری داشته باشند).
بخش‌های بعدی آنقدر عمیق نمی‌شوند که بپرید و شغلی به‌عنوان مدیر پایگاه داده (DBA) پیدا کنید، اما امیدواریم که مهمات کافی برای شرکت در گفتگو با کارشناسان و شناسایی بهترین راه‌حل برای موارد استفاده خود به شما ارائه دهد. این مفاهیم برای هر نوع لایه داده، از یک صفحه گسترده گرفته تا یک پایگاه داده خود میزبان و حتی به یک پایگاه داده بدون سرور. آنچه متفاوت خواهد بود این است که هر راه حل چگونه متغیرهای در هم تنیده در این پارادایم ها را متعادل می کند.
مهمترین مفاهیم، برای شروع، سازگاری، در دسترس بودن و تحمل پارتیشن هستند. اگر با هم ارائه شوند بهتر درک می شوند زیرا تعادل بین آنها به میزان قابل پیش بینی بودن داده های شما در زمینه های مختلف کمک می کند.
قضیه CAP
این قضیه رابطه بین 3 جزء در یک سیستم توزیع شده را توصیف می کند: سازگاری، در دسترس بودن، و تحمل پارتیشن (CAP). خلاصه کردن نتیجه کلی آسان است: هر سیستمی فقط می تواند 2 مورد از این مؤلفه ها را همزمان در نظر بگیرد. اگرچه این یک جمله ساده است، اما این ایده نیاز به کمی باز کردن بسته بندی دارد.
سازگاری (C)
در قیود قضیه CAP، “ثبات” به طور مستقیم به داده ها اشاره دارد. هنگامی که مشتریان مختلف یک درخواست را ارائه می دهند، پاسخ یکسانی دریافت می کنند. هنگامی که یک درخواست کتبی پذیرفته و تأیید شد، همه کاربران به طور همزمان به این اطلاعات به روز دسترسی خواهند داشت.
در دسترس بودن (A)
هر درخواست پاسخی با داده دریافت خواهد کرد. بدون خطا. با این حال، هیچ قولی در مورد به روز بودن یا نبودن داده ها وجود ندارد. بسته به اینکه آیا این با سازگاری © یا تحمل پارتیشن (P) جفت می شود، رفتار متفاوتی خواهید داشت.
تحمل پارتیشن (P)
“پارتیشن” زمانی است که ارتباط بین دو گره در یک سیستم قطع شود. قضیه CAP اساساً توصیف می کند که چگونه یک سیستم پارتیشن را تحمل می کند: اجرای در دسترس بودن (سیستم AP) یا اجرای سازگاری (سیستم CP). صرف نظر از اینکه یک سیستم چقدر کوچک است، پارتیشن ها همیشه می توانند اتفاق بیفتند. بنابراین چیزی به نام سیستم CA وجود ندارد.
برای ارائه یک مثال گرافیکی تر از هر سیستم، می توانیم موارد زیر را در نظر بگیریم:
- سیستم AP
گره دیگری یک کپی از داده ها دارد. کاربر اطلاعات را پس می گیرد، اما بدون قولی مبنی بر اینکه 100٪ درست (به روز) باشد. معمولا با اجرا می شود DynamoDB، کاساندرا، و غیره. - سیستم CP
بازگشت خطا و پذیرش معامله غیرممکن است. معمولاً با DBهای خرد شده سنتی پیاده سازی می شود، سیتوس، مثلا.
اگرچه قضیه CAP محبوب است و اغلب به آن اشاره می‌شود، می‌توان آن را ناقص در نظر گرفت زیرا موقعیت‌های فراتر از پارتیشن شبکه را در نظر نمی‌گیرد. به خصوص امروزه، با شبکه‌های تحویل محتوای با دسترسی بالا (CDN) و اتصال شدید، مهم است که تأخیر و جنبه‌های عمیق‌تر سازگاری (خطی‌سازی و سریال‌سازی) را در نظر بگیریم.
سردرگمی سازگاری
خنده دار است که چگونه “ثبات” اصطلاحی است که معانی را بر اساس زمینه تغییر می دهد. بنابراین، در قضیه CAP، همانطور که قبلاً دیدیم، همه چیز به داده‌ها مربوط می‌شود و اینکه یک کاربر بدون توجه به اینکه به کدام پارتیشن می‌رسد، چقدر قابل اعتماد به همان درخواست پاسخ می‌دهد. هنگامی که یک قدم از سیستم خود فاصله می گیریم، یک دیدگاه جدید باعث می شود که بپرسیم: «چگونه همواره آیا عملیات همزمان را انجام خواهیم داد؟». و درست مانند آن، قضیه CAP به اندازه کافی پیچیدگی های عملکرد در مقیاس را توصیف نمی کند.
معنای سومی از “ثبات” وجود دارد که ما آن را برای بعد ذخیره می کنیم. این بخشی از مخفف دیگر (ACID) است. اگر پاراگراف آخر باعث شد سرتان را خارانید، نمی‌توانم به اندازه کافی توصیه کنم.افکار ناسازگار در مورد سازگاری پایگاه دادهنوشته الکس دیبری.
قضیه PACELC
سه حرف اول همان CAP است که تازه مرتب شده است. “ثبات” در قضیه PACELC عمیق تر از قضیه CAP است. آن را دنبال می کند مدل سازگاری، که قرارداد بین یک فروشگاه داده و یک سیستم را تعیین می کند. برای اینکه کارها کمتر پیچیده شود، PACELC an را در نظر بگیرید افزونه قضیه CAP
PACELC علاوه بر درخواست از توسعه‌دهنده برای استراتژی برای رویداد یک پارتیشن شبکه، همچنین در نظر می‌گیرد که وقتی سیستم هیچ پارتیشنی ندارد (شبکه سالم) چه اتفاقی می‌افتد.
ELC مخفف موارد دیگر: تأخیر یا سازگاری؟
- تاخیر: آیا می توانید یک پاسخ بیات گهگاهی را به خاطر عملکرد بپذیرید؟
- ثبات:
- خطی سازی: آیا قبل از در نظر گرفتن تراکنش انجام شده، تأخیر بالاتری را برای همگام سازی داده ها در تمام گره های یک شبکه می پذیرید؟
- سریال پذیری: در صورت تراکنش های همزمان روی داده های یکسان، آیا آنها را به صورت موازی یا در یک صف انجام می دهید؟
به همین دلیل، به نظر من PACELC مدل ذهنی بهتری برای این دوره جدید از پایگاه‌های داده بدون سرور است. وقتی سالم است، طبقه بندی اسکالر «AP» یا «CP» نیست. طیفی را می‌پذیرد زیرا تأخیر می‌تواند زیاد باشد یا نباشد، و سازگاری نیز می‌تواند سطوح مختلفی داشته باشد.
هنگامی که شروع به صحبت در مورد انواع پایگاه های داده و ساختار داده آنها می کنیم و تضمین می کند که هر کدام می توانند ارائه دهند، همچنین در مورد معماری سیستم و اینکه چگونه معماری شما می تواند معاوضه ها را کاهش دهد، صحبت خواهیم کرد، در حالی که حتی با اعمال یکپارچگی، می توانید برای یک کم تلاش کنید. سناریوی تاخیر
بعدا می بینمت
با آن، من معتقدم که ما آماده هستیم تا بحث های خود را در مورد تفاوت بین هر نوع پایگاه داده محدود کنیم. علاوه بر این، می توان انتظارات را در مورد هر راه حلی که اتخاذ شده است، مورد بحث و بررسی قرار داد و معماری ها را به صورت جداگانه تحلیل کرد. از این پس بر روی پایگاه داده های رابطه ای و غیر رابطه ای تمرکز خواهیم کرد.
در چند روز، در ما فصل آخر، تفاوت های بین NoSQL و SQL را پوشش خواهیم داد: چه تضمینی باید انتظار داشت، چه معنایی برای داده های شما دارد و چگونه بر گردش کار توسعه تأثیر می گذارد. سپس ما آماده خواهیم بود تا مستقیماً به پایگاه داده های بدون سرور و آنچه در آینده انتظار داریم بپریم. من نمی توانم صبر کنم!
طبق معمول، با خیال راحت به من برس با بازخورد، پرسش و/یا درخواست برای قسمت بعدی.
(vf، yk، il)
