img

با استفاده از MongoDB عملکرد فن آوری اطلاعات در کسب و کار را بهبود ببخشید…

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

در حدود یک دهه اخیر یا بیش از آن، میزان داده ایجاد شده به طرز فزاینده ای افزایش یافته است. راه‌های ذخیره سازی، مدیریت و تجسم این داده‌ها از شیوه‌های کهنه و منسوخ، به شیوه‌های نوآورانه و امروزی سوق پیدا کرده است.
در تعداد و تنوع پایگاه‌های داده افزایش انفجار گونه ای را شاهد بوده ایم. بسیاری به منظور فراهم آوردن مقیاس پذیری در سطوح بالا، پذیرش خطا و دارا بودن ویژگی‌های اصلی ACID طراحی شده اند. هر پایگاه داده متن بازی، واجد برخی ویژگی‌های منحصر به فرد می‌باشد که به همین خاطر، بسیار مهم است که توسعه دهنده یا صاحب کسب و کار انتخابی هوشمندانه انجام دهد و همچنین تحلیل درستی از مشکل و راه حل‌ها و کاربردی که در نظر دارد به طور مستقل داشته باشد.
در این مقاله، اجازه دهید نگاهی داشته باشیم به یکی از پایگاه‌های داده متن بازی که ما خودمان مورد سنجش قرار دادیم و آن برای مناسب سازی با ساز و کار کسب خود تغییر دادیم تا مطابق نیازهای ما گردد.
MongoDB آنگونه که در توضیحاتش نگاشته شده است، متن باز، چندسکویی و پایگاه داده ای سند گرا می‌باشد، که برخوردار از عملکردی عالی و دسترسی بسیار بالا و مقیاس پذیری آسان است.
MongoDB با مفهوم مجموعه‌ها سازگار است، چیزی شبیه آنچه که جدول‌ها در سامانه‌های مدیریت پایگاه داده رابطه ای انجام می‌دهند، همانند MySQL و Oracle. هر مجموعه از اسناد تشکیل شده است(همانند XML, HTML, یا JSON) که اساس MangoDB را همین اجزا می‌باشند که قابل قیاس با ردیف‌های منطقی در پایگاه‌های داده ای Oracle هستند.
MangoDB در قیاس با پایگاه داده ای Oracle الگویی انعطاف پذیر دارد. در Oracle ما نیاز به جداولی دقیق با ستون‌های مشروح داریم و تمامی داده‌ها بایستی با در تطابق با نوع داده ردیف‌های جدول باشند. در حالی که MongoDB این امکان را به شما می‌دهد که داده‌های خود را در قالب اسناد، در قالب JSON و راه‌های غیر منطقی ذخیره سازید.
هر سند می‌تواند قالب مخصوص خود را داشته باشد، که آن را مستقل از سایر اسناد و داده‌های دیگر می‌سازد.
تنها عیبی که این مقوله ایجاد می‌کند عدم امکان ایجاد پیوند در میان داده‌ها می‌باشد. یکی از تغییرات اساسی که ما به عنوان توسعه دهندگان و معماران بایستی از آن گذر کنیم هنگامی که می‌خواهیم MongoDB را به کار بندیم، تغییر در طرز تفکر است، یعنی پذیرفتن ذخیره داده‌های استاندارد شده و معمولی، خلاص شدن از انبوهی داده مازاد در دنیایی که نیاز دارد همه داده‌های ممکن را در قالب سند ذخیره کند، و حل مشکل هم روندی. عامل مقیاس پذیری افقی با مفهوم تقیسم کردن انجام می‌شود، که در آن داده در میان چندین دستگاه و بخش به نام تکه(Shard) پخش می‌شود که مقیاس پذیری مضاعفی را ممکن می‌سازد.
امکانات خطا پذیری اینگونه میسر می‌شوند که داده‌ها می‌تواند در میان دستگاه‌ها و پایگاه‌های متفاوت جابه جا و جایگزین شوند، پس اینگونه مشکلی به دلیل خرابی یا از دست رفتن یک سرور پدید نخواهد آمد.
همچنین در فرآیند انتخاب رهبر خودکار(نوعی عملیات داده پردازی) دسترسی بسیار عالی در میان خوشه‌های سرور وجود دارد. به طور سنتی، پایگاه‌های داده تنها از یک نوع مدل داده ای پشتیبانی می‌کردند، مثل زوج‌های کلید-مقداری، گراف ها، نسبت ها، سلسله مراتب ها، جست و جو‌های متنی، و غیره…
اما امروزه پایگاه‌های داده این توانایی را دارند که با مدل‌های گوناگونی از داده سر و کار داشته باشند. MongoDB نیز از جمله این پایگاه‌های داده ای محسوب میشود که با انواع مدل‌های داده ای سازگار است.
اگرچه MongoDB توانایی تحلیل داده‌های مکانی و جست جوی متن را دارد، ولی به خوبی یا دقت Solar یا Elastic نیست، که به وسیله آنها موتورهای جست و جوی بهتری را می‌توان ساخت.

تحلیلی از مورد آزموده شده توسط ما
ما در حال حاظر در فضای مدیریت سفارشات فعال هستیم، جایی که اطلاعات سفارش به بیش از ۱۲۰ برنامه از طریق بیش از ۲۷۰ یکپارچه سازی به وسیله میان افزار ما انجام می‌شود.
یکی از اجزای اصلی که ما خودمان به داده بردارمان افزودیم، سرویسی است که به منظور ثبت انتقالات، فعال سازی ردگیری پیام و رد گیری خطاها در سیستم ما نقش ایفا می‌کند. اغلب پیام هایی که ارسال می‌شوند ناهماهنگ هستند. یکپارچه سازی‌ها ناهمگون می‌باشند، که ما را قادر می‌سازد با Oracle، Microsoft SQL، پایگاه داده‌های رابطه ای، MQ IBM، سرویس گذرگاه، سرویس‌های وب و تعدادی یکپارچه سازی مبتنی بر فایل متصل شویم.
فرآیندهای میان افزار ما حجم عظیمی از رویداد‌ها را در جریان عبور سفارشات از سیستم فن آوری اطلاعات ما تولید می‌کنند، که خود این رویداد‌ها اغلب محتوی سایر فرا داده ها، ضمایم سفارشات که برای جست و جو لازم می‌باشند، نمایشگر موفقیت، خطا‌ها و هشدار و غیره می‌باشند، و در برخی موارد ما تمامی اطلاعت دریافتی را برای عیب یابی ذخیره می‌کنیم.
چارچوب ثبت اختصاصی ما به طور سنتی برای ذخیره سازی این رویداده‌ها بصورت فایل‌های متنی ساده در هر یک از سامانه‌های نگهداشت سرورها ذخیره می‌شوند، و ما در پس زمینه توسط پایتون این فایل‌های داده برداری را خوانش می‌کنیم و سپس تکه، تکه در جداول پایگاه‌های داده رابطه ای قرار می‌گیرند. داده برداری(لاگینگ) سریع انجام می‌شود، به هر روی، ردگیری یک پیام در میان چندین سرور سعی در به دست آوردن یک دید بی درنگ از سفارش هنوز امکان پذیر نیست.
مشکلاتی پیرامون زمان بند و عملیات پس زمینه ای وجود دارد که نیاز به زیرنظر گرفته شدن دارند. و همین سایر مشکلات.
در یک خوشه با هر دوی Prod و DR در حالت فعال با ۱۶ سرور فیزیکی، ما بایستی ۱۶ عملیات زمان بندی را اجرا کنیم و سپس آنها بررسی کرده تا اصمینان حاصل کنیم که در همه حال این عملیات انجام می‌شوند.
ما می‌توانیم سرعت گرفتن داده را با استفاده از چند رشته یا زمان بندی در بازه‌های کوتاه تر افزایش دهیم، به هر روی مدیریت آنها در میان چندین دامین هنگامی که ما خوشه‌های خود رو مقیاس بندی کنیم، برای نگهداری یک دردسر خواهد بود.
برای به دست آمدن یک دید بی درنگ، ما چاره ای جر دوباره نویسی چارچوب داده برداری خود با یک سرویس وب سبک نداریم، که این توانایی را دارد که مستقیما در جداول سامانه‌های مدیریت داده رابطه ای داده‌ها را ثبت کند.
این کار بهره وری سیستم را کاهش داد. ابتدا هنگامی که ما بر فایل‌های مستقل در یک سیستم محلی می‌نوشتیم، سرعت فرآیند چیزی در حدود ۹۰ تا ۱۰۰ هزار پیام در دقیقه بود. اکنون با طراحی جدید نگارش بر جدول پایگاه داده، عملکرد تنها در حدود ۴ الی ۵ هزار پیام در دقیقه شده بود. این یک عیب بزرگ در بهره وری محسوب می‌شد، که ما نمی توانستیم بپذیریم.
ما چهارچوب را با Oracle AQs بازنویسی کردیم، بطوری که سرویس وب داده رو بر روی Oracle AQs می‌نویسد، یک عملیات زمان بند بر روی پایگاه داده انجام میشود که پیام‌ها از AQ از صف خارج می‌کند و داده را به جداول وارد می‌کند.
این کار عملکرد را تا ۱۰ هزار پیام در دقیقه بهبود بخشید. سپس ما با پایگاه داده Oracle به بن بست برخورد کردیم. حالا برای دریافت یک دید بی درنگ از سفارش برای از دست نرفتن عملکرد، ما گشتن در دنیای متن باز را آغاز کردیم، جایی که با MongoDB آشنا شدیم.
MongoDB کاملا با مورد ما جور درآمد. ما به پایگاه داده ای نیاز داشتیم که بتواند رویدادهای موازی را با سرعت بالا در چندین فرآیند همزمان ثبت کنیم. نرخ پرسمان در این داده برداری به طور چشمگیری پایین بود.
ما به اسناد را با استناد به تجربیات قبلی به سرعت مدل سازی کردیم و قادر بودیم به سرعت داده بردار خود را که از MongoDB استفاده می‌کرد عملیاتی کنیم.
بهره وری بسیار بهبود پیدا به طوری که به حد ۷۰ هزار پیام در دقیقه دست یافتیم.
این اتفاق ما را قادر ساخت که بتوانیم تقریبا دیدی بی درنگ بر روی سفارش در میان چنیدن فرآیند و سیستم‌ها بر اساس نیاز داشته باشیم، بدون اینکه بهره وری و سرعت را قربانی کرده باشیم.
اینگونه نیاز به چندین فرآیند زمان بند در میان خوشه‌های سرورها ازبین رفت و همین طور دیگر نیازی به مدیریت آنها وجود نداشت. همچنین بی ارتباط به مقیاس پبندی نرم افزار نسبت به تعداد فرآیندها و تعداد سرورهای میزبانی کننده، چهار چوب داده برداری ما، مستقر در زیرساخت‌های جداگانه می‌تواند پاسخ گوی نیازهای یک الگوی سرویس گرا باشد.
در حال حاضر، ما از تجربیاتمان می‌آموزیم. تعدادی از چالش هایی که ما هنگام تطبیق MonogDB با آنها برخورد داشتیم در رابطه مدیریت رشد داده و نیاز به داشتن مکانیزم برای پالایش داده‌ها بودند
این چیزی نیست که به طور واضحی در دسترس باشد و نیاز به برنامه ریزی و مدیریت در هنگام تکه سازی دارد.
مدیریت تکه‌ها نیاز دارد که بهبود پیدا کند تا امکان ذخیره سازی را بهینه تر در اختیار گذارد. همچنین، کپی‌ها و مکان آنها تعیین می‌کند که بازیابی فاجعه ما به چه میزان خوب عمل می‌کند.
ما قادر بودیم infra را بدون دردسر استفاده و نگهداشت کنیم، به انتظار داریم که بتوانیم چهار چوب داده برداری هایی بدین شکل را در سایر زمینه‌ها نیز امتحان کنیم. مثل فضاهای یکپارچه سرپرستی تولید یا سرپرستی مصرف کننده در فن آوری اطلاعت خودمان.
این امر بدون تغییرات زیاد ممکن خواهد بود، زیرا MongoDB منطبق بر اسناد در قالب JSON می‌باشد.

نظر بدهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

It is main inner container footer text