1. データベース技術の羅針盤
(db tech showcase 2013)
Matsunobu Yoshinori (松信 嘉範)
2013.11.15
https://www.facebook.com/yoshinori.matsunobu

2. Agenda
1. データベース技術の変遷
2. クラウドや規模の違いは技術の選択にどんな影響を与えるか
3. 先の無い技術やサービスをどのように見極めるか

3. リレーショナル・データベース
最も基本となるデータベース技術
製品ラインアップも非常に豊富
商用：Oracle, SQL Server, DB2, Sybase, …
オープンソース: MySQL, PostgreSQL, Firebird, …
設計理論はどの製品でもほぼ使い回し可能
テーブル設計/正規化, インデックス, SQL
製品特有のノウハウもある
– パーティション、特殊SQL構文など
運用管理は製品によって大きく異なる
どれか1つに詳しければ、2個目以降の学習はより簡単にできる
細かく見ていくとアーキテクチャはかなり違う
その違いが顕在化するのはある程度規模が大きくなってから

4. Oracle
言わずと知れた、最も売れているデータベース製品
機能の充実
最近のMySQLやPostgreSQLで搭載されている機能は、
2001年頃のOracle (8/8i)にはすでにあった
学習教材に恵まれている
参考書
認定試験
有料トレーニングコースの種類が豊富

5. MySQL
世界で最も普及している、オープンソースのリレーショナル・データベース
特にWeb業界ではデファクトになっている
ストレージエンジン： 複数のデータストアの中から選択可能 (クエリは同一)
2004年頃までの普及した理由：「同じく無料のPostgreSQLよりも高速だから」
MyISAMストレージエンジン： クラッシュ時にデータが壊れる
– それを気にしない人たちが使っていた
InnoDBの登場により、「壊れにくいデータベース(普通のデータベース)」とな
った
その後様々な政治的問題を経て現在に至る(後述)

6. PostgreSQL
オープンソースの高機能リレーショナル・データベース
日本では歴史的にコミュニティが強く、日本人コミッタも多数存在している
日本語ドキュメントも充実している
Oracleとの互換性が高い
PostgreSQL9からレプリケーションがサポートされ、Web系で使われるケー
スも増えてきた
だが接続はプロセスベースなのでLL言語との相性は良くない
Pgpoolなどコネクションプールを併用することが多い

7. MySQLとPostgreSQLの普及要因
無償で使える
最も大きな普及要因
必要に応じて有償サポートやコンサルを受けることがで
きる
– MySQLの場合はオフィシャルベンダー (MySQL→Sun→Oracle)
やサードパーティー (Percona, SkySQL)から
– PostgreSQLの場合はサードパーティー (アシスト, SRAなど)から

8. MySQLの普及要因
レプリケーションが古くからサポートされていた
1台が壊れても、残ったスレーブでサービスを継続できる (全データ消失は
防げる)
高速
スレッドベース
– 現在のハードウェアスペックであれば、25,000/s ~ 35,000/sくらいの接続
が可能
– コネクションプーリングを使いづらい環境(LL言語)で圧倒的魅力
~2004: MyISAM時代
– コミット時同期書き込みをしないのでINSERTを大量に行っても高速
– トランザクションが無いなどの簡易性から、行あたりのスペース消費が
少ない→ データサイズが小さい → キャッシュヒット率が高くなる →高
価なメモリを有効に使える
主にWeb業界を中心に普及

9. PostgreSQLの普及要因
日本語のドキュメントが充実
Oracle互換のSQL構文が多い
Oracleを使っていたユーザが、より低コストなデータベースとして移行
先を探す場合、MySQLよりも互換性が高いためPostgreSQLを選ぶこ
とは多かった
同様のことが商用ツールベンダーにもあてはまった
エンタープライズ業界(Oracleユーザの多い業界)や、商用ツールベンダー
を中心にPostgreSQLを使う動きが多かった

10. FacebookはなぜMySQLを使っているか
InnoDB Clustered Index
主キー検索を1回のランダムI/Oで完結することができる (低IOPS)
InnoDB Compression
データサイズを(多くのテーブルで)半分以下に減らすことができる
MVCCとCovering Index
セカンダリインデックス検索および範囲検索を1回のランダムI/Oで
完結することができる
範囲検索の結果に一貫性がある

11. 運用管理のための知識
稼働監視 - 接続できない等の大きな問題が無いかどうか確認し、問題があった場
合にすぐ対処する
性能管理 - 性能の突発的ダウン/段階的ダウンなどを検知し短期的/長期的に対
応する
容量管理 - データ量をチェックしてサーバ調達やデータ縮小化などの対処をする
バックアップ - ある時点でのデータの複製を取る。これをオンラインで(サービスを
止めずに)行うことが求められる
リストア - 万一必要なデータを消してしまった時などにバックアップからデータを復
旧する
バージョンアップ - RDBMSのバージョンを上げる。互換性やクエリ実行計画など
にも注意する必要がある
フェイルオーバー - RDBMSがダウンした場合などに、同じデータを持っている別
のサーバに主系統を切り替える。データの整合性が取れているかどうか、データ
ロストを許容するかどうかなど、確認すべき点が多く実際には難易度が高い

12. クラウドの台頭とAWS RDS
Amazon本家による、RDBMSの運用代行サービス
現在はMySQL, Oracle, SQL Serverをカバー
PostgreSQLもカバーされることが発表された
若干の割増料金でサービスを受けられる
RDSを使わずに、EC2上で自前で運用することも可能
RDBMSの運用周りの知識が無くても一定水準のサービスを運営できる
ようになった、という点で大きなマイルストーン
小規模環境ではもはやDBAやインフラエンジニアは不要に

13. NoSQLの台頭
2004年くらいから、リレーショナル・データベースがWebサービ
スで使いづらいと呼ばれるケースが散見されるようになった
1台のサーバで処理をしきれないケースが増えた
SQL文そのものの負荷が無視できないケースが出てきた
特殊なデータ構造を使いたいケースが増えた
テーブル設計をしたくない人が増えた

14. NoSQL台頭の背景 - 複数台のサーバとの相性
ある程度ヒットしたサービスになると、1台のサーバには必要なデータが乗り切らな
い
32bit OS時代： 2GB RAM + 20~40GB HDD
64bit OS時代：16GB RAM + 100~150GB HDD
SSD時代：8~64GB RAM + 200~400GB SSD
ヒットサービスでは1TBを超えるデータ量は普通
複数台にデータを分散することが定番となった – Sharding
複数のサーバにまたがったJOINを行うことは基本的にできない
RDBMSのメリットが大きく失われることになった
ShardingをサポートしたNoSQLが注目を集めるようになった
MongoDB, HBase, MySQL Cluster
多くの大規模サイトでは相変わらずMySQL(InnoDB)をアプリロジックでShardingして
使っている
Shardingは簡単
Re-Shardingは困難

15. NoSQL台頭の背景 – SQLの負荷軽減
SELECT * FROM
SELECT * FROM
SELECT * FROM
SELECT * FROM
SELECT * FROM
SELECT * FROM
user WHERE user_id= 10001234;
user WHERE user_id= 10002345;
user WHERE user_id= 10003456:
user WHERE user_id= 10004567;
user WHERE user_id= 10005678;
user WHERE user_id= 10006789;
主キーのWHERE条件が違うだけの同一のクエリが、全体の大部分を占めるケ
ースがある
Mobageのユーザ管理テーブルや、mixiのログイン時刻管理テーブルなど
いずれも主キーはユーザID
ユーザIDを主キーとするテーブルは、テーブルサイズはそこまで大きくならない
１レコード100バイトとして、3000万レコードで3GBにしかならない
全データがメモリに乗るのでCPUバウンドになる
SQLがボトルネックになる → API一発で取れるNoSQLの方が高速
実はMySQLはストレージエンジンをNoSQLとして切り離して使うことができる
InnoDB memcached plugin
RDBMSとNoSQLのハイブリッド構成

16. NoSQL台頭の背景 – 特殊なデータ構造
ソーシャルゲームのリアルタイム・ランキング
動画の新着100件
従来型RDBMSで管理しようとすると “score”, “user_id”に対して
SELECT COUNT(user_id) FROM rank WHERE score > my_score;
これはO(N)であり規模の増加に対してスケールしない
RedisのSorted Setsデータ構造を使うと、O(logN)でスコアを得ることがで
きる
動画の新着100件はRedisのListデータ構造を使えば簡単に実現できる

17. NoSQL台頭の背景 – テーブル設計をしたくない

18. NoSQL台頭の背景 – テーブル設計をしたくない
重複値の多発による整合性問題への対処など、問題の先送りにしかならないことが
多いので注意
容量が肥大化しやすい => コスト高になるので大規模環境で著しく優位性に欠ける

19. データウェアハウス (DWH)

20. 分析用途におけるRDBMSの課題
特定の「列」だけ扱えれば良いことが多いのに対して、RDBMSの処理単位は「行」
▪
「列指向データベース」が分析用途ではより優れている
▪
列単位の「圧縮」は効率が良いので、データサイズの削減にもつながる

21. DWHのトレンド
規模によってはRDBMSで代用できることもある
SSDなどを使えば十分に高速にさばけて、実用に耐えられることも多い
まずRDBMSで必要十分かどうかを検討してみると良い
レンジパーティショニング必須
商用DWH
Exadata, Vertica, Netezza, Paraccel, Greenplumなど様々なものがある
以前は商用DWH以外に選択肢が無かったこともあり非常に高価だった (1
億円レベル)
オープンソースのDWHも登場してきた
InfiniDB
– MySQLベースのストレージエンジン (MySQL本体側も改変している：特
にオプティマイザ周り)
– 最新バージョンのInfiniDB 4で、全ての機能がオープンソースになった

22. Hadoopエコシステム(Hadoop+Hiveなど)
Hadoop(HDFS)にデータを溜め、クエリインターフェイス(Hiveなど)で分析
昔のオープンソースみたく「安かろう悪かろう」だったが…
性能はだいぶ向上しつつある
– 主にクエリエンジンの出来が悪いことに起因。それが解決されつつある
Impala, Stinger, Presto
容量/性能などを踏まえると、商用DWHより高コストになることもある
Hiveはデータがパーティション/テーブル単位でしか消せないなど。
結果として容量が大きくなりやすい→高コスト
バッチ処理に向いている
特にクラウド上ではバッチ処理との相性が非常に良い
– 必要な時だけマシンを割り当て、使い終わったら割り当て解除
– Amazon Elastic MapReduce (EMR)
従来型DWHとバッチHadoopのハイブリッド構成
MapReduceでデータ変換→DWHにロード

23. AWS上でのデータウェアハウス: Redshift
RDSのDWH版という位置づけ
2TBあたり、年間2000ドル~4000ドル(米国リージョンの場合)程度で使える
東京リージョンだと少し高いが、それでも月額数万円単位
ほかのDWH PaaSや商用DWHのライセンス費用に比べてもずっと安い
運用支援機能が充実
S3へのバックアップが自動かつ無料
ソリューション/エコシステムも充実
Elastic MapReduceによるバッチ処理→Redshiftにロード
地理的に離れたリージョンへのスナップショット・バックアップ
FlyData – fluentdからのログ出力を数分間隔で耐障害機能つきで
Redshiftにロード

24. 事業規模と技術選択

25. 事業規模は技術選択に影響を与えるか
そもそも「規模」とはなにか
トータルコスト (インフラコスト)
– ハードウェア費用、ソフトウェア費用
– 運用費、人件費
5台のDBサーバを4台にできることに、大きな価値を見出す経営層は少ない
機能の欠落を埋めるために必要なコスト > 効率化によって得られるコスト削減
「自動スケール」「多様なデータ型」など機能面がより重要になる
50000台を40000台にできるとしたら、そこには大きな価値がある
機能の欠落を埋めるために必要なコスト < 効率化によって得られるコスト削減
性能の高さ、消費容量の少なさなど、コスパ面がより重要になる
機能と性能は必ずしも両立しない
規模の変化に伴って、最適な技術も変わってくる
小規模でPostgreSQLやMongoDB、大規模でMySQLが使われる傾向にあるの
は偶然ではない

26. クラウドと自前運用の違い
AWSの月額料金総額が500万円を超えるくらいの規模感で、オンプレミスへの移
行が検討される傾向にある
http://gigaom.com/2013/10/10/amazon-web-services-should-you-stay-or-shouldyou-go/
年間の料金が6000万円→ DBはそのうちの数割程度 → 1000万円強程度
– 頑張ってチューニングしても、人件費の穴埋めすら難しい
– 専任のDBAを雇う動機は少ない
– 専任のインフラエンジニアを雇うメリットもそれほど大きくは無い
クラウドはハードウェアとネットワークがブラックボックスになる
スペシャリストは生まれにくい土壌
大規模なサービス事業者(非クラウド)の中には、年間のサーバ費用が数億~数十
億規模になるところもある
頑張ってチューニングすれば数億単位のコスト削減効果
– 専任のDBエンジニアを雇う動機になる

27. データベース技術とキャリア形成
オールラウンドに複数のプロダクトを習得 (フルスタックエンジニア型)
データベースだけでは食べていけない。インフラ/Webプログラミング
なども幅広く習得が必要
就職先の選択肢が広がる
量産されやすいので給与が抑えられる傾向にある
特定のプロダクトの専門家 (スペシャリスト型)
就職先の選択肢が限定される
ニーズが合った場合には好条件で働きやすい
専門技術が廃れると、その後のキャリアは悲惨なことになる
プロダクトの鞍替えはできないわけではない (が回り道になる)
MySQLからMongoDBのセールスエンジニアになった人もいる
MySQLからClouderaのトレーニング講師になった人もいる
Firebirdエキスパートだが、MySQLのサポートエンジニアとして採用
された人もいる

28. 先の無い技術やサービスをどのように見極めるか

29. 製品の取捨選択
RDBMSだけでも実にたくさんのラインアップがある
Oracle、MSSQL、DB2
MySQL、PostgreSQL、Firebird
特定の製品の中にも多数の要素技術がある
MySQL: InnoDB、NDBCluster、TokuDB、…
クラウド上での選択肢も増えた
全部勉強するのは現実的ではない
勝ち組と負け組が明らかに存在するように見えるので、
それを見極めたい
だが見極めは簡単ではない

30. 先の無い技術やサービスを予測・回避する
当たり前の話だが、廃れ行く技術/製品/サービスに時間/費用をかけるの
は損失
会社にとって：
– 軌道修正にかかるコスト
– 見る目が無い企業というイメージダウン
エンジニアにとって：
– 時間を無駄にしてしまった分、技術面で伸び悩む
– 結果として給与が伸び悩む
先が無い技術を見極めることができれば：
余計なことに時間を使わなくて済む
先の無い技術を使う会社に転職するといった、キャリア上の大きな失
敗を未然に防げる

31. 先が無いことを見抜くのは難しい
「先が無い」とは誰も言ってくれない
興味の無いものに対してわざわざ情報発信してベンダーに喧嘩を売る動機は無い
結果として出回る情報はベンダー/メディア/お友達による大本営発表のみ
– ポジティブなニュースしか出ない中で、ネガティブ性を判断しなくてはいけない
先が無い技術を選んで一番痛い目を見るのはその採用企業とエンジニア
エンジニアは技術を蓄積していくもの。その蓄積にならない
セールス・マーケ・マスコミなど非技術職の人にとっては別に痛くない
向上心を失ったエンジニアにとっても別に痛くはない
技術面以外の理由で先が無くなるケースが少なくない
このような事情から、多くの人が有望だと言っている技術/製品/サービスが
実はそうではなかった、ということがよくある
世の中の動向を見ながら、自分たちで判断するしかない

32. オープンソースRDBMSの歴史
2000年頃は、MySQLもPostgreSQLもたいして使い物にならなかったので、
オープンソースデータベースの選択肢はほとんど無かった
商用データベースの独壇場
Oracle、MSSQL、DB2だけでなくほかにもたくさんあった
2005年頃から、オープンソースデータベースの普及が浸透していった
OracleはInnobaseを買収するなどして抵抗
商用データベースは低価格ラインアップを出して対抗。デフレの世界へ
2~3番手以降の商用データベースはほぼ廃れた
MySQLまたはPostgreSQLが必要十分なものだということ、そして
「価格優位性」が非常に重要なものだということを
早くから見抜いていれば、この展開は予想できたはず
自分は2006年にMySQL ABに転職するという形で、自分なりの答えを
出した

33. MySQLのフォーク/ストレージエンジンの歴史
2005年にOracleがInnobaseを買収
これでInnoDBに先が無くなったと(MySQL社含め)多くの人が考え、多くのス
トレージエンジンが誕生
Falcon、TokuDB、PBXT、Maria、RethinkDBなど。だが、どれもInnoDBほど
の性能/品質には至らず
2008年にSunがMySQLを買収
エンジニア個々人が好きなプロジェクトを始めだした
– MySQLのフォークデータベースとなるDrizzleの登場
2010年にOracleがSun/MySQLを買収
これで突如としてInnoDBがデフォルトのストレージエンジンとして復活した
– 過去の歴史的経緯によって誕生した多数のトランザクション対応ストレー
ジエンジンは、突如として先が無くなった
– 今も存在はしているものの、ほとんど誰も使っていない
Drizzleチームは合併時に解雇された

34. MySQLエンジニアのキャリアへの影響例
Drizzleチームのメンバーの場合
Oracleによる解散後、Rackspace社がチームごと採用した
1年強経った後、RackspaceもDrizzleのスポンサーを終了→解雇
一部の人はPerconaに、一部はHPに移籍し、今は別のことをやっている
自分の場合
Falconの技術検証に200時間くらいは費やした → 無駄になった
途中でInnoDBとの技術的格差に気づいてフェードアウトしたので、致命
傷にはならずに済んだ
Falconのチームマネージャの場合
2008年頃(Oracleによる買収前)、InnoDBの素晴らしさに気づいてOracle
に転職、InnoDBチームマネージャに
OracleによるSun買収後もInnoDBチームのマネージャを継続
2013年にTwitterのDatabase Engineeringのマネージャとして転職

35. 日本市場の特殊性
2004年頃、世界ではMySQL >> PostgreSQLだったが、日本ではPostgreSQL >>
MySQLだった
日本ではPerlが大人気でPythonはあまり人気が無いが、世界ではその逆
自分はMHAというツールをPerlで書いてしまった (日本では普通の行為だが、世
界では愚行)
なぜこのようなことが起こるのか
日本語障壁
海外の有名技術者は、日本ではプレゼンスを発揮しづらい (母国語で伝えられな
い)
日本の有名技術者の方が目立つ = 影響力がある
海外の廉価製品/サービスが言葉の壁で普及しにくい= 高コストな製品/サービス
が淘汰されずに残る傾向がある
地理的要因
海外の有名技術者は、年に1~2回来日できれば良い方
OSSやプログラミング言語はコスト差が明確ではないので、身近で人気があるものを
使う傾向にある

36. AWS上のSaaS/PaaSサービスの歴史
(EC2上で自分自身で運用する場合は、オンプレミスの場合と同様に考えれば良い)
RDBMSのPaaSの歴史
Xeround など複数の企業が、AWS上でMySQLベースの運用サービスを提供
2009年にAWSからRDSが登場。RDSの方が安いので皆RDSに (コストメリット)
2013年に、Xeroundはサービスを終了した
– 直前まで資金調達していて、機能もRDSより豊富だったにも関わらず終了した
DWHのPaaSの動向
クラウド上でDWHの運用サービスを展開するPaaS事業者がいくつか登場
2013年にAWSからRedshiftが登場。Redshiftが非常に安いので皆Redshiftに
SaaS/PaaSサービスは、AWS本家が同等のサービスを提供した場合にどうなるか
AWSのインフラを使っているため、オープンソースベンダーのようには価格優位
性を提供できない
– AWS本家は、規模の経済性を最大限に活かして低コストのメニューを提供す
るという方針

37. コスト意識とキャリア形成
著しく高価な製品/サービスを使っているユーザ企業が散見さ
れる
そういう企業はエンジニアのキャリアを伸ばす場としてはあまり
良くない
より安価な製品/サービスを使いこなす技術力を持ち合わせていない
会社(トップマネジメント)にコスト意識が乏しい
だが中の人にとっては逆にチャンスでもある
Low-Hanging Fruit – 少ない労力で大きな成果(数百万~数億単位でのコスト削
減)を出せるチャンス
その成果を武器に社内でのし上がっても良いし、社内で評価されなくても世の中
には評価してくれる会社が必ずあるので転職しても良い
– 少なくともFacebookではこのような人材を募集しています

38. まとめ
規模によって、適切なデータベース製品や使い方は変わってくる
小規模なうちは多機能データベース (オートスケール、多用なデータ型など)
– PostgreSQL, Redis, MongoDB
– RDSのような運用サービスも効果的
– このレベルの環境だと専任DBAや専任インフラエンジニアは不要なので
、DBに限らず全方位的な技術の習得が必要
大規模になると省スペース・高性能データベース、そして自前運用
– MySQL, HBase
– ユーザ企業でスペシャリストが働けるとしたらこのような環境のみ
ずっと同じデータベースを使い続けなければいけないわけではない
– むしろ同じものを使い続けるのは非現実的
– 小規模で使いやすいものは、往々にして大規模になると高コストになる

39. まとめ
製品やサービスの行く末を予想して選ぶ
「先の無い製品を選ぶ→廃れる→会社に負債が残りキャリアも無駄になる
」は避けたい
– 会社も、自分自身も不幸になる
ほとんどの場合「登場した時点では将来性があったが、本命の出現により
先が無くなった」
– 即死するわけではなく、徐々に廃れていく
「競争力が無いが知名度だけはある」製品/サービスには要注意
「日本でのみ普及する」製品/サービスというものがある
– 日本語という障壁と地理的要因が主な理由
– 価格が高止まりしやすい → 長期的には淘汰される傾向に
「先が無い」ことは誰も言ってくれないので自分で判断するしかない
AWSクラウド上では、AWS純製データサービス(RDS、Redshift等)と直接的
に競合するサービスを使うリスクは非常に大きい