سیستم های پایگاه داده NOSQL مانند Amazon DynamoDB از مدل های جایگزین برای مدیریت داده ها ، مانند جفت های ارزش کلیدی یا ذخیره سازی اسناد استفاده می کنند. هنگامی که از یک سیستم مدیریت پایگاه داده رابطه ای به یک سیستم پایگاه داده NOSQL مانند DynamoDB تغییر می دهید ، درک تفاوت های کلیدی و رویکردهای طراحی خاص مهم است.
موضوعات موضوعاتی
- تفاوت بین طراحی داده های رابطه ای و NOSQL
تفاوت بین طراحی داده های رابطه ای و NOSQL
سیستم های پایگاه داده رابطه ای (RDBMS) و پایگاه داده های NOSQL دارای نقاط قوت و ضعف مختلفی هستند:
در RDBMS ، داده ها می توانند به صورت انعطاف پذیر پرسیده شوند ، اما نمایش داده ها نسبتاً گران هستند و در موقعیت های پر ترافیک به خوبی مقیاس نمی شوند (مراحل اول برای مدل سازی داده های رابطه ای در DynamoDB را ببینید).
در یک پایگاه داده NOSQL مانند DynamoDB ، داده ها را می توان به صورت کارآمد از طریق تعداد محدودی از راه ، که در خارج از آن نمایش داده شدگان گران و کند باشد ، پرسید.
این تفاوت ها باعث می شود طراحی پایگاه داده بین دو سیستم متفاوت باشد:
در RDBMS ، شما بدون نگرانی در مورد جزئیات اجرای یا عملکرد ، انعطاف پذیری را طراحی می کنید. بهینه سازی پرس و جو به طور کلی بر طراحی طرحواره تأثیر نمی گذارد ، اما عادی سازی مهم است.
در DynamoDB ، شما طرحواره خود را به طور خاص طراحی می کنید تا رایج ترین و مهمترین سؤالات را به سرعت و هرچه بیشتر ارزان قیمت انجام دهید. ساختار داده های شما متناسب با الزامات خاص موارد استفاده از مشاغل شما است.
دو مفهوم کلیدی برای طراحی NOSQL
طراحی NOSQL به یک طرز فکر متفاوت از طراحی RDBMS نیاز دارد. برای RDBMS ، می توانید پیش بروید و یک مدل داده عادی ایجاد کنید بدون اینکه در مورد الگوهای دسترسی فکر کنید. سپس می توانید بعداً وقتی سؤالات جدید و الزامات پرس و جو ایجاد می شود ، آن را گسترش دهید. می توانید هر نوع داده را در جدول خود سازماندهی کنید.
طراحی NOSQL چگونه متفاوت است
در مقابل ، شما نباید شروع به طراحی طرحواره خود برای DynamoDB کنید تا زمانی که سؤالاتی را که باید به آنها پاسخ دهید ، بدانید. درک مشکلات تجاری و موارد استفاده از برنامه در جلو ضروری است.
شما باید تا حد امکان در یک برنامه DynamoDB تا حد امکان نگهداری کنید. داشتن جداول کمتر ، همه چیز را مقیاس پذیر تر نگه می دارد ، به مدیریت مجوزهای کمتری نیاز دارد و برای کاربرد Dynamodb شما سربار را کاهش می دهد. همچنین می تواند به کاهش هزینه های پشتیبان گیری در کل کمک کند.
نزدیک شدن به طراحی NOSQL
اولین قدم برای طراحی برنامه DynamoDB شما شناسایی الگوهای پرس و جو خاص است که سیستم باید آن را برآورده کند.
به طور خاص ، درک سه ویژگی اساسی الگوهای دسترسی برنامه شما قبل از شروع مهم است:
اندازه داده ها: دانستن اینکه چقدر داده ها در یک زمان ذخیره و درخواست می شوند ، به تعیین مؤثرترین روش برای تقسیم داده ها کمک می کند.
شکل داده ها: به جای تغییر شکل داده ها هنگام پردازش پرس و جو (همانطور که یک سیستم RDBMS انجام می دهد) ، یک پایگاه داده NOSQL داده ها را به گونه ای سازماندهی می کند که شکل آن در پایگاه داده با آنچه پرس و جو خواهد شد مطابقت داشته باشد. این یک عامل اصلی در افزایش سرعت و مقیاس پذیری است.
سرعت داده ها: با افزایش تعداد پارتیشن های فیزیکی که برای پردازش نمایش داده شد ، و با توزیع کارآمد داده ها در آن پارتیشن ها ، مقیاس های دینامودب را مقیاس می دهند. دانستن از قبل چه بارهای پرس و جو اوج می تواند به تعیین نحوه تقسیم داده ها برای استفاده بهتر از ظرفیت I/O کمک کند.
پس از شناسایی الزامات خاص پرس و جو ، می توانید داده ها را طبق اصول کلی که حاکم بر عملکرد است ، سازماندهی کنید:
داده های مرتبط را با هم نگه دارید. تحقیقات در مورد بهینه سازی جدول مسیریابی 20 سال پیش نشان داد که "محل مرجع" مهمترین عامل در سرعت بخشیدن به زمان پاسخ است: نگه داشتن داده های مرتبط در یک مکان. این به همان اندازه در سیستم های NOSQL امروزه صادق است ، جایی که نگه داشتن داده های مرتبط در نزدیکی تأثیر عمده ای بر هزینه و عملکرد دارد. به جای توزیع موارد داده مرتبط در چندین جدول ، باید موارد مرتبط را در سیستم NOSQL خود تا حد امکان نزدیک نگه دارید.
به عنوان یک قاعده کلی ، شما باید در یک برنامه DynamoDB تا حد ممکن جداول را حفظ کنید.
استثنائات مواردی است که داده های سری زمانی با حجم بالا درگیر هستند ، یا مجموعه داده هایی که الگوهای دسترسی بسیار متفاوتی دارند. یک جدول واحد با شاخص های معکوس معمولاً می تواند نمایش داده های ساده را برای ایجاد و بازیابی ساختارهای داده سلسله مراتبی پیچیده مورد نیاز برنامه شما ایجاد و بازیابی کند.
از سفارش مرتب سازی استفاده کنید. در صورتی که طراحی اصلی آنها باعث شود که آنها در کنار هم قرار بگیرند ، موارد مرتبط با هم گروه بندی می شوند و به طور کارآمد پرسیده می شوند. این یک استراتژی مهم طراحی NOSQL است.
توزیع نمایش داده ها. همچنین مهم است که حجم بالایی از نمایش داده ها روی یک قسمت از پایگاه داده متمرکز نشود ، جایی که می توانند از ظرفیت I/O فراتر رود. درعوض ، شما باید کلیدهای داده را برای توزیع ترافیک به طور مساوی در پارتیشن ها تا حد امکان طراحی کنید و از "نقاط داغ" خودداری کنید.
از فهرست های ثانویه جهانی استفاده کنید. با ایجاد شاخص های ثانویه جهانی خاص ، می توانید نمایش داده شدگان مختلف را از جدول اصلی خود فعال کنید و این هنوز سریع و نسبتاً ارزان است.
این اصول کلی به برخی از الگوهای طراحی متداول تبدیل می شود که می توانید برای مدل سازی داده ها به طور مؤثر در DynamoDB استفاده کنید.
