データに対する時間がたくさんある

ちょっとハマったので、整理というか殴り書き。

一つのデータにも様々な時間が関わります。

スマートフォンアプリから、WebAPIを経由して、DBおよび検索エンジンに至るまでのデータに対する時間

- ユーザが作成した時間
- アップロードした時間
[↑スマートフォン端末側]
-------------------
[↓サーバ側]
- APIが受け付けた時間

- DBMasterに記録された時間
- DBMasterで参照可能になった時間

- DBSlaveに記録された時間
- DBSlaveで参照可能になった時間

- 検索エンジンに反映された時間
- 検索エンジンで検索可能になった時間

これらの時間を取り違えると、挙動がおかしくなります。

スマートフォンの時間、サーバの時間

大きな点として、スマートフォンと、サーバシステムでの時間の扱いがあります。

基本的にスマートフォン側の時間は、ずれることもあることや、基本的にサーバ側からは操作不可で、それを考慮する必要があります。また、スマートフォンはオフライン時に操作してそれを後から送信するといったユースケースがあるため、一概にサーバ到達時刻に置き換えることができません。

もちろん端末の時間がずれていたら別なので、その対処も必要です。日記などの時刻の場合は、ユーザが意図的に変更していても問題ないですが、特定のイベントに関することや、厳密にその時間に行ったことを証拠とするケースでは端末とサーバシステム側の時刻の整合性が必要です。

サーバ側では、基本的に複数台で同一の時間になるようにNTPで調節します。そして、システム的に記録した時間が重要になってきます。例えば、APIで受け付けた時間を、ユーザが作成した時間と取り違えると、実際にユーザが作成したは時間はいつなのか、消えて無くなります。

DB上に記録された時間も同様です。DBに記録された時間はユーザが作成した時間とは異なりますし、APIが受け付けた時間とも異なります(少なくとも数ミリ秒は)

また、DB上に記録された時間で厄介なのがトランザクションです。MySQLの場合、NOW()で、その時間はMySQL側の現在時刻に合わせることはできますが、トランザクションが完了するまで、別の接続からはそれを見ることはできません。つまりデータは存在する（予定）ですが、その時点では見えない状態です。 つまり、他の接続からは、この時間からこの時間の間に作られたデータを参照しても、ある時点では存在しないことになっていたが、後から存在していたことになった。という状況が生まれます。

単純に、1分前から今までに作成されたデータを参照していたら、参照インターバルをまたぐデータ作成・更新があると抜けるケースが出てきます。

さらに検索エンジンへの反映も、時間差は生まれるので、同様にDB上での時間と検索エンジンで検索できるようになった時間がずれるので、同様の問題が発生します。

秒以下も重要

また、これらの時間を秒単位で記録している場合、ミリ秒での前後関係の問題が出てきます。

12:00:00に作成されたデータが、12:00:00に参照しても取得できなかった場合に、それが遅延によるものなのか、そもそも順番が違うのかが判断できません。

• 参照が12:00:00.001に来て、作成が12:00:00.999に行われていたのか（作成前の参照なので正常）
• 作成が12:00:00.001に来て、参照が12:00:00.999に行われていたのか（何かしら遅延があったのか）

APサーバの場合、1台の中であれば、ログファイルの順序で判断できるケースもありますが、基本的に複数台で構成されるため、それらをマージすると秒以下の順序は無くなります。

他にも

タイムゾーン、サマータイムなどが時間では大きな落とし穴になります。 あまりまとまってないのと、それでどうするのかというところは書けてないですが、とりあえず殴り書き。