چرا انتخاب های طراحی پایگاه داده برای توسعه دهندگان اهمیت دارد

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

توسعه دهندگان نرم افزار امروزه گزینه های بیشتری در اختیار دارند. آنها ابزارها و خدماتی دارند که می تواند به آنها کمک کند تا برنامه های جدید را به سرعت بسازند، سپس آن خدمات را برای مشتریان در سطح جهانی راه اندازی کنند، و سپس آنها را برای پاسخگویی به تقاضای رو به رشد مقیاس دهند. معماری‌های میکروسرویس‌ها و توسعه چابک بر حرکت سریع‌تر و ارائه خدمات جدید هر زمان که نیازهای مشتری و نیازهای تجاری باید برآورده شود، تأکید دارند.

این در مورد داده ها نیز صدق می کند. توسعه دهندگان باید از داده هایی که برنامه هایشان ایجاد می کنند پشتیبانی کنند و این به معنای پیاده سازی یک پایگاه داده است. انتخاب طرح مناسب می تواند تفاوت را در برنامه ایجاد کند. این کمک می کند تا اطمینان حاصل شود که برنامه در طول زمان در دسترس، کارآمد و مقیاس پذیر خواهد بود. با این حال، توسعه‌دهندگان نمی‌خواهند خودشان پایگاه‌های داده را پیاده‌سازی و مدیریت کنند. به همین دلیل است که اکثر شرکت ها – ۹۰ درصد، بر اساس IDC — در در میان انتقال پایگاه داده‌ها و حجم کاری داده‌ها به ابر.

برای این شرکت‌ها، چندین گزینه مختلف در دسترس است. این خدمات شامل سرویس های مدیریت شده، نصب پایگاه داده مبتنی بر ابر، و ارائه پایگاه داده به عنوان سرویس (DBaaS) است. همه این سرویس‌ها وعده می‌دهند که بار مدیریت داده را کاهش می‌دهند و به توسعه‌دهندگان کمک می‌کنند تا به اهداف خود در ارسال برنامه‌های جدید و به‌روزرسانی‌های برنامه‌ها سریع‌تر برسند. عباراتی مانند “بدون طرح‌واره” و “کاملاً مدیریت شده” می‌توانند اینطور به نظر برسد که پایگاه‌های داده را می‌توان تحویل داد و توسعه‌دهندگان را به احساس رضایت از خود براند.

در حقیقت، توسعه‌دهندگان به همان اندازه که برای سیستم‌های سنتی on-prem مسئولیت زیرساخت‌های ابری را بر عهده داشته‌اند، مسئول هستند، به‌ویژه در مورد انتخاب‌های طراحی و نحوه پیاده‌سازی پایگاه داده. این شامل عدم اعتماد به اینکه تنظیمات پیش‌فرض محصولات DBaaS برای برنامه‌های آن‌ها مناسب است، نمی‌شود.

انتخاب پایگاه داده مناسب

بنابراین توسعه دهندگان و معماران برنامه باید به آینده بلندمدت پروژه های کاربردی خود نگاه کنند و مطمئن شوند که الزامات اساسی این پروژه ها را درک می کنند. اولین سوال این است که از کدام طراحی پایگاه داده برای پروژه استفاده شود.

امروزه گزینه های پایگاه داده بسیار زیادی وجود دارد که انتخاب ها به سرعت بسیار زیاد می شوند. برای مثال، رتبه‌بندی موتورهای DB ۳۵۹ پایگاه داده مختلف را فهرست می‌کند، بنابراین وسوسه‌های زیادی برای استفاده وجود دارد. پایگاه داده ای که قبلاً می شناسید، یا پایگاهی که وعده های گسترده ای در مورد آنچه ارائه خواهد داد می دهد. مثلاً اگر MongoDB را پیاده سازی کرده اید، پس چرا از همان پایگاه داده برای پروژه بعدی خود استفاده نکنید؟

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

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

چگونه در مورد طراحی پایگاه داده فکر کنیم

اتخاذ رویکرد بدون طرح‌واره برای بسیاری از توسعه‌دهندگان جذاب است. از این گذشته، اگر به سرویس پایگاه داده اجازه دهید مراقب سازماندهی داده ها باشد، دیگر لازم نیست. با این حال، واقعاً اینطور نیست. همه ارائه دهندگان پایگاه داده – حتی آنهایی که رویکردهای “بدون طرحواره” را با استفاده از JSON یا توانایی اضافه کردن اشیا ارائه می دهند – نوعی اعتبار سنجی طرحواره را تشویق می کنند. پایگاه‌های داده بدون طرح‌واره اطلاعات را به‌عنوان داده‌های بدون ساختار ذخیره می‌کنند، و این از نظر عملکرد و هزینه با رشد پیاده‌سازی تأثیر قابل‌توجهی دارد.

حتی کوچکترین تصمیم‌ها می‌توانند با افزایش مقیاس پایگاه‌های داده تأثیر زیادی داشته باشند. برای مثال فرمت های داده را در نظر بگیرید. تصور کنید فرمی در برنامه خود دارید که ورودی های داده را می پذیرد، مانند اینکه فردی در کدام کشور زندگی می کند. از چه فرمتی باید استفاده کنید؟

طول نام کشورها متفاوت است، بنابراین اجازه دهید به طور متوسط ​​۱۲ کاراکتر برای ورودی فرض کنیم. ذخیره آن داده ها در قالب کاراکتر متغیر (varchar) با مجموعه کاراکترهای UTF سه بایت در هر کاراکتر یا در مجموع ۳۹ بایت برای هر ورودی اشغال می کند. این بزرگ به نظر نمی رسد، اما اجازه دهید آن را با استفاده از int یا enum برای همان فیلد مقایسه کنیم: یک int در مجموع تنها به چهار بایت نیاز دارد. هر ورودی، در حالی که یک enum فقط یک بایت طول می کشد. این را تا ۱۰۰ میلیون نقطه داده مقیاس دهید، و گزینه varchar ۳۷۰۰ مگابایت (MB) فضا اشغال می کند، در حالی که گزینه enum به ۹۵ مگابایت نیاز دارد که کاهش ۹۷.۵٪ را نشان می دهد. .

میزان داده‌ای که ذخیره می‌کنید تأثیر بیشتری نسبت به افزایش فضای دیسکی که استفاده می‌کنید دارد. هنگامی که داده های بیشتری برای کار با آن دارید، معمولاً تصویر ماشینی را که برای پردازش آن داده ها در حافظه استفاده می کنید، بزرگ می کنید. اگر رویکرد کمتر کارآمدی به داده ها داشته باشید، باید CPU و منابع حافظه را برای پردازش داده ها افزایش دهید. در حالی که هزینه ذخیره ترابایت داده روی دیسک نسبتاً ارزان است، هزینه CPU و زمان محاسبه گران است، بنابراین باید سعی کنید کارآمدترین روش ممکن را در پیش بگیرید.

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

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

قبل از ساختن فکر کنید

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

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

مت یونکویت رئیس استراتژی منبع باز در پرکونا.

—

New Tech Forum مکانی برای کاوش و بحث در مورد فناوری سازمانی نوظهور در عمق و وسعت بی سابقه ای فراهم می کند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه سوالات را به newtechforum@infoworld.com ارسال کنید.