آیا معاملات Scooby-Doo دارید یا معاملات واقعی؟

کوچکترین فرزند من اخیراً یک مرحله کوتاه "اسکوبی دو" را پشت سر گذاشته است. بعد از پایان از او پرسیدم که چرا علاقه اش را از دست داده است. او با تمام خشم یک پسر کوچک به من نگاه کرد و زمزمه کرد: «این است. همیشه. الف. مرد. که در. الف. کت و شلوار" از میان دندان های شیری به هم فشرده، قبل از پا زدن به من. این نمایشی است که بیش از 275 میلیون دلار با استفاده از یک طرح مشابه بیش از 40 بار درآمد داشته است.

پس این چه ربطی به پایگاه داده دارد؟در حال حاضر صحبت های زیادی در مورد اینکه چگونه 5G و IIoT باعث افزایش حجم تراکنش های ناشی از جریان رویدادها می شوند، وجود دارد، اما به همان اندازه، دست تکان دادن و تعاریف مبهم زیادی در مورد اینکه واقعاً یک «تراکنش» چیست، وجود دارد. در نتیجه، من استدلال می کنم که مردم کارهایی را که می توان با صف های هوشمندانه انجام داد، دست کم گرفت و میزان پردازش جریان تراکنش های با حجم بالا را دست کم گرفتند.

صرفاً به این دلیل که یک تراکنش ساده تک موردی می تواند در یک صف مقیاس شود، به این معنی نیست که تراکنش تجاری پیچیده شما می تواند در یک صف مقیاس شود.

معمولاً ما به تراکنش های ACID فکر می کنیم که به این صورت تعریف می شوند:

• اتمی - یا همه اتفاق می افتد، یا هیچ کدام اتفاق نمی افتد. هیچ کس هرگز بخشی از آن را نمی بیند.
• سازگاری - یک تراکنش نمی تواند کلید اصلی یا سایر محدودیت ها را بشکند.
• جداسازی - تراکنش های در حال اجرا بر یکدیگر تأثیر نمی گذارند. آنها همیشه طوری رفتار می کنند که انگار تنها اتفاقی هستند که در آن زمان اتفاق می افتد.
• دوام - نتایج یک معامله به نوعی دائمی است.
• از منظر SQL، یک قسمت Scooby-Doo ممکن است به شکل زیر باشد:

این مجموعه اقدامات در واقع یک تراکنش ACID را تشکیل می دهد و با خوشحالی در یک صف زندگی می کند، اما معرف مشکلات دنیای واقعی نیست. در Scooby-Doo، نتیجه توسط یک Showbible از پیش تعیین شده است و بنابراین یک نتیجه از پیش تعیین شده است. اسکوبی هرگز شکست نمی خورد. شما نمی توانید در وگاس روی پیچ و تاب های داستانی Scooby-Doo شرط بندی کنید. با خوشحالی می توانید داده های مربوط به صف بندی مورد علاقه خود را بدون لحظه ای فکر یا تلاشی از جانب خود، بدون نیاز به اقدام بیشتر، وارد کنید.

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

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

همه معاملات با استفاده از فن آوری های صف بندی آسان نیستند:

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

در حال حاضر صنعت پایگاه داده به دنبال 5G و IIOT است. من با افرادی در تجارت Telco مکالمه ای داشته ام که به طور اتفاقی اظهار داشتند که انتظار دارند حجم ده برابر شود ، و این در فضایی است که 500K TPS در حال حاضر غیر معمول نیست. یک سری کامل از مشکلات معاملاتی با حجم بالا برای حل وجود خواهد داشت. برخی از این موارد ممکن است "معاملات Scooby-Doo" باشد-جایی که شما به طور موثری رویدادهایی را که قبلاً اتفاق افتاده است ضبط می کنید. اما بسیاری از آنها نوع معاملات خواهند بود که تصمیمات مربوط به پاسخ به رویدادها در حجم زیاد باید در صورت مرتبط بودن در میلی ثانیه انجام شود. از آنجا که این توانایی به طور مستقیم روی خط پایین شما تأثیر می گذارد ، خواستار تصمیم گیری های بسیار دقیق طراحی است.

رسیدگی به صدها هزار معاملات تأثیرگذار و پیچیده در ثانیه.

شما چهار گزینه دارید:

1. سعی کنید این کار را با میراث RDBMS حل کنید. این رویکرد کار نخواهد کرد مگر اینکه شما به نوعی یک مزرعه از پایگاه داده های Legacy RDBMS ایجاد کنید ، کار را در سراسر مزرعه انجام دهید ، یک لایه در بالای آن بنویسید و تعداد زیادی DBA را برای مدیریت آن استخدام کنید.
2. سعی کنید این را با NOSQL حل کنید. در حالی که محصولات NOSQL شروع به ارائه معاملات می کنند ، توانایی های آنها در حال حاضر بسیار عقب مانده از آنچه دنیای واقعی از آنها می خواهد. رویکردهایی که شامل نوشتن کل نسخه های سوابق با نسخه های جدید است ، در برابر مشکلات مقیاس گذاری آسیب پذیر خواهد بود ، به ویژه هنگامی که SLA های کم درگیر هستند ، زیرا درگیری ها منجر به ترمیم های وقت گیر متعدد می شوند.
3. سعی کنید این کار را با یک محصول صف هوشمند حل کنید. فروشندگان محصولات صف شروع به قرار دادن لایه های SQL در بالای عملکرد پایه خود کرده اند و گروه اصلی را با و جمع بندی مبتنی بر زمان اجرا کرده اند. این رویکرد برای سناریوهای ساده مانند ارائه داشبورد به خوبی کار می کند. اما ، هنگامی که این مصالح نشان دهنده انحراف از هنجار است ، باید اقدامات لازم انجام شود ، کافی نخواهد بود که فقط در هر زمان که انتخاب کنند ، جمع آوری شده برای افراد ذینفع را جستجو کنند. در نهایت این رویکرد در صورت تغییر پیچیدگی در مورد استفاده شما ، خطر شکستن را به طور کامل ایجاد می کند و شامل منطق مشروط یا هر پیچیدگی اضافی دیگر است.
4. از داده های فعال ولت استفاده کنید. ما ادعا نمی کنیم که هر مشکلی را حل کنیم ، اما رسیدگی به تعداد زیادی از معاملات پویا با تأخیر قابل پیش بینی بدون به خطر انداختن داده ها و صحت تصمیم گیری ، منطقه ای است که ما سابقه ای تعیین شده در آن داریم.

مراحل بعدی

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

آیا شما معاملات SCOOBY-DOO یا معاملات پیچیده تجاری دارید که باید در یک صف مقیاس بندی شوند؟در تماس باشید و اجازه دهید در مورد چگونگی کمک به داده های فعال ولت گپ بزنیم.