GoのORマッパー連載の2日目の記事です。
データベースでパフォーマンスが大きな問題になりがちなのが、バッチでのデータのインサートと、複雑なクエリーです。が、今回は後者は置いといて、前者のデータの取り込みについて扱います。データの挿入の高速化は最近、ちょびっと大事かなと思うところがあります。というのも、バッチ処理をクラウド上で実行するといろいろな制約が襲ってくるからです。
クラウドサービスとバッチの時間制限
AWSのLambdaは15分(900秒)です。GCPのCloud Functionsは9分(540秒)。この時間で済むならスケジューラサービスと繋げて定時実行でLambdaとかで処理できれば運用はとても簡単です。もうちょっと厳しい制限だと、AWSのAPI Gatewayは30秒制限です。この時間内であれば、サーバーレスな管理画面からアップロードしてデータをバルクインサートみたいなことが簡単にできます。
他のサービスだとちょびっと長いのですが、GCPのCloud Runだと1時間、AWSのApp Runnerはまだそのような制限は発表されてませんが、同じぐらいになるかと思われます。なお、EC2とかを使えば時間制限はなくなりますが、ALBとか経由で実行するとドキュメントにはないが90分で切られるとかなんとか。
時間が厳しければ、通信時間を節約するためにあらかじめsigned URLを発行してS3にアップロードしてからそれを処理するみたいな方法もありますし、行ごとにqueueに入れてLambdaでファンアウトで処理するとかもありますが、登場人物が少なければデバッグも楽ですし、トラブルシュートもやりやすくなります。まあなんにせよ、制限はいたるところにあって、高速化すればよりシンプルな仕組みが選択できるようになり、運用は楽になりますし、コストまで安くなります。高速化は正義です。
COPY FROM?
PostgreSQLには高速にファイルの読み込みを行うCOPY FROMがあると聞きました。知らなかったので調べてみました。
COPY
と\COPY
がある。COPY
はDBサーバーのローカルファイルとのやりとり(COPY FROM
でテーブルへのローカルファイルからの読み込み、COPY TO
でテーブルからのローカルファイルへの書き込み)ができる- pg_dumpは内部で
COPY FROM/TO
を使っているらしい。COPY FROM STDIN
とかCOPY TO STDOUT
を使ってローカルにファイルを転送している? \COPY
はクライアント/サーバー間でも利用可能。INSERTを並べたSQLよりも11倍高速。INSERTをまとめて1つのトランザクションで処理するのと比べても3倍以上高速(この記事参照)
2種類あるけど特に使い分けとか考える必要はなさそうです。
GoとCOPY
by Renée French
GoのPostgreSQLドライバには2種類あります。
lib/pqとpgxはpgxの方がパフォーマンスが良いようですね。スター数はlib/pqの方が多いですが、pgxも少なくないです。
lib/pqにもCopyを使ったバルクインポート機能がありますし、pgxにもCOPYプロトコルサポートがありました。
実現方法はちょっと違っていて、pgxはdatabase/sql
のConn
を拡張した独自Conn
型を持っており(database/sql
のインタフェースの上位互換になっている)、そのConn
にCopyFrom()メソッドが生えています。lib/pqはPrepare/Execの標準インタフェースを活用する実装になっていました。
O/Rマッパーの中にはConnを完全にラップして、裏のConnを見せないようなライブラリもあったりする(gormとか?)のでその場合はlib/pqを使うとか、状況によって使い分けできそうですね。まあ、そもそもバッチでデータ一括で入れるなら本番コードとアーキテクチャを合わせたりO/Rマッパー使わなくてもいいと思うのでpgxをダイレクトに使う・・・とかでも良さそう。
試してみる(準備)
鳥貴族のページのアレルギーの情報のPDFをダウンロードしました。PythonとPoetryはインストール済みの前提で書きます。
poetry new conv-toriki |
スクリプトはこんな感じ
import tabula |
実行します。CSVファイルができるのでヘッダー行とかは手で除去します(自動化できるのかもしれませんが)。
poetry run python convert.py |
ついでにPostgreSQLもDockerで入れて、起動しておきます。
docker pull postgres:13.3 |
このコンテナのpsqlコマンドを起動してテーブルを作っておきます。
$ docker exec -it db psql -U pg -d toriki |
lib/pqでの利用例
CSVを読み込んでCopyで流し込むサンプルです。CopyIn()
の引数は、1つめがテーブル名、2つ目以降がカラム名です。絵文字はエラー箇所がわかる目印で入れています(log.SetFlag使うとサンプルがちょい長くなるので)。
stmt.ExecContext()
で各行の内容をどんどん追加してあげて、最後にstmt.Close()
で1つのリクエストで全行挿入ができました。内部実装追いかけてないですが、全部の内容がオンメモリにのっかるなら、数1000行ずつとかわけて実行した方が良いですかね。
package main |
pgxでの利用例
pgxはpgx.CopyFromSource
インタフェースをアプリ側で用意する必要があります。スライスなどからこのインタフェースを生成する便利関数もありますが、あらかじめ全部メモリに載っけるか、行数がわかっているかでないと使えないので、超大規模なデータ投入には向かない気がしました。なので、今回はcsv.Readerをラップしたインタフェースを自作してみました。内部的にもバイナリプロトコルで逐次で流していそうなので、全部がメモリに載せないで処理できそうな気がします(要追加検証)。
package main |
まとめ
ふだんはRDBをあまり使わない(なんかNoSQLが多い)ので、ちょっとウォームアップがてら調べてコードを書きました。DB特有機能ですが、DB乗り換えるとしてもINSERTに戻すのも苦ではないし、効果が高いし、バッチ処理でバルクでデータを入れる用途ならありなんじゃないかなと思います。lib/pqでもpgxでもどちらでも使えるのでアプリケーションで選択しるライブラリの種類のよらず恩恵はありそうです。
これで、特定アレルゲンが入っている食品とか、入ってない食品が簡単に検索できるようになりました。メガ金麦マジかよ・・・
# select menu from allergies where wheat=true; |
それはそうと、鳥貴族、アレルギー表が日本語だけじゃなくて英語版も用意されててすごいですね。あと、めちゃくちゃ良いのが小麦アレルギーの項目ごとの注釈。小麦がアレルギーだとしても発酵した醤油はOKな人はいるのですが、単に小麦だけ書かれると良いのか悪いのか迷うことがあります。で、厳しくNGにするとほとんどなにも外食できなくなってしまう。何度かアレルギーの持ちの人と一緒に外食するために店探しをしたりしましたが、これはかなり助かる情報です。他の外食業界の会社さんも真似して欲しい!
次は、宮崎さんの100%型安全なgolangORM「ent」を使ってみたです。