تقریباً به مدت چهار دهه SQL زبان واقعی پایگاه های ارتباطی( با نام مستعار RDBMS ) بوده است. به همین دلیل پایگاه داده های رابطه ای به عنوان پایگاه داده SQL نیز شناخته می شوند..
با هر حال ، پایگاه های داده اصلی SQL مانند Oracle ، PostgreSQL و MySQL از نظر معماری یکپارچه هستند. آنها قادر نیستند داده ها و پرس و جوها را به طور خودکار در چندین نمونه توزیع کنند. پایگاه داده های NewSQL برای مقیاس پذیری SQL ظهور کردند. به هر حال ، آنها سازگاری ناراحت کننده خود را نیز خود را نیز نشان دادند.
پس از معرفی Docker و Kubernetes برای ایجاد یک زیرساخت انعطافپذیر و قابل تجزیه و ترکیب از سال 2015 ، برنامه های مبتنی بر میکرو سرویس (خدمات محدود) در حال افزایش هستند. اصول بومی سازی ابری ، مقیاس گذاری داخلی ، انعطاف پذیری و توزیع جغرافیایی از مهمترین تغییرات در این معماری است. اکنون زمان معرفی مفهوم جدیدی از پایگاه داده به نام "توزیع شده "SQL رسیده بود. مشخصه تعریف یک پایگاه داده توزیع شده SQL این است که کل دسته پایگاه داده (صرف نظر از تعداد گره های موجود در آن) به عنوان یک پایگاه داده منطقی SQL به برنامه ها نگاه می کند.
معماری پایگاه داده
پایگاه های داده توزیع شده SQL دارای یک ساختار سه لایه هستند.
همانطور که از نام مشخص است ، یک پایگاه داده توزیع شده SQL باید دارای یک SQL API برای برنامه های کاربردی برای مدل سازی داده های رابطه ای و همچنین جستجوی مربوط به آن روابط باشد. ساختارهای معمول مدل سازی داده ها که منحصر به این پایگاه های داده هستند شامل شاخص ها ، محدودیت های کلید خارجی ، درخواست های JOIN و تراکنش های چند ردیفی ACID هستند.
درخواست ها باید به طور خودکار در چندین گره از خوشه توزیع شود به طوری که هیچ گره واحد به گلوگاه پردازش پرس و جو تبدیل نمی شود. درخواستهای ورودی باید توسط هر گره در خوشه پذیرفته شود و سپس از سایر گره ها درخواست کند تا بخشی از درخواست خود را پردازش کنند به گونه ای که تأخیر پردازش به حداقل برسد ، و شامل زمان داده منتقل شده بین گره های شبکه است. گره اصلی که درخواست را می پذیرد ، باید نتایج جمع شده را به برنامه مشتری ارسال کند.
داده ها از جمله شاخص ها باید به طور خودکار در چندین گره خوشه توزیع شوند (به هم ریخته شود) به طوری که هیچ گره ای به عنوان تنگنا برای اطمینان از عملکرد بالا و در دسترس بودن بالا تبدیل نشود. علاوه بر این ، خوشه پایگاه داده برای اطمینان از مفهوم پایگاه داده منطقی واحد ، باید از تکرار کاملاً سازگار و معاملات ACID چند ردیفی (معروف به توزیع شده) پشتیبانی کند.
تکرار برای پایداری
پشتیبانی از یک لایه قدرتمند SQL API به طور ذاتی مستلزم ایجاد لایه ذخیره سازی اساسی وپاسخگویی مناسب و کاملاً سازگار در میان گره های خوشه پایگاه داده است. این بدان معنی است که نوشتن در پایگاه داده همزمان در چندین گره انجام می شود تا تضمین در دسترس بودن در هنگام خرابی ها باشد. خواندن یا باید آخرین نوشتار قطعی را ارائه دهد یا یک خطا. این خاصیت معمولاً به عنوان قابلیت خطی شناخته می شود. طبق قضیه معروف CAP ، پایگاه های داده توزیع شده SQL به عنوان پایگاه داده های سازگار و مقاوم براساس پارتیشن (CP) طبقه بندی می شوند.
لایه ذخیره پایگاه داده همچنین باید از تراکنشهای ACID توزیع شده در مواردی که هماهنگی تراکنش در چندین ردیف واقع در چندین گره مورد نیاز است پشتیبانی کند. معمولاً این نیاز به استفاده از پروتکل 2 Phase Commit (2PC) دارد. سطوح جداسازی ، که بعنوان I در ACID هستند ، نشانگر سختگیری پایگاه داده نسبت به دسترسی همزمان داده است. انتظار می رود پایگاه های داده توزیع شده SQL قابلیت سریال سازی را به عنوان یک روش ایمن سازی بسیار دقیق و به خوبی روش های سطحی تر مانند Snapshot پشتیبانی کنند.
مزایای تجاری
درحالیکه که پایگاه های داده NoSQL مانند Amazon DynamoDB ، MongoDB و FaunaDB در حال شروع کردن برخی عملیات ها هستند، توسعه دهندگان نرم افزار همچنان پایگاه های SQL را بسیار دوست دارند. یکی از دلایل این میل ترکیبی ، قدرت ذاتی SQL به عنوان یک زبان مدل سازی داده است که بدون هیچ زحمتی عملیات رابطه ای و چند ردیفی را مدل سازی می کند. به عنوان مثال ، SQL با اجازه دادن به معاملات چند ردیفی هم به طور ضمنی (با استفاده از شاخص های ثانویه ، کلیدهای خارجی و پرسش های JOIN) و هم به (با استفاده از نحو BEGIN و END TRANSACTION) فراتر از NoSQL مقدار کلیدی بصورت متداول است. مهمتر از همه ، توسعه دهندگان عاشق سهولت استفاده از SQL برای مدل سازی (و ذخیره) داده ها فقط یک بار هستند و سپس با تغییر JOIN ها به محض نیاز به تغییر کسب و کار ، درخواست ها را تغییر می دهند.
سیستم های توزیع شده مدرن معمولاً برای اطمینان از انعطاف پذیری هنگام مواجه شدن با خرابی های تصادفی به توافق توزیع شده Paxos یا Raft متکی هستند. "تکثیر مبتنی بر اجماع چگونه در پایگاه های داده توزیع شده کار می کند؟" نحوه عملکرد چنین الگوریتم های تکرار را در عمل برجسته می کند. پایگاه های داده توزیع شده SQL توافق توزیع شده را در سطح هر جزء اعمال می کنند تا اطمینان حاصل شود که هر قطعه (و نه به سادگی هر نمونه) در صورت خرابی بسیار در دسترس است. خرابی های زیرساخت همیشه فقط روی زیرمجموعه ای از داده ها (فقط آن دسته از قطعاتی که رهبران(گره بالادستی) آنها را جدا کرده اند) و هرگز کل خوشه را تحت تأثیر قرار نمی دهند. و با توجه به توانایی نسخه های باقی مانده اجزاء برای انتخاب خودکار یک رهبر جدید در چند ثانیه ، خوشه خود را ترمیم می کند بنابراین ویژگی های خود ترمیم را در صورت خرابی نشان می دهد. برنامه برای این تغییرات پیکربندی خوشه شفاف باقی مانده و بدون قطعی یا کندی به طور معمول کار می کند.
در این پست ببینید که چگونه معمولاً داده های اتوماتیک در پایگاه داده توزیع شده SQL اجرا می شود.
با افزودن گره های جدید یا حذف گره های موجود ، اجزاء به طور خودکار در تمام گره های موجود متعادل می مانند. میکروسرویس ها که نیاز به مقیاس پذیری نوشتن برای برنامه های تبادلی دارند ، اکنون می توانند به طور مستقیم به پایگاه داده متکی باشند ، در مقابل اضافه کردن زیرساخت های جدید مانند حافظه کش (که درخواست های خوانده شده از پایگاه داده را بارگیری می کند تا بتوان آن را برای رسیدگی به درخواست های نوشتن حفظ کند) یا یک پایگاه داده NoSQL (که مقیاس گذاری میکندُ اما از تضمین های ACID صرف نظر می کند).
همانطور که در "9 تکنیک ساخت برنامه های SQL Cloud-Native ، Geo-توزیع شده با تأخیر کم" برجسته شده است ، پایگاه های داده توزیع شده SQL می تواند طیف گسترده ای از تکنیک ها را برای ساخت برنامه های توزیع شده جغرافیایی ارائه دهد که نه تنها به تحمل خودکار خرابی های منطقه کمک می کند بلکه به کاهش تأخیر برای کاربران نهایی با نزدیک کردن داده ها به منطقه محلی آنها نیز می انجامد.
YugabyteDB به معماری توزیع شده SQL که قبلاً شرح داده شده است ، پیوست و در نتیجه مزایای برجسته شده در بالا را ارائه می دهد. علاوه بر این ، با سه مزیت زیر خود را از دیگران در گروه SQL توزیع شده متمایز می کند.
DocDB فروشگاه اسناد توزیع شده مستقر در JugabyteDB RocksDB است که با زبان C ++ نوشته شده است. با توجه به مهندسی عملکرد در پشت DocDB ، YugabyteDB مناسب برنامه هایی است که به درخواست های سریع (مانند برنامه های OLTP توزیع شده مثل کاتالوگ محصولات خرده فروشی) یا مصرف زیاد داده (مانند یک بستر تجزیه و تحلیل IoT) نیاز دارند. YugabyteDB چنین برنامه هایی را با خوشه های کوچکتر از سایر پایگاه های داده SQL توزیع می کند. علاوه بر این ، هر گره YugabyteDB می تواند چندین TB داده را ذخیره کند بدون اینکه وعده اصلی مقیاس پذیری نوشتن افقی را برای خوشه پایگاه داده کلی به خطر بیندازد. "مقایسه عملکرد SQL توزیع شده در - YugabyteDB در برابر شفق قطبی آمازون ُ PostgreSQL در مقابل CockroachDB" ویژگی های عملکرد JugabyteDB را در مقابل دو پایگاه داده دیگر در گروه SQL توزیع شده محک می زند.
امروزه سازمان های نرم افزاری الگوهای طراحی خنثی در ابر و چند ابری را آزادی ساخت و مدیریت برنامه ها با سرعتی بی نظیر می دانند. هماهنگ سازی برنامه های کاربردی حاوی Kubernetes یک روش اثبات شده برای اجرای چنین الگوهای طراحی است. با این حال ، پایگاه داده های معاملاتی یکی از پیچیده ترین بارهای کاری است که در Kubernetes اجرا می شود. ماهیت زودگذر غلافهای Kubernetes و نیاز مستمر به برنامه ریزی مجدد آنها روی میزبان جدید Kubernetes ، نیاز دارد که ردیف پایگاه داده اساسی نیز به همان اندازه چابک شود. (در واقع همگام به کارآیی Kubernetes در توسعه نرم افزار باید انعطافپذیری پایگاه داده ها نیز بالا برود ) در غیر این صورت ، برنامه شاهد خاموشی ، کندی و بدتر از همه از دست دادن داده ها و نتایج نادرست است. YB-Master ، سرویس مدیریت پیکربندی داخلی YugabyteDB ، تضمین می کند که برنامه ها با نظارت و تعادل مجدد اجزاء داده ها در گره های موجود ، حتی در یک محیط بسیار پویا مانند خوشه Kubernetes ، هرگز چنین سناریوهایی را تجربه نکنند.
در دوره پروژه های پایگاه داده که به طور فزاینده ای به سمت نرم افزارهای اختصاصی حرکت می کنند و در نتیجه اعتماد جامعه خود را از بین می برند ، YugabyteDB افتخار می کند که با انتشار کل پایگاه داده تحت مجوز منبع باز Apache 2.0 ، مسیر دقیقاً مخالف را دنبال می کند. "چرا ما مجوز YugabyteDB را به 100٪ منبع آزاد تغییر دادیم" دلایل وجود چنین فلسفه ای را برجسته می کند. نتیجه نهایی این است که کاربران با استفاده از ویژگی های پیشرفته پایگاه داده مانند پشتیبان گیری توزیع شده ، تغییر ضبط داده ها ، استقرار در دو منطقه ، رمزگذاری در حالت استراحت و موارد دیگر ، برنامه های مهم تجاری را سریعتر ساخته و منتشر می کنند. محصولات تجاری ، یوگابایت پلتفرم و ابر یوگابایت (که بصورت تجاری پیاده سازی شده اند و متن باز نیستند) تنها در صورت نیاز به یک پایگاه داده خودکار یا کاملاً مدیریت شده به عنوان سرویس مورد توجه قرار می گیرند که عملیات شرکت را بیش از پیش ساده کند.
اکنون که هفت مزیتی را که کاربران باید از پایگاه داده توزیع شده SQL خود انتخاب کنند ، مشخص کردیم ، بیایید مقایسه کنیم که چگونه پنج پایگاه داده در برابر این مزایای مورد نظر مطابقت دارد. پنج پایگاه داده ای که برای مقایسه انتخاب کرده ایم عبارتند از Amazon Aurora ، Google Cloud Spanner ، PingCap’s TiDB ، CockroachDB و YugabyteDB. دو مورد اول خدمات پایگاه داده مدیریت شده اختصاصی هستند در حالی که سه مورد آخر پروژه های خنثی در برابر ابر هستند.
آمازون شفق قطبی که به طور کلی از سال 2015 در دسترس است ، بر روی یک موتور ذخیره سازی توزیع شده اختصاصی ساخته شده است که به صورت خودکار 6 نسخه از داده را در 3 منطقه در دسترس برای تکرار در دسترس تکرار می کند. از نقطه نظر API ، Aurora با سیستم های سازگار با PostgreSQL و MySQL سازگار است. رویکرد نوشتن حد نصاب شفق قطبی بر اساس 6 تکرار امکان دسترسی و ماندگاری به مراتب بهتر از نسخه master-slave را فراهم می کند. به طور پیش فرض ، Aurora با یک پیکربندی تک مستر اجرا می شود که فقط یک گره می تواند درخواست نوشتن را پردازش کند و سایر گره ها کپی فقط خواندنی هستند. اگر گره نویسنده در دسترس نباشد ، با یک مکانیزم رفع عیب یکی از گره های فقط خواندنی را به عنوان نویسنده جدید ارتقا می دهد.
پیکربندی چند مدیری امکان جدیدی است که اخیراً به Aurora MySQL اضافه شده است (هنوز در Aurora PostgreSQL موجود نیست) برای نوشتن مقیاس که شامل گره نویسنده دوم است. با این حال ، از آنجا که همه داده ها اکنون در هر دو گره وجود دارد ، نوشتن همزمان در همان داده ها در دو گره می تواند منجر به ایجاد درگیری و خطاهای بن بست شود که برنامه باید از عهده آنها برآید. یک لیست طولانی از محدودیت ها شامل عدم توانایی مقیاس گذاری بیش از دو گره اصلی نویسنده و همچنین کمبود نوشتارهای توزیع شده جغرافیایی در چندین منطقه وجود دارد.
Spanner پایگاه داده SQL در سراسر جهان است که Google توزیع می کند و بسیاری از ویژگی های مهم تجاری آن مانند AdWords ، Apps ، Gmail و موارد دیگر را تأمین می کند. گوگل از سال 2007 ابتدا Spanner را به عنوان یک نگهدارنده کلیدهای رابطه ای و سپس به عنوان یک پایگاه داده SQL ایجاد می کرد. زیرمجموعه ای از سیستم Spanner در سال 2017 در Google Cloud Platform به عنوان یک سرویس مدیریت شده اختصاصی به نام Google Cloud Spanner در دسترس عموم قرار گرفت. Cloud Spanner یک API اختصاصی SQL ارائه می دهد که نه با هیچ پایگاه داده دیگری با منبع باز SQL سازگار است و نه از ساختارهای مدل سازی داده های رابطه ای سنتی مانند محدودیت های کلید خارجی پشتیبانی می کند. با این حال ، با استفاده از ساعت اتمی اختصاصی Google TrueTime ، Spanner قادر است سطح قابل قبولی از سازگاری خارجی را تضمین کند که حتی سخت تر از قابلیت سریال سازی است
PingCap’s TiDB ، یک پایگاه داده توزیع شده با MySQL که بر روی TiKV ساخته شده و از Google Spanner و Apache HBase الهام گرفته است. در حالی که ساختار تقسیم و تکثیر آن شبیه به Spanner است ، اما برای ارتباطات و تبادلات چند جزء از طرحی کاملاً متفاوت پیروی می کند. همانطور که در "پیاده سازی معاملات توزیع شده به روش Google: Percolator vs. Spanner" توصیف شده است ، TiDB از Google Percolator به عنوان الهام بخش برای طراحی تراکنش های چند جزء استفاده می کند. این انتخاب اساساً TiDB را برای استقرار با نوشتارهای توزیع شده جغرافیایی نامناسب می کند ، زیرا بیشتر معاملات (نقل و انتقال درخواست ها) با دسترسی تصادفی OLTP اکنون هنگام دستیابی به یک نشانگر تاخیر بالایی را تجربه خواهند کرد. علاوه بر این ، TiDB از ساختارهای مهم مدل سازی داده ای رابطه ای مانند کلید خارجی و constraints و سریال سازی پشتیبانی نمیکند.
CockroachDB ، یک پایگاه داده توزیع شده سازگار با PostgreSQL که با استفاده از Raft و RocksDB ساخته شده است ، از Google Spanner تا آنجا که مربوط به تقسیم ، تکثیر و معاملات توزیع شده است ، الهام گرفته شده است. لایه API یک اجرای مجدد از لایه پرس و جو PostgreSQL است که منجر به از دست دادن عمق عملکردی می شود. به عنوان مثال ، indexes, stored procedures, triggers پشتیبانی نمی شوند. علاوه بر این ، CockroachDB اخیراً با ایجاد مجوز در پایگاه داده تحت مجوز اختصاصی منبع BSL 1.0 که دسترسی آزاد را محدود میکند. از امتیازات open source دست کشیده است. آخرین و نه کمترین ، ویژگی های پیشرفته مانند پشتیبان گیری توزیع شده و تغییر داده ضبط حتی در نسخه freemium نیز وجود ندارد و نیاز به مجوز تجاری دارد.
