چطور برای اپلیکیشن موبایل‌مان پایگاه داده انتخاب کنیم

مصرف‌کننده‌های امروزی خیلی به استفاده از اپلیکیشن‌های موبایل خود وابسته هستند. اگر اپلیکیشنی کار نکند به ارحتی کنار گذاشته می‌شود.

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

دلیل اصلی اتصال دائمی اپلیکیشن‌های موبایل به اینترنت در گذشته دسترسی آن‌ها به پایگاه داده بود. اپلیکیشن‌های امروزی برای قطع کردن این وابستگی به اینترنت از روش‌های همگام‌سازی (Synchronization) و قابلیت‌های آفلاین برای دسترسی محلی به پایگاه داده استفاده می‌کنند.

راهکارهایی مثل کوچ بیس (Couchbase)، خدمات موبایلی مایکروسافت آزور (Microsoft Azure Mobile Services)، کاگنیتو (Cognito)ی آمازون و فایربیس (Firebase) گوگل همگی امکاناتی را به ما به عنوان توسعه‌دهنده اپلیکیشن می‌دهند که ما را قادر می‌سازد اپلیکیشن‌هایی طراحی کنیم که هم آنلاین کار کنند و هم آفلاین.

با وجود این همه ابزار و امکانات جالبی که در اختیار ما قرار می‌دهند، چگونه می‌توانیم برای توسعه اپلیکیشن‌مان از بین آن‌ها ابزاری که برای ما بهتر است را انتخاب کنیم؟ ۶ حوزه پیش رو مهم‌ترین بخش‌هایی است که موقع انتخاب راهکار برای پایگاه داده اپلیکیشن موبایل باید مدنظر داشته باشیم: پلتفرمی که پشتیبانی می‌کند (Platform Support)، انعطاف‌پذیری در مدلسازی (Modeling Flexibility)، حل کردن تعارض‌ها (Conflict Resolutions)، بهینه‌سازی همگام سازی (Sychronization Optimization) و چیدمان‌های شبکه که پشتیبانی می‌کند (Topology [1]Support).

پلتفرم‌های تحت پشتیابی

سؤال اصلی در این مرحله این است: این پایگاه داده از چه پلتفرما‌هایی پشتیبانی می‌کند؟ آیا می‌خواهیم چیزی بیش از یک اپلیکیشن تحت اندروید یا iOS داشته باشیم؟ ایا می‌خواهیم برای پلتفرم‌هایی اپلیکیشن تولید کنیم که رایج نیستند (مثل سیستم‌های نهفته (Embedded Systems)، دستگاه‌های IoT و تجهیزات پوشیدنی (Wearables))؟ آیا می‌خواهیم اپلیکیشن ما روی سیستم عامل ویندوز هم اجرا شود؟ بسیاری از اپلیکیشن‌های امروزی روی موبایل ارائه می‌شوند و سپس به یک نسخه تحت وب یا تحت دسکتاپ توسعه پیدا می‌کنند. به همین دلیل ارزیابی دیتابیس‌های موجود و تطبیق آن با نیازهایی که پلتفرم انتخابی ما ایجاب می‌کند بسیار مهم است. حتی باید تا حدودی نیازهای آتی اپلیکیشن را درنظر بگیریم و با توجه به آن دیتابیس خود را انتخاب کنیم.

امنیت داده‌های خوابیده و داده‌های در حرکت

زمانی که از ذخیره‌سازی همگام‌سازی شده (Sychronized) و غیرمتمرکز (Decentralized) استفاده می کنیم، مسئله امنیت در دسترسی، انتقال و ذخیره‌سازی ایمن پیش می‌آید. برای اینکه از پس چنین مسئله مهمی برآییم، باید بتوانیم به اعتبارسنجی (Authentication)، داده‌های خوابیده (Data in Rest)، داده‌های در حرکت (Data in Motion) و دسترسی خواندن و نوشتن (Read and Write Access) را به درستی آدرس بدهیم.

اعتبارسنجی باید منعطف باشد و اجازه دهد بتوانیم از روش‌های اعتبارسنجی استاندارد، عمومی و دلخواه استفاده کنیم. همچنین گاهی اوقات در اپلیکیشن خود نیاز داریم حتی کاربران به صورت ناشناس نیز به اپلیکیشن دسترسی داشته باشند. برای داده‌های خوابیده روی بخش سرور و کلاینت نیاز داریم رمزنگاری در سطح فایل‌ها سیستمی و سطح داده‌ها داشته باشیم. برای داده‌های در حرکت، ارتباط باید از طریق کانالی امن مانند SSL یا TLS انجام شود. برای داده‌های مربوط به دسترسی نوشتن و خواندن، پایگاه داده باید کنترل گرانولار (Granular Control) را روی دسترسی به داده‌هایی که قابل تغییر توسط کاربران هستند، بدهد.

استفاده از مدل داده‌ای انعطاف‌پذیر

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

پایگاه‌های داده رابطه‌ای (Relational) هنوز گزینه مناسبی برای اپلیکیشن‌هایی هستند که نیاز به سازگاری قوی داده‌هایشان دارند یا به داده‌هایشان به رابطه‌های زیادی با هم دارند. اگر به چنین حجمی از کارایی نیاز نداشتیم پایگاه داده NoSQL انعطاف‌پذیری بالایی را در اختیار ما قرار می‌دهد.

حل آرام تعارض‌های داده‌ها

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

کنترل تعارضات در هر سیستمی متفاوت است. به عنوان مثال کوچ بیس موبایل از درخت‌های بازنگری (Revision Trees) به همراه یک سری قوانین حل‌کننده با قاعده «فعال ترین شاخه برنده است» استفاده می‌کند. همین رویکرد در سیستم‌های کنترلی بازنگری گیت (Git) مورد استفاده قرار می‌گیرد و با سیستم های کنترلی بر پایه «آخرین تغییر برنده است». سیستم‌های حل‌کننده تعارض ساعت محور به خاطر تفاوت در ساعت‌ها در دستگاه‌های مختلف مشکل‌ساز می‌شوند. کوچ بیس این امکان را می‌دهد که از طریق کد، مکانیزم‌های حل کننده تعارض دلخواه و پیچیده تعریف کنیم.

همگام سازی در زمان درست

علاوه بر حل این که باید سعی کنم تعارضات را برطرف کنیم، باید توانایی همگام‌سازی سیستم را نیز داشته باشیم. این سیستم شامل استراتژی پاسخگویی (Replication)، پاسخگویی شرطی و فیلتر کردن پاسخگویی می‌شود. برای استراتژی پاسخگویی باید دنبال پشتیبانی از استریمینگ (Streaming)، رأی گیری، وان تایم (one-Time)، تدوام (Continuous) و پوش (Push) باشیم. همچنین قابلیت استفاده ترکیبی از این استراتژی‌ها را هم داشته باشیم. برای پاسخگویی ممکن است در شرایطی نیاز داشته باشیم تنها تحت شرایط خاصی داده‌های پاسخ را ارسال کنیم. نمونه این شرایط وقتی است که می خواهیم تنها به شرطی داده‌ها داد و ستد شوند که اتصال وای فای وجود داشته باشد یا دستگاه شارژ باتری کافی داشته باشد. برای فیلتر کردن پاسخگویی نیز باید بتوانیم بین داده‌ها تمایز قائل شویم تا برخی تبادل شوند و برخی دیگر قابل تبادل نباشند.

همگام‌سازی در بخش‌های صحیح

پشتیبانی از شکل قابل تنظیم چیدمان شبکه (Configurable Sync Topology Support) نیاز است تا به الزامات بخش‌بندی خود برسیم. به بیان دیگر، نیاز داریم تا سیستم را به شکلی تنظیم کنیم که به اجزای مشخصی اجازه دهد به شکل آفلاین فعالیت کنند. رایج‌ترین چیدمان ستاره است. در چیدمان ستاره هر دستگاه به یک هاب (Hub) مرکزی با استفاده از اتصال نقطه به نقطه وصل می‌شود که به دستگاه اجازه می‌دهد به شکل آفلاین عمل کند. دیگر چیدمان‌ها مثل درخت (Tree) و مش (Mesh)  به اجزی مختلف سیستم (و دستگاه) اجازه می‌دهند به شکل آفلاین کار کنند. همچنین ممکن است نیاز داشته باشیم از چیدمان‌های ابری نیز پشتیبانی کنیم تا به دستگاه‌ها اجازه بدهد به شکل همتا به همتا (Peer-to-Peer) با هم ارتباط داشته باشند و داده‌های را مستقیما بین خودشان همگام کنند.

یک سیستم POS (نقطه فروش، Point of Sale) مثال خوبی از چیدمان درختی است. در سیستم‌های POS نیاز است یک فروشگاه فیزیکی (Brick and Mortar Store) علی رغم قطع شدن اتصال از بقیه شبکه به فعالیت خود ادامه دهد. در این تنظیمات دستگاه‌های POS با یک پایگاه داده سطح فروشگاه همگام می‌شوند که خود با یک سیستم گلوبال (Global System) همگام می‌شود. بنابراین فروشگاه‌ها به فعالیت و همگام کردن داده‌هابا دستگاه‌های POS خود فارغ از اینکه به سیستم گلوبال متصل هستند یا نه، ادامه می‌دهند.

از همه این‌ها که بگذریم

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

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

منبع: مقاله‌ای از سایت infoworld.com با عنوان «?How to choose a database for your mobile apps»

[۱]  در بیان علمی به «ریخت‌شناسی» ترجمه می‌شود که در اینجا برای سهولت در مطالعه متن «چیدمان» ترجمه شده است.