مقایسه و انتخاب

واکاوی مهاجرت از مانگودی‌بی به پستگرس برای ذخیره داده‌های JSON

‍ اگر هنوز برای مدیریت اسناد و JSONهای خود از MongoDB استفاده می‌کنید، شاید وقت آن رسیده کمی عمیق‌تر به این موضوع نگاه کنیم.

اخیراً Gabriele Ferreri در لینکدین پستی منتشر کرده و توضیح داده است که چگونه جایگزینی MongoDB با PostgreSQL و استفاده از JSONB توانسته نیاز او به چند دیتابیس را حذف کند و حتی هزینه‌های زیرساخت را تا ۴۰٪ کاهش دهد. به دلیل اهمیت این موضوع، بیایید با هم نگاهی به نکات اصلی این تجربه بیندازیم.
https://www.linkedin.com/posts/gabriele-ferreri_postgresql-database-backenddev-share-7431970713886146560-uQLL

📌 مشکل رایج تیم‌ها

بسیاری از تیم‌ها این ساختار را دارند:

داده‌های رابطه‌ای ← PostgreSQL
users, orders, payments← اسکیمای سخت‌گیرانه

داده‌های انعطاف‌پذیر ← MongoDB
preferences, configs, metadata → document store

✅ نتیجه: دو دیتابیس، دو connection pool، دو استراتژی بکاپ، دو مسیر خطا…
و مهم‌تر از همه، پیچیدگی عملیاتی بالا: مانیتورینگ جدا، migration جدا، تخصص‌های جدا، و لحظه‌ای که مجبور می‌شوید join بین دو سیستم انجام دهید.

🚀 راهکار JSONB در PostgreSQL

با JSONB دیگر نیازی به دو دیتابیس ندارید.
می‌توانید داده‌های انعطاف‌پذیر و داده‌های حیاتی را در یک دیتابیس مدیریت کنید.

مثال ساده:

CREATE TABLE users (
id uuid PRIMARY KEY,
email text NOT NULL,
prefs jsonb DEFAULT '{}'
);
CREATE INDEX idx_prefs ON users
USING GIN (prefs jsonb_path_ops);

SELECT * FROM users
WHERE prefs @> '{"theme": "dark"}';

الگوی پیشنهادی:

  • ستون‌های سخت‌گیرانه برای داده‌های حیاتی (auth، billing، identity) یعنی داده های اصلی در قالب ستون های یک جدول ذخیره شوند.
  • قالب JSONB برای داده‌های متغیر (preferences، configها، feature flagها)

یک دیتابیس. یک بکاپ. یک مدل ذهنی ساده.

⚡️ عملکرد

Ferreri گزارش می‌دهد که کوئری‌های JSONB با GIN index روی میلیون‌ها ردیف، در ۳–۸ میلی‌ثانیه پاسخ می‌دهند — تقریباً همانند lookupهای MongoDB.
نسخه ۱۸ PostgreSQL با jsonb_path_ops برای جستجوی containment بهینه شده و فضای کمتری نسبت به حالت پیش‌فرض مصرف می‌کند.

❌ محدودیت‌ها

در موارد زیر بهتر است از مانگودی بی استفاده کنیم :

  • بارهای کاری با نوشتن زیاد روی JSONBهای عمیق (Postgres کل سند را بازنویسی می‌کند)
  • اسناد بزرگ (بیش از ~۵۰۰KB) که BSON chunking Mongo کمک می‌کند
  • تیم‌هایی که کاملاً در اکوسیستم Mongo با Change Stream و aggregation pipelines هستند

✅ جمع‌بندی

پستگرس با پشتیبانی از JSONB می‌تواند جایگزین MongoDB شود، هزینه‌ها و پیچیدگی عملیاتی را کاهش دهد و یک مدل داده انعطاف‌پذیر در یک دیتابیس واحد ارائه کند.
شرکت‌هایی مثل Figma و Notion هم همین مسیر را رفته‌اند.

 

مجتبی بنائی

دانشجوی دکترای نرم‌افزار دانشگاه تهران (yun.ir/smbanaie)، مدرس دانشگاه و فعال در حوزه توسعه نرم‌افزار و مهندسی داده که تمرکز کاری خود را در چند سال اخیر بر روی مطالعه و تحقیق در حوزه کلان‌داده و زیرساخت‌های پردازش داده و تولید محتوای تخصصی و کاربردی به زبان فارسی و انتشار آنها در سایت مهندسی داده گذاشته است. مدیریت پروژه‌های نرم‌افزاری و طراحی سامانه‌های مقیاس‌پذیر اطلاعاتی از دیگر فعالیتهای صورت گرفته ایشان در چند سال گذشته است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

این سایت از اکیسمت برای کاهش جفنگ استفاده می‌کند. درباره چگونگی پردازش داده‌های دیدگاه خود بیشتر بدانید.

دکمه بازگشت به بالا