معماری سقراط و مقايسه آن با معماری HADR در حوزه کلان داده

سقراط یک معماری جدید در پایگاه داده ها میباشد که توسط شرکت مایکروسافت بوجود آمده و تحت عنوان sql hyper scale در محصولات مایکروسافت همچون windows AZURE در حال استفاده میباشد.

معماری HADR

پیش از اینکه به تشریح معماری سقراط بپردازیم بهتر است که ابتدا توضیحی در مورد معماری که پیش از این تحت نام (HADR(high availability disaster recovery وجود داشته صحبت کنیم، که نمونه کلاسیک از تکرار کننده وضعیت ماشین است . و همانطور که در شکل زیر مشخص است از 4 نود تشکیل شده، یک نود اصلی و 3 نود فرعی که تمامی کارهای معمول یک پایگاه داده اعم از ذخیره سازی، ثبت لاگ، پشتیبان گیری، ثبت تراکنش ها، بازیابی و … به عهده نود اصلی میباشد و نود های فرعی صرفا دسترسی Read only به اطلاعات دارند و وظیفه شان انتقال آنها به سرویس ذخیره سازی است .

معايب معماری HADR

این معماری، معماری پذیرفته شده ایی است و همچنان هم مورد استفاده قرار میگیرد منتها دارای 2 اشکال اصلی میباشد، اول اینکه اگر نود اصلی به هر دلیلی از کار بیافتد تمام سیستم از دسترس خارج میشود و ما مجبوریم که سیستم را از ابتدا بوسیله نسخه های پشتیبانمان بازیابی کنیم.

اشکال دوم این هست که این معماری همیشه در حال اجرا یک نسخه (scope) از سیستم را در کنار خود نگه میدارد تا در صورت لزوم و بروز خطا از آن استفاده کند که باعث میشود تا عملا برنامه هایی که از آن ها استفاده میکنند نتوانند ظرفیت خود را به بیش از 4 ترابایت افزایش دهند.

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

دستاورد های معماری سقراط

همانطور که گفتیم ایده پروژه سقراط باعث شد تا پروژه های مهم دیگری نیز برای بهبود سرویس‌های موجود بوجود آیند تا بهره وری و موفقیت سقراط را تضمین کنند، تمامی این پروژه ها توسط تیم های شرکت مایکروسافت توسعه و بهبود داده شدها ند و همگی نقش بسزایی را در سقراط بازی میکنند

ADR(Accelerated Database Recovery)

این سرویس نسبت به سرویس مشابه قبلی خود (ARIES) کاملا تغییر کرده و تکنولوژی جدیدی محسوب میشود که از 3 بخش تشکیل شده است : آنالیز، redo و undo که برای کار با تراکنش ها بوجود آمده تا آنهارا به بخش های مربوطه معماری برای ثبت و بازبینی و بدهد. پیش از این اگر یک تراکنش توسط این سرویس خوانده میشد عملی روی آن انجام میشد و دوباره به آن نیاز پیدا میکردیم باید دوباره مراحل سه گانه ایی که در ابتدا گفته شد را انجام میدادیم اما در ADR دیگر نیازی به این کار نیست و ما میتوانیم در هر مرحله ایی از redo یا undo باشیم بدون آنکه دوباره نیاز به آنالیز باشد.

RBPE(Resilient Buffer Pool Extension)

این سرویس نیز نسبت به نسخه قبل خود (BPE) که توسط مایکروسافت ایجاد و توسعه پیدا کرده بهتر شده و مقیاس پذیرتر شده است، یعنی میتواند توسط سرویس های دیگر و همچنین بخش ها و لایه های دیگر این معماری مورد استفاده قرار بگیرد و در لود بالا کیفیت خدماتی خود را از دست ندهد که باعث افزایش سرعت در اکثر بخش ها به خصوص در هنگام بازیابی سیستم پس از بروزرسانی شده است.

RBIO(Remote Block Input Output) protocol

این تکنولوژی جدید و خلاقانه در بخش شبکه این معماری مورد استفاده قرار میگیرد که جایگزین سرویس قبلی خود (UCS) شده که نسبت به آن مستقل تر شده و دارای پشتیبان گیری اتوماتیک میباشد و Qos را نیز پشتیبانی میکند.

در واقع کار اصلی این تکنولوژی این است که درهنگام عملیات input/output سیستم سیکل کمتری از پردازنده را بهکار گیرد

Snapshot Backup/Restore

این سرویس نیز نسبت به سرویس قبلی snapshot با توجه به تکنولوژی هایی که در بالا اشاره کردیم دچار تغییری بنیادین شده است و آن این است که در هنگامی که مشغول انتقال اطلاعات به سرویس ذخیره سازی میباشد میتواند یک snapshot از کل سیستم بگیرد، که عملا باعث میشود تا ما بتوانیم در صورت لزوم کل سیستم را بدون فرآیند هایی از قبیل pause،restart و غیره بدن وقفه برگردانیم.

این عمل آنقدر سریع و باکیفیت انجام میشود که میتوان پایگاه داده های چند صد ترابایتی که باهم در ارتباط هستند را به سرعت و بدون وقفه برگرداند !

خوب همانطور که گفته شد این 4 تکنولوژی در کنار سقراط استفاده میشود و هرکدام تیم عملیاتی خود را برای توسعه داشته تا بتواند بیشترین تاثیرگذاری و بهره وری را برای معماری سقراط فراهم کند. در شکل زیر تفاوت هایی که این 4 تکنولوژی به طور اَخَص باعث و بانی آن بودهاند در مقایسه با معماری قبلی یا هر معماری دیگری که تا به حال وجود داشته است اشاره شده است.

	Today	Socrates
Max DB Size	4TB	100TB
Availability	99.99	99.999
Upsize/downsize	O(data)	O(1)
Storage impact	4x copies (+backup)	2x copies (+backup)
CPU impact	4x single images	25% reduction
Recovery	O(1)	O(1)
Commit Latency	3 ms	< 0.5ms
Log Throughput	50MB/s	100+ MB/s

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

معماری سقراط

در اینجا به تشریح معماری سقراط میپردازیم که برخلاف HADR از 5 لایه تشکیل شده است !

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

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

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

بخش بعدی Page Servers ها هستند که در واقع در تعداد بسیار بالایی میتوانند خود را انشعاب دهند و عملا حاوی کپی ایی از اطلاعات و دیتاهای مختلف هستند که مابین نود های اصلی و فرعی و لایه های دیگر سقراط (XLOG,XSTORE,comput nodes,..) جابهجا میکنند .

Page Servers ها دو کار حیاتی را در این معماری بر عهده دارند اولاً اینکه آنها همواره اطلاعاتی را با خود به همراه دارند و در صورتی که نود های پردازشی مان (همان نود اصلی و سه نود فرعی) برای انجام کاری در خواست اطلاعاتی کنند پیش از آنکه این اطلاعات از خود سرویس ذخیره سازی یا لاگ مان برداشته شود اگر آنرا در صفحات خود داشته باشند به سرعت در اختیار نود ها قرار میدهند و به این ترتیب سرعت برداشت اطلاعات را به صورت قابل توجه ایی بالا میبرند در مقابل نیز اگر در هنگام لود بالا نود های اصلی برای کارایی بهتر و حفظ عملکردشان میتوانند مقداری از اطلاعاتشان را به صورت موقت بر روی این صفحات منتقل کنند تا در انجام کارهایشان خللی ایجاد نشود.

دوماً زمانی که میخواهند اطلاعات خود را برای ذخیره سازی به سرویسهای XLOG و XSTORE بدهند، برای سرعت بخشی در عمل ذخیره سازی خودشان اطلاعات را دسته بندی و به صورت block در میاورند تا باری را از آن سرویس ها کم کنند که در نهایت تاثیرات شگفت انگیزی بر روی این روال پردازشی میگذارند

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

بخش بعدی GET-page@LSN ها هستند که به صورت واحد مسئله جدیدی نیستند منتها چون در این معماری برای هدفمند کردن و بهینه کردن انتقال اطلاعات مابین نود های پردازشی و page servers ها مورد استفاده قرار میگیرند، تغییراتی در آنها بوجود آمده تا بهینه تر عمل کنند و به سرعتِ فعالیت کلی که در حال انجام است بیشتر کمک کنند.

نکته جالب توجه دیگری که باید به آن اشاره کرد این است که page servers ها به دو صورت میتوانند به معماری اضافه شوند. یک اینکه به صورت یکی پس از دیگری با توجه به درخواست و نیاز نود های پردازشی اضافه شوند یا به صورت دسته ایی اضافه شوند و هر کدامشان یک کپی از صفحه خود را در کنار خود داشته باشند تا در صورت از دست رفتن آنها یا خدشه دار شدنشان جایگزین صفحه اصلی شوند که این روش دوم هم مزایای خود را دارد ولی باعث میشود که عملا سیکل های بیشتری از پردازنده را اشغال کنیم.

نحوه اضافه کردن page servers ها طبق گفته مایکروسافت به عهده خود معماری است و معماری با توجه به باری که بر روی سیستم در یک بازه زمانی گذشته میباشد تصمیم میگیرد که چگونه page servers هارا به معماری اضافه کند.

XLOG

در این جا به نحوه کار این سرویس میپردازیم، xlog همانطور که در شکل میبینیم اطلاعات از طریق نود اصلی به آن وارد میشود که به صورت همزمان در landing zone و به اصطلاح موتور

معماری XLOG

سرویس xlog ریخته میشود. Landing zone وظیفه دسته بندی و طبقه بندی کردن لاگ هارا به عهده دارد تا نهایتا به صورت block در اختیار هسته مرکزی یا موتور سرویس قرار دهد.

در موتور این سرویس، پردازش های درخواستی برای در اختیار قرار دادن اطلاعات بهpage servers ها از طریق log broker صورت میگیرد و قسمت pending blocks نیز وظیفه پردازش درخواست هایی با حجم بالا را به عهده دارد تا پیش از آنکه برای انتشار به log broker ها دهد توسط خودش مورد بهینه سازی قرار گیرد

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

سخن آخر

تکنولوژی های گفته شده در معماری سقراط تا به این لحظه که توسط شرکت مایکروسافت اعلام شده در هیچ مرکز دانشگاهی و تحقیقاتی دیگری مورد بحث و توسعه نبوده و همه ی آنها از ابتکارات و دستاورد های این شرکت میباشد

نخستین ویژگی برجسته این معماری علاوه بر استفاده و بوجود آوردن تکنولوژی ها و سرویس هایی که بیان کردیم این است که تمام آنها به صورت کاملا بهینه و هماهنگی در راستای یک راهبرد در کنار یکدیگر توسعه و استفاده میشوند.

ویژگی بعدی این است که این معماری سرفصل و معنای جدیدی به 2 مسئله همواره مورد مناقشه دنیای فناوری اطلاعات میدهد و آن بحث پایداری durability و دسترسپذیری availability میباشد که کاربرد بسیاری در فناوری های ابری مورد استفاده بشر دارد

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

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

 

آدرس کانال تلگرام سایت بیگ دیتا:

t.me/bigdata_channel

آدرس کانال سروش ما:
https://sapp.ir/bigdata_channel

جهت دیدن سرفصل های دوره های آموزشی بر روی اینجا کلیک کنید.

جهت ثبت نام در دوره های آموزشی بر روی اینجا کلیک کنید.

بازدیدها: 230