20142014年12月12日金曜日libpqxxを使ってみた。枠が空いていたので、2回目の飛び込みをしてみました。昨日はnuko_yokohamaさんのjsqueryを使ってみたでした。普段わたしはウェブアプリをPHPで作っていて、そこからPostgreSQLへアクセスするのですが、バッチ処理やループ処理などはCやC++で書くことがあります。前までは、C言語でバッチ処理を書いていて、ecpgを使った埋め込みSQLを使っていました。AIXでDB2を使っていた経験があり、その延長で埋め込みSQLは便利だなと思っていたのです。複雑なことをするに従って、また他のライブラリの都合などもあり、徐々にC++に移行してきました。さんのスライドにもあったように、C++でecpgを使うのは、ちょっと微妙です。完全対応では無いので、何か問題が発生したときに切り分けで嵌まりそうです。そこで、libpqxxという、C++ライブラリを使ってみました。http://pqxx.org/development/libpqxx/現在、最新バージョンとしては4.0.1が公開されています。開発版のスナップショットも公開されています。4.0.1はリリースが古く、それからちょこっと修正も入っているので、こちらの方がいいかなと思います。コードは、とてもシンプルです。コネクションやトランザクション、結果などそれぞれがオブジェクトになるので、簡単にアクセスできます。endl;}更新でも同じ流れです。));tran.commit();quoteだけではなく、ちゃんとプリペアドステートメントも使えます。endl;}tran.commit();プリペアドステートメントはデータベースコネクションへ登録、実際のステートメントはトランザクションからtran.prepared(ステートメント名)($1)($2)・・・.exec()という形式で呼び出します。嵌まりどころがなくて、拍子抜けするぐらいです。int型を使おうとするには、includeファイルの定義を変更したりする必要があったのですが、今のバージョンでは不要です。#pgcon14jでした。PostgreSQLへ移行しました。一昨日ぐらいに全データを移し終わったところです。RDS内部のソフトウェア的なところは、これまでも他の方の記事にあったので、スペック部分に的を当てて書いてみたいと思います。それまでは、自宅サーバでよく使うデータやインデックスだけをSSD上のテーブルスペースに置き、あまり参照されないデータなどをHDD上のテーブルスペースで運用していました。今年の5月からVPSのSSDプランを借り、よく使うデータやインデックスだけをVPSのSSDに置いて、残りのデータを自宅サーバに置き、postgresql_fdwで自宅サーバに繋いで利用していましたが、いろいろ問題点が溜まってきました。ふぁぼ収集サービスのつらみより気がついたら、コードを書くよりインフラのメンテナンス作業の方に時間を多く取られていることに気がつきました。障害を克服する楽しさが無いとは言いませんが、ソフトウェアでやりたいことが溜まっていくのに、なかなか手がつけられません。ストレスが溜まります。PostgreSQLに移行しました。2000GB最終的に、上記の構成になりました。IOPSにして利用しようと考えていました。100GBの構成でテストしてみたり、料金計算ツールでなんとか払える範囲であることを確認したり・・・。最小構成で動くことを確認し、あとは本番用サーバを建てようとしたところ、なにやらエラーが。趣味に使える金額ではありません。IOPSからだったのに・・・。考えてみると、EC2のEBSはサイズが1TBまででしたので(2014年11月に16TBまでの拡張が発表されました)、3TBまで使えるRDSは内部でEBSを束ねているのだろうと考えられます。(SSD)でも、ボリュームサイズが大きければ、単体ディスクの時よりスピードが出るのではないか?動かしてみた。IOPS程度出ています。IOPS用の最適化なしという条件で、コア数的には自宅サーバやVPS時代と比べて劣っているのですが、ディスクが高速なおかげで、全く遜色を感じません。こんなことなら、もっと早く移行しておくべきでした。いうことで、速度も巨大ストレージも欲しているデータベースは、RDSでも幸せに運用できるのではないかと思います。2014年12月現在、3TBまでですが、これもEBSの拡大に合わせて大きくできるのではないかと期待しています。ここまで書いておいて、これ単純にAWSの話で、PostgreSQL関係なくね?と気がついたので、やっぱりソフトウェア的な話も。絡めるか、また自宅サーバで1.7TBほどディスクを使っているデータベースをどうやって移行するかが悩みどころでした。AWSから出ていくデータには大きなデータ転送量が掛かってしまうため、AWSのサービスを使い始めたら最後、日常的に参照以外でデータをまとめて取り出すことは考えない方がいいでしょう。して、それまで組んでいた「よく使うデータはインターネット側、あまり使わない古いデータは自宅サーバ」という構成は諦めることにしました。全てのデータを1台のサーバで運用するのは、それまで自宅サーバだけの時代に経験しているので、あとは移行方法です。動かしたまま移行したいと考えていたところ、タイミング良く11月の更新で移行ツールのサポートが発表されました。リードレプリカ、9.3.5のサポート、データ移行、3つの新しい拡張モジュールLondisteというツールでレプリケーションを組むことで、マスターサーバからデータを送りつける感じ?でコピーを作成するようです。検証環境を組んでLondisteを使ってみようとしたのですが、上手く行かない。wikiには2.xの説明しかありません。3.xではコマンド体系が変わっているようで、なんとか付属のドキュメントを読みつつ試してみたのですが、全く動きそうなところにも持って行けませんでした。この時点でVPSでの運用ができなくなり、自宅サーバに戻って速度の出ないディスクを前に未処理のデータが溜まり続けるという前にも後ろにも進めないような状況に陥ってしまいました。「早く標準のストリーミングで移行できるようにしてくれ」と願っている時間もなく、RDSの仕組みを見る限り、ターミナルにログインしてpg_basebackupコマンドを叩けるような構成では無さそうです。仕方なく、オーソドックスなpg_dump、psqlの組み合わせで移行しました。データベース作成には、LC_COLLATE、LC_CTYPEの設定が必要だったため、既存のデータベースの削除と、テーブルスペース作成・データベースの作成までは先に済ませます。-1;続いて元のサーバからデータのエクスポートRDSでは、rdsadminユーザーがSUPERUSER権限を持ち、サーバを建てた時点で作られているユーザーにはrds_superuserという権限が与えられています。postgres;単純にpg_dumpでデータを出力すると、テーブルの権限を設定する部分で警告が出まくります。--no-ownerオプションをつけて、ログインユーザーで作成します。[database]これでテーブルを作成し、あとは必要なデータからコピーしていくという流れで移行しました。本格的な運用はまだこれからですが、とりあえずtextsearch_jaを使っていた処理をどうしようかなぁ、というところです。サーバ側でカスタマイズは難しそうなので、postgresql_fdwみたいな感じで、postgresql_RPCとかできると良さそうですね。東京で3日間Wi2を使ってみた。SIM無しNexus5で東京に行かねばならない。3GモバイルからOCNモバイルONEに切り替えた都合で余った標準SIM。標準SIMをMicroSIMに切って使うか?と思ったのですが、So-netのSIMは、破損してたり返さないと3000円払ってもらうよと書かれています。プロバイダによっては請求されないらしいのですが、値段まで書いてある以上、数日東京に行くために3000円払うのは、b-mobile契約するのと変わらないし、勿体ないなという気持ちが働きました。そこで目を付けたのがWi2。わたしは大阪に住んでいますが、ちょくちょく無線LANアクセスポイントに表れるWi2。ときどきパスワードの掛かっていないアクセスポイントがあるのですが、繋いでみてもWi2の契約をしないとネットには繋げないようで、基本的には邪魔な存在でした。モバイル接続が無い状態とあれば話は別。アクセスポイントの位置を確認すると、結構広範囲で、駅だとまず使えそうです。今回は新宿あたりへ行くので、その付近も確認。