DBMS توزیع شده برای سازمان

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

تنها چیزی که مشخص نیست معنی حرف "پ" است. وقتی خوشه تقسیم می‌شود، تصمیم می‌گیرد تا زمانی که به حد نصاب برسد، پاسخ ندهد یا داده‌های موجود را پس بدهد. بسته به نتایج این انتخاب، سیستم به عنوان یک CP یا یک AP طبقه بندی می شود. برای مثال، Cassandra می‌تواند به هر شکلی رفتار کند، نه حتی به تنظیمات کلاستر، بلکه به پارامترهای هر درخواست خاص. اما اگر سیستم "P" نیست و تقسیم می شود، پس چه؟

پاسخ به این سوال تا حدودی غیرمنتظره است: یک خوشه CA نمی تواند تقسیم شود.
این چه نوع خوشه ای است که نمی تواند تقسیم شود؟

یکی از ویژگی های ضروری چنین خوشه ای یک سیستم ذخیره سازی داده مشترک است. در اکثر موارد، این به معنای اتصال از طریق SAN است که استفاده از راه حل های CA را به شرکت های بزرگی که قادر به حفظ زیرساخت SAN هستند محدود می کند. برای اینکه چندین سرور با داده های یکسان کار کنند، یک سیستم فایل خوشه ای مورد نیاز است. چنین سیستم های فایلی در پورتفولیوهای HPE (CFS)، Veritas (VxCFS) و IBM (GPFS) موجود هستند.

اوراکل RAC

گزینه Real Application Cluster اولین بار در سال 2001 با انتشار Oracle 9i ظاهر شد. در چنین خوشه ای، چندین نمونه سرور با یک پایگاه داده کار می کنند.
اوراکل می‌تواند هم با یک سیستم فایل خوشه‌ای و هم با راه‌حل خاص خود - ASM، مدیریت ذخیره‌سازی خودکار، کار کند.

هر کپی مجله مخصوص به خود را نگه می دارد. معامله توسط یک نمونه اجرا و انجام می شود. اگر یک نمونه شکست بخورد، یکی از گره‌های خوشه (نمونه‌ها) باقیمانده گزارش آن را می‌خواند و داده‌های از دست رفته را بازیابی می‌کند - در نتیجه در دسترس بودن را تضمین می‌کند.

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

اما اگر یکی از نمونه ها نیاز به تغییر داده ها داشته باشد چه اتفاقی می افتد؟

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

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

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

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

اگر یک گره به ضربان قلب واکنش نشان ندهد، گرهی که آن را شناسایی کرده است ابتدا روی دیسک رای گیری را آغاز می کند. اگر گره از دست رفته در اینجا ذکر نشده باشد، یکی از گره ها مسئولیت بازیابی اطلاعات را بر عهده می گیرد:

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

برای ساده کردن سوئیچینگ بین گره ها، اوراکل مفهوم یک سرویس - یک نمونه مجازی را دارد. یک نمونه می تواند چندین سرویس را ارائه دهد و یک سرویس می تواند بین گره ها حرکت کند. یک نمونه برنامه کاربردی که به بخش خاصی از پایگاه داده سرویس می دهد (مثلاً گروهی از مشتریان) با یک سرویس کار می کند و سرویس مسئول این قسمت از پایگاه داده در صورت خرابی یک گره به گره دیگری منتقل می شود.

سیستم های داده خالص آی بی ام برای تراکنش ها

یک راه حل خوشه ای برای DBMS در مجموعه Blue Giant در سال 2009 ظاهر شد. از نظر ایدئولوژیک، جانشین خوشه Sysplex موازی است که بر روی تجهیزات "معمولی" ساخته شده است. در سال 2009، DB2 pureScale به عنوان یک مجموعه نرم افزاری منتشر شد و در سال 2012، IBM ابزاری به نام Pure Data Systems for Transactions را ارائه کرد. نباید آن را با Pure Data Systems for Analytics که چیزی جز یک تغییر نام Netezza نیست، اشتباه گرفت.

در نگاه اول، معماری pureScale شبیه Oracle RAC است: به همین ترتیب، چندین گره به یک سیستم ذخیره سازی داده مشترک متصل می شوند و هر گره نمونه DBMS خود را با مناطق حافظه و گزارش های تراکنش خود اجرا می کند. اما، برخلاف اوراکل، DB2 دارای یک سرویس قفل اختصاصی است که توسط مجموعه‌ای از فرآیندهای db2LLM* نمایش داده می‌شود. در پیکربندی خوشه ای، این سرویس بر روی یک گره مجزا قرار می گیرد که در Sysplex موازی به آن Coupling Facility (CF) و در Pure Data PowerHA می گویند.

PowerHA خدمات زیر را ارائه می دهد:

• مدیر قفل؛
• حافظه نهان بافر جهانی؛
• حوزه ارتباطات بین فرآیندی

برای انتقال داده ها از PowerHA به گره های پایگاه داده و برگشت، از دسترسی به حافظه راه دور استفاده می شود، بنابراین اتصال خوشه ای باید از پروتکل RDMA پشتیبانی کند. PureScale می تواند از Infiniband و RDMA از طریق اترنت استفاده کند.

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

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

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

"کثیف"، یعنی تغییر یافته، می توان صفحات را هم از یک گره معمولی و هم از PowerHA (castout) روی دیسک نوشت.

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

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

تست های داخلی IBM روی حجم کاری 90% خواندن و 10% نوشتن، که بسیار شبیه به حجم کاری تولید در دنیای واقعی است، مقیاس تقریباً خطی تا 128 گره را نشان می دهد. شرایط آزمون، متأسفانه، فاش نشده است.

HPE NonStop SQL

پورتفولیوی شرکت هیولت پاکارد نیز پلتفرم بسیار در دسترس خود را دارد. این پلتفرم NonStop است که در سال 1976 توسط Tandem Computers به ​​بازار عرضه شد. در سال 1997، شرکت توسط Compaq خریداری شد که به نوبه خود در سال 2002 با Hewlett-Packard ادغام شد.

NonStop برای ساخت برنامه های کاربردی مهم استفاده می شود - به عنوان مثال، پردازش HLR یا کارت بانکی. این پلتفرم در قالب یک مجتمع نرم افزاری و سخت افزاری (دستگاه) که شامل گره های محاسباتی، سیستم ذخیره سازی داده ها و تجهیزات ارتباطی است، ارائه می شود. شبکه ServerNet (در سیستم های مدرن - Infiniband) هم برای تبادل بین گره ها و هم برای دسترسی به سیستم ذخیره سازی داده ها خدمت می کند.

نسخه های اولیه سیستم از پردازنده های اختصاصی استفاده می کردند که با یکدیگر همگام شده بودند: تمام عملیات ها توسط چندین پردازنده به صورت همزمان انجام می شد و به محض اینکه یکی از پردازنده ها خطا می کرد، خاموش می شد و دومی به کار خود ادامه می داد. بعداً، سیستم به پردازنده‌های معمولی (اول MIPS، سپس Itanium و در نهایت x86) روی آورد و مکانیسم‌های دیگری برای همگام‌سازی استفاده شد:

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

از سال 1987، یک DBMS رابطه‌ای بر روی پلتفرم NonStop اجرا می‌شود - ابتدا SQL/MP و بعداً SQL/MX.

کل پایگاه داده به بخش‌هایی تقسیم می‌شود و هر قسمت مسئول فرآیند مدیریت دسترسی به داده (DAM) خود است. مکانیزم های ضبط، ذخیره و قفل کردن داده ها را فراهم می کند. پردازش داده ها توسط Executor Server Processes اجرا می شود که روی همان گره هایی که مدیران داده مربوطه اجرا می شوند، انجام می شود. زمانبندی SQL/MX وظایف را بین مجریان تقسیم می کند و نتایج را جمع می کند. هنگامی که لازم است تغییرات مورد توافق ایجاد شود، از پروتکل تعهد دو فازی ارائه شده توسط کتابخانه TMF (Transaction Management Facility) استفاده می شود.

NonStop SQL می تواند فرآیندها را اولویت بندی کند تا پرس و جوهای تحلیلی طولانی در اجرای تراکنش ها اختلال ایجاد نکنند. با این حال، هدف آن دقیقاً پردازش تراکنش های کوتاه است و نه تجزیه و تحلیل. توسعه دهنده در دسترس بودن خوشه NonStop را در سطح پنج "نه" تضمین می کند، یعنی زمان خرابی تنها 5 دقیقه در سال است.

SAP-HANA

اولین انتشار پایدار HANA DBMS (1.0) در نوامبر 2010 انجام شد و بسته SAP ERP در می 2013 به HANA تغییر یافت. این پلت فرم مبتنی بر فناوری های خریداری شده است: موتور جستجوی TREX (جستجو در فضای ذخیره سازی ستونی)، P*TIME DBMS و MAX DB.

کلمه "HANA" به خودی خود مخفف دستگاه تحلیلی با عملکرد بالا است. این DBMS به صورت کدی ارائه می شود که می تواند بر روی هر سرور x86 اجرا شود، با این حال، نصب های صنعتی فقط بر روی تجهیزات تایید شده مجاز است. راه حل های موجود از HP، Lenovo، Cisco، Dell، Fujitsu، Hitachi، NEC. برخی از پیکربندی‌های Lenovo حتی امکان عملیات بدون SAN را فراهم می‌کنند - نقش یک سیستم ذخیره‌سازی مشترک توسط یک خوشه GPFS روی دیسک‌های محلی ایفا می‌شود.

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

هر گره خوشه ای HANA مسئول بخشی از داده های خود است و نقشه داده در یک مؤلفه خاص - Name Server که در گره هماهنگ کننده قرار دارد، ذخیره می شود. داده ها بین گره ها کپی نمی شوند. اطلاعات قفل نیز در هر گره ذخیره می شود، اما سیستم دارای یک آشکارساز بن بست جهانی است.

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

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

منبع: www.habr.com