logデータの突き合わせプログラムを書けという自分への指令(5・終)

ログの原簿であるLog200のデータにある交信レコードをup-to-dateにしているメインのデータベースであるMariaDB (MySQLコンパチブル)のデータと照合して,MariaDBに欠落しているレコードがないか,を確認するプロジェクトですが,照合スクリプトの最終形が吐き出したエラー分について手で確認をしました.

MariaDBとの照合は,日付,時刻(±5分のマージン)とコールサインで検索しました.参考の為に,モードの違いについても,検索してヒットしたレコードと原簿のレコードについて照合して,違う場合はwarningとしました.

原簿にある7万9千レコード全部について照合するのに,190分ほどかかりました.そのうちほとんどがMariaDBが占めていて,PerlのCPU占有は30秒余りです.

その結果,モードの違いまでも含めると,540ありました.検索条件が違うので(4)の293件より多くなっています.

このうちwarning扱いのモードの違いをのぞいたエラーは,128件で,手作業で照合しました.

ほとんどが,コールサインの間違いです.もらったQSLカードで修正したものがほとんどです.また,時刻の違いも何件かありました.時刻は,PCの時計データを取り込むようにしていますが,そのPCが仮想マシンのため,仮想マシンが再起動した直後に時刻データが不正確であった可能性があります(これは仮想マシンの特定のバージョンにより含まれているバグです).可能性は低いとはいえ,自分が間違っている可能性もあり,間違っているのは自分か相手か断定できません.しかし,もらったQSLカードに返信の形で発行するQSLカードは相手の時刻に合わせた方が無難なので,ほとんどのケースで相手に合わせて修正してます

完全な漏れは,先に判明したUR2FEO局の2交信分の他は,8N2SEA/2局との1交信のみでした.いずれも追加済です.思っていたよりうんと少ないレベルなので,安心しました.

これで,少なくとも原簿であるLog200に記録されている交信は全てメインの交信データベースにあるという状態にできました.

ただし,多くはない思いますが,原簿に漏れている交信もあるはずです.それらについてはどうしようもないです.QSLカードが届いて,該当する交信レコードがないときはこっそり追加するしかありません😓

ただし,あり得ない時間や明らかにJST/UTCの計算違いの場合は,こちらの時間にしています.

logデータの突き合わせプログラムを書けという自分への指令(4)

最初のバージョンでは,日付とコールサインとモードが一致するという条件にしました.レコードが完璧に抜け落ちていたのは,2QSOのみで,それがいずれもUR2FEO局です.全くの偶然か,そのコールサインだけひっかかるような原因があるか,当時のLog200からMySQLにexportするスクリプトは残っていないので,全く探りようがありません.

この段階で,レコードの不一致があったものは,293件です.全レコード数は,7万9千件ほどなので,0.37%です.先日発表された,東京の新コロナの抗体保有者とコンパラです😓

目だったレコードの不一致は,モードの不一致です.50MHz帯の交信のSSBとCWが入れ替わっていることが多いです.周波数からモードを自動的に決める機能が,50MHzではあだとなっています.交信相手からQSLカードをもらって,気づいて修正しているところが多いです.

MariaDB(かつてはMySQL)のデータは修正しますが,オリジナルのログデータは修正しないことにしているのでこの不整合が発生します.

考えてみれば,ログソフトからMariaDBに取り込むときの漏れを問題にしているので,モードの不一致はドントケアーとします(警告だけ出すようにします).

その代わりに,時刻を±5分のマージンで絞ることにしました.この制限を付けても,全体の処理時間はほとんど変わりません.

そんな感じで何度か試行錯誤して練ってきたほぼ最終版を今走らせています.一度走らせると3時間待たないと結果が出ないので,試行錯誤のサイクルは長いです

関連項目

MariaDBのデータをMacかCore i7のWSに移して,テストすればたぶん何倍か早くなると思いますが,慌てることはないので😓

logデータの突き合わせプログラムを書けという自分への指令(3)

今日は少し元気なので,課題に😓実質的に着手しました.

とりあえず今日のところの成果物は,日付とモードとコールサイン指定して,検索して,もし結果が返らなかったら”die”する,つまり最初に未登録のデータを見つけたらそこまででおしまいというプリミティブなものです.

作業的には元のスクリプトから削除するのが大部分となりました.

走らせたところ,3時間ちょっとで終了です.Perlの実行時間はなんとそのうちの33.7秒で,ほとんどはmysqldの所要時間です.

topからも,そこら辺が解ります.

まだ,dieしなければ,何にも返ってこない仕様なので,これだけではスクリプトが正しいかどうか解りません.また,日付とモードとコールサインだけで指定しているので,コンテストなどだと,複数レコードが返ってくるはずなので,そこら辺を表示するように改良したいと思います.

関連項目

logデータの突き合わせプログラムを書けという自分への指令(2)

スクリプト名だけを考えました.

call_db_intactness.pl

です.拡張子の通り,Perlスクリプトです.

中身は,Log200の中身をMariaDBに放り込むスクリプトをコピーした段階です(つまり,実質的には何もしていない😓).

Log200のログデータを読み込んでparsingするところは,そのまま流用できます.

その後,Log200の1レコードずつについて,日付,交信開始時,コールサイン,周波数,モードを抜き出して,MariaDBに検索をかけて,ヒットするレコードがひとつならばOKなので無罪放免,ヒットするレコードがなければエラーを出す,2つ以上あれば警告を出す,という仕様にします.

ちなみに,現在,MariaDBには,アマチュア無線人生全ての期間(1972〜現在)の95,000余りのレコードが登録されていて,Log200は,1998年4月以降の分の8万弱レコードが登録されています.

今日はここまで(って結局実質的に何もしないでおしまい😓).

関連項目

logデータの突き合わせプログラムを書けという自分への指令

最近は,スマホやパソコンのTo Doに書いておいても,完全に無視するのでBLOGに書いときゃやる気になるかなと言う試みです.

私はログは書き込みのフロントエンドと,データベースのコア部分とは別立てとして,特にデータベースには信頼性の高いものを使うべきとも考えています.

フロントエンドは通常運用,コンテスト,デジタル運用とそれぞれの運用の特性に適したものを使うべきです.

そういう訳で,通常の運用全般には,JH3GBD堀野さん作のLog200を長年愛用しています.Log200の交信データはテキストなので,これをPerlの自作スクリプトで中核のデータベースであるMariaDBに放り込んでいます.

データベースはもともとMySQLを使用していましたが,いろんな意味であんまり信頼できない会社に買収されてしまったので,オープンソース社会の流れに従ってMariaDBに移行しました.

また,コンテストのフロントエンドとしてはN1MM+を使いますが,中間的にLog200にマージしてから,同じスクリプトでMariaDBに送り込みます.

FT4/FT8はWSJT-XのmacOS版を使用し,そのログをMariaDBに別のスクリプトで送り込んでいます.

今は改修済みなのですが,Log200からMariaDBに送り込むスクリプトの,既にMariaDBに送り込んだレコードかどうかを判別する部分にバグがあって,頻度は少ないはずですがレコードを取りこぼしている可能性があります.

その取りこぼしを検証するスクリプトを書かなければいかんと前から思っているのですが,取りこぼしがあったところで,痛くもかゆくもないし,あまり楽しいスクリプト書きではなさそうなので,伸ばし伸ばしにしてきたというわけです.

関連項目