一進一退

openbdのjson、coverageの全件読み込みに続いて、getで1000件ずつONIXの読み込み。千件までは問題なし。では、和書全件（83万件）行くかと思ったらタイムアウトに次ぐタイムアウト。もうなにやってもダメ。file_get_contentsじゃだめかとcurlも試すがやはりだめ。すっかりやる気も無くなり諦めかけたが、読み込むフィールドを絞り込んだらどうかと再挑戦。やはりだめ。再び諦めそうになるも、set_time_limitでどうにかならないかとすがってみる。なんと、読み込む量が増えたではないか。ということは時間伸ばせばいけるのか。根本的な解決ではないのはわかったうえでset_ti

me_limitをさらに増やしてみた。

読み込むじゃん。

ということで、ようやく、ISBN、タイトル、著者、発売日、出版社（ここまでsummaryから）、価格、内容紹介（短）、内容紹介（長）を一気にREPLACEできるようになった。よかった。しかし、これでタイムアウトということは、これ以上重い処理はどうなのか。不安。

ここで一旦PHPを書くのはやめて、テーブル設計を再考。単に検索や表示だけでなく、データのインポートまで含めて考える必要があるようだ。

一度に作成するのは諦めて、「ISBNと日付をDBにインポート」→「クエリーで近刊のみを抽出→千件ずつopenbdのJSONを読み込む」やり方に方向転換。cronで動かそう。

近刊のみの抽出のSQLではまる。なんで？　いや、近刊のみの抽出はできてる。問題は、千件ずつの切り分け。ああ、そうか、変数名を変えないとダメだ。あれだ、XMLでネストした時にハマった奴だ。

なんとか完成。

手順1.coverageで取得したISBNを千件ずつ切り分けてgetでjsonから抽出したpubdateと合わせてDBにインポート（約6分）

手順2.クエリーで近刊のみを抽出して千件ずつに分けgetでjsonから抽出した価格や内容紹介（長・短）と合わせて別のテーブルにインポート（約3秒）

件数少ないと速いなあ。そして、83万件全件だとフィールド数が多くても少なくてもそれほど時間は変わらなかった。全件インポートを高速化するには並列処理とかって話になりそう。だからpythonなのか。あと、GOとか。PHPでもできるんだろうか、並列処理。

ここまでで「openbdの全件データをインポート可能な状態」になった。何度でもやり直せる。来週の三連休でもっと進めたい。