MongoDB كمصدر بيانات: بلا تصدير وبلا نسخة في السحابة

بلا تصدير، بلا نسخة من مجموعتك في السحابة

بيانات المنتج وبنود الطلبات والأرقام التسلسلية—إذا كانت تعيش أصلًا في MongoDB، فإن تصديرها إلى CSV حتى يطبعها ملصق هو عبء خالص، والتصدير يصبح قديمًا لحظة كتابته.

يصل مركز البيانات zplCloud بالمجموعة مباشرة. وكيل CLI في شبكتك يحمل سلسلة الاتصال، والمنصة تصف الاستعلام، والوكيل يعيد فقط المستندات المطابقة. تبقى قاعدة البيانات غير قابلة للوصول من الإنترنت.

البنية

zplcloud proxy يحافظ على اتصال TLS خارجي واحد إلى api.zplcloud.com. لا شيء يستمع من جانبك، فلا منفذ وارد ولا استثناء جدار حماية. الاستعلام والفرز والترقيم تُدفع للأسفل: الوكيل يبني استعلام MongoDB حقيقيًا ويستدعي Find(filter).Sort(…).Skip(n).Limit(m). المجموعة لا تُنزَّل أبدًا.

الخطوة 1 - شغّل الوكيل مع MongoDB

# عدة أعلام --mongo مسموحة؛ الاسم هو ما تختاره في المنصة.
zplcloud proxy --agent "Lager" \
  --mongo LOCAL="mongodb://admin:…@127.0.0.1:27017/products" \
  --mongo PROD="mongodb://admin:…@mongo.internal.lan:27017/erp"

يجب أن تتضمن سلسلة الاتصال اسم قاعدة البيانات—إنه الجزء بعد المضيف، …:27017/products. بدونه يكون للوكيل خادم بلا قاعدة للاستعلام.

من الأفضل إبقاء الأسرار خارج تاريخ الصدفة:

$env:ZPLCLOUD_MONGO_LOCAL_CONNECTION = "mongodb://admin:…@127.0.0.1:27017/products"
zplcloud proxy --agent "Lager"

اللافتة تؤكد ما سُجّل: MongoDB servers: LOCAL, PROD. ثق بالمنصة بـ--api-key <key> أو ZPLCLOUD_API_KEY؛ اجعله دائمًا بـ--service-install (systemd على Linux/Raspberry Pi، مهمة مجدولة على Windows) أو بـZPLCLOUD_MONGO_LOCAL_CONNECTION في docker-compose.agent.yml.

أعط الوكيل مستخدم قراءة فقط محصورًا في قاعدة البيانات التي يحتاجها. الوكيل ينفذ بذلك المستخدم، لذا فإن نموذج أدوار MongoDB نفسه هو حدود الصلاحيات.

الخطوة 2 - أنشئ مصدر البيانات

في مصادر البيانات يظهر الوكيل تحت Remote SQL Server برقاقة لكل مثيل MongoDB. النقر عليه يملأ النموذج مسبقًا.

اختبار يرسل ping للمثيل ويعيد الخادم · قاعدة البيانات. الحقول تأخذ عينة من مستند وتدرج أسماء الحقول بأنواعها BSON.

اكتشاف الحقول يعمل من عينة، وهو ما يهم في مخزن بلا مخطط: إذا كانت المستندات الأولى تفتقد حقلًا تملكه مستندات لاحقة، فلن يظهر في القائمة. أضفه يدويًا في الربط إن كنت تعرف أنه موجود.

الخطوة 3 - كيف يُنفَّذ عامل تصفية

صف التصفية الذي تبنيه في الاستعلام—عمود وعامل وقيمة—يُترجم إلى مستند تصفية MongoDB وينفذه الوكيل:

نتيجتان تستحقان القول بوضوح:

• لا سطح حقن. عامل تصفية MongoDB مستند BSON—بيانات، لا سلسلة تُحلَّل ككود. القيمة التي تحتوي $ أو {} تظل مجرد قيمة.
• $regex بلا مرساة لا يستطيع استخدام فهرس. يحتوي على مجموعة كبيرة مسح كامل. يبدأ بـ ينتج ^…، ويمكن لفهرس عادي على ذلك الحقل خدمته. على المجموعات الكبيرة، فضّله.

الحدود الصارمة (من كود الوكيل)

تُرقَّم مجموعات النتائج الأكبر: تطلب المنصة صفحة بعد صفحة بـSkip متزايد، كل منها محدودة بـ1000 مستند. طباعة 10 000 ملصق دفعةً واحدة لا تُبقي إذن أكثر من صفحة في الذاكرة، من أي جانب.

لاحظ أن Skip على إزاحة كبيرة يجعل MongoDB يعبر المستندات المتخطاة. للكتالوجات بمئات الآلاف، حقل فرز مفهرس يبقي ذلك رخيصًا؛ الفرز غير المفهرس لن يفعل.

الخطوة 4 - استخدمه في المصمم وPrint Views

• المصمم ← تبويب بيانات الاختبار ← مصدر البيانات: اختر مصدر البيانات واضغط تحميل، ويُنشأ كل ربط بمستندات حقيقية. أطوال الحقول والقيم المفقودة ومشكلات الترميز تظهر هنا لا على لفة الملصقات.
• Print Views ← الإعداد ← مصدر البيانات (مركز البيانات): المعاينة والطباعة تستخدمان الاستعلام الحي. المشغّل لا يرى أبدًا أن MongoDB خلفها.

أنماط الفشل

الخطة

مركز البيانات (مصادر MongoDB وSQL Server عبر وكيل CLI) جزء من خطة Pro. انظر صفحة الأسعار.

ذات صلة

• CLI zplCloud - الأوامر وتثبيت الخدمة وUSB ومجلدات المراقبة
• الوكيل كحاوية Docker
• Cloud Integration / Connections