2016年9月9日金曜日

Database Lounge Tokyo #2 に参加しました

Database Lounge Tokyo #2 に参加しました。
今回はバックアップ回で、きっとメインのパネルディスカッションは壮絶な感じなんだろうなーと誰もが予感していたと思いますが、ネタとしては基本中の基本の範囲でカバーしておくべきでもあり、データベースに関わる人すべてが(少なくとも自分が触っているデータベースに関して)きちんと理解しているべき内容です。
というわけで、弊社の新人ちゃんも誘って参加してみました。

イベントの流れは、Lighting Talksがババッとあって、その後、バックアップ・リカバリ観点でのOracle DB、PostgreSQL、MySQLの比較の話と、それを肴にパネルディスカッション。
イベントページで録画や発表資料が公開されると思うので、現時点では記憶を頼りにザザっと書いています。ゆるっと追記・修正していく予定。

■Lighting Talks


・ 「差分、増分、デルタ(って何?) バックアップあれやこれや」 by @meijik


firebirdやMySQLでのバックアップ手法について。
特に差分や増分というデータベース製品によって意味するところが異なるキーワードを解説されていました。今日の一発目として、基本のおさらいだったり、知らない人的には「ほー」っと言う感じ。アーカイブ(トランザクションログ)を適用する話がそもそも増分と呼ばれていたり、文化の違いを感じる。

・「Postgresはグラフデータベースの夢を見るか?」 by @nuko_yokohama


グラフデータベース neo4j を PostgreSQL のインターフェース で扱っちゃう話。
PostgreSQLではロジカルデコーディングという、論理WALを吐くことができるので、PostgreSQLに対して実行したクエリを別のデータベースに伝えて実行させることが可能である。それを受信する側の機構を自作する必要があるが。今回は論理WALをjson型に変換→Cypherクエリ→REST APIでneo4jに突っ込む。
データを参照する方はneo4j_fdwで。PostgreSQLはForeign Data Wrapperという、外部データソースからデータを取ってくる(実装によっては更新も可)基盤があるが、データソース、今回で言うとNeo4jに対応したものを作らないといけない。と思ったら、以前にぬこさん自身が作ったものが公式Wikiにまで掲載されいている!

・「An intelligent storage?」 by @kkaiga


実は運営などバタバタしていて全然聞けなかった。。。
GPUの超メニーコアを使った高速化をやり続けている海外さんの取り組み。フラッシュ上に配置したデータを、CPUがちょろちょろGPUに渡しているとCPUがボトルネックになってしまうので、直接渡せると嬉しいよね!という話(だったと思う。資料が公開されたらちゃんと読む。)

・「ポスグレのバックアップでやらかした話 (˚இ˚) 」 by @kkkida_twtr


僭越ながら発表させていただきました。弊社では、取り扱う製品を自分たちで使ってみて、酸いも甘いも経験して、ちゃんとノウハウを得てからサービス提供してるんですよ!という美しいお話でした。(ウソ)
バックアップ取得先の容量管理とか、シェルのロジックとかの問題で、消し込みがうまく回らずPostgreSQLのアーカイブ領域が埋まる→新規のWALが書けずにDB停止、というのを実際にやっちゃうと運用担当者(俺)がパニくるんですよ。とか。VACUUM FULLの後にVACUUMやってるから意味無くね?って言ってコメントアウトしてみたらANALYZE止めちゃって本来5分のクエリが2時間かかったとか。そんな情けない話でも共有してみんなを救いたい!っていう健気な俺ちゃんのゆるふわな発表でした。

■メインテーマ


・ 「バックアップと障害復旧から考えるOracle Database, MySQL, PostgreSQLの違い」 @wrcsus4


実はお仕事などバタバタしていてあんまり聞けなかった。。。
各データベースのオンラインバンクアップ(アーカイブ運用とか、ポスグレ界でいうところのPITR前提の取り方)について比較し、酔った勢いでMySQLを変わり者と評する感じの流れw。と思いきや、早々にマサカリが飛びかっていることをtwitterで知りあわてて会場に戻りましたw
途中をいろいろ端折って抱いたイメージは、MySQLはOra、Posの当たり前が通用しないけど、論理バックアップにログを適用して最新に追いつけるよ?的な?それはそれで便利そうではある。(取る人は楽ちん、戻す人は大変そうだけど。)
これも資料公開されたらちゃんと勉強する。と思ったけど↑は本題ではないようだwマサカリおそろしいwww

・ディスカッション@wrcsus4 @yoku0825 @kasa_zip @kumagi


テーマが5個ぐらいあったけどメモれず。こういう用途でどんな方法でバックアップ取るか、どう戻すか、みたいなパターンがいくつか。
印象的だったのは、MySQLはスレーブから戻すケースが多くて、「死んだノードで整合性を保った状態で復旧せよ」みたいな問題を考えるほうが珍しいということ。
あとは、PostgeSQLで長年疑問に思っていた、「トランザクション位置を指定したPITRって需要どんだけあるんだろうか?」に対して「普通xid記録してないよね。」ということが分かった。収穫。

全体的に、新たに知ったことや、へーっと思ったことは記憶に残ってるのでMySQLのメモが多いが、PostgreSQLやOracleについてももちろんたくさん話がでていました。総じて両者は似ている。フラッシュバック憧れる。(どれだけ使うかは別として。)
そして@kumagiさんの容赦ない切り口。いろんな経験の人がしゃべってるの面白いなーと思いました。


■その他

今回は、弊社で会場提供して、その活動報告を弊社の広報ブログで取り上げる予定です。
そのために皆さんにも写真撮影にご協力いただきました。きっとキャッキャウフフした感じが撮れていると思いますので、記事の公開を楽しみにしておいてください。

次のテーマは「トランザクション」とのこと。
学術的な方面の人たちがフィーバーしてそうで今から楽しみです。

0 件のコメント:

コメントを投稿

PostgreSQL11のJITコンパイリングを試す

llvm-postgres 開発中のPostgreSQL11でJIT(Just In Time=実行時)コンパイリングを行い、クエリ性能の高速化を期待する新機能が登場した。 本記事では 構築方法を確認したので紹介。JITコンパイ...