0

「1983 年 7 月 21 日 01:15:00」のような文字列としてデータベースに保持できる date または getTime を使用して、サーバーの時刻とそれに関連する時刻を格納/取得している人がいます。

これまでは、現在と 2013 年 1 月 1 日との差としてサーバー時間を保存していました。これは、2013 年 1 月 1 日と現在の間で切り捨てられた数値 (分単位) を返し、内部サーバー時間として保持します。

これの利点は次のとおりです。-サーバーへのクエリは単純な数値比較操作を意味しますが、（私は知識に基づいた推測を行います）2つの日付の比較はオブジェクトへの内部変換を意味し、脂肪比較操作を使用します。- そのサイズの数を保存することは、〜 25 文字の文字列よりも軽量です。- 「リアルタイム」に戻すには、2013 年 1 月 1 日を追加しますが、最初の丸めにより秒とミリ秒の値が失われます。

それでも、他の仲間のプログラマーは、文字列バージョンを使用することは人間として読みやすいと主張しています。- ほとんどの言語 (特に、このプロジェクトに含まれる nodejs、mongodb、および as3) のユニバーサル フォーマットです。

大規模なデータベース、特にマルチプレイヤー ソケット ベースのゲームにはどちらが適しているかはわかりません。これについて実際の経験を持つ他の人が私の問題に光を当てることができると確信しています.

では、どちらが優れており、その理由は何ですか?

4

1 に答える 1

1

それらを Mongo Date オブジェクトとして保存します。Mongo は日付を 8 バイトの秒オフセット整数 [1] として保存し、人間が読める形式で表示します。あなたは25文字を保存していません！

したがって、すべての比較は同じくらい高速です。クエリを実行している場合を除いて、文字列の解析はありません。これは、クエリごとに 1 回限りの操作です。

差は、4 バイトの int として保存されます。したがって、通常の MongoDB 日付ストレージよりも 4 バイトしか節約できません。mongo オブジェクトの平均サイズを考えると、これは非常に小さな節約です。

「2013 年 1 月以降のオフセット」方法のすべての欠点を考慮してください。

  • 更新またはクエリの際に日付をオフセットするための追加ロジックの作成に費やされた時間。
  • 日付をオフセットするのを忘れたために発生したバグに対処するために費やされた時間。
  • 実際の日付をすぐに確認するのではなく、データベースの出力を調べるとき (問題を診断するとき) に、手動または頭の中で日付をシフトするのに費やした時間。
  • 追加の作業なしでは MongoDB 集計で日付演算子を使用できない (例: $dayOfMonth、余分な作業は日付を内部的に にシフトするための予測です)。

基本的に、より多くのコードとより多くの頭痛とより多くの時間が費やされ、フィールドの名前を「updated」から「upd」に変更することで同じ 4 バイトを節約できるデータベース内のオブジェクトで 4 バイトを節約できますか? それは賢明なトレードオフだとは思いません。

また、 日付/時刻をmongodbに保存する最良の方法

時期尚早の最適化は諸悪の根源です。何か問題があると判断しない限り、最適化しないでください。

1 - http://bsonspec.org/#/仕様

于 2013-08-22T13:16:06.740 に答える