PostgreSQL و MongoDB به پیلاردین اضافه شد؛ گفتگو با داده‌های عملیاتی در همان فضای کاری

چه چیزی در پیلاردین تغییر کرده است؟

پیلاردین اتصال زنده به دو پایگاه داده پرکاربرد سازمانی، PostgreSQL و MongoDB، را به مجموعه یکپارچه‌سازی‌های خود اضافه کرد. پیش از این، پشتیبانی از SQL Server اعلام شده بود؛ با این افزوده، سازمان‌هایی که داده عملیاتی خود را روی پایگاه‌های رابطه‌ای یا سندی نگه می‌دارند می‌توانند بدون مهاجرت و بدون ساخت انبار داده موازی، پرسش‌های زبان طبیعی را روی همان داده‌ها مطرح کنند.

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

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

PostgreSQL و MongoDB؛ دو مدل داده، دو نوع پرسش

PostgreSQL یک پایگاه داده رابطه‌ای با پشتیبانی جدی از تراکنش‌های سازگار (ACID)، کلیدهای خارجی و روابط میان جدول‌هاست. برای سازمان‌هایی که سفارش‌ها، سوابق مالی، موجودی انبار یا داده مشتریان را در آن نگه می‌دارند، پاسخ به یک پرسش تحلیلی معمولاً یعنی اتصال چند جدول و تجمیع نتایج. موتور پرسش پیلاردین باید این روابط را بفهمد تا پرسشی مثل «مشتریانی که در سه ماه گذشته خرید نکرده‌اند اما تیکت باز دارند» به کوئری درست تبدیل شود.

MongoDB مدل سندی دارد؛ هر رکورد می‌تواند ساختار تودرتوی خودش را داشته باشد و اسکیما در طول زمان تغییر کند. همین انعطاف آن را برای لاگ رویدادها، پروفایل مشتری با فیلدهای متغیر، کاتالوگ محصول و داده نیمه‌ساختاریافته مناسب می‌کند. در مقابل، همین انعطاف کار را سخت‌تر می‌کند: وقتی فیلدها در اسناد مختلف نام‌ها و شکل‌های متفاوتی دارند، تعریف واژه‌نامه کسب‌وکار اهمیت بیشتری پیدا می‌کند.

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

• PostgreSQL — بهترین گزینه برای داده تراکنشی، روابط پیچیده میان جدول‌ها و گزارش‌های عددی دقیق.
• MongoDB — بهترین گزینه برای اسناد با ساختار متغیر، رویدادها و داده‌های تودرتو.
• SQL Server — پشتیبانی‌شده از قبل؛ گزینه اصلی سازمان‌های مایکروسافت‌محور.
• ترکیب دو منبع — مناسب سازمان‌هایی که سیستم عملیاتی رابطه‌ای و ذخیره سندی را همزمان دارند.

این تغییر برای تیم‌های کسب‌وکار چه معنایی دارد؟

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

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

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

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