در داخل و خارج: معاملات

بنابراین ، در قسمت آخر ، من در مورد چگونگی سحر و جادو پایگاه داده صحبت کردم. اما ، من یکی از جادویی ترین موضوعات را برای آخرین بار ذخیره کردم: معاملات! این همان چیزی است که من امروز در مورد آن صحبت خواهم کرد. و من می خواهم این کار را با کمی کمک از دوستانم پت هلند ، یک معمار اصلی در Salesforce انجام دهم.

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

تصویر: عوام خلاق

این به معنای عملکرد به عنوان یک واحد اتمی است - "اتمی" به معنای یونان باستان "غیرقابل توصیف" (ἄτομος). شما می خواهید که این دو رویداد از هم جدا شوند. اگر دستگاه خودپرداز را به این فکر می کنید که 100 دلار به آن داده اید ، اما این واقعاً یک بسته بندی لثه بود ، اکنون 100 دلار (زمان مهمانی!). برعکس ، اگر دستگاه خودپرداز به خودآگاهی دست یابد و صد دلار خود را به جای اعتبار حساب خود در آتلانتیک سیتی ، در یک قمار قمار در آتلانتیک سیتی می گیرد ... خوب ، شما 100 دلار کاهش می دهید (بو).

بدیهی است که هیچ یک از اینها رفتار صحیح نیستند.

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

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

این جایی است که شما شروع به قلاب زدن به اسید می کنید.

تصویر: عوام خلاق. مشاهده توصیه نمی شود.

اسید؟بله ، A. C. I. D. این یک کلمه مخفف است (مانند برنامه نویسان مانند Catnip است). این مخفف "اتمی ، سازگار ، منزوی و بادوام" است:

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

هیچ یک از این ویژگی ها خیلی عجیب به نظر نمی رسند - منظورم این است که شما انتظار دارید یک سیستم اینگونه رفتار کند، درست است؟انجام ندادن هیچ یک از این کارها بسیار شکسته به نظر می رسد.

خوب، معلوم می شود که قبل از ظهور پایگاه های داده رابطه ای، اکثر سیستم های ذخیره سازی این را تضمین نمی کردند. آنها اکثراً اینگونه رفتار می کردند، اما در 100% موارد نه. اگر ضمانتی برای آن ویژگی ها می خواستید، باید آن را در برنامه خود در بالای پایگاه داده قرار می دادید.

و معلوم می شود که بسیار سخت است. به این فکر کنید که در نظر گرفتن هر جایگشتی در مورد اینکه چگونه ممکن است همه چیز اشتباه شود، چه دردسری خواهد داشت: اگر یک فرآیند 10 مرحله ای دارید، اگر سرور یا شبکه بعد از ... مرحله 1 از کار بیفتد، چه کاری انجام می دهید؟یا مرحله 2؟و غیره. تراکنش های ACID کمک بزرگی در ساده سازی برنامه ها هستند، زیرا مطمئن می شوید که فضای ذخیره سازی همانطور که به نظر می رسد رفتار می کند.

و بر خلاف دنیای واقعی بی ثبات، یک پایگاه داده در حال اجرا با کمی بدبینانه بودن می تواند این را تا 100% تضمین کند: یک تراکنش تنها زمانی به حالت "متعهد" تبدیل می شود که همه کار انجام شود و درست نشان داده شود. هر چیز دیگری به عقب برمی گردد، گویی هرگز اتفاق نیفتاده است. پایگاه داده های مختلف این کار را به روش های مختلف انجام می دهند، اما عمدتاً با داشتن یک گزارش ویژه (معمولاً به نام "Write-Ahead" یا "Undo" log) که در آن همه عملیات ها را به محض وقوع می نویسد، به طوری که در صورت خرابی، می توانید به طور خودکار اقدامات اخیر را به جلو یا عقب پخش کنید تا به یک نقطه ثابت برسید. شما به سادگی نمی توانید یک پایگاه داده سالم و در حال اجرا داشته باشید که به نحوی این تضمین ها را باطل کند. اگر در حال اجرا باشد، درست است.

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

پایگاه داده های رابطه ای برای ارائه این نوع تضمین طراحی شده اند. می توانید برنامه ای بنویسید که هزاران رکورد را در صدها جدول مختلف به روزرسانی می کند، و کل آن را commit یا rollback می کند. این فراتر از مفید است - PFM است.(سحر و جادو خالص Freaking.)

در Salesforce، بسیاری از محصولات ما که مشتری را قادر می سازد، توسط یک پایگاه داده رابطه ای پشتیبانی می شوند - و تراکنش ها بخش مهمی از آن هستند. همانطور که مشتریان ما داده ها را تغییر می دهند، یا از ابزارهای مدیریتی برای اصلاح فراداده ها و تنظیمات استفاده می کنند، آن ها ضمانت ACID را دریافت می کنند، بنابراین کارها هرگز به حالت نیمه متعهد ختم نمی شوند. همین امر برای زمانی که آنها منطق تجاری پیچیده تری ایجاد می کنند (به عنوان مثال، با استفاده از کد Apex) صدق می کند. مشتریان نیازی به سیستم های پیچیده «میان افزار» ندارند، این دقیقاً نحوه عملکرد آن است.

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

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

تصویر: عوام خلاق

تراکنش های ACID به همان اندازه که خوب هستند، فقط می توانند به طور قابل اعتماد در داخل، در یک سرویس در حال اجرا عمل کنند. منظور من از "درون" چیست؟به جای توضیح کامل آن، شما را به مقاله برجسته پت هلند راهنمایی می کنم:

(اگر عجله دارید، The Moing Paper به تازگی خلاصه ای عالی از مقاله را در این هفته انجام داده است.)

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

اما به محض اینکه داده ها خارج از این مرزها قرار می گیرند، تابع فیزیک «انیشتینی» (یعنی نسبیت) می شوند: اطلاعات زمان می برد تا از سرویسی به سرویس دیگر منتقل شود، و شما فقط می توانید در مورد وضعیت آن از مدتی درگذشتهو مهمتر از همه، شما توانایی انجام تراکنش های تضمین شده ACID را که در بالا در مورد آن صحبت کردیم، از دست می دهید: آنها بسیار شکننده و کند هستند.

چرا اینطور است؟زیرا زمانی که پیام ها باید بین سیستم های مختلف حرکت کنند (به جای استفاده از حافظه مشترک)، اطمینان از اینکه همه در یک صفحه هستند بسیار دشوارتر می شود. تراکنش هایی که ماشین ها را در بر می گیرند - همانطور که به آن ها «تراکنش های توزیع شده» می گویند - از نظر فنی امکان پذیر هستند، اما انجام آن ها در مقیاس واقعاً سخت است.(قیاس پت برای این است: تصور کنید تلفنی ازدواج می کنید. می گویید "من انجام می دهم" و سپس تماس قطع می شود. آیا مجاز به قرار ملاقات با افراد دیگر هستید؟)

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

به عنوان مثال، به جستجو فکر کنید. ما فرآیندی را برای فهرست بندی مستمر تمام داده ها در Salesforce اجرا می کنیم (در غیر این صورت، اگر می خواهید کلمه "موز" را جستجو کنید، سیستم باید هر رکورد را به صورت جداگانه در زمان جستجوی شما بررسی کند، که برای همیشه طول می کشد!). هر بار که یک قطعه داده به روز می شود، یک کپی از آن داده های جدید برای نمایه سازی به این سیستم جستجو تحویل داده می شود، بنابراین جستجوها سریع هستند.

اما از نظر فنی، این نمایه سازی همیشه بر اساس یک واقعیت کمی قدیمی عمل می کند - "گذشته". بین لحظه ای که مقدار را به روز کردید، و لحظه ای که نمایه ساز جستجو آن را دریافت می کند (معمولا چند ثانیه بعد)، ممکن است دوباره تغییر کرده باشد (که البته در آینده پیام دیگری به نمایه ساز خواهد داد). ایندکس کننده جستجو باید فرض کند که واقعاً حقیقت فعلی در مورد داده ها را نمی داند، فقط یک سری تلگرام با کمی تأخیر در مورد آن می داند.

چرا؟از آنجایی که سیستم نمایه ساز جستجو "در خارج" است - این یک سرویس جداگانه از پایگاه داده است (در مورد ما، به عنوان یک خوشه که Apache Solr را اجرا می کند، پیاده سازی شده است). به همان اندازه که پایگاه های داده قدرتمند و جادویی هستند، نمی توان انتظار داشت که همه جنبه های یک سیستم توزیع شده بزرگ مانند سرویس Salesforce را احاطه کنند.

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

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

برای اصلاحات محصور شده در یک درخواست مشتری ، نقطه کانونی به روزرسانی های معامله ما پایگاه داده رابطه ای است. برای اطمینان از مقیاس و ظرفیت کافی ، ما به شدت زیرساخت های خود را به آنچه "نمونه ها" می نامیم (که به یاد می آورید ، من در قسمت 2 صحبت کردم - اکنون می دانید که چرا اینقدر مهم است!) در قلباز سیستم ما ، به روزرسانی های یک مشتری واحد به داده های استاندارد رکورد محور خود باید همه از طریق این یک نقطه جریان یابد ، که توسط پایگاه داده رابطه ای نگهداری می شود.

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

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

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