حاليًا، يُعد مستودع PostgreSQL قاعدة البيانات الأساسية لتخزين منشورات المنتدى وحسابات المستخدمين وما إلى ذلك.
هل لي أن أقترح جعل تنسيق التخزين الرئيسي لمحتويات المنتدى ملفات نصية بسيطة؟
نظرًا لصعوبة إصلاح مشكلات قاعدة البيانات (وهو أمر صعب عليّ كـمستخدم)، أعتقد أن خطر فقدان جميع بيانات المنتدى مرتفع بسبب تنسيق الملفات الثنائي الذي يبدو غير شفاف/غير مفهوم لقواعد بيانات SQL. يبدو أنه لا أحد قادر على إصلاح قاعدة بيانات تالفة بشدة (وهو ما لن يكون مشكلة ظاهرة كما في المسألة المذكورة أعلاه) أو أن التكلفة باهظة على غير المتخصصين.
أنا متأكد من وجود أسباب وجيهة جدًا لاستخدام قواعد بيانات مثل PostgreSQL، مثل الأداء. ومع ذلك، أقترح اعتماد تنسيق نصي شفاف يمكن للبشر قراءته كنسخ احتياطي كحل أخير في حالات الطوارئ، في حال تعطل أو تلف وظيفة النسخ الاحتياطي والاستعادة لقاعدة البيانات.
ربما لا تحتاج إلى إقناعك بمدى روعة Git، فأنت تستخدمه بالفعل. يمكن تخزين محتويات المنتدى كمجلدات فرعية وكميات كبيرة من الملفات النصية. وبالتالي، يمكن وضع المجلد بأكمله تحت نظام التحكم في الإصدارات Git. إذا طرأت أي أخطاء، فسيكون تتبع الإصدار الذي تسبب فيها أسهل بكثير.
وبما أن قواعد البيانات (غير الموثوقة والمعقدة) لا تزال مطلوبة على الأرجح، فيمكن أن تعمل هذه الملفات النصية (البسيطة والموثوقة) كنموذج لإعادة إنشاء قاعدة البيانات “من المصدر”. إذا كان تخزين المنشورات الجديدة داخل الملفات النصية بطيئًا جدًا في الوقت الفعلي، فيمكنك تفعيل خيار النسخ الاحتياطي للملفات النصية عند الطلب أو عندما يكون النظام خاملًا (كتابة مؤجلة/ذاكرة تخزين مؤقت للكتابة).
ستكون البيانات العامة (منشورات المنتدى العامة) في مجلد مختلف عن بيانات المستخدم الخاصة وكلمات المرور المشفرة. ومن المزايا الإضافية أنه يمكن نشر الجزء العام (المنشورات) حتى على مستودع Git بعيد لأولئك الذين يجدون ذلك مفيدًا (للأرشفة). بينما ستبقى بيانات المستخدم في مستودع Git محلي فقط (أو مستودع Git مخصص، بعيد، خاص، ومشفر).
هناك وفورات في الحجم. إن تغيير هندسي من هذا القبيل ذو أهمية بالغة. ولو كانت الخيارات المذكورة أعلاه ممكنة، فإن الآثار المترتبة على الأداء ستكون من شأنها أن تجعل تكاليف التشغيل الإضافية تتجاوز على الأرجح تكلفة استئجار مستشار لإصلاح قاعدة بياناتك.
توجد قواعد البيانات لأنها أكثر كفاءة بكثير من البديل المتمثل في ملفات نصية مسطحة.
البرمجيات مجانية، لكن هذا هو كل شيء. سيكون من الأفضل لك بكثير أن تستثمر على المدى القصير في موضوع Marketplace بدلاً من الترويج لنهج يجعل تشغيل Discourse مكلفًا للغاية.
في تسعينيات القرن الماضي، عملتُ مع برامج منتديات الإنترنت (BBS عبر بروتوكول Telnet) التي بُنيت على ملفات نصية. كنا نتمنى باستمرار الحصول على وظائف أكثر وأفضل. احتجنا إلى إضافة «أعمدة» إلى البيانات. أضفنا علامة TAB ثم أضفنا العمود الإضافي. احتجنا إلى تطبيق ذلك على جميع الملفات الموجودة. ثم أردنا حذف (جزء آخر) من البيانات. كتبنا سكريبت awk للمرور عبر جميع الملفات وحذف هذا الجزء من البيانات. احتجنا إلى وضع البرنامج في وضع الصيانة خلال ذلك الوقت لأن البرنامج كان سيعتبر أن الملفات النصية تحتوي على عدد مختلف من الحقول. كان الأمر جحيمًا. كنا نرغب بشدة في نظام أفضل، لكننا احتجنا إلى تشغيل البرنامج بأقل الموارد المتاحة، وبالتالي كان لدينا فقط نظام ملفات. احتجنا… إلى قاعدة بيانات.
ومع ذلك، فإن الأداء ليس المشكلة الوحيدة. فملفات النص قد تتلف أيضًا، على سبيل المثال إذا كان عمليان يكتبان فيها في نفس الوقت.
هناك أيضًا ما يُعرف بـ «سلامة المرجعية»، الذي يضمن وجود الإشارات الداخلية (مثل أن هذا المنشور ينتمي إلى الموضوع رقم 152787 والمستخدم رقم 406).
ثم هناك المعاملات، واللقطات، والنسخ المتماثل، وتوازن الأحمال.
بالتأكيد، قد تتعطل قاعدة بياناتك. تعطلت سيارتي أمس لأن برنامج التحكم المعقد جدًا في نظام الفرامل المانعة للانغلاق (ABS) عرضة حقًا لمشاكل صغيرة تبدو غير مرتبطة. من المستحيل إصلاحها بنفسي. أحتاج إلى دفع مبلغ كبير من المال لإصلاحها. لكن لها مزايا كثيرة تفوق المشي في كل مكان. هل هي غير موثوقة؟ لا. ما زالت تفرمل، وتم تحذيري فورًا بواسطة المؤشر على لوحة القيادة.
تم بناء قواعد البيانات من أجل الموثوقية لأن ملفات النص لم تكن كذلك.
تشبيه ريتشارد دقيق. سيكون من المستحيل مواكبة بيانات Discourse في ملفات نصية.
حتى إضافة دعم لقاعدة بيانات أخرى سيتكلف ما يقارب 200,000 دولار أمريكي سنويًا.
ربما يكون من الأفضل تحديد ميزانية وطلب المساعدة في قناة Marketplace لشخص لإصلاح قاعدة بياناتك. إنها مهمة صعبة للتقييم لأنها ليست واضحة على الفور ما إذا كانت لديك فهرس تالف واحد مع بضعة سجلات لإصلاحها أم عدة فهارس مع عشرات السجلات لإصلاحها.
مؤشرات التالف في PG10 هي أمر نراقبه عن كثب، وسنقدم المساعدة قدر الإمكان في الموضوع الذي أشرت إليه، لصالح الجميع. أتمنى أن يكون PG12 أكثر مقاومة لهذه المشكلة، وأن يؤدي الترقية إلى حلها على المدى الطويل.
لكنني أؤمن تمامًا أن “العودة إلى ملفات النص العادي” ليست حلاً مناسبًا لهذه المشكلة.
