Databricks تقدم LTAP كنسخة مرجعية واحدة

تسوق Databricks تقنية Lake Transactional/Analytical Processing، أو LTAP، كطريقة لتقريب المعاملات والتحليلات من بعضهما دون إنشاء نظام بيانات مرجعي ثان.

تقول الشركة إن البنية تجمع Reyden، وهو محرك حوسبة جديد، مع Lakebase، قاعدة بيانات PostgreSQL بلا خادم على تخزين كائنات مفتوح. وتصف Databricks ‏Lakebase بأنها أول قاعدة PostgreSQL مدارة بالكامل لديها، وتقول إن المنتج يستند إلى تقنية Neon التي اشترتها Databricks العام الماضي.

يستهدف ادعاء المنتج انقساما حقيقيا في قواعد البيانات. يعالج online transactional processing قراءات صغيرة موجهة بالصفوف وكتابات متكررة. ويعالج online analytical processing قراءات كبيرة موجهة بالأعمدة وعملا دفعيا. وتقول Databricks إن أحمال AI agents تجعل هذا الانقسام أكثر إلحاحا لأن التطبيقات تحتاج بشكل متزايد إلى قراءة البيانات التشغيلية وكتابتها وتحليلها في دورات أقصر.

Lakebase وReyden يثيران جدل النسخ

تقول Databricks إن LTAP يوحد البيانات في طبقة التخزين عبر المعاملات والتحليلات والبث والبيانات التشغيلية. واستخدمت الشركة أيضا لغة تسويقية حول zero copies وعدم تكرار البيانات.

الخلاف التقني أضيق من الشعار. قال مهندس بيانات في الخدمات المالية إن بيانات PostgreSQL الحالية تبقى بصيغة pageserver كتخزين محلي ثم تنتقل إلى تخزين الكائنات للمتانة طويلة الأجل بصيغة Parquet، حيث يمكن للتحليلات الاستعلام عنها بصيغة عمودية.

قالت شرائح مؤتمر من مايو إن pageserver هو مكون التخزين وإن تنفيذ تحليلات Spark يقرأ ملفات الطبقات من تخزين الكائنات. وتحتوي تلك الملفات على صور كاملة لصفحات PostgreSQL. وقال مهندس من Databricks في مجتمع رسائل خاص إن هناك تقنيا نسختين لأن pageservers تعمل كطبقة تخزين مؤقت أو materialisation في بنية Neon.

هذا الفارق يقع في قلب ادعاء المنتج.

Databricks لا تقول إن كل ذاكرة تخزين مؤقت أو صورة صفحة أو تمثيل داخلي يختفي. بل تقول إن المستخدمين لا يحتاجون إلى تشغيل مخزني بيانات مرجعيين منفصلين ومزامنتهما يدويا.

SingleStore تعترض على الخط التسويقي

Databricks ليست وحدها في السعي إلى نظام يجمع المعاملات والتحليلات. وفقا لـ SingleStore، بدأت الشركة في 2014 العمل على مخزن صفوف في الذاكرة ومخزن أعمدة على القرص مع تخزين متعدد الطبقات. وتقول SingleStore إنها أطلقت في 2020 خدمة قاعدة بيانات سحابية على AWS أو Azure أو GCP تدير البيانات تلقائيا عبر الذاكرة وذاكرة التخزين المؤقت المحلية والتخزين.

قال Nadeem Asghar المدير التقني لـ SingleStore إن Databricks لا ينبغي أن تصف HTAP بالفشل بينما تقترح نظاما يسعى إلى الهدف نفسه. وقال إن Databricks قد تملك ادعاء تخزين واحدا، لكن المحركات وذاكرات التخزين المؤقت ونماذج حداثة البيانات وأنماط الفشل تظل مهمة عندما يتعايش تمثيل صفي وتمثيل عمودي.

حاول مزودون آخرون أيضا تقليل الفاصل بين أنظمة المعاملات والتحليلات. تقدم MongoDB فهارس أعمدة للاستعلامات التحليلية داخل التطبيقات. وتشغل Oracle HeatWave for MySQL التحليلات على التطبيقات المعاملاتية في Oracle Cloud Infrastructure. وروجت SAP للتحليلات الآنية عبر HANA منذ 2011، وفقا للنقاش نفسه حول تاريخ قواعد البيانات.

Databricks تقول إن مصدر الحقيقة يبقى واحدا

قال متحدث باسم Databricks إن LTAP يمنح المستخدمين نسخة مرجعية واحدة من البيانات ومصدر حقيقة واحدا في Iceberg، وهو تنسيق جداول مفتوح المصدر يحتوي على ملفات Parquet. وقال المتحدث إن كل أنظمة قواعد البيانات لديها نسخ داخلية وسيطة عبر ذاكرة التخزين المؤقت والذاكرة والتخزين غير المتطاير وتخزين blob.

تؤهل Databricks الادعاء في العروض بأنه نسخة مرجعية واحدة أو نسخة واحدة في التخزين أو نسخة واحدة في lake. وتترك هذه الصياغة مجالا للتدرج التخزيني الداخلي بينما ترفض فكرة أن المستخدمين يجب أن يديروا نظامين مرجعيين.

قال Andy Pavlo الأستاذ المشارك في databaseology في Carnegie Mellon University إن Databricks أنجزت هندسة صعبة عبر تمكين Reyden من قراءة صفحات PostgreSQL. وقال إن الجزء الصعب هو تفسير ما يسمح للاستعلام برؤيته من صفحات تحتوي على نسخ مختلفة وبيانات وصفية مخزنة في صفحات منفصلة.

قال Pavlo إن التصميم يمكن أن يدعم تحليلات أسرع أو أكثر توقيتا دون انتظار انتقال البيانات إلى S3، مع الحفاظ على سلامة المعاملات. وقال أيضا إن محرك تحليلات Reyden عديم الحالة يمكن أن يتوسع أفقيا بإضافة الحوسبة.

لم تكشف Databricks عمليات نشر عملاء لـ LTAP أو بيانات معدلات الفشل في الإنتاج أو أسعار Lakebase وReyden معا أو معايير مستقلة تبين أداء البنية مقارنة بأنظمة HTAP الحالية.