شركة Databricks الأمريكية تطلق تقنية LTAP وتدّعي عدم وجود نسخ مكررة

أخبار ar.wedoany.com، تعلن شركة Databricks عن إطلاق تقنية جديدة تُعرف باسم LTAP (المعالجة التحليلية/المعاملاتية القائمة على بحيرة البيانات)، بشعار تسويقي هو "بيانات واحدة، بدون مساومة، بدون نسخ مكررة"، بهدف حل التحدي المتمثل في صعوبة التعايش بين معالجة المعاملات عبر الإنترنت (OLTP) والمعالجة التحليلية عبر الإنترنت (OLAP) داخل نظام واحد. تعتمد هذه التقنية على محرك التحليل الموحد مفتوح المصدر Apache Spark، وتستند إلى منتجين جديدين: Reyden (محرك حوسبة جديد) وLakebase (قاعدة بيانات PostgreSQL غير خادمية قائمة على التخزين الكائني المفتوح). تسعى Databricks من خلال نسخة تخزين واحدة في بحيرة البيانات (التي تجمع بين بحيرة البيانات ومستودع البيانات) إلى توحيد المعاملات والتحليلات والتدفقات والبيانات التشغيلية، مما يعالج التحدي الأساسي المتمثل في قيام OLTP بتنفيذ عمليات قراءة صغيرة موجهة للصفوف وكتابة متكررة، بينما ينفذ OLAP عمليات قراءة كبيرة موجهة للأعمدة وكتابة مجمعة. تزداد أهمية هذه المشكلة في الوقت الذي يسعى فيه سوق قواعد البيانات إلى مواكبة أعباء العمل الناتجة عن نشر وكلاء الذكاء الاصطناعي (AI Agents).

ومع ذلك، هناك جدل حول ادعاء "عدم وجود نسخ مكررة". يشير مهندسو بيانات إلى أن بيانات PostgreSQL الحالية في LTAP تُخزَّن بتنسيق pageserver كتخزين محلي، ثم تُنشر إلى التخزين الكائني بتنسيق ملفات Parquet لتحقيق الاستمرارية طويلة الأجل. يمكن لـ PostgreSQL/Lakebase استرداد البيانات من التخزين الكائني وإعادة تحويل بيانات Parquet مرة أخرى إلى pageserver. ويعلق أحد المعلقين من منافسي Databricks قائلاً إن هذا يعني في الواقع "نسختين من البيانات، وليس نسخة واحدة". في مؤتمر PostgreSQL عُقد في مايو من هذا العام، أكدت الشرائح التي قدمها مهندسا Databricks، Hristo Stoyanov وJonathan Katz، ذلك أيضًا، حيث أظهرت أن pageserver يوفر التخزين، بينما يسحب منفذ تحليل Spark ملفات الطبقات التي تحتوي على صور صفحات كاملة من طبقة المرآة في التخزين الكائني. في مجتمع رسائل خاص اطّلعت عليه The Register، رد أحد مهندسي Databricks بأنه من الناحية الفنية توجد نسختان، لأن pageserver يعمل كطبقة تخزين مؤقت أو طبقة مادية في بنية Neon. يعتمد Lakebase على تقنية Neon التي استحوذت عليها Databricks العام الماضي، والتي توفر فروعًا بنسخ عند الكتابة (copy-on-write) وحوسبة غير خادمية قابلة للتوسع التلقائي.

توحيد OLTP وOLAP ليس ابتكارًا من Databricks. ففي عام 2014، بدأت SingleStore العمل على التخزين الصفي في الذاكرة والتخزين العمودي على القرص، واعتمدت تقنية التخزين متعدد الطبقات التي تسمح بإجراء التحليلات ومعالجة المعاملات على نظام واحد. في عام 2020، أطلقت الشركة خدمة قاعدة بيانات سحابية تدّعي إدارة البيانات تلقائيًا عبر بنية ثلاثية الطبقات تشمل الذاكرة والتخزين المؤقت المحلي والتخزين الكائني. ردًا على ادعاء Databricks بأن المعالجة المختلطة للمعاملات/التحليلات (HTAP) قد فشلت، قال كبير مسؤولي التكنولوجيا في SingleStore، Nadeem Asghar، إن توحيد OLTP وOLAP هو بالضبط هدف HTAP، وأضاف: "تغيير الاسم إلى LTAP هو مجرد تغيير في التسويق. إنه لا يغير الواقع المادي". وأشار إلى أن نظام Databricks يشغل ثلاثة محركات، لكل منها ذاكرة تخزين مؤقت خاصة به وتقييمه الخاص لحداثة البيانات، وأن الشكل المادي لـ "نسختين من البيانات" يتطلب آلية ما للحفاظ على التزامن. بالإضافة إلى ذلك، تقدم MongoDB فهارس تخزين عمودية، وتسمح Oracle's HeatWave for MySQL بتشغيل التحليلات على تطبيقات المعاملات، بينما تروج SAP منذ عام 2011 للتحليلات في الوقت الفعلي استنادًا إلى قاعدة البيانات في الذاكرة HANA.

تصر Databricks على أن ادعاءها "بعدم وجود نسخ مكررة" حقيقي، لأنه يتجنب وجود نسختين موثوقتين من البيانات تحتاجان إلى المزامنة. في بيان لـ The Register، قال متحدث باسم Databricks إنه في LTAP، يعمل المستخدمون على نسخة موثوقة واحدة من البيانات، والتي تحتوي على مصدر حقيقة واحد في Iceberg، بينما تُعتبر النسخ الداخلية الوسيطة الأخرى جزءًا من "التسلسل الهرمي لتخزين قاعدة البيانات". في مؤتمر حديث، قيدت Databricks ادعاءها بأن البيانات تحتوي على نسخة "موثوقة" واحدة فقط أو نسخة واحدة فقط "في التخزين"، وهو ما يشبه وصف SingleStore لطبقة التخزين الخاصة بها بأنها "شفافة للمستخدم".

يشير Andy Pavlo، الأستاذ المشارك في قواعد البيانات بجامعة كارنيجي ميلون (Carnegie Mellon University)، إلى أنه بغض النظر عن الجدل التسويقي، فقد أنجزت Databricks عملاً هندسيًا مثيرًا للإعجاب في تمكين المحرك الجديد Reyden من قراءة صفحات PostgreSQL. ويوضح أن محرك Reyden قادر على تفسير محتوى صفحات PostgreSQL ليس بالأمر السهل، لأن الصفحات ليست مكتفية ذاتيًا تمامًا، وتتطلب العودة إلى Neon/PostgreSQL للحصول على البيانات الوصفية من الكتالوج. تسمح هذه التقنية بإجراء تحليلات أكثر توقيتًا، ويتم ذلك بطريقة آمنة من حيث المعاملات، دون الحاجة إلى انتظار دفع البيانات إلى S3. في الوقت نفسه، فإن Reyden عديم الحالة (stateless)، ويمكن توسيعه أفقيًا عن طريق زيادة موارد الحوسبة. يعترف Pavlo أيضًا بأن "البيانات ستُنسخ في النهاية".