オーマイニュースのお知らせには
と書いてあるが、『オーマイニュースは俺を笑いぬっころがすつもりらしい(1)』で、読者評価ランキングの更新は停止していないらしい事には触れた。
どうも、各記者のマイページ上の値の更新は停止(というか更新間隔を長くした)ようなんだが、これにより効果があったとするならばなんだかなぁという思いがする。
というのは、単純に考えて記事にアクセスがあった時に、記者毎に集計するようにしていれば済む話だからだ。
一般にある入力データがありそれに基づき計算した何らかの値を表示(出力)する場合には、基本的には次の3通りの方法が考えられる。
論理的には 2. の方法が一番楽(わかりやすい)と思うが、現実にはそれぞれの処理にかけられる時間には制限がある為、1. ~ 3. の方法を必要に応じてミックスする事になる。
で、アクセス数の積算には時間がかかるのか?
答えはNoである。
元々最低でもアクセス時に記事毎には集計(加算)しているはずである。(違う可能性もあるがそれについては後述する)
それを記者毎にも集計(加算)するようにするだけではないか。
記事→記者の関係は1対1なのでアクセス時に集計(加算)するのは容易であるが、記者→記事の関係は1対多なので、前述した 2. あるいは 3. のような方法を用いて、集計するのは実行コストが高い。
結局、どんな設計してるんだよという話になる。
実際の所、オーマイニュースの場合には、『オーマイニュースのランキングの秘密を解いたつもり』で書いたように、単位時間内でのアクセス数からポイント値を計算するというような即時積算できない理由があるのかもしれない。
これはこの仕様がまずいので、他の仕様に直したほうがいいだろう。例えば直前のアクセスからの経過時間によりポイント値を算出する等。これなら即時計算できる。
おまけで、(違う可能性もあるがそれについては後述する)について書いておく。
今回のアクセス数の場合には、十分即時集計できると思うが、世の中には入力データの発生間隔が短すぎて複雑な計算をしていると間に合わないという分野も存在する。
その場合、解決策として考えられるのが、前述した 2. あるいは 3. のような方法であるが、もうひとつキューイングするという方法も考えられる。
入力データの発生間隔が短すぎる状態が継続的に続くならば適用不能であるが、ピーク時のみきついということであれば、入力データを取り込む専門のプログラムと取り込まれたデータを積算する専門のプログラムに分業することにより解決できるかもしれない。
前述した 3. の一種と考えても良いかもしれない。取り込まれたデータが存在するということが、トリガーとなる訳だ。
本当は例題を用意してもう少しわかりやすく書こうかと思ったけど、こんなもんで勘弁してね♡
2007/12/05 12:40(障害報告)
アクセス増に伴う仕様変更について
当サイトへのアクセス増加に伴い、時間帯によってページ閲覧に時間がかかる状況が発生し、ご迷惑をおかけしております。
暫定措置として、10分ごとに更新しております「活躍中!」「読者が選んだ注目記事」、マイページにおける「アクセス数」の更新頻度を、1日1回(午前4時ごろ)といたしました。
ユーザの皆さまが快適にご利用できるよう対策を検討中ですので、しばらくご不便をおかけしますがよろしくお願い申し上げます。
アクセス増に伴う仕様変更について
当サイトへのアクセス増加に伴い、時間帯によってページ閲覧に時間がかかる状況が発生し、ご迷惑をおかけしております。
暫定措置として、10分ごとに更新しております「活躍中!」「読者が選んだ注目記事」、マイページにおける「アクセス数」の更新頻度を、1日1回(午前4時ごろ)といたしました。
ユーザの皆さまが快適にご利用できるよう対策を検討中ですので、しばらくご不便をおかけしますがよろしくお願い申し上げます。
と書いてあるが、『オーマイニュースは俺を笑いぬっころがすつもりらしい(1)』で、読者評価ランキングの更新は停止していないらしい事には触れた。
どうも、各記者のマイページ上の値の更新は停止(というか更新間隔を長くした)ようなんだが、これにより効果があったとするならばなんだかなぁという思いがする。
というのは、単純に考えて記事にアクセスがあった時に、記者毎に集計するようにしていれば済む話だからだ。
一般にある入力データがありそれに基づき計算した何らかの値を表示(出力)する場合には、基本的には次の3通りの方法が考えられる。
- 入力データ(基礎データ)をトリガーとし即時計算する。
- 表示(出力)する際に、その表示(出力)要求をトリガーとし、基礎データから計算する。
- 入力処理、出力処理に関係なく別トリガー(多くの場合はタイマー)により、バックグラウンドで計算する。
論理的には 2. の方法が一番楽(わかりやすい)と思うが、現実にはそれぞれの処理にかけられる時間には制限がある為、1. ~ 3. の方法を必要に応じてミックスする事になる。
で、アクセス数の積算には時間がかかるのか?
答えはNoである。
元々最低でもアクセス時に記事毎には集計(加算)しているはずである。(違う可能性もあるがそれについては後述する)
それを記者毎にも集計(加算)するようにするだけではないか。
記事→記者の関係は1対1なのでアクセス時に集計(加算)するのは容易であるが、記者→記事の関係は1対多なので、前述した 2. あるいは 3. のような方法を用いて、集計するのは実行コストが高い。
結局、どんな設計してるんだよという話になる。
実際の所、オーマイニュースの場合には、『オーマイニュースのランキングの秘密を解いたつもり』で書いたように、単位時間内でのアクセス数からポイント値を計算するというような即時積算できない理由があるのかもしれない。
これはこの仕様がまずいので、他の仕様に直したほうがいいだろう。例えば直前のアクセスからの経過時間によりポイント値を算出する等。これなら即時計算できる。
おまけで、(違う可能性もあるがそれについては後述する)について書いておく。
今回のアクセス数の場合には、十分即時集計できると思うが、世の中には入力データの発生間隔が短すぎて複雑な計算をしていると間に合わないという分野も存在する。
その場合、解決策として考えられるのが、前述した 2. あるいは 3. のような方法であるが、もうひとつキューイングするという方法も考えられる。
入力データの発生間隔が短すぎる状態が継続的に続くならば適用不能であるが、ピーク時のみきついということであれば、入力データを取り込む専門のプログラムと取り込まれたデータを積算する専門のプログラムに分業することにより解決できるかもしれない。
前述した 3. の一種と考えても良いかもしれない。取り込まれたデータが存在するということが、トリガーとなる訳だ。
本当は例題を用意してもう少しわかりやすく書こうかと思ったけど、こんなもんで勘弁してね♡
例えば一回のSQL発行で済む積算を、ループ内の複数回のSQL発行にて実装している等。
工夫してSQLの発行回数を抑えるというのは常識だと思うのだが、何せオマニーシステムだから。