۵ قانون برای درست کردن معماری داده ها

با پرداختن به ملاحظات کلیدی در مراحل اولیه معماری داده، می توانید از مشکلات جدی در آینده جلوگیری کنید.

معماری برنامه‌های کاربردی مدرن کار دشواری است، و معماری یک مدل داده جامد برای برنامه‌های کاربردی مدرن یکی از سخت‌ترین و در عین حال مهم‌ترین بخش‌های یک معماری کاربردی مدرن است.

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

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

از نوع مناسب پایگاه داده استفاده کنید

اولین و مهمترین تصمیم در معماری داده های شما این است که بدانید به چه نوع پایگاه داده ای برای ذخیره و دسترسی به داده های خود نیاز دارید. آیا لازم است:

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

برای تعیین نوع پایگاه داده ای که باید استفاده کنید، به پاسخ این سؤالات نیاز دارید. بسته به این پاسخ‌ها، ممکن است یک پایگاه داده SQL، یک ذخیره‌سازی با مقادیر کلیدی ساده، یک حافظه پنهان مقیم حافظه، یک ذخیره‌سازی شی ساده، یا یک ذخیره‌سازی داده بسیار ساختاریافته را انتخاب کنید.

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

داده ها را در مکان مناسب ذخیره کنید

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

بیشتر داده ها در قسمت پشتی ذخیره می شوند. اما برخی از داده ها باید در لبه یا در یک کلاینت ذخیره شوند. برای بهینه سازی عملکرد، در دسترس بودن، قابلیت اطمینان و مقیاس پذیری، اغلب به ذخیره سازی داده ها در قسمت جلویی نیاز است.

از ابتدا به مقیاس بندی فکر کنید

برنامه‌های کاربردی مدرن باید بتوانند برای پاسخگویی به نیازهای رو به رشد مشتریان یک کسب‌وکار، مقیاس شوند. این برای همه مشاغل و همه برنامه ها صادق است.

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

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

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

داده های خود را بین سرویس ها توزیع کنید

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

اما این استراتژی معیوب است. داده های متمرکز داده هایی هستند که نمی توانند به راحتی مقیاس شوند. مؤثرترین راه برای مقیاس‌بندی داده‌هایتان، غیرمتمرکز کردن آن‌ها و ذخیره آن‌ها در سرویس فردی است که داده‌ها را در اختیار دارد. برنامه شما، اگر از ده ها یا صدها سرویس توزیع شده تشکیل شده باشد، داده های شما را در ده ها یا صدها مکان توزیع شده ذخیره می کند.

این مدل مقیاس‌بندی آسان‌تر را امکان‌پذیر می‌کند و از مدل مالکیت خدمات کامل پشتیبانی می‌کند. مالکیت سرویس، تیم‌های توسعه را قادر می‌سازد تا مستقل‌تر کار کنند و SLA‌های قوی‌تر بین سرویس‌ها را تشویق می‌کند. این خدمات با کیفیت بالاتر را تقویت می کند و تغییرات داده را از طریق محلی سازی ایمن تر و کارآمدتر می کند.

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

داده های خود را به صورت جغرافیایی توزیع کنید

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

قبل از اینکه معماری داده خود را ایجاد کنید، باید به این سوالات کلیدی پاسخ دهید:

1. آیا مهم است که داده‌های شما در سطح جهانی در دسترس باشند یا نسخه منطقه‌ای داده‌ها برای کسب و کار شما مهم‌تر خواهد بود؟ به عنوان مثال، آیا می خواهید داده های مشابه یا متفاوتی در ایالات متحده و آلمان موجود باشد؟ بسیاری از برنامه‌های کاربردی ترکیبی از هر دو مدل را مهم می‌دانند، و این پاسخ قابل قبول است، تا زمانی که بدانید کدام داده‌ها باید جهانی شوند و کدام باید منطقه‌ای شوند.
2. آیا محدودیت‌های منطقه‌ای در مورد اینکه چه داده‌هایی را می‌توانید ذخیره کنید و کجا می‌توانید ذخیره کنید دارید؟ برخی از محلات محدودیت هایی دارند که از خروج اطلاعات مشتری از کشور محل اقامت مشتری جلوگیری می کند. سایرین محدودیت هایی در مورد اینکه چه داده هایی می توانند در سراسر کشور و مرزهای منطقه ای منتقل شوند، دارند. برخی از مناطق نسبت به مناطق دیگر محدودیت های حریم خصوصی شدیدتری دارند. چه محدودیت های داده ای برای چه بخش هایی از داده های شما اعمال می شود؟
3. برای داده‌هایی که در بین مناطق به اشتراک گذاشته می‌شوند، چقدر مهم است که دقیقاً همان داده‌ها در هر منطقه نشان داده شود؟ به عبارت دیگر، آیا داده ها باید دقیقاً بین مناطق همگام شوند؟ مدل های مختلف بارهای متفاوتی را بر مجموعه داده های شما وارد می کنند. یک مدل سازگاری نهایی ویژگی‌های عملکردی بسیار متفاوتی با ACID-سازگار، مدل یکپارچگی تراکنش.

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

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

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