この記事は1年以上編集されていないため、情報が古い可能性がございます。
ご注意ください。

このWordPress pluginを配布しています

以下記事で紹介されているアンチパターンを見事に体現していたサービスがありましたので、失敗談をかいつまんでご紹介します。

素晴らしい記事

yakst
PostgreSQLのアンチパターン : 何でもかんでもjsonに入れる
http://yakst.com/ja/posts/2445

本当にあった怖い話

iOS/Androidでリリースしていたソーシャルゲーム。(現在はサービス終了)
当時のゲームはポチポチ系が多く、今流行っているようなアプリと比較してアクセスが圧倒的に多いことが特徴。

KPIを求めるためのログテーブルを用意したが、どのシーンのログも1つのテーブルに突っ込むという乱暴な設計。
MySQLのtext型カラムを1つ用意し、シーンごとの細かいパラメーターをほぼほぼJson化して保存していたために超巨大なテーブルとなり、検索もままならない状態に陥る。

EAVアンチパターンにかなり近い感じ。

データ量が多くさまざまな弊害が発生。

  • データ量が多すぎてバックアップできない
  • 集計するにも、集計したいデータがjsonに含まれているためRDBMS側で事前に絞り込むことが難しい、コストが大きい
  • 1つのテーブルで複数のログを扱っていたため、ログ種類を絞り込むだけでサーバが悲鳴を上げる
  • 月替わりに集計を試みるが、12時間経過した後で、サーバが落ちる

後日談

リリースしてしばらくしてからMySQLのテーブルパーティショニングを追加することで、若干改善はされたようです。

可変データをJsonとして残しておくことは楽なのですが、データの集計や再利用が難しかったり、不要なデータまで「とりあえず残しておこう」という判断をしてしまいがちですから、本当に必要かどうかは一呼吸おいて検討したいですね。
少なくとも可変==万能ではございません。

また、このお話はスマホが普及して間もなくのタイトルのため、現在(2015年)で考えるとDB性能であったりインフラ技術であったり、当時と比較して発達したものも多く、今はもっと楽に対応できるのではないかなと思います。

しかし、ログ用のDBサーバだけでも何台もあったようなので、おそらくかなりの費用感だったのではないでしょうか。
使うか使わないかわからないログのために、何台もサーバを用意しておくなんて、もったいないと思います。


スポンサーリンク
ad_336
ad_336
  • このエントリーをはてなブックマークに追加
  • Evernoteに保存Evernoteに保存