در این مقاله، اولین قسمت از مجموعه «پایگاه‌های اطلاعاتی برای توسعه‌دهندگان فرانت‌اند»، آتیلا فاسینا به شما کمک می‌کند تا مفاهیم پشت معماری پایگاه‌داده را درک کنید تا از آنها به طور قابل اعتماد استفاده کنید و اطلاعاتی را در مورد پایگاه‌های داده بدون سرور روشن کنید.
به عنوان توسعه دهندگان فرانت اند، ما نقش اساسی را درک می کنیم داده ها در کارهای روزمره ما بازی می کند. ممکن است از یک API خارجی، یک CMS یا حتی یک صفحه گسترده باشد. اما خدای نکرده در مورد راه اندازی پایگاه های اطلاعاتی صحبت کنیم.
آن روزها تمام شد. با محبوب شدن پایگاه داده های بدون سرور، ایجاد یک معماری تمام پشته با مقیاس عمودی و افقی، در دسترس بودن بالا و سازگاری ضد گلوله هرگز آسان تر نبوده است.
برای بهره مندی کامل از مزایای چنین معماری، درک تصمیماتی که گرفته می شود ضروری است برای شما. همانطور که مانترا “یادگیری جاوا اسکریپت، نه یک چارچوب” رایج شد، ما نیز باید مفاهیم پشت معماری پایگاه داده را درک کنیم تا بتوانیم به طور قابل اعتماد از آنها استفاده کنیم. بنابراین، به بخش اول ما خوش آمدید “پایگاه های اطلاعاتی برای توسعه دهندگان فرانت اند” سلسله.
این مجموعه قرار نیست شما را به یک متخصص در سیستم های توزیع شده تبدیل کند یا قادر به پرش به نقش مدیر پایگاه داده باشد، اما مفاهیم، اصطلاحات و کلمات اختصاری را که هنگام آماده شدن برای انتخاب پشته بعدی خود با آنها روبرو خواهید شد، روشن می کند. آن را به عنوان یک آغازگر در پایگاه داده (بدون سرور) ببینید. امیدواریم که به شما فشار وارد کند به سوراخ خرگوش و شما را در پیوستن به گفتگوها برای ارزیابی معاوضه برای راه حل های مختلف مطمئن سازد.
صفحات گسترده و سیستم های مدیریت محتوا
چی؟! صفحات گسترده؟ خب بله. رابط کاربری (شما و من، یا U و من، یا UI) کاملا شبیه به یک پایگاه داده است. صفحات گسترده جدولی را در اختیار شما قرار می دهند که در آن داده ها را ذخیره کنید. در برخی موارد، آنها فقط به شما اجازه می دهند تا انواع داده های خاصی را در هر ستون تعریف کنید. آشنایی‌ها وجود دارد، اما صفحه‌گسترده‌ها پس از باز کردن هود، پایان ناگهانی پیدا می‌کنند.
در دسترس بودن مشکوک است: صفحه‌گسترده‌ها برای این منظور نیستند خدمت محتوا، فقط فروشگاه محتوا. برای شروع، آنها به برنامه‌ای که در مقیاس بزرگ می‌شود، انرژی نمی‌دهند، و ممکن است در مورد اطمینان از یکپارچگی داده‌ها از برخی بهترین شیوه‌ها پیروی نکنند. تا همین اواخر، آنها سریعترین راه برای شروع با برخی از لایه های داده بودند. اما در حال حاضر، هیچ کاربردی برای یک برنامه وجود ندارد نه برای استفاده از یک پایگاه داده واقعی (بدون سرور) (در ادامه بیشتر در این مورد).
آ سیستم مدیریت محتوا (CMS) نوع دیگری از پایگاه داده است. “محتوا” نوع خاصی از داده است که CMS در آن تخصص دارد. این اطلاعات به کاربر (توسعه‌دهنده) انتزاعات کافی برای تسهیل مدیریت چنین داده‌هایی تا جایی که پایگاه داده زیربنایی نگران کننده نباشد، ارائه می‌دهد. این قابلیت تحویل، در دسترس بودن و یکپارچگی داده های شما را کنترل می کند. اما هر چه انتزاع سنگین تر باشد، مبادله بالاتر است. انواع داده‌ها محدود به آنچه که CMS به شما می‌دهد محدود می‌شود، حتی اکثراً معماری خود را برای مدیریت روابط، پرس و جوها، انواع و غیره تحمیل می‌کنند. البته، هنوز موارد استفاده قابل توجه و قابل‌توجهی برای CMSها وجود دارد، و آنها به کار نمی‌روند. هر جا. بنابراین، تا زمانی که مطمئن باشید که اینطور است شما استفاده از مورد، شما خوب با یکی.
دردهای رشد
اگر مسیر ساده تر و «انتزاعی» یک صفحه گسترده یا یک CMS را به عنوان منبع حقیقت خود انتخاب کنید و داده های شما شروع به متنوع شدن کند، موانع ظاهر می شوند. اولین مشکل یک صفحه‌گسترده معمولاً مربوط به API اصلی است، اغلب برای ترافیک بیشتر برنامه‌های با اندازه متوسط در نظر گرفته نشده است، و سپس اولین مکالمه‌های بازسازی مجدد وجود دارد.
با یک CMS، API ها معمولا مشکلی ندارند، اما مدیریت داده ها می تواند مشکل باشد. همانطور که یک برنامه رشد می کند و داده ها متنوع می شوند، برخی از آنها در نهایت وجود ندارند محتوا دیگر و ممکن است بیشتر به منطق برنامه مرتبط باشد.
وقتی داده ها محتوا نیستند، مدیریت آن در یک CMS ایده آل نیست. انعطاف‌پذیری کمتری دارد و اغلب با گردش کار تیم مالک سازگار نیست. در حال حاضر، در حالی که امکان همزیستی دیگر پایگاه‌های داده و CMS وجود دارد، این به توسعه‌دهندگان بستگی دارد که مزایا و معایب هر راه‌حل را درک کنند و تصمیم بگیرند که چه چیزی برای ارائه برنامه و تجربه کاربری آنها بهترین است.
مدیر پایگاه داده سخت است
به‌عنوان توسعه‌دهندگان فرانت‌اند، اولین باری که درباره پایگاه‌های داده صحبت می‌کنیم، معمولاً گفتگو درباره «رابطه‌ای در مقابل غیرمرتبط» است. از آن زمان به بعد، در حالی که سعی می کنیم تفاوت ها را بفهمیم، تعداد بیشماری از اصطلاحات مانند ACID، BASE و حتی CAP Theorem را می شنویم. این مقاله از توضیح کامل این تفاوت ها صرف نظر می کند. در قسمت بعدی این مجموعه بهتر به آنها خواهیم پرداخت. در حال حاضر، کافی است بگوییم پایگاه های داده «غیر رابطه ای» تحمیل می کنند ثبات نهایی روی یک برنامه
سازگاری نهایی را نیز می توان در یک بحث طولانی تر باز کرد، اما بیایید آن را به این صورت در نظر بگیریم:
سازگاری نهایی به این معنی است که در شرایط خاص خاص، داده های دریافتی کهنه هستند.
مانند نظرات در یک پست وبلاگ، اگر چند ثانیه بعد از یک کامنت روی برنامه شما تأثیری نگذارند نوشتن شما هنوز آخرین مورد را نمی بینید. اما به روز رسانی رمز عبور باید انجام شود به شدت سازگار است همیشه، نه در نهایت سازگار.
البته این تنها تفاوت ها نیست. عملکرد پرس و جو بین هر نوع پایگاه داده متفاوت است. می‌توان تصور کرد که در نهایت سازگاری باعث می‌شود سریعتر انجام شود می خواند زیرا اطمینان کمتری وجود دارد.
دردهای رشد بیشتر
هنگامی که پایگاه داده تصمیم گیری شد، برنامه می تواند برای مدتی به طور پیوسته و هموار رشد کند. با بزرگ شدن یک برنامه، پیچیدگی داده ها افزایش می یابد و با افزایش پیچیدگی داده ها، پایگاه داده کندتر می شود. در مقیاس، چگونه یک پایگاه داده را سریعتر بسازیم؟
- آیا منابع بیشتری را به یک سرور اضافه می کنید؟ (مقیاس عمودی)
- چگونه می توان داده ها را در مجموعه ای از ماشین ها تکرار کرد؟
- آیا پایگاه داده خود را به پارتیشن های کوچکتر (شارد) تقسیم می کنید؟ (مقیاس افقی، بیشتر در مورد این در قسمت 2)
- آیا برای پرس و جوهای رایج یک پایگاه داده در حافظه سریعتر در مقابل آن اضافه می کنید؟ (فروشگاه با ارزش کلیدی)
پاسخ به این سوالات آسان نیست. این بستگی به پایگاه کاربر، نوع داده، مقدار، فراوانی و منشاء پرس و جوها دارد. آیا پایگاه داده شما خواندنی یا نوشتن سنگین است؟ و اگرچه عوامل متعددی بر این تصمیم تأثیر می‌گذارند، انتخاب اشتباه هزینه بالایی نیز دارد.
علاوه بر این، برخی از موارد استفاده حتی ممکن است نیاز به جستجو در میان داده‌ها آسان‌تر از سرزمین کاربر داشته باشند. حل یک موتور جستجو مشکل آسانی نیست و اغلب به نوع دیگری از پایگاه داده نیاز دارد تا داده های شما را به درستی فهرست کند (اگر خرد شده باشد، حتی سخت تر است). داشتن همه اینها در اطراف داده های کاربر شما همچنین مجموعه کاملی از ابزارها را در اطراف خود به ارمغان می آورد تا آن را قابل نگهداری باشد.
حتی بیشتر از آن، زیر نظر داشتن پایگاه‌های داده (در حال حاضر «زیرساخت داده» اگر موتور جستجوی ترکیبی داشته باشیم) به سطح بالایی از مشاهده و مشاهده نیاز دارد. OLAP (پردازش تحلیلی آنلاین). این یک سطح کاملاً جدید از پیچیدگی را معرفی می کند!
همانطور که ممکن است متوجه شده باشید، ریسک های بسیار بالا با ایجاد، نگهداری و رشد یک پایگاه داده مرتبط است. تصمیماتی که می تواند یک برنامه را بگیرد یا خراب کند، تصمیماتی که بازگشت به آن پرهزینه است و باید نسبتاً زودتر گرفته شود.
پایگاه داده های بدون سرور سرگرم کننده هستند
به دلیل پیچیدگی‌هایی که در بالا ذکر شد، بسیاری از سرمایه‌گذاران و انکوباتورها به استارت‌آپ‌هایی معطوف شده‌اند که پایگاه‌های داده بدون سرور ایجاد می‌کنند. آنها یک دسته کاملاً جدید از پایگاه های داده هستند. مفاهیم سنتی هنوز هم اعمال می شود، اما متفاوت است.
پایگاه های داده بدون سرور
برای درک اینکه واقعاً «پایگاه داده بدون سرور» چیست، ابتدا باید این اصطلاح را تجزیه کنیم. این یک شوخی رایج است که “بدون سرور” یک نام اشتباه است. با این حال، هدف معماری بدون سرور این است که پیچیدگی رسیدگی به قابلیت اطمینان سایت و نگهداری سرور ارائه شده توسط یک فروشنده بدون سرور، مانند Netlify، Vercel، Amazon Web Services (AWS) و بسیاری دیگر را از مصرف کننده (توسعه دهنده) دور کند. . من تمایل دارم که دوست داشته باشم تعریف Xata از “پایگاه داده بدون سرور”.
یک “پایگاه داده بدون سرور” همان کاری را که بدون سرور برای سرورها انجام می دهد، برای پایگاه داده ها انجام می دهد. پیچیدگی از بین رفته است (به درجات مختلف بسته به پلت فرم انتخاب شده). برخی، مانند Supabase و Firebase، بسیاری از ویژگی‌های مرتبط بدون سرور را برای همراهی با پایگاه داده شما ارائه می‌دهند. دیگران، مانند AWS Aurora یا PlanetScale، بر آسان‌تر کردن استفاده و مقیاس‌بندی PostgreSQL و MySQL DB تمرکز می‌کنند. و در نهایت، دیگرانی هستند که پایگاه داده را به طور کامل انتزاعی می کنند، مانند Xata. آنها یک SDK مانند ORM را در اختیار شما قرار می دهند، پایگاه داده را پشت یک API نگه می دارند و می توانند مجموعه پیچیده ای از ویژگی های پایگاه داده را ارائه دهند که محدودیت های فعلی پایگاه های داده سنتی رابطه ای و غیر رابطه ای را خم می کند.
وقتی به قسمت بعدی این مجموعه رسیدیم، در مورد انواع مختلف پایگاه داده صحبت خواهیم کرد. سپس شما آماده خواهید بود تا روی هر پایگاه داده بدون سروری که می خواهید، هود را باز کنید و تفاوت ها را برای خود درک کنید. در ضمن بیایید سطحی نگاه کنیم.
باتری های گنجانده شده است
پیشوند «بدون سرور» را ساده نگیرید. این پایگاه های داده از نژاد متفاوتی هستند. آنها می‌توانند تضمین‌ها و عملکردی را ارائه دهند که پایگاه‌های داده «سنتی» برای دستیابی به آنها نیاز به تلاش دارند، گاهی اوقات حتی چنین نیست. این به این دلیل است که در پایگاه داده های بدون سرور، کار انجام شده است، نه توسط تیم شما.
به همین دلیل، تصمیمات در مورد مقیاس پذیری و تحویل پذیری اغلب خارج از تیم شما گرفته می شود. چیزی که تیم شما دریافت می کند این اطمینان است که هر درخواستی به موقع پاسخ دریافت می کند و داده ها به ضمانت های سازگاری احترام می گذارند. باز هم، راه حل های مختلف معاوضه های متفاوتی دارند. مهم است که قبل از پرش، بررسی کنید که هر پیشنهاد چه چیزی را تحمیل می کند.
شما را در یکی بعدی
امیدواریم این برای تحریک کنجکاوی شما کافی بوده باشد. این اولین مقاله از یک مجموعه 3 قسمتی است. در موارد بعدی، ما اطلاعات عمیق تری را در مورد اینکه واقعاً چه پایگاه های داده ای را پوشش خواهیم داد هستند. به طور خاص، ما بررسی خواهیم کرد:
- طرحواره ها
- قضایا و مدل ها،
- انواع پایگاه های داده،
- هر آنچه را که در نظرات زیر پیشنهاد می کنید!
تمام دانش لازم به شما امکان می دهد بهترین راه حل را برای برنامه خود انتخاب کنید. درک معاوضه راه حل های مختلف بدون سرور و احاطه کردن خود با نوع کمک مناسب برای تنظیم برنامه شما برای موفقیت بسیار مهم است. به من برس اگر در همین حین به چیزی نیاز دارید وگرنه چند روز دیگه میبینمت!
مطالعه بیشتر در مجله Smashing
(yk, il)
