フロントエンドとバックエンド間のトランスポートとしてフラットファイルとデータベース/ APIを使用する

数人の開発者の間で議論がかなり白熱したアプリケーションがあります。

基本的に、Webレイヤーとバックエンドレイヤーに分割されます。Webレイヤーは単純なWebフォームによって情報を収集し、このデータをJSONドキュメント（文字列は.jsonファイル）としてバックエンドが使用する監視フォルダーに格納します。バックエンドは数秒ごとにこのフォルダーをポーリングし、ファイルを取得して、その機能を実行します。

ファイル自体は非常にシンプル（つまり、すべての文字列データ、ネストなし）で、最大で1〜2kで、システムはほとんどの時間をアイドル状態にします（ただし、最大100メッセージまでバーストします）。バックエンド処理ステップは、メッセージごとに約10分かかります。

議論は、ある開発者がファイルシステムをメッセージングレイヤーとして使用することは悪いソリューションであると示唆した場合、リレーショナルデータベース（MySQL）、noSQLデータベース（Redis）、またはプレーンREST APIコールなどを代わりに使用する必要がある場合に出てきます。

Redisは、キュー内のメッセージ処理のために組織内の他の場所で使用されることに注意してください。

私が聞いた議論は次のように分類されます

フラットファイルを支持して：

• フラットファイルは、他のソリューションよりも信頼性が高くなります。ファイルは、「監視」フォルダーから、取得後に「処理」フォルダーに、最後に「完了」フォルダーに移動するためです。とにかく他のものを壊すような非常に低レベルのバグがない限り、メッセージが消えるリスクはありません。

• フラットファイルを理解するには、それほど高度な技術は必要ありません- catそれだけです。書き込むクエリはありません。誤ってメッセージをキューからポップして、メッセージが永遠に消えてしまうリスクはありません。

• ファイル管理コードは、すべての言語の標準ライブラリの一部であるため、プログラミングの観点からデータベースAPIよりも簡単です。これにより、コードベースの全体的な複雑さと、導入する必要のあるサードパーティコードの量が削減されます。

• YAGNI原則州フラットファイルが今うまく動作することを、それを残して、より複雑なソリューションに変更するための実証され必要はありません。

データベースを支持して：

• ファイルがいっぱいのディレクトリよりもデータベースを拡張する方が簡単です

• フラットファイルには、誰かが「完了」ファイルを「監視」ディレクトリにコピーして戻すリスクがあります。このアプリケーションの性質（仮想マシン管理）により、これにより壊滅的なデータ損失が発生する可能性があります。

• T / Sにより高度な技術を必要とするアプリは、教育を受けていないスタッフが物事を突くだけで何かを台無しにする可能性が低いことを意味します。

• 特にRedisなどのDB接続コードは、少なくとも標準ライブラリファイル管理機能と同じくらい堅牢です。

• DB接続コードは、ファイル操作よりもレベルが高いため、開発者の観点からは（機能的にではないにしても）明らかに単純です。

私が見ることができることから、両方の開発者は多くの有効なポイントを持っています。

これら2人のプロファイル開発者、またはプロデータベース開発者のうち、どちらがソフトウェアエンジニアリングのベストプラクティスに沿っているのでしょうか？

Ewanが言及したデータベースまたはキューシステムを含むソリューションに切り替えると、

• バックエンドとフロントエンドの両方で、新しい複雑なシステムへの依存関係を作成します
• 不必要な複雑さと新しい障害点のsh * tloadを導入する
• コストの増加（所有コストを含む）

単一のボリューム内でのファイルの移動/名前変更は、ファイル/レコードのロックなどの問題がどのような困難であっても、現在のすべてのOSでアトミックであることが保証されています。OSレベルの権限管理は、洗浄されていないものをロックアウトし、許可されたオペレーター（管理者/開発者）による思いがけない/偶発的な誤操作を防止するのに十分でなければなりません。したがって、現在のソリューションのパフォーマンスが十分である限り、データベースには何も提供されません。

当社では、数十年にわたって同様のファイルベースのインターフェースを使用しており、大きな成功を収めています。他の多くのものが出入りしましたが、これらのインターフェースは、そのシンプルさ、信頼性、最小限の結合/依存性のために残っています。

どちらの解決策も相変わらず悪い習慣だとは思わないので、ベストプラクティスであると答えることは難しいかもしれません。

あなたが規模を扱っているなら、YAGNIの校長がここに適用されるとは思わない 「作業」は相対的なものであり、壊滅的なデータ損失の可能性が高く、スケーリングする能力がほとんどない場合、その作業を実際に考慮することはありません。対処している規模が正確にはわかりませんが、これらのエントリが大量にある場合、それぞれが新しいシステムに切り替えるのが難しくなります。その場合、データベースがベストプラクティスであると思います。

MongoDBまたはredis（私はredisの経験がなく、良いことだけを読んでいます）は、データが既にうまく収まっているはずなので、うまくいくはずです（json文書は、MongoDBのBSON文書に頻繁に変更されます）。また、ディスクへの頻繁な読み取り/書き込みが常に発生する可能性がある代わりに、メモリに大量のデータを保持するという利点もあります。また、同時読み取り/書き込みが破損やブロッキングを引き起こさないようにします。

YAGNIプリンシパルがここで適用され、ファイルがボトルネックではなく、スコープ内でスケーリングし、壊滅的な問題がない場合、ファイルを使用することは「ベストプラクティス」です。問題がない場合は何も変更する必要はありません。テストを書いてストレスをかけ、制限とボトルネックがどこにあるかを確認してください。

とにかく、データベースがこのコンテキストでのソリューションであるかどうかはわかりません。同じサーバー上のものと通信している場合、何らかのIPCを実行できますか？

良い 'olは、ファイルを保存し、それを完了したディレクトリにコピーすることは、多くのコミュニケーションレイヤーの主力です。古いメインフレームシステムなど。「反」者にはポイントがあります。多くの問題とエッジケースがあるという点で。これは、100％の信頼性が必要な場合に対処するのが難しく、ファイルの頻度とボリュームを拡大するにつれて頻繁に発生します。

トランザクションの両側を制御する場合、利用可能な多くの単純なキューイングシステムのいくつかを検討することをお勧めします。データベースではなく、ZeroMQ、RabbitMQ、MSMQなど。しかし、あなたが暗示するように、それが壊れていないなら...

データベースソリューションは正しいものです。特定のホストまたは境界条件への多くの依存関係を解決します。

データベースは特定のホストでホストされないことを除いて、どちらも同様のソリューションです。これにより、unixシステムのファイアウォール/アクセスの問題が解消されます。ファイルシステムで「偶発的な」削除のケースがあり、誰も責任を負いません。

databaseを使用しても、同じ問題が発生する可能性がありますが、削除を削除するための監査をオンにしたり、ロジックのみを挿入したりできます。

また、ファイルシステムで、OASISなどのファイル名にアプリケーションを配置する必要がある場合は、OASIS.john_doe.system1.20160202ファイルを作成する必要があります。これは退屈になり、データベースでより簡単に表すことができます。データベースとそれに基づいたロジックにnullフィールドを持つこともできます

また、テーブルに対して行うパッチや修正の場合は、ファイルディレクトリ全体ではなくデータベースを簡単に更新できます。もちろん、ファイルシステムで実行できますが、データベースの更新はより直感的です。

たとえば、再実行が必要ですが、OASISとは異なるシステムで、DESERTとjohn_doeをdoe_smithに、日付を20160101から20151231と言います。

シェルスクリプトでこれらのファイルを作成するのではなく、元のセットからDESERT / doe_smith / 20151231の行を簡単に生成できます。

そのため、読みやすさから、拡張視点データベースソリューションが優れています。