2013年1月15日火曜日

LoTwってどうやってんだろ?

最近のシステム増強に伴い、昨日位からバックログが2時間位に減っていて、概ねリアルタイムと言ってもいいようになってきました。
しかし、このシステムやっている事を考えると、ログの量が増えれば増える程遅くなる筈ですよね。一行毎に交信相手の記録があるかどうか、あれば日時、周波数があっているかをチェックしながら入力してゆくのですから、、、。  どうやってこなしているんだろう?? 
ここ2日程の平均値で見ると、一分間に2千QSO程度の入力をしているようですので;
 
   現時点で登録されている交信数は470百万件。
   一分間に2千QSOの入力
     従って、1秒間に470 X 33 = 15,510百万件の照合をしている事になります。
     (2000/60 = 33 QSO/sec)
     155億/secのデータ照合!!
   将来の拡張性や、処理速度を考えると、50~100台位のサーバのビッグデータDBかな?
   ホスティングは googleとかamazonなのかな?

取敢えずはビッグテーブル(Excel票のお化け)で自分のコールサインと交信相手のコールサイン、交信日時、バンドのハッシュキーでマッチングするのかな? これだったら、サーバを何台も足して並列化出来るし、仕事の割り振りも難しくないし、、、。チェックの順番を日付の新しい物からの様な優先順位を作って全部を見に行かないように位はしているのでしょうけど、、、。 時間を含めた纏めたハッシュキー(一発でマッチング出来ますが)だとマッチングの確立が下がり過ぎるかもしれませんが、交信時間の曖昧さはどうやって処理しているんだろう? 

デバイスの小型化、低価格化がデータベースの基本的な考え方を;a) 資源利用の最適化 - 1970年代のRDBから 2) 処理スピードの最短化とデータの安全性(冗長性)に変わって来て、今まで想像したことも無いような処理がbinary hashやtableのお化け(単なるデータの羅列)で出来るようになっていますね。 ログのマッチングの様な将来確実に処理速度が遅くなるようなアプリケーションでさえ何も考えずに実現出来てしまう、、、。

以上は私の推測ですので本当の所は知りません。

現在自作RDBをビッグテーブルにしようかと考えていますが、何十年も掛かってRDBの為の正規化等身につけて、折角作ったRDBを今からビッグテーブルに戻す作業は、殆どトルストイの時代のロシアの刑罰にも通じる所があります。 でも、リアルタイムのトランズアクションが必要無ければ、このようなDBになってゆくのでしょうね、直観的だし、、。


LoTwのHomeに
Jan 9, 2013: Update -- If you have been following the Logbook of The World statistics you know that the delay and queue size have been declining rather steadily since Monday morning.  On Friday, LoTW was taken off line for previously announced maintenance. This was for the installation of the new hardware that included new Solid State Drives (SSDs). 

After installation and testing, the system was brought back on line Friday afternoon. After some initial start up problems, the system has been stable and the new hardware is proving to be much faster.  Thanks for your patience

とあって、処理速度の向上はSSDのお蔭!とありますが、自前のサーバ? 分散処理もしてない? めちゃくちゃな力技? っかな?



0 件のコメント:

php のインストールの確認

phpって最初のfacebook書くときに使われたみたいで、それなりに歴史のある言語で、私も2006年位から使っていますが、CLIで使う事はあまり無いので、apacheとの連携のトラブル(mod_phpのバージョンの齟齬)などは気になりますが、拡張モジュールのインストールの問題に...