adrelanos
(Adrelanos)
1
現在、フォーラム投稿やユーザーアカウントなどの主要なストレージはPostgreSQLデータベースです。
フォーラムコンテンツの主要なストレージ形式をシンプルなテキストファイルにすることを提案してもよろしいでしょうか？
修正が難しいデータベースの問題（ユーザーである私にとっては特に困難）のため、SQLデータベースの一見（または実質的に）不透明なバイナリ形式により、すべてのフォーラムデータを失うリスクが高いと考えています。深刻に破損したデータベース（上記の問題のように目に見える問題ではない場合）を修正できる人はいないか、素人には高すぎると考えられます。
PostgreSQLのようなデータベースを使用するのには非常に良い理由（パフォーマンスなど）があることは間違いありません。しかし、データベースのバックアップとリストア機能が破損または故障した場合の最終的な緊急手段として、人間が読み取れる透明なテキスト形式でのバックアップを提案します。
Gitの素晴らしさを説得する必要はないでしょう。すでに使用されていますから。フォーラムコンテンツはサブフォルダ内の多数のテキストファイルとして保存できます。これにより、フォルダ全体をGitのバージョン管理下に置くことができます。バグが導入された場合でも、どのコミットが原因かを特定するのがはるかに簡単になります。
データベース（不安定で複雑）がまだ必要である可能性がありますが、これらのテキストファイル（シンプルで信頼性が高い）は、データベースを「ソースから」再作成するためのテンプレートとして機能できます。リアルタイムでのテキストファイルへの新規投稿の保存が遅すぎる場合は、オンデマンドまたはシステムがアイドル状態のときにテキストファイルのバックアップオプションを有効にできます（遅延書き込み/書き込みキャッシュ）。
公開データ（公開フォーラム投稿）は、プライベートなユーザーデータやハッシュ化されたパスワードとは異なるフォルダに保存されます。さらに、公開部分（投稿）は、アーカイブ目的で有用と考える人のためにGitリモートに公開することも可能です。ユーザーデータはローカル専用のGitリポジトリ（またはカスタム、リモート、プライベート、暗号化されたGitリポジトリ）に保持されます。
Stephen
(Stephen)
2
ここには規模の経済が働いています。そのようなエンジニアリングの変更は重大です。上記が実現可能だったとしても、パフォーマンスへの影響はあまりに大きく、追加の運用コストがデータベースを修正するコンサルタントの費用を上回る可能性が高いでしょう。
データベースが存在するのは、代替となる平たいテキストファイルよりもはるかに効率的であるからです。
ソフトウェア自体は無料ですが、それ以上ではありません。Discourse の運用コストを過大にしてしまうアプローチを推進するよりも、Marketplace トピックへの短期的な投資を行った方が、はるかに得策です。
「いいね！」 5
RGJ
(Richard - Communiteq)
3
TL;DR いいえ、それは欲しくありません。本当に欲しくありません。
シンプルさを求めるあなたの気持ちは理解できます。
しかし。
1990 年代、私はテキストファイルベースのインターネットフォーラム（Telnet BBS）ソフトウェアで働いていました。私たちは常に、より高度で優れた機能を渇望していました。データに「列」を追加する必要がありました。そこで TAB を追加し、さらに列を追加しました。既存のすべてのファイルにも同様の追加を行う必要がありました。その後、（別の）データ項目を削除したいと考えました。そこで awk スクリプトを作成し、すべてのファイルを走査してそのデータ項目を削除しました。その間、ソフトウェアが異なる数のフィールドを持つテキストファイルを検知しないようにするため、ソフトウェアをメンテナンスモードにする必要がありました。それは地獄でした。私たちはより良いシステムを強く望んでいましたが、最小限のリソースでソフトウェアを実行する必要があったため、ファイルシステムしか利用できませんでした。必要だったのは…データベースです。
ただし、パフォーマンスだけが問題ではありません。テキストファイルは、例えば 2 つのプロセスが同時に書き込もうとした場合など、破損する可能性があります。
また、内部参照の存在を保証する「参照整合性」という概念もあります（例えば、この投稿はトピック #152787 とユーザー #406 に属している、など）。
さらに、トランザクション、スナップショット、レプリケーション、ロードバランシングもあります。
もちろん、データベースが故障することもあります。私の車は昨日故障しました。過度に複雑な ABS 制御ソフトウェアが、小さく一見無関係な問題に非常に脆弱だったためです。自分で修理することは不可能です。修理するには多額の費用が必要です。しかし、どこへ行くにも歩くことと比較すると、これほど多くの利点があります。信頼できないのでしょうか？いいえ。ブレーキは機能しており、ダッシュボードのインジケーターですぐに警告されました。
データベースは、テキストファイルがそうではなかったため、信頼性のために構築されました。
「いいね！」 16
pfaffman
(Jay Pfaffman)
4
リチャードの比喩は的を射ています。Discourse のデータをテキストファイルで追跡するのは不可能です。
さらに、別のデータベースへのサポートを追加するだけでも、年間約 20 万ドルのコストがかかります。
予算を決めて、Marketplace でデータベースの修正を依頼する方が良いでしょう。入札が難しいのは、修正が必要な破損インデックスが 1 つでレコードも数件なのか、それとも複数あり数十件もあるのかが即座にはわからないからです。
「いいね！」 7
PG10 の破損したインデックスについては、私どもも注視しており、リンクされたトピックにおいて、皆様の利益のため、できる限りサポートいたします。PG12 ではこの問題にさらに強いものとなり、アップグレードすることで長期的に解消されることを願っております。
しかし、「プレーンテキストファイルに戻そう」というのは、この問題に対する適切な解決策ではないと確信しております。
「いいね！」 10
dfabulich
(Dan Fabulich)
6
Postgres は、pg_dump というプレーンテキストのバックアップソリューションを提供しています。
pg_dump は PostgreSQL データベースをバックアップするためのユーティリティです。
スクリプトダンプは、保存された時点でのデータベースの状態を再構築するために必要な SQL コマンドを含むプレーンテキストファイルです。
「いいね！」 5
adrelanos
(Adrelanos)
7
ご検討、ご返信をいただき、誠にありがとうございます！心より感謝申し上げます！ 
「いいね！」 3
Laurent
(Laurent)
8
厳密に言えば、テキストファイルの集まりはデータベースですが、重要な用途やパフォーマンスが求められる場面で使いたいようなものではありません。
「いいね！」 2