データベース更新用プログラムの設計

[kerochan]

データベース更新用プログラムの設計についてのディスカッションです。

カード更新・追加

機能

入力のカードデータのidに一致するカードを更新または一致するidが無ければカードを追加する。

入力

{
"pageid": Number // FANDOMのpageid
"name": String // 名称（カードの要素）
"cost": Number // コスト（カードの要素）
"attack": Number // 確保力（カードの要素）
"oc": String // オブジェクトクラス（カードの要素）
"maintypes": Array // メインタイプ（カードの要素）
"subtypes": Array // サブタイプ（カードの要素）
"effect" : String // 効果（カードの要素。ただし効果外テキストもここに記載される）
"tags": Array // タグ（カードの要素）
"banned": Boolean // 永久収容
"latest_revid": Number // FANDOMのリビジョン
}

urlは"http://localhost:55000/upsert"

出力

エラーがあった場合にのみ、
{ error: エラーメッセージ }

カード削除

機能

指定されたidのカードを削除する

入力

{
"deleteTargetCardPageids" : [Number]
}
urlは"https://localhost:55000/bulk_delete"

出力

エラーがあった場合にのみ、
{ error: エラーメッセージ }

DBカードデータのid、revid所得

機能

DBのカードデータを得る

入力

なし(GETメソッドを使用)
urlは"http://localhost:55000/current_cards"

出力

[
{
"pageid": Number // ページID,
"last_revid": Number // リビジョン
}
]

[smctrl]

データベース更新用プログラムとWebアプリケーションの結合部分について

こちらで話した通り、データベース更新用プログラムについてはWebアプリ側にデータ更新用のメソッドを作ってそれをPythonから叩いてもらうことを考えています。
@kerochan さん的にはどんな形でデータ送りたいですか？カード1枚単位で更新リクエスト投げて成功失敗をレスポンスで貰うか、複数枚をリストにして送って失敗したものだけ一覧にしてレスポンスで貰うか、やりようはいろいろあります。

[smctrl]

カード更新とカード追加の区別についてはそのpageidのカードがDBに存在するかでサーバー側で判断できます。
NeDBのupdateでは「あれば更新、なければ追加」みたいな動作が可能です（実際に動作確認できていませんが、今の実装ではそう作っています）。

[kerochan]

カードidとrevidを得るメソッドについてはどのような形式でリクエストを送ればよいでしょうか

[smctrl]

カードidというのがFANDOMのページIDで合っていれば、
NeDB側で削除されていない全カードについて単純に
[
{"pageid": ページID, "last_revid": リビジョン},
{"pageid": ページID, "last_revid": リビジョン},
...
]
の形のを返せばいいのでしたら特にリクエストに付けるものは必要ないと思います。
URLはhttp://localhost:55000/current_cards にGET送信していただければOKなようにします。
上記の情報を使ってFANDOMの方が新しいカード、もしくはFANDOMにしかないカードがあればWebアプリケーションの方に1枚ずつ送ってくれるという認識で合っていますか？
この情報があればPython側でFANDOMになくてNeDBにあるカードも判別できるので #8 (reply in thread) で提案したような「現在FANDOMに存在するカードのpageidの配列をPythonからWebアプリに送って、それをもとにWebアプリがNeDBからカード削除を行う」ではなく素直にカード削除対象のpageidの配列をWebアプリに送り付けてカード削除を実行できる気がしますが、いかがでしょうか？

[kerochan]

その認識で問題ありません。確かにDBのカードデータがあれば、削除対象のカードを判別できるので、提案は実現できると思います。上記で提案していただいた案を採用したいと思います。#8 での提案は、データのやり取りを2回行うのであれば、fandomから得たidをNeDBに1回送る方が良いのではないかという考えから提案しました。しかし、考え直してみるとカードの更新と追加でDBのカードデータを引っ張るのであれば、ついでにそれを使って削除対象のカードを探索する方が、一貫性が出てより良いと思い直したためです。

[smctrl]

すみません、上記のlast_revidはlatest_revidの間違いでした。DBに合わせてlatest_revidで実装しています。

[smctrl]

「更新」の用途がデータベースに対する読み取り以外の操作全般かカード1枚に対する更新か紛らわしいので何かうまい言い方を考えたいです

[kerochan]

変更、はどうでしょう？

[smctrl]

その「変更」がDBに対する変更かカード1枚に対する変更かが問題になりそうなので、プレフィックス的なのを付ける感じでどうでしょう。

• カード新規登録
• カード更新
• カード削除
• DB変更（上記3つの総称）

といった具合です。

[kerochan]

その表現に賛成です。とてもわかりやすいと思います。

[kerochan]

文字数的に他のものと合わせて、カード新規登録はカード追加でも良いかもしれません。

[smctrl]

上記に賛成します。ということで、これからは分かりやすいように

• カード追加
• カード更新
• カード削除
• DB変更（上記3つの総称）

という言葉を使うように心がけるようにします。
上記みたいに基準になる言葉があれば確認もしやすいので。

[kerochan]

PythonとNodejs間でのデータの受け渡しや関数の呼び出しはどのような手法で行うことを想定していますか？

[smctrl]

PythonからNode.jsのWebアプリへHTTPでJSONをPOSTでリクエストしていただくことを想定しています（必要な情報はレスポンスで返します）。
カード追加とカード更新のURLは、http://localhost:55000/upsert
カード削除は、http://localhost:55000/sync_deleted
を想定しています。
ドメインではなくlocalhostでURL切っているのはPythonとNodeで動かすサーバーが同じためです。
ポートを443や80でないところに切っているのは検索用のURLと違って外からアクセスされたくないからです（ポート55000は外からの通信を塞ぐように設定しています）。

[smctrl]

上記のhttp://localhost:55000/sync_deleted は削除方式を単純なものに変更したためhttps://localhost:55000/bulk_delete に変更します。「削除されたものを同期」みたいな意味のURLを「一斉削除」に変更したようなイメージです。

[smctrl]

度々すみません。
カード削除のリクエストの方式の変更にともなって、currentFandomCardPageidsという名前はdeleteTargetCardPageidsに変更して実装しました。前者だと意味が「現在のFANDOMのカードのページIDたち」になってしまうためです。

[smctrl]

おそらくPythonとNodeの結合部分に着手できるだけの情報はほぼ出揃ったかと思うので、環境一式とそれっぽいコードを用意しました。
詳細はとりあえずここです。
上記の概略としては、必要なソフトをインストール、必要なディレクトリを作ってそこにフロントエンドのコードとサーバーサイドのコードと左記サーバーサイドのコードを実行するVM生成用のコード（Vagrantfile）をチェックアウトしてVMを起動、VM内にサーバーサイドのコードをコピーしてビルド・起動、VM外でフロントエンドのコードを実行（これはまだ不要かもしれない）、Pythonを（詳細は分かりませんが）VM内で実行、FANDOMのカードが取り込まれたNeDBのファイルをVMから取り出して確認、みたいな感じです。
着手できるとはいえ話し合えてない部分や私の実装の抜け漏れ・バグなどはおそらく出てくると思うので、質問・ツッコミがあればよろしくお願いします。

[kerochan]

Python自体をずっと走らせる感じにしようかと思っています。PythonでのFANDOMカード回収にはBotを走らせるのですが、そのBotにログインする必要があるため外部から走らせることが困難であるためです。

[smctrl]

API以外に何かPythonでログインするべきBotがあるということですか？

[kerochan]

コード見直しましたが、クエリを投げてデータを得るだけなので特にログインする必要は無さそうです。これならば、crontabを使用して定期的にシェルスクリプト走らせるという形で良さそうです。

[smctrl]

いずれデータを得るだけではなくカードメーカーとしてFANDOMに投げるようになるとログインも考慮に入れることになると思いますが、そこまで見込んだ上でとりあえず今は検索を実装し切るという判断でしたら私もcrontabで賛成します。

[smctrl]

SSL関連のエラーは消す方法が一応あるかもしれないので、邪魔なようであれば試してみます。ざっくり言えば、scptcgjpj.tkのDNSにlocalhostって名前でAレコードを立てて127.0.0.1に向けて、localhost.scptcgjpj.tkについて証明書を発行する感じです。

[smctrl]

余力があればPython・Node間で相互の死活監視が欲しいです

[kerochan]

具体的にはどのような方法を取りますか？

[smctrl]

原始的で手軽な方法としては、Node側で死活監視用のhttpメソッドを用意してPython側で（DB変更の有無に関わらず）定期的に呼び出すという手があります。
Node側が落ちていればPythonは死活監視用のhttpメソッドのレスポンスが受け取れないはずなので、所定秒数あけてリトライします。何回かのリトライで全部失敗したらPython側は「Node側が死んだ」とみなして何らかのアラートを投げます（何らかのアラートは）。
Python側が落ちていればNodeには死活監視用のhttpリクエストが来ないはずなので、前回の死活監視リクエストから所定秒数経過してもリクエストが来なかったらNode側は「Python側が死んだ」とみなして何らかのアラートを投げます。
「何らかのアラート」についてはtwitterのDMやメールを想定していますが、他にもいろいろやりようはあると思います。

[smctrl]

FANDOMからデータを回収してDB変更を実行するうえで、Python・Nodeの双方でログを残しておくことでシステム障害の復旧に役立つことが期待できます。今のところは検索だけなので障害でNeDBのデータが破損してもFANDOMのデータを正と決め打ちして回収できるため、v1.0.0では実装しないという判断もなくはないですが、v1.0.0で実装するのであれば出力場所や何を出力するかなどを決める必要があります。

[smctrl]

出力するファイルは複数プログラムで同時に一つのファイルを編集するのが怖いので、Node側とPython側で分けたいのですが、いかがでしょうか？
例えば、
データベース更新用プログラム側はcrawler.log-yyyy-MM-dd
Webアプリ側はserver.log-yyyy-MM-dd
みたいな感じです。

[kerochan]

DB更新1回分で1ファイル分という感じになりますかね？

[smctrl]

大量のログを出すわけではないので、同じ日のログは同じファイルに追記する形で1日1ファイルでいいと思います。

[kerochan]

ログは例えばこのような感じになりますかね
INFO:2021-03-22 14:52:46:Upsert Card From DB:{ここにカードデータのjson}:OK

[smctrl]

今のところ必要な情報が揃っているので良いと思います。

[kerochan]

DB更新処理の実行間隔ですが、1日1回00:00に実行でどうでしょう。Fandomでのカードの更新や追加の頻度はあまり高くない(平均1回/日程度)ため、そこまで頻繁に実行する必要は無いと思います。

[smctrl]

同様の理由で1日1回00:00に賛成です。
「カード作ったのに反映されない！」のような混乱を避けるため、FANDOMやこのシステムにDB変更のタイミングは明記したいですが、いかがでしょうか？

[kerochan]

その案に賛成します。ただ1点、あくまで検索システムの方で更新が反映されないだけなので、DB更新タイミングをFANDOMの方に追記する必要は無いと思います。

[smctrl]

了解しました。では検索システムの方だけにタイミングを明記しておく形にします。