چرا DocumentDB می‌تواند برای MongoDB یک برنده باشد

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

DocumentDB و گرانش

به اندازه‌ای که دورهٔ اخیر MongoDB عالی بود (و واقعاً بود)، شاید چیز حتی بهتری باشد که برخی افراد فکر می‌کنند می‌تواند به دوره‌های آینده‌اش آسیب برساند: DocumentDB میزبانی‌شده توسط Linux Foundation. به‌عنوان «یک پایگاه داده سندی کاملاً متن باز و سازگار با MongoDB» معرفی شده است، DocumentDB توانایی انتقال توسعه‌دهندگان از MongoDB را دارد. اما این تمام داستان نیست. DocumentDB همچنین به MongoDB فرصتی می‌دهد تا در یک تلاش صنعت‌محور برای محبوب‌سازی رویکردش به مدل‌سازی داده‌ها مشارکت کند، که برای مقابله موفقیت‌آمیز با Postgres که به‌طور فزاینده‌ای محبوب می‌شود، لازم است.

همانطور که متخصص MongoDB مات کیپ می‌گوید، «این … یک فرصت عالی برای MongoDB است تا API خود را به عنوان … استاندارد NoSQL».

رویکرد منفرد MongoDB در حال از دست دادن شتاب است در مقابل حرکتی که جامعه Postgres دارد و هنوز به استاندارد حامل SQL نفوذ نکرده است. اگر MongoDB بخواهد با یک پیش‌فرض باز و قابل حمل رقابت کند در حالی که بازار هدف کل خود را به‌طور چشمگیری افزایش می‌دهد، به نسخهٔ خود از یک پیش‌فرض باز و قابل حمل نیاز دارد. DocumentDB وارد می‌شود.

Helping yourself by helping others

DocumentDB لینوکس فاندیشن یک پروژه منبع باز جدید است که مایکروسافت در اوایل سال جاری راه‌اندازی کرده و اکنون به LF اهدا شده است. نه، این به سرویس Amazon DocumentDB مرتبط نیست، اگرچه به‌طور کمی‌ confusingly، آن تیم حمایت خود را اعلام کرد برای این ابتکار DocumentDB مرتبط-اما-نامرتبط. هدف آن ارائه یک پایگاه داده سندی با مجوز permissive، سازگار با MongoDB و مبتنی بر Postgres است. همچنین برنامه دارد استاندارد باز برای APIهای سندی و رفتار ایجاد کند. AWS قبلاً به کمیته فنی steering این پروژه پیوسته، گوگل به‌طور عمومی حمایت می‌کند، و زبان منشور پروژه انطباق و قابلیت حمل‌پذیری بین‌فروشندگان را به‌عنوان اهداف مرکزی مطرح می‌کند. هدف نهایی ایجاد «استاندارد باز برای برنامه‌های مبتنی بر سند [همانند] آنچه SQL برای پایگاه‌های داده رابطه‌ای انجام داد» است، همان‌طور که جیم زم‌لین، مدیر اجرایی LF، اشاره می‌کند.

این یک چادر بزرگ است، نه یک شاخه کوچک. اما آیا این نیز یک مشکل بزرگ است؟

مشکل MongoDB گرانش است، نه یک ارائه‌دهنده‌ ابری خاص. Postgres به‌عنوان پیش‌فرض «ایمن» برای توسعه‌دهندگان تبدیل شده است. این بهره‌مند از دهه‌ها استانداردسازی (SQL/ISO 9075)، انتظارات انطباق و یک ابزارک بزرگ است که Postgres را به‌عنوان پایه می‌پذیرد. استانداردها خطر و هزینه‌های تعویض را کاهش می‌دهند؛ اکوسیستم‌ها حول استانداردها رشد می‌کنند. اگر MongoDB بخواهد از بلعیدن بیشتر زمینه‌های بالقوه توسط Postgres جلوگیری کند، باید هزینه‌های تعویض به سمت راه MongoDB را کاهش دهد — نه فقط به سمت سرویس cloud MongoDB (Atlas).

این واقعاً جنجال‌برانگیز نیست — تاریخ است. اگر در دهه‌های ۸۰ و ۹۰ برنامه می‌ساختید، ظهور SQL به‌عنوان یک استاندارد ANSI و یک استاندارد ISO سه کار انجام داد که برای توسعه‌دهندگان و شرکت‌ها مهم بود:

• قابلیت حمل مهارت‌ها و کدها: دانستن

  SELECT

  ،

  JOIN

  و تراکنش‌ها یک شرط فروشنده نبود؛ یک شرط شغلی بود. می‌توانستید بین فروشندگان جابجا شوید بدون اینکه مبانی را دوباره بیاموزید. شرکت‌ها می‌توانستند برای «SQL» استخدام کنند نه برای «DSL فروشنده X».

• قابلیت پیش‌بینی بین فروشندگان: استانداردها تفاوت‌ها را از بین نیاوردند، اما زمینه مشترک کافی برای معماران ایجاد کردند تا سیستم‌های بلندمدت با ریسک قفل‌گذاری کمتر برنامه‌ریزی کنند. ابزارها به‌دلیل اینکه «مرکز» قابل اعتماد بود، رشد کردند.
• فضای کافی برای برتری متمایز: فروشندگان بر عملکرد، عملیات، امنیت، اکوسیستم و ابزارهای مدیریت رقابت می‌کردند — نه بر این که آیا

  GROUP BY

  وجود دارد یا نه.

Oracle این جریان را مبارزه نکرد؛ بلکه رهبری کرد و سوار آن شد. (افشای اطلاعات: من برای Oracle کار می‌کنم و دو بار برای MongoDB کار کرده‌ام.) Oracle اولین RDBMS تجاری SQL را عرضه کرد و سپس با قابلیت حمل‌پذیری چندسکویی، عملکرد و عملیات برای برآورده کردن نیازهای سازمانی پیشی گرفت. استاندارد بازار را گسترش داد؛ به‌عنوان حامل استاندارد SQL، Oracle سهم عظیمی را با ارائه بهترین تجربه مدیریت‌شده و اکوسیستم پیرامون به دست آورد. درسی برای MongoDB وجود دارد.

Helping yourself by helping others

استاندارد موانع را برای همه کاهش می‌دهد. این می‌تواند حس ناراحتی ایجاد کند اگر استراتژی شما به کنترل مالکیتی وابسته باشد. با این حال تشویق به استانداردها دقیقاً همان روشی است که یک دسته‌بندی را رشد می‌دهید که بهترین موقعیت برای پیروزی در آن را دارید. MongoDB صدها میلیون دلار بر روی تحقیق و توسعه هزینه کرده است، اما Postgres چند برابر آن را در سرمایه‌گذاری جمعی در سراسر صنعت می‌بیند. یک استاندارد قوی‌تر سندی در سطح بازار باید به این عدم تعادل سرمایه‌گذاری کمک کند، پارت کلی دیتابیس سندی را گسترش دهد، با این که MongoDB آماده است سهم بزرگی از این بارهای کاری به‌دلیل…

به‌طور صریح‌تر: کنترل محدود است؛ تأثیر ترکیبی است. SQL Oracle یا SQL Server را از بین نگذاشت — بلکه آنها را به کسب‌وکارهای بزرگتر تبدیل کرد. Kubernetes کالا‌سازی ابر نکرد — بلکه رقابت را به سمت تجربه مدیریت‌شده، امنیت و قابلیت اطمینان سوق داد. همین دینامیک برای MongoDB در دسترس است.

البته MongoDB تنها فروشنده‌ای که بهره‌مند می‌شود نیست، اما این یک ویژگی است، نه باگ. AWS، Google و دیگران به DocumentDB می‌پیوندند زیرا آن‌ها نیز امید دارند بهره‌مند شوند (و مطابق با آن بازده‌های مورد انتظار سرمایه‌گذاری می‌کنند). کارفرمای من، Oracle، هنوز حمایت رسمی از این استاندارد اعلام نکرده است، اما Oracle نیز بهره‌مند می‌شود. Oracle Database 23ai JSON Relational Duality را معرفی کرده که به توسعه‌دهندگان اجازه می‌دهد همان داده‌های رابطه‌ای پایه را به‌صورت اسناد JSON قابل به‌روزرسانی ارائه و به‌روز کنند — بدون تکرار داده — و از طریق APIهای سازگار با MongoDB، REST و SQL دسترسی داشته باشند. این بسیار جذاب است. استانداردها تمایل دارند این نوع «داشتن هر دو مسیر» را امکان‌پذیر کنند و اکوسیستم‌ها تمایل دارند این را تقویت کنند. اگر یک استاندارد سندی خنثی رفتار و معنای API را تثبیت کند، فروشندگان می‌توانند بر چگونگی ذخیره و بهینه‌سازی داده‌ها زیر آن API نوآوری کنند — دقیقاً همان‌چیزی که Oracle با ترکیب سند و رابطه در یک موتور انجام می‌دهد.

به‌عبارت دیگر، وقتی سطح نمایی (تجربه توسعه‌دهنده و API) پیش‌بینی‌پذیر باشد، خریداران بر پایه برتری عملیاتی، مقیاس، حاکمیت و قابلیت‌های مرتبط (تحلیل‌ها، هوش مصنوعی، امنیت) انتخاب می‌کنند. این همان جایی است که MongoDB به‌مدت یک دهه با Atlas سرمایه‌گذاری کرده است. یک استاندارد آن را از بین نمی‌برد؛ بلکه برجسته می‌کند.

جایگزین این است که ادامه به مقابله با گرانش با مجوزدهی بدهید. این مسیر به‌وضوح توزیع و حسن نیت را کاهش می‌دهد. خطوط روند DB‑Engines صعود مستمر Postgres و مسطح شدن نسبی MongoDB را نشان می‌دهد از زمانی که از متن باز به Server Side Public License تغییر یافت — حتی در حالی که شرکت MongoDB به‌طور درخشانی در درآمدزایی عمل کرد. می‌توانید در نبردهای درآمدی برنده شوید و همچنان جنگ پلتفرم را از دست بدهید.

Have the standards cake and eat it too

MongoDB نیازی به تسلیم کنترل نقشه راه خود ندارد تا از مزایای استانداردسازی بهره‌برداری کند. در عمل، شرکت می‌تواند کمی کنترل را در ازای تأثیر زیاد به دست آورد.

قابلیت انطباق را جایی بگذارید که مهم است: مشخصات و آزمون‌ها. MongoDB در حال حاضر مجموعه‌های عمیق انطباق داخلی اجرا می‌کند. اهدای یک بخشی از آن‌ها به‌عنوان یک چارچوب آزمون خنثی‑فروشنده‑محور که بر CRUD اصلی، معنای پرس‌و‌جو، رفتار ایندکس‌گذاری و مدیریت خطا متمرکز است، MongoDB را به‌عنوان حامل استاندارد جای می‌گذارد در حالی که فضای نوآوری تجاری (مانند تجمیع پیشرفته، Atlas Search، بایگانی آنلاین، ویژگی‌های برداری) حفظ می‌شود. یک برنامه انطباق لایه‌ای (هسته، گسترش یافته، سازمانی) ساختاری را منعکس می‌کند که بنیاد Cloud Native Computing Foundation یا استانداردهای SQL در عمل دارند.

داستان راننده را هدایت کنید. پروژه Linux Foundation هدفش «۱۰۰٪ سازگاری با درایورهای MongoDB» است. MongoDB می‌تواند با شفاف‌سازی انتظارات درایور (جزئیات پروتکل سیمی، معنای retry، جریان‌های تغییر) و به‌هم‌نویسی اسناد خنثی انطباق درایور کمک کند. این توسعه‌دهندگان را از ناسازگاری‌های ظریف محافظت می‌کند و نقش MongoDB را به‌عنوان مرجع پیاده‌سازی «راه MongoDB» تقویت می‌کند.

یک پایه مهاجرت‑دوستانه را تشویق کنید. در جایی که بازار به ثبات نیاز دارد — شناسه‌ها، نوع BSON، رفتار ایندکس‌گذاری، کدهای خطا — MongoDB می‌تواند پیش‌بینی‌پذیری را نسبت به هوشمندی ترجیح دهد. استاندارد می‌تواند این موارد را تعریف کند بدون این که نوآوری‌های MongoDB را متوقف کند. تاریخ ANSI SQL آموزنده است: ۸۰٪ استانداردسازی، ۲۰٪ نوآوری، و یا ایده‌های برتر را به استاندارد برگرداند یا به‌عنوان افزونگی ارزش‑افزوده نگه دارد.

از بی‌طرفی به نفع خود استفاده کنید. توسعه‌دهندگان به حاکمیت خنثی‑فروشنده‑محور اعتماد دارند. Linux Foundation یک کمیته فنی راهبردی و منشور تنظیم می‌کند که مراقبت چند‑فروشنده و تصمیم‌گیری شفاف را تشویق می‌کند. MongoDB باید به مشارکت بپردازد، آثار واضح‑محدوده (آزمون‌ها و مشخصات) ارائه دهد و به شکل‌گیری یک «پرفایل» سازگاری کمک کند که تعادل بین عمل‌گرایی و وفاداری به مدل MongoDB را حفظ کند. دوباره، تأثیر بیشتر از کنترل است.

در جایی که مشتریان احساس می‌کنند متمایز باشید. استانداردها بازارها را گسترش می‌دهند و تجربه‌ها قراردادها را می‌برند. برتری عملیاتی Atlas، امنیت، یکپارچگی AI، لایه‌بندی داده، مقیاس‌پذیری چند‑منطقه‌ای و ابزار «کل برنامه» حول مدل سندی را ادامه دهید. هدف جلوگیری از گفتن «MongoDB» توسط دیگران نیست — بلکه اطمینان از این است که وقتی این کار را می‌کنند، Atlas همچنان احساس بهتری می‌دهد.

اگر DocumentDB موفق به ایجاد یک استاندارد معتبر، خنثی برای پایگاه‌داده‌های سندی شود، دو اتفاق می‌افتد: ابتدا، بازار طراحی سند‑اول رشد می‌کند. معماران پیش‌بینی‌پذیری که می‌خواهند و قابلیت انتقال مهارت‌ها را تیم‌هایشان می‌طلبد، به‌دست می‌آورند. این بار کاری را جذب می‌کند که در غیر این صورت به سمت یک نوع SQL/رابطه‌ای پیش‌فرض می‌رفت. دوم، مزایای نسبی MongoDB چند برابر می‌شود. با کاهش اصطکاک سعی در مدل‌سازی سند، تیم‌های بیشتری MongoDB Atlas را ارزیابی می‌کنند.

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

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