آپاچی کافکا را پایگاه داده خود نکنید

معماری های رویداد محور فوق العاده هستند. اما کافکا هرگز قرار نبود یک پایگاه داده باشد و استفاده از آن به عنوان پایگاه داده مشکل شما را حل نمی کند.

این داستانی به قدمت زمان است. یک شرکت با محدودیت‌های عملکرد و مقیاس‌پذیری پایگاه داده رابطه‌ای فعلی خود مبارزه می‌کند. تیم‌هایی که وظیفه یافتن راه‌حل جدیدتری را بر روی معماری رویداد محور قرار می‌دهند، نگاهی به آپاچی کافکا می‌اندازند و می‌گویند: «آها! در اینجا راه حل جدید پایگاه داده ما است.” سریع است مقیاس پذیر است. بسیار در دسترس است. این ابرقهرمانی است که به آن امید داشتند!

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

پایگاه داده چیست و چیست؟

وقتی توسعه‌دهندگان یک پایگاه داده را مفهوم‌سازی می‌کنند، معمولاً مانند اکثر راه‌حل‌های SQL و NoSQL، به یک فروشگاه داده با فهرست و جداول ثانویه فکر می‌کنند. یکی دیگر از الزامات سنتی، انطباق با اسید است: اتمی، قوام، جداسازی و دوام. با این حال، تفکر سنتی در مورد اینکه چه چیزی یک پایگاه داده است یا نیست، مرتباً به چالش کشیده می شود. برای مثال، Redis جداول ندارد و RocksDB ایندکس ثانویه ندارد. و هیچکدام با ACID سازگار نیستند. با این حال، هر دو معمولا به عنوان پایگاه داده نامیده می شوند. به طور مشابه، Apache Cassandra به عنوان پایگاه داده NoSQL شناخته می شود، اما با ACID سازگار نیست.< /p>

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

کافکا زبان پرس و جو ندارد. شما می‌توانید برای یک بازه زمانی خاص به رکوردهای خاصی دسترسی داشته باشید، اما به گزارش پیش‌نویس دسترسی دارید. کافکا دارای افست ها و موضوعات است، اما آنها جایگزین فهرست ها و جداول نیستند. مهمتر از همه، کافکا با ACID سازگار نیست. اگرچه می‌توان از کافکا به‌عنوان ذخیره‌سازی داده یا ایجاد نسخه‌ای از پایگاه داده خود استفاده کرد، کافکا به خودی خود یک پایگاه داده نیست.

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

کافکا بهترین بازیکن تیم است

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

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

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

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

قابل اتصال و همه کاره، اما نه پایگاه داده

کافکا بیشترین ارزش خود را در موارد استفاده فعال از قبیل تجمیع داده‌ها و معیارهای بی‌درنگ ارائه می‌کند. استفاده از ابزارهای اکوسیستم کافکا و آپاچی مانند Spark، Flink، یا KStreams، توسعه دهندگان می توانند تجمیع و تبدیل داده های جریانی را انجام دهند و سپس آن داده ها را به پایگاه داده مورد نظر منتقل کنند. برخی از این ابزارها همچنین می‌توانند داده‌ها را به‌صورت سری‌های زمانی یا پنجره‌ای جمع‌آوری کنند و آن‌ها را به موتور گزارش‌دهی برای معیارهای هم‌زمان هدایت کنند.

اگر توسعه‌دهندگان مایلند داده‌های خاصی را در حافظه پنهان ذخیره کنند – شاید برای پشتیبانی از یک وب‌سایت یا سیستم‌های CRM – ساده است که به جریان داده کافکا ضربه بزنید و داده‌ها را به Redis یا یک موضوع فشرده کافکا منتقل کنید. جریان داده‌ها از کافکا به تیم‌ها اجازه می‌دهد تا اجزای مختلفی را به دلخواه خود بدون نگرانی در مورد هرگونه تخریب در سرویس اضافه کنند، زیرا کافکا بسیار مقیاس‌پذیر، قابل اعتماد و در دسترس است. این شامل تغذیه داده‌ها به هر فروشگاه داده، خواه آپاچی کاساندرا، پلتفرم‌های کلان داده، دریاچه‌های داده یا تقریباً هر گزینه دیگری است.

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

اندرو میلز یک معمار ارشد راه حل در Instaclustr، بخشی از Spot توسط NetApp است که ارائه می کند یک پلت فرم مدیریت شده و پشتیبانی پیرامون فناوری های منبع باز. در سال ۲۰۱۶ اندرو سفر جریان داده خود را آغاز کرد و دانش عمیق و تخصصی Apache Kafka و اکوسیستم اطراف آن را توسعه داد. او چندین خط لوله داده بزرگ را با محوریت کافکا طراحی و اجرا کرده است.

—

New Tech Forum مکانی را برای رهبران فناوری – از جمله فروشندگان و سایر مشارکت‌کنندگان خارجی – فراهم می‌کند تا فناوری سازمانی نوظهور را در عمق و وسعت بی‌سابقه بررسی و بحث کنند. انتخاب ذهنی است، بر اساس انتخاب ما از فناوری هایی که معتقدیم مهم هستند و برای خوانندگان InfoWorld بیشترین علاقه را دارند. InfoWorld وثیقه بازاریابی را برای انتشار نمی پذیرد و حق ویرایش تمام محتوای ارائه شده را برای خود محفوظ می دارد. همه پرس و جوها را به doug_dineley@foundryco.com.