人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

現在アクセス解析情報をPostgreSQLに持たせようと考えています

たとえば単一TABLEに
日時、access元、keyword、browser、pageを持つのと
それぞれTABLEに分けて結合するのと
どちらが高速なんでしょうか?

[accessTABLE]
access元ID,keywordID,browserID,pageID,日時

[access元TABLE]
[keywordTABLE]
[browserTABLE]
[pageTABLE]
ID,名

さらに各TABLEには日時を持たせると
日時検索が早いような気がしますがいかがでしょうか?

[accessTABLE]
accessID,keywordID,browserID,pageID,日時

[access元TABLE]
[keywordTABLE]
[browserTABLE]
[pageTABLE]
ID,名,日時

Siteの規模はuser数約5000人
AlexaのPageviews(%mil)が約20、Reach(%mil)が約200
この時どのように情報を持つべきでしょうか?

fileも検討してますが、nfs利用時のlockが不可と聞き
DBにすべきかと思っています

●質問者: ganessa
●カテゴリ:ウェブ制作
✍キーワード:access Alexa dB keyword NFS
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

1 ● andi
●30ポイント

> どちらが高速なんでしょうか?


そもそもワンセットのデータ(日時、access元、keyword、browser、page)を正規化してテーブル分割する意味は無いように思われます。

また結合処理は当然、結合を行わない場合より速度は低下します(勿論そのテーブルの使用目的(アプリの設計、作り)にもよりますが)。

◎質問者からの返答

やはりそうですか・・・

それでは一つのテーブルに全て持って

しまってかまわないということですね。

この場合だと下のほうに記述した日時を

含んだ場合でも同じでしょうか?

たとえばキーワードランキングを

生成するとしたらブラウザなんかは必要ないわけですが、

そのとき大きなテーブルを見るよりは、

キーワードだけのテーブルを見たほうが

早いかと思ったんですが・・・


2 ● andi
●30ポイント

> この場合だと下のほうに記述した日時を

> 含んだ場合でも同じでしょうか?


そもそも同じ内容のデータを複数のテーブルに登録するのはRDBMSの正規化の目的と矛盾しています。

(正規化すれば早くなると言うわけではありませんが)


> そのとき大きなテーブルを見るよりは、

> キーワードだけのテーブルを見たほうが

> 早いかと思ったんですが・・・


そこまで行くとRDBMSの内部的な仕組みの話になってしまいますので想像になってしまいますが、同じRDBMS上のテーブル-カラムという枠組みにデータを登録する以上、データを見に行く速度は変わらないと思います(テーブル→カラムのアドレスを探しに行くという順序は変わらない)。

◎質問者からの返答

ご回答ありがとうございます。

やはりそうですか。

余計なことを考えずに他の方法で

高速化できるよう頑張ります。

お忙しいところご回答ありがとうございました。

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ