データベース技術の羅針盤(db tech showcase 2013)

Matsunobu Yoshinori (松信 嘉範)

2013.11.15

https://www.facebook.com/yoshinori.matsunobu

Agenda

1. データベース技術の変遷

2. クラウドや規模の違いは技術の選択にどんな影響を与えるか

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

リレーショナル・データベース

� 最も基本となるデータベース技術

� 製品ラインアップも非常に豊富

� 商用：Oracle, SQL Server, DB2, Sybase, …

� オープンソース: MySQL, PostgreSQL, Firebird, …

� 設計理論はどの製品でもほぼ使い回し可能

� テーブル設計/正規化, インデックス, SQL

� 製品特有のノウハウもある

– パーティション、特殊SQL構文など

� 運用管理は製品によって大きく異なる

� どれか1つに詳しければ、2個目以降の学習はより簡単にできる

� 細かく見ていくとアーキテクチャはかなり違う

� その違いが顕在化するのはある程度規模が大きくなってから

Oracle

� 言わずと知れた、最も売れているデータベース製品

� 機能の充実

�最近のMySQLやPostgreSQLで搭載されている機能は、2001年頃のOracle (8/8i)にはすでにあった

� 学習教材に恵まれている

�参考書

�認定試験

�有料トレーニングコースの種類が豊富

MySQL

� 世界で最も普及している、オープンソースのリレーショナル・データベース

� 特にWeb業界ではデファクトになっている

� ストレージエンジン： 複数のデータストアの中から選択可能 (クエリは同一)

� 2004年頃までの普及した理由：「同じく無料のPostgreSQLよりも高速だから」

� MyISAMストレージエンジン： クラッシュ時にデータが壊れる

– それを気にしない人たちが使っていた

� InnoDBの登場により、「壊れにくいデータベース(普通のデータベース)」となった

� その後様々な政治的問題を経て現在に至る(後述)

PostgreSQL

� オープンソースの高機能リレーショナル・データベース

� 日本では歴史的にコミュニティが強く、日本人コミッタも多数存在している

� 日本語ドキュメントも充実している

� Oracleとの互換性が高い

� PostgreSQL9からレプリケーションがサポートされ、Web系で使われるケースも増えてきた

� だが接続はプロセスベースなのでLL言語との相性は良くない

� Pgpoolなどコネクションプールを併用することが多い

MySQLとPostgreSQLの普及要因

� 無償で使える

�最も大きな普及要因

�必要に応じて有償サポートやコンサルを受けることができる

– MySQLの場合はオフィシャルベンダー (MySQL→Sun→Oracle)

やサードパーティー (Percona, SkySQL)から

– PostgreSQLの場合はサードパーティー (アシスト, SRAなど)から

MySQLの普及要因

� レプリケーションが古くからサポートされていた

� 1台が壊れても、残ったスレーブでサービスを継続できる (全データ消失は防げる)

� 高速

� スレッドベース

– 現在のハードウェアスペックであれば、25,000/s ~ 35,000/sくらいの接続が可能

– コネクションプーリングを使いづらい環境(LL言語)で圧倒的魅力

� ~2004: MyISAM時代

– コミット時同期書き込みをしないのでINSERTを大量に行っても高速

– トランザクションが無いなどの簡易性から、行あたりのスペース消費が少ない→ データサイズが小さい → キャッシュヒット率が高くなる →高価なメモリを有効に使える

� 主にWeb業界を中心に普及

PostgreSQLの普及要因

� 日本語のドキュメントが充実

� Oracle互換のSQL構文が多い

� Oracleを使っていたユーザが、より低コストなデータベースとして移行先を探す場合、MySQLよりも互換性が高いためPostgreSQLを選ぶことは多かった

� 同様のことが商用ツールベンダーにもあてはまった

� エンタープライズ業界(Oracleユーザの多い業界)や、商用ツールベンダーを中心にPostgreSQLを使う動きが多かった

FacebookはなぜMySQLを使っているか

� InnoDB Clustered Index

� 主キー検索を1回のランダムI/Oで完結することができる (低IOPS)

� InnoDB Compression

� データサイズを(多くのテーブルで)半分以下に減らすことができる

� MVCCとCovering Index

� セカンダリインデックス検索および範囲検索を1回のランダムI/Oで完結することができる

� 範囲検索の結果に一貫性がある

運用管理のための知識

� 稼働監視 - 接続できない等の大きな問題が無いかどうか確認し、問題があった場合にすぐ対処する

� 性能管理 - 性能の突発的ダウン/段階的ダウンなどを検知し短期的/長期的に対応する

� 容量管理 - データ量をチェックしてサーバ調達やデータ縮小化などの対処をする

� バックアップ - ある時点でのデータの複製を取る。これをオンラインで(サービスを止めずに)行うことが求められる

� リストア - 万一必要なデータを消してしまった時などにバックアップからデータを復旧する

� バージョンアップ - RDBMSのバージョンを上げる。互換性やクエリ実行計画などにも注意する必要がある

� フェイルオーバー - RDBMSがダウンした場合などに、同じデータを持っている別

のサーバに主系統を切り替える。データの整合性が取れているかどうか、データロストを許容するかどうかなど、確認すべき点が多く実際には難易度が高い

クラウドの台頭とAWS RDS

� Amazon本家による、RDBMSの運用代行サービス

� 現在はMySQL, Oracle, SQL Serverをカバー

� PostgreSQLもカバーされることが発表された

� 若干の割増料金でサービスを受けられる

� RDSを使わずに、EC2上で自前で運用することも可能

� RDBMSの運用周りの知識が無くても一定水準のサービスを運営できるようになった、という点で大きなマイルストーン

� 小規模環境ではもはやDBAやインフラエンジニアは不要に

NoSQLの台頭

� 2004年くらいから、リレーショナル・データベースがWebサービスで使いづらいと呼ばれるケースが散見されるようになった

� 1台のサーバで処理をしきれないケースが増えた

� SQL文そのものの負荷が無視できないケースが出てきた

�特殊なデータ構造を使いたいケースが増えた

�テーブル設計をしたくない人が増えた

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は困難

NoSQL台頭の背景 – SQLの負荷軽減

� 主キーのWHERE条件が違うだけの同一のクエリが、全体の大部分を占めるケースがある

� Mobageのユーザ管理テーブルや、mixiのログイン時刻管理テーブルなど

� いずれも主キーはユーザID

� ユーザIDを主キーとするテーブルは、テーブルサイズはそこまで大きくならない

� １レコード100バイトとして、3000万レコードで3GBにしかならない

� 全データがメモリに乗るのでCPUバウンドになる

� SQLがボトルネックになる → API一発で取れるNoSQLの方が高速

� 実はMySQLはストレージエンジンをNoSQLとして切り離して使うことができる

� InnoDB memcached plugin

� RDBMSとNoSQLのハイブリッド構成

SELECT * FROM user WHERE user_id= 10001234;

SELECT * FROM user WHERE user_id= 10002345;

SELECT * FROM user WHERE user_id= 10003456:

SELECT * FROM user WHERE user_id= 10004567;

SELECT * FROM user WHERE user_id= 10005678;

SELECT * FROM user WHERE user_id= 10006789;

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データ構造を使えば簡単に実現できる

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

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

� 重複値の多発による整合性問題への対処など、問題の先送りにしかならないことが多いので注意

� 容量が肥大化しやすい => コスト高になるので大規模環境で著しく優位性に欠ける

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

分析用途におけるRDBMSの課題

� 特定の「列」だけ扱えれば良いことが多いのに対して、RDBMSの処理単位は「行」

▪ 「列指向データベース」が分析用途ではより優れている

▪ 列単位の「圧縮」は効率が良いので、データサイズの削減にもつながる

DWHのトレンド

� 規模によってはRDBMSで代用できることもある

� SSDなどを使えば十分に高速にさばけて、実用に耐えられることも多い

� まずRDBMSで必要十分かどうかを検討してみると良い

� レンジパーティショニング必須

� 商用DWH

� Exadata, Vertica, Netezza, Paraccel, Greenplumなど様々なものがある

� 以前は商用DWH以外に選択肢が無かったこともあり非常に高価だった (1

億円レベル)

� オープンソースのDWHも登場してきた

� InfiniDB

– MySQLベースのストレージエンジン (MySQL本体側も改変している：特にオプティマイザ周り)

– 最新バージョンのInfiniDB 4で、全ての機能がオープンソースになった

Hadoopエコシステム(Hadoop+Hiveなど)

� Hadoop(HDFS)にデータを溜め、クエリインターフェイス(Hiveなど)で分析

� 昔のオープンソースみたく「安かろう悪かろう」だったが…

� 性能はだいぶ向上しつつある

– 主にクエリエンジンの出来が悪いことに起因。それが解決されつつある

Impala, Stinger, Presto

� 容量/性能などを踏まえると、商用DWHより高コストになることもある

� Hiveはデータがパーティション/テーブル単位でしか消せないなど。結果として容量が大きくなりやすい→高コスト

� バッチ処理に向いている

� 特にクラウド上ではバッチ処理との相性が非常に良い

– 必要な時だけマシンを割り当て、使い終わったら割り当て解除

– Amazon Elastic MapReduce (EMR)

� 従来型DWHとバッチHadoopのハイブリッド構成

� MapReduceでデータ変換→DWHにロード

AWS上でのデータウェアハウス: Redshift

� RDSのDWH版という位置づけ

� 2TBあたり、年間2000ドル~4000ドル(米国リージョンの場合)程度で使える

� 東京リージョンだと少し高いが、それでも月額数万円単位

� ほかのDWH PaaSや商用DWHのライセンス費用に比べてもずっと安い

� 運用支援機能が充実

� S3へのバックアップが自動かつ無料

� ソリューション/エコシステムも充実

� Elastic MapReduceによるバッチ処理→Redshiftにロード

� 地理的に離れたリージョンへのスナップショット・バックアップ

� FlyData – fluentdからのログ出力を数分間隔で耐障害機能つきでRedshiftにロード

事業規模と技術選択

事業規模は技術選択に影響を与えるか

� そもそも「規模」とはなにか

� トータルコスト (インフラコスト)

– ハードウェア費用、ソフトウェア費用

– 運用費、人件費

� 5台のDBサーバを4台にできることに、大きな価値を見出す経営層は少ない

� 機能の欠落を埋めるために必要なコスト > 効率化によって得られるコスト削減

� 「自動スケール」「多様なデータ型」など機能面がより重要になる

� 50000台を40000台にできるとしたら、そこには大きな価値がある

� 機能の欠落を埋めるために必要なコスト < 効率化によって得られるコスト削減

� 性能の高さ、消費容量の少なさなど、コスパ面がより重要になる

� 機能と性能は必ずしも両立しない

� 規模の変化に伴って、最適な技術も変わってくる

� 小規模でPostgreSQLやMongoDB、大規模でMySQLが使われる傾向にあるのは偶然ではない

クラウドと自前運用の違い

� AWSの月額料金総額が500万円を超えるくらいの規模感で、オンプレミスへの移行が検討される傾向にある

� http://gigaom.com/2013/10/10/amazon-web-services-should-you-stay-or-should-

you-go/

� 年間の料金が6000万円→ DBはそのうちの数割程度 → 1000万円強程度

– 頑張ってチューニングしても、人件費の穴埋めすら難しい

– 専任のDBAを雇う動機は少ない

– 専任のインフラエンジニアを雇うメリットもそれほど大きくは無い

� クラウドはハードウェアとネットワークがブラックボックスになる

� スペシャリストは生まれにくい土壌

� 大規模なサービス事業者(非クラウド)の中には、年間のサーバ費用が数億~数十億規模になるところもある

� 頑張ってチューニングすれば数億単位のコスト削減効果

– 専任のDBエンジニアを雇う動機になる

データベース技術とキャリア形成

� オールラウンドに複数のプロダクトを習得 (フルスタックエンジニア型)

� データベースだけでは食べていけない。インフラ/Webプログラミングなども幅広く習得が必要

� 就職先の選択肢が広がる

� 量産されやすいので給与が抑えられる傾向にある

� 特定のプロダクトの専門家 (スペシャリスト型)

� 就職先の選択肢が限定される

� ニーズが合った場合には好条件で働きやすい

� 専門技術が廃れると、その後のキャリアは悲惨なことになる

� プロダクトの鞍替えはできないわけではない (が回り道になる)

� MySQLからMongoDBのセールスエンジニアになった人もいる

� MySQLからClouderaのトレーニング講師になった人もいる

� Firebirdエキスパートだが、MySQLのサポートエンジニアとして採用された人もいる

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

製品の取捨選択

� RDBMSだけでも実にたくさんのラインアップがある

� Oracle、MSSQL、DB2

� MySQL、PostgreSQL、Firebird

� 特定の製品の中にも多数の要素技術がある

� MySQL: InnoDB、NDBCluster、TokuDB、…

� クラウド上での選択肢も増えた

� 全部勉強するのは現実的ではない

� 勝ち組と負け組が明らかに存在するように見えるので、それを見極めたい

�だが見極めは簡単ではない

先の無い技術やサービスを予測・回避する

� 当たり前の話だが、廃れ行く技術/製品/サービスに時間/費用をかけるのは損失

� 会社にとって：

– 軌道修正にかかるコスト

– 見る目が無い企業というイメージダウン

� エンジニアにとって：

– 時間を無駄にしてしまった分、技術面で伸び悩む

– 結果として給与が伸び悩む

� 先が無い技術を見極めることができれば：

� 余計なことに時間を使わなくて済む

� 先の無い技術を使う会社に転職するといった、キャリア上の大きな失敗を未然に防げる

先が無いことを見抜くのは難しい

� 「先が無い」とは誰も言ってくれない

� 興味の無いものに対してわざわざ情報発信してベンダーに喧嘩を売る動機は無い

� 結果として出回る情報はベンダー/メディア/お友達による大本営発表のみ– ポジティブなニュースしか出ない中で、ネガティブ性を判断しなくてはいけない

� 先が無い技術を選んで一番痛い目を見るのはその採用企業とエンジニア

� エンジニアは技術を蓄積していくもの。その蓄積にならない

� セールス・マーケ・マスコミなど非技術職の人にとっては別に痛くない

� 向上心を失ったエンジニアにとっても別に痛くはない

� 技術面以外の理由で先が無くなるケースが少なくない

� このような事情から、多くの人が有望だと言っている技術/製品/サービスが実はそうではなかった、ということがよくある

� 世の中の動向を見ながら、自分たちで判断するしかない

オープンソースRDBMSの歴史

� 2000年頃は、MySQLもPostgreSQLもたいして使い物にならなかったので、オープンソースデータベースの選択肢はほとんど無かった

� 商用データベースの独壇場

� Oracle、MSSQL、DB2だけでなくほかにもたくさんあった

� 2005年頃から、オープンソースデータベースの普及が浸透していった

� OracleはInnobaseを買収するなどして抵抗

� 商用データベースは低価格ラインアップを出して対抗。デフレの世界へ

� 2~3番手以降の商用データベースはほぼ廃れた

� MySQLまたはPostgreSQLが必要十分なものだということ、そして「価格優位性」が非常に重要なものだということを早くから見抜いていれば、この展開は予想できたはず

� 自分は2006年にMySQL ABに転職するという形で、自分なりの答えを出した

MySQLのフォーク/ストレージエンジンの歴史

� 2005年にOracleがInnobaseを買収

� これでInnoDBに先が無くなったと(MySQL社含め)多くの人が考え、多くのストレージエンジンが誕生

� Falcon、TokuDB、PBXT、Maria、RethinkDBなど。だが、どれもInnoDBほどの性能/品質には至らず

� 2008年にSunがMySQLを買収

� エンジニア個々人が好きなプロジェクトを始めだした

– MySQLのフォークデータベースとなるDrizzleの登場

� 2010年にOracleがSun/MySQLを買収

� これで突如としてInnoDBがデフォルトのストレージエンジンとして復活した

– 過去の歴史的経緯によって誕生した多数のトランザクション対応ストレージエンジンは、突如として先が無くなった

– 今も存在はしているものの、ほとんど誰も使っていない

� Drizzleチームは合併時に解雇された

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のマネージャとして転職

日本市場の特殊性� 2004年頃、世界ではMySQL >> PostgreSQLだったが、日本ではPostgreSQL >>

MySQLだった

� 日本ではPerlが大人気でPythonはあまり人気が無いが、世界ではその逆

� 自分はMHAというツールをPerlで書いてしまった (日本では普通の行為だが、世界では愚行)

� なぜこのようなことが起こるのか

� 日本語障壁

� 海外の有名技術者は、日本ではプレゼンスを発揮しづらい (母国語で伝えられない)

� 日本の有名技術者の方が目立つ = 影響力がある

� 海外の廉価製品/サービスが言葉の壁で普及しにくい= 高コストな製品/サービスが淘汰されずに残る傾向がある

� 地理的要因

� 海外の有名技術者は、年に1~2回来日できれば良い方

� OSSやプログラミング言語はコスト差が明確ではないので、身近で人気があるものを使う傾向にある

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本家は、規模の経済性を最大限に活かして低コストのメニューを提供するという方針

コスト意識とキャリア形成

� 著しく高価な製品/サービスを使っているユーザ企業が散見される

� そういう企業はエンジニアのキャリアを伸ばす場としてはあまり良くない� より安価な製品/サービスを使いこなす技術力を持ち合わせていない

� 会社(トップマネジメント)にコスト意識が乏しい

� だが中の人にとっては逆にチャンスでもある� Low-Hanging Fruit – 少ない労力で大きな成果(数百万~数億単位でのコスト削

減)を出せるチャンス

� その成果を武器に社内でのし上がっても良いし、社内で評価されなくても世の中には評価してくれる会社が必ずあるので転職しても良い

– 少なくともFacebookではこのような人材を募集しています

� 規模によって、適切なデータベース製品や使い方は変わってくる

� 小規模なうちは多機能データベース (オートスケール、多用なデータ型など)

– PostgreSQL, Redis, MongoDB

– RDSのような運用サービスも効果的

– このレベルの環境だと専任DBAや専任インフラエンジニアは不要なので、DBに限らず全方位的な技術の習得が必要

� 大規模になると省スペース・高性能データベース、そして自前運用

– MySQL, HBase

– ユーザ企業でスペシャリストが働けるとしたらこのような環境のみ

� ずっと同じデータベースを使い続けなければいけないわけではない

– むしろ同じものを使い続けるのは非現実的

– 小規模で使いやすいものは、往々にして大規模になると高コストになる

まとめ

� 製品やサービスの行く末を予想して選ぶ

� 「先の無い製品を選ぶ→廃れる→会社に負債が残りキャリアも無駄になる」は避けたい

– 会社も、自分自身も不幸になる

� ほとんどの場合「登場した時点では将来性があったが、本命の出現により先が無くなった」

– 即死するわけではなく、徐々に廃れていく

� 「競争力が無いが知名度だけはある」製品/サービスには要注意

� 「日本でのみ普及する」製品/サービスというものがある

– 日本語という障壁と地理的要因が主な理由

– 価格が高止まりしやすい → 長期的には淘汰される傾向に

� 「先が無い」ことは誰も言ってくれないので自分で判断するしかない

� AWSクラウド上では、AWS純製データサービス(RDS、Redshift等)と直接的に競合するサービスを使うリスクは非常に大きい

まとめ