[WIP] データベース内データのJSONダンプおよびダンプされたデータのインポート #156
Conversation
データ量が多いので1000件ずつのバッチ処理にする
件数が多いため、each_group_of_hash_for_json_in_batchesのバッチ処理数を 10000件に上げた（併せて、引数を渡していなかったバグを直した）
updated_at を調べるべき箇所で created_at を調べていた
ochaochaocha3
force-pushed
the
dump_to_json
branch
from
140e491 to
2eecb95
Compare
ただ、これらとは矛盾するようですが、今回の最終的な目的である、テーブル構造の一からの見直しするためのダンプ機能であるなら、処理は複雑化しますが IRC ネットワークを流れるデータを模したような形式での(過去ログをインポートするような)インポートを目指すべきなのかもしれないとも思います。 |
|
1と2について、承知しました。その方針で作ろうと思います。 3について、MessageDateとChannelLastSpeechはキャッシュ用途なので、ダンプしないことに同意します。 最後の段落について、「IRCネットワークを流れるデータを模したように」する具体例と、「テーブル構造の改良後に使いやすい」のがどのような場合かの具体例はございますでしょうか？ やや抽象的で、今のところどうなるのかの想像が難しいです。 |
|
IRCネットワークを流れるデータを模した具体例は以下の通りです。 [
{
"type": "Notice",
"channel_id": 1,
"channel": "もの書き",
"timestamp": "2019-08-31T19:31:12.000+09:00",
"nick": "Role",
"message": "koi-chan -> 2D6 = [5,5] = 10",
"created_at": "2019-08-31T19:31:12.000+09:00",
"updated_at": "2019-08-31T19:31:12.000+09:00",
"user": "dicebot",
"host": "services.cre.jp"
}
]上記の例のもととした conversation_messages_0.json との違いとしては以下の通りです。
こうすることで、例えば Messages-IrcUser の中間テーブルを作成するなどの「テーブル構造の改良後」のテーブルにダンプしたデータを再挿入したとき、元の IrcUser のデータと突き合わせてどのレコードとの紐付けが為されていたのかを探す処理を新しく作らずとも、IRC ボットから入力される(元からメッセージの他の構成要素とセットになっている)データを保存する処理を使い回しやすくなります。 さらに、このようにダンプデータも元のメッセージが予めセットになったデータにしておくことで、既に稼働している(チャンネルIDやIrcUserがダンプと重複するデータが保存された)データベースに追加するときにも、データの変更や復元処理が不要になります。 テーブル構造を新規に見直し作り直したプログラムの更新の際に、サービスを止める時間を短くすることも出来ます。 |
|
具体例ありがとうございます。irclog2jsonが出力する形式に近いですね。多少インポートが遅くなりますが、データの整合性を考慮すると、確かにそちらの方がIrcUserなどの他テーブルに依存しない分安全で良いと思いました。徹底すると |
|
channel_id もなくして良いと思います。 |
|
タスクを分割しました。また、ダンプ対象からキャッシュ用のテーブルを除きました。以下のものが対象として残っています。
|
MessageのダンプにおいてN+1問題が発生し、非常に遅かったため
channelとirc_userのデータを含むようにする。 id、created_at、updated_at、channel_id、irc_user_idを除外する。
|
タスクの分割、キャッシュ用のテーブルの除外、MessageとConversationMessageのダンプで出力する内容の変更までできました。問題がなければ、インポートの実装に進めそうです。 |
|
テストファイルに ChannelLastSpeech, MessageDate が残っていますが、わざとでしょうか。 状態確認用のため、コンソール出力内容に、どのタスクを実行しているかを挿入していただけませんか。 |
|
data:dump:json:conversation_messages にて、以下のエラーが出力されます。 2019-09-08 17:14 追記 |
|
確認ありがとうございます。 |
* data:json:concat 複数の JSON ファイルを結合する * data:json:sort_by_time タイムスタンプを元にメッセージを並べ替える * data:json:suppliment_user_host JOIN メッセージを元に推測した IrcUser を補完する
|
@koi-chan さんとの相談の結果、タスクの名前空間を
おっと、これらやってませんでした。また修正します。 |
これについては残しておくことにします（ |
現在のデータベース内データをJSONにダンプする機能と、その機能によってダンプされたデータをデータベースにインポートする機能を作っています。
ダンプ機能では、指定したディレクトリの中に、モデルごとに以下のJSONファイルにデータを出力します。ファイル名にNがついているモデルは、件数が多いため10,000件ごとにファイルを分割するものです。
まず最低限のダンプ機能を作ったため、正常に動くかローカル環境で試していただけないでしょうか？
もし正常に動いた場合、続いて以下のことをこのPR上で確認、決定したいと考えています。
data:import:dumped_json[dir]など。to_jsonを使ってJSONにするデータを作っていたため、そのデータと形式を合わせておくと、インポート処理を書くのが楽です。