プログラマ専用SNS ミクプラ

お世話になっています。

プログラミングより運用のご相談なのですが。
現在、Androidでゲームを開発しているのですが、ソーシャル系要素も取り入れたいらしく、
足跡、チャットのような機能をデータとしてずっと持ちたいようです。

ただでさえ、パフォーマンスに難があるのに、DBの負荷も上げたいようです。
ソーシャル系と言うとユーザの行動履歴のようなもので、データはガンガン積もっていきます。

各ユーザごとにファイルでそれを持つように促しましたが、やっかいな事にタイムラインのような
フォローしてるユーザのみの最新行動を取るなんて所もあり、１テーブル(日付の最新順ソートの為)でこれらを管理しなければいけないようです

DBはPostgreSQL8.3なのですが、負荷を抑えるにはテーブルのパーティション分けしか思いつきません。
[code]
CREATE TABLE play_tbl (
userid varchar(40) NOT NULL, -- ユーザID
playid varchar(40) NOT NULL,
playkbn varchar(1) NOT NULL, -- 1:いいね 2:購入アイテム 3:レビュー 4:雑談
userval varchar(40),
playval varchar(40),
free1 varchar(500),
free2 varchar(500),
createtime varchar(19) NOT NULL,

PRIMARY KEY (userid, playid, playkbn)
);
CREATE INDEX idx_play_tbl1 ON play_tbl (playid, playkbn);
CREATE INDEX idx_play_tbl2 ON play_tbl (playid, playkbn, createtime);
[/code]
現在、このようなテーブル設計ですが、パーティション分けをするのは後々でも良いのでしょうか？

公式ページ、こちらのサイトでもリファレンスが載っていたのですが、いまいちピンと来ません。
http://benzaiten.dyndns.org/roller/ugya ... 3%E3%82%B0

そもそも、パーティション分けするにも、キーは「年月」がキーとなるのですが、SQLは日付(上記createtime)の降順の最新順になるので、効果があるのかも不安です。

みなさんは、ゲーム開発も多いと思いますが、このようなデータ様式の場合、どのように対応されているのでしょうか？

データを無限に保存は、どんなものでもムリです。
だからここは割り切りが必要だと思いますがどうなのでしょう？

私ならAndroid本体に保存するのでなく、専用のデータベースサーバに保存するように実装しちゃうかもしれません
そもそもAndroid本体自身に空きを圧迫するようなやり方はユーザの怨嗟を買う行為だと思うので好みません
Google提供のアプリは個人情報などのデータを自分のデータベースサーバに収集しているので、あそこまでやるのはどうかとは思いますが　(^^;

Android本体に保存したいのであれば必ず制限は必要です。
たとえば最近１週間のデータをAndroid本体に保持しておいて、それより古くなった場合はどっか別のデータベースサーバに転送しておくとかね。

・・・見当違いの回答でしたらすみません

へにっくすさん

ありがとうございます。
現在データはPostgreSQLの8.3に入れた、Android(UI) & サーバサイドのシステム構成です。
当然、DBはサーバサイドにあります。Androidはあくまでもサーバの通信データを得て、動作します。

ただ、DBのデータがおっしゃる通り、無限なので。。
データの上限が見えないのはシステムとして致命的だと思うのですが・・。
(それもソーシャル機能なんで溜まりやすい・・)

ビックデータの取り扱いは、未だ業界でも試行錯誤だと思います。無限という条件は検索時間も無限を意味します。
と言うことで要件定義が曖昧なまま進めても破綻すると思いますので、予算の範囲で可能な範囲から逆に限界を決めたほうが良くないでしょうか。

あと、そんなに過去まで遡るんでしょうか？
一番の問題は、一日にどのぐらいのデータを扱うことに成るのか、まったく見えていない気がするんですが。
ところで、これ企業秘密の情報漏れになってませんよね？

softyaさん

ありがとうございます。

>ところで、これ企業秘密の情報漏れになってませんよね？
まだ企画段階の談笑でシステムを知らない人のおた話なので。

ただ、一応負荷の膨大さ、今ある技術での調査はしておきたいと思ってまして。

もし、実現させようとした場合の為、自分の頭の中で留まっているレベルです。
テーブルの列も本来これじゃ全然足りませんし。

ビッグデータ対応は確かに最近注目しだされてきまして、今ある無償DBではほぼ対応不可だと思ってます。
(HasP??なんてのも出てきましたが、アーキテクト部分でまだまだの印象・・)
ただ、現在ある技術では、DBのパーティション分割ぐらいは把握しておきたいと思ってまして。。

みなさんは大きい件数を処理する際は、どのようなパーティション運用をされているんでしょう？

bobodaa さんが書きました:ただ、DBのデータがおっしゃる通り、無限なので。。
データの上限が見えないのはシステムとして致命的だと思うのですが・・。
(それもソーシャル機能なんで溜まりやすい・・)

行動履歴を全部見たいわけじゃないでしょ。
第一、膨大な履歴をすべてとっても人間それを全て見る人はいない気がしますが。いたらその人はよほど暇人？
年月でパーティションを切り分けるにしても、それをまたがる取り出し方をするようでは意味がないです。
(常に１週間の履歴を見たいとかいった場合、またがるケースがありますよね)
まずは取り出したい情報の整理をしてください。
そして、各項目の頻度を考えてみるのです。リスト用、詳細用と切り分けてね。

softya（ソフト屋) さんが書きました:ところで、これ企業秘密の情報漏れになってませんよね？

テーブルの定義をさらしちゃってますが、まあ、これだけでは何に使うか限定はできないと思うので一応セーフかと思います。
さらす必要はなかったと思いますけどね。

RDBではなくKVSでは駄目なのでしょうか？

Pocoさん

ありがとうございます。
メモリオンDBは、リファレンスを読む限りですが、トランザクション管理に向いてないんですよね？
ロールバックすると全体がロールバックされるとか・・。

正直、使った事は無いのであまり分かりません。
ただ、件数が肥大化したテーブルで多アクセスが予想されるものはよく、メモリキャッシュを使います。
DBをそもそもアクセスしないで、内部バッチでX分毎にデータを更新するとか。

でも、これもソーシャル機能のように瞬時に反映されるべき、データ様式の場合は・・。
データを二意で持つのもあまり好きじゃありません。

へにっくすさんのおっしゃられる通り、全てのデータより、最新のXX件さえ取れれば良いと思って、
パーティションについてお聞きしたのですが、結局更新日降順だとの全なめでデータを参照してしまいますよね。。

テーブル定義を載せたのはこういうテーブル構成の場合、どのようにパーティション切りするか
具体的な例がいただけるかなと期待したからです。

「日付」と「それ以外」の項目だけでも良い気がしますが。
また、パーティション分けは運用時、遅くなってからの対応も可能かお聞きしたかったです。
パーティション分けするにしてもパーティション数の上限も気にしないとだめですよね？？