Twitter のユーザーIDが Int64 (Snowflake) に変更


このブログでは、以前から Twitter データの解析を行ってその結果を公開していました。

Twitterクライアント 総選挙2015

諸事情により一時的に収集を中止していたいので、再開し確認したところ、何かがおかしい事に気づきました。

これまでのデータ

かなり省略するとこのようなデータでした。

{
 id: 728236267847061504,
 id_str: "728236267847061504",
 text: "テストツイート",
 source: "<a href="http://twitter.com" rel="nofollow">Twitter Web Client</a>",
 user: {
  id: 2239296018,
  id_str: "2239296018",
  screen_name: "oyasu_info",
 }
}

ここの user 内の id がこれまでは10桁以下だったのですが、急にツイート自体の id と同じような18桁の数字になっているものが見られるようになりました。

例えば、最近 Twitter を始められた SKE48 の松井珠理奈さん(@JURINA38G)は 706826757500866560 でした。

ツイートのidと混同していないかも含めて調べてみたところ、どうやら仕様変更だったようです。

データの移り変わり

ツイートIDのような10桁の数字というのは、Snowflake と呼ばれていますので、こちらでもそのように表記します。

こちらは収集されたデータを基準にしているので、収集の対象としていない日本語以外のツイートや、一部のツイートしか取得できない Streaming API の特性もあるということにご注意ください。
日時は全て UTC+0 で表しています。

Snowflake 形式で一番小さい(=一番最初に登録した)アカウントはこちらの id でした。
694250264547581953
登録日は、2016/2/1 20:05:35 のようです。

一方、旧仕様で一番大きい(=一番最近登録した)アカウントはこちらの id でした。
4928639051
登録日は、2016/2/18 17:57:18 のようです。

PC 版 Twitter ウェブサイトからの投稿のクライアント名が web からTwitter Web Client に変化したときのように順次移行していますが、以前は30分間でこちらは17日間と長い期間かけています。
もしかすると、登録方法によって id の割り当て方が異なるといったこともあったのかもしれません。

プログラムの対応

目視での確認で気づいたように、大幅な変更にもかかわらず影響は最小限でした。
今回は MySQL データベースを使用しており、ユーザ ID にも BIGINT を使用していました。
通常の INT の最大値は 2147483647 で、UNSIGNED でも 4294967295 と旧仕様でも桁あふれを起こす状態であり、9223372036854775807 まで使用できる BIGINT を使用していたので、この問題は回避できたというようです。

ちなみに、プログラミング言語の数値型も同じことがいえますので、こういった情報を扱うときは注意が必要です。


Comments

comments

コメントを残す

メールアドレスが公開されることはありません。

*

日本語が含まれない投稿は無視されますのでご注意ください。(スパム対策)