با استفاده از maxwell تغییرات اطلاعات رو از دیتابیس اصلی می خوانیم و بر روی RabbitMQ قرار می دهیم و در نهایت یک سرویس indexer ایجاد می کنیم تا مسیج هایی که روی RabbitMQ قرار گرفته اند را پردازش و اطلاعات را بر روی Typesense ایندکس کند.
با استفاده از CDC پایپلاین میتوانیم اطلاعات را به صورت به صورت آنی یا نزدیک به آنی, از یک ماشین به ماشین دیگری منتقل کنیم بدون اینکه ترافیکی روی دیتابیس ایجاد کنیم.
با استفاده از Debezium تغییرات اطلاعات رو از دیتابیس اصلی می خوانیم و بر روی RabbitMQ قرار می دهیم و در نهایت یک سرویس indexer ایجاد می کنیم تا مسیج هایی که روی RabbitMQ قرار گرفته اند را پردازش و اطلاعات را بر روی Typesense ایندکس کند.
با استفاده از CDC پایپلاین میتوانیم اطلاعات را به صورت به صورت آنی یا نزدیک به آنی, از یک ماشین به ماشین دیگری منتقل کنیم بدون اینکه ترافیکی روی دیتابیس ایجاد کنیم.
معمولا در هنگام کار با دیتابیس ها, سناریوهایی وجود دارد که یک دیتابیس به تنهایی پاسخگوی تمام نیازهای ما نیست یا اینکه استفاده مستقیم از دیتابیس مشکلاتی ایجاد میکند در اینجا چند مثال جهت درک بهتر مشکلات احتمالی داریم:
جداسازی بار (Load seperation)
وقتی دیتابیس اصلی برای تراکنش های اپلیکیشن استفاده می شود و گزارش گیری یا آنالیز سنگین همزمان داده ها باعث کندی و مصرف زیاد منابع دیتابیس می شود. در این حالت داده ها را به یک دیتابیس دیگر مانند ClickHouse یا Snowflake منتقل میکنند که مناسب اجرای دستورات آنالیز داده ها باشد.
جمع آوری و یکجا کردن داده ها از دیتابیس های مختلف (Data lake یا Data warehouse)
معمولا با توجه به قوانین هر کشور, شرکت ها داده ها ها را برای چندین ماه نگهداری میکنند. برای مثال اگر سرویس شما یک اپلیکیشن پیام رسان باشد و کاربر پیامی را حذف کند آن پیام با توجه به قوانین, برای مدتی درون دیتابیس دیگری نگهداری می شود.
حتی تغییرات مربوط به اطلاعات نیز جمع آوری, تجمیع و برای مدتی نگهداری می شوند. این داده ها می توانند برای تحلیل و بررسی رفتار کاربران و پیش بینی آینده ی بیزینس مورد استفاده قرار گیرند.
بروزرسانی سیستم های جانبی
در بعضی معماری ها مانند مایکرو سرویس (Micro service) اپلیکیشن ما به چندین سرویس کوچکتر تقسیم میشود که هرکدام دیتابیس خودشان را دارند و به صورت مستقل عمل می کنند. در چنین موارد ممکن است یکی از سرویس های ما نیازمند اطلاعاتی باشد که درون دیتابیس سرویس دیگر ذخیره شده است! یکی از راهکار ها ذخیره سازی و همگام سازی اطلاعات مورد نظرمان در هردو سرویس است! بدین صورت که مالکیت اطلاعات (حق افزودن اطلاعات جدید و ویرایش آنها) با یک سرویس است و سرویس دیگر یک کپی از آن اطلاعات را نگهداری خواهد کرد تا نیازی نباشد که لود روی دیتابیس سرویسی که مالکیت اطلاعات را به عهده دارد زیاد شود.
مانیتورینگ و حسابرسی تغییرات (Monitoring and Audit)
تقریبا تمام شرکت های بزرگ تغییرات اطلاعات را به صورت نزدیک به آنی (real time) مانیتور می کنند. برای مثال با بررسی تعداد insert/update/delete در هر لحظه میتوان میزان فشاری که بر روی دیتابیس است را بررسی کرد و نسبت به تغییرات آن واکنش نشان داد. برای مثال اگر میزان delete اطلاعات در یک بازه زمانی مشخص دوبرابر همان بازه زمانی شود میتواند نشان دهنده یک مشکل امنیتی باشد!
و یا اگر تعداد insert (افزوده شدن اطلاعات به دیتابیس) تغییرات فاحشی داشته باشد (مثلا دو برابر شود) میتواند نشان دهنده ی یک نوع حمله ی DDOS باشد.
CDC چیست؟
دیتابیس اصلی معمولاً برای کارهای روزمرهٔ اپلیکیشن طراحی شده (ثبت سفارش، مدیریت کاربر، تراکنشهای مالی و …) است و هنگامی که همان دیتابیس برای نیازهای دیگه مثل گزارشگیری، آنالیز یا انتقال داده استفاده شود، با چند مشکل جدی روبرو خواهیم شد.
مشکل احتمالی
دلیل
فشار بالا به دیتابیس اصلی به خاطر کوئریهای متنوع
معمولا کوئری های گزارش گیری و آنالیز پیچیده تر و سنگین تر از کوئری های معمول که توسط اپلیکیشن استفاده میشوند هستند.
با افزایش بار بر روی دیتابیس ممکن است کوئری های اپلیکیشن اصلی با سرعت کمتری اجرا شوند و این باعث کند شدن عملکرد اپلیکیشن خواهد شد.
عدم مقیاس پذیری / مقیاس پذیری گران
مقیاس پذیری دیتابیس اصلی معمولا یا غیر ممکن خواهد بود و یا اینکه با مشکلات زیادی روبرو خواهیم شد که باعث افزایش هزینه های ما خواهد شد (زمان برای نگهداری دیتابیس + پول برای پرداخت هزینه های زیرساخت)
ریسک بالا بر روی availability
کوئری های گزارش گیری و آنالیز معمولا سنگین تر هستند زیرا نیاز است تا مقدار حجیمی از اطلاعات بررسی و پردازش شوند. در چنین مواقعی اجرای یک کوئری سنگین ممکن است باعث کرش و خارج شدن دیتابیس اصلی از دسترس شود (down شدن).
یکی از بهترین راه حل ها برای مشکل مطرح شده, استفاده از CDC است. در CDC بهجای اینکه کل دیتابیس را دوباره بخوانیم (که نیازمند هزینه و زمان زیادی است)، فقط تغییرات ثبتشده در لاگ دیتابیس (مثل Binlog در MySQL یا WAL در PostgreSQL) استخراج می شوند. این تغییرات را می توان بعدا به سیستمهای مختلف منتقل کرد برای مثال Kafka یا MQ برای پردازش و همچنین real-time ElasticSearch برای جستجوی سریع و یا Data Warehouse برای تحلیل داده.
بدین ترتیب با استفاده از CDC میتوان تغییرات را به صورت آنی یا نزدیک به آنی ثبت و چندین بار پردازش کرد بدون آنکه فشاری بر روی دیتابیس اصلی وارد شود.
چگونگی پیاده سازی
برای پیاده سازی CDC نیاز داریم تا binlog را فعال کنیم. سپس میتوانیم از ابزارهای موجود بر حسب نیاز استفاده کنیم تا تغییرات بر روی دیتابیس را ثبت کنیم. در اینجا دوتا از ابزارهای اوپن سورس (open-source) را بررسی میکنیم.
هردو ابزار معرفی شده اوپن سورس و رایگان هستند. اما تفاوت هایی دارند که در پایین بررسی می کنیم:
Maxwell نیازمند تنظیمات ساده تری است اما فقط قادر است با binlog مربوط به دیتابیس MySQL کار کند. بنابراین اگر میخواهیم تغییرات اطلاعات مربوط به دیتابیسی به غیر از MySQL را ثبت کنیم نمیتوانیم از Maxwell استفاده کنیم.
Debezuim تنظیمات بیشتری دارد اما قادر است با دیتابیس های MySQL, PostgreSQL, MongoDB و Oracle کار کند. بنابراین اگر نیاز دارید تا تغییرات دیتابیسی به غیر از MySQL را ثبت کنید میتوانید از Debezuim استفاده کنید.
ایجاد CDC بر روی دیتابیس با استفاده از Maxwell
تا اینجا با CDC و نحوه عملکرد آن آشنا شدیم.
در قسمت بعد به عنوان یک مثال واقعی, Maxwell را بر روی دیتابیس MySQL اجرا میکنیم و تغییرات اطلاعات را بر روی RabbitMQ میفرستیم و در نهایت در Typesense ثبت میکنیم تا توسط یک اپلیکیشن که جستجوی سریع در بین اطلاعات را انجام میدهد مورد استفاده قرار گیرد. بدین ترتیب اطلاعات را بدون ایجاد فشار بر روی دیتابیس اصلی, روی Typesense ایندکس میکنیم.