データをプレーンテキストでjsonとして保存することは非効率ですか？
APIキー用の永続的なストレージが必要でしたが、私はプレーンテキストでjsonの読み書きを思いついたのですが、ユーザーはそれを機能させると思いますが、リレーショナルdbmsと比較すると非常に非効率ですか？
データをjsonとして保存し、この使用例のために手動で編集します。
[
{
"241103000000056": {
"Value": "xxx-4c85-xxx-8420-xxx",
"account1": "3000",
"account2": "1910",
"series": "A"
},
"2411030000000516": {
"Value": "String",
"account1": "3000",
"account2": "1910",
"series": "A"
},
"2411030000000562": {
"Value": "Text",
"account1": "3000",
"account2": "1910",
"series": "A"
},
"2411030000000564": {
"Value": "100",
"account1": "3000",
"account2": "1910",
"series": "A"
},
"2411030000000566": {
"Value": "ZZZ",
"account1": "3000",
"account2": "1910",
"series": "A"
}
}
]
これには、データベースまたはNoSQLストレージの管理UIを待つのではなく、ユーザーが手動でAPIキーを追加できる場合に、実用的なユースケースが迅速に得られるという利点があります。変数は
Value-プログラムがユーザーごとに使用するAPIキーaccount1-支払いのデビットアカウントaccount2-支払いのクレジットアカウント
データは、支払いのバッチプロセスで毎日1回だけ読み取られ、書き込まれます。データセットはそれほど大きくありません（100未満であり、APIキーは販売者と企業であり、消費者ではないため、常に1000未満になります）。
尋ねる質問はどのように効率的ですか？ （データベースのように）固定レコード構造を想定して値をバイナリで保存することにより、レコードをよりスペース効率の高い方法で格納できるようです。
レコード番号は、64ビットのintに収まるように見えますが、現在は16文字の文字列と2つの二重引用符、およびフォーマットで格納されています。テキストフィールドに長さの制限がある場合は、それも役立ちます。アカウント値は、16ビット整数に収まるように見えますが、スケーリングにはおそらく32ビット整数が必要です。したがって、「値」と「シリーズ」の文字列は31文字と長さバイトに制限できるとしましょう。あなたはすべてのレコードを見ている：
- レコード番号に8バイト
- 値用に32バイト
- アカウント1の4バイト
- アカウント2の4バイト
- シリーズ用に32バイト
これは、レコードあたり80バイトです。リストの最初のレコードは150バイトです。もちろん、文字列が少なくとも1kである必要があるが、それらが平均150バイトである場合、それは方程式を変更します。もちろん、文字列を固定長にする必要もありません。長さバイトを格納し、レコードサイズを可変にできます。現在、ディスクに保存することは非常に効率的ですが、読み取りと書き込みに時間がかかる場合があります。特に、多くのランダムアクセスを行う必要がある場合。
レコードのセット全体がメモリに収まりますか？次に、アプリの起動時に1回だけ読み取り、アプリのシャットダウン時に1回書き込むため、遅い読み取り/書き込み時間は問題にならない可能性があります。 （おそらくそうではありませんが、私は極端な例を挙げています。）
これらの各項目を最適化したり、いずれか1つの項目を最適化すると効率が低下したりする状況で妥当な妥協点を見つける方法があります。しかし、それはすべて、このデータをどのように処理するかによって異なります。
文字列にエンコードされた例のような小さなデータをバイナリとして保存する方が、バイナリとして保存するよりも効率的ではありませんか？はい。どれくらい少ない？気にするのに十分ではありません。
バイナリよりも文字列に数千のそのようなレコードを格納する方が効率的ですか？ああ、神様。
理由は次のとおりです。前のレコードのフィールドが固定長ではなかったため、42番目のレコードの「account1」のインデックスを予測できません。つまり、その前にすべてを解析しなければ、それを見つけることができません。
確かに、固定長でテキストを作成することもできますが、誰もそれを尊重しないため、誰もそれを行いません。奇妙な理由のために、バイナリで行われる場合はそれを尊重します。どうして？わかりません。メモ帳の代わりに16進エディタで強制的に強打すると、より優れたクラスのコーダーが得られるでしょう。
そのとおり、データベースは本当にあなたに与える大きなものであり、それはあなたのファイルシステムよりも価値があります。まあ、トランザクション以外にも。
80バイト対150バイトはどうですか？ふh！私がO(n)のような要素を気にかけているなら（私はしません））私はただそれをZipするでしょう。
私が気にしているのは、データ量が増えたので、細かいことを行う前に schlemiel the Painter の問題が発生することです。これは、問題に大きなハードドライブを投げるだけで解決できるものではありません。これらのレコードがどのように使用されるかを考えてください。
これが、jsonファイルを作成する前にシステムの最大ファイルサイズについて尋ねる人々が本当に座って話しかける必要がある理由です。
バッチ処理の効率については、最大の関心事ではありません。データベースにデータを保存します。 sqlを使用して正しいデータを書き込む方が、テキストファイルを編集するよりもはるかに簡単です。また、データベースとの整合性チェックが多くなります（外部キーと正しいデータ型を使用する場合）。リレーショナルデータベースも高速ですが、バッチ処理を行っているため、テキストファイルの処理はおそらく十分高速です。
これは以下のコメントに反していることを理解しています（JSONはどの言語でも非常に簡単で、人間が読める...です）。私が遭遇した問題の多くは、テキストファイルを正しく編集していない人が原因となっています。そして、はい、私の年齢にもかかわらず、私はJSONを使用しました。 JSONは、一般的なデータベースの制約によってチェックできるエラーを作るのは一見簡単そうだと私は感じています。
他の回答とは異なる観点から：
スペースの複雑さの点でDBMSは多すぎる可能性が高いことに同意しますが、DBMSはセキュリティだけでなくデータの整合性も保証します。多くの場合、組み込みのバックアップ機能があり、ディスク上のデータを暗号化することができます（適所にある場合とない場合があるOSレベルの暗号化に加えて）。
これはあなたの質問への直接の回答ではないかもしれませんが、XML、JSON、INIまたは潜在的に機密性の高いデータを格納する他の人間が読めるテキスト形式（たとえば、アカウント番号とAPIキーを照合する）、私は常に、攻撃者がそのファイルを取得してその内容を使用するのがいかに簡単であるかを考えています。このファイルは、OPの形式の場合、各データの意味を詳しく説明しています。
攻撃者がそのJSONファイルを取得すると、すべてが手に入ります。彼らはすべての顧客を知っており、APIキーにアクセスできます。つまり、そのAPIを介して提供されるすべてのデータに簡単にアクセスできます。エントリを個別に暗号化するようにDBMSを構成できます。つまり、攻撃者がデータベースを入手した場合、暗号化されています。攻撃者が顧客レコードを取得した場合：Ok少し悪いですが、すべての顧客レコードへのアクセス権はありません。
独自のデータ整合性、バックアップ、暗号化などをロールバックしようとすると、何か問題が発生することをほぼ保証できます。 DBMS」はすでに何度も「誤解」されており、それらすべてがこれらの問題を修正する必要がありました。データを適切に保護することと比較して、DBMSとプログラムでのやり取りが難しいと感じられることはありません。
多分それは大きな問題ではないかもしれません-私はこれらのAPIキーが提供するアクセスを知りません-"アカウント"と "支払い"に言及することは私を少しEdgeに置きます。これは、適切に保護する必要があるデータのように聞こえます。節約された量が取るに足らないものであるということは、空間的に誰もが絶対的に正しいことです。しかし、セキュリティに関しては、JSONファイルはかなり怖いです。
1日に数回処理される100〜1000件のレコードの場合、効率は完全に無関係です。いずれにしてもボタンを押すよりも速くなります。