NoSQL勉強会

NoSQL徹底解剖

2012年9月13日

株式会社シーエー・アドバンス
大谷祐司

Copyright © 2012 CAADvance, Inc. All Rights Reserved. 1

まずは自己紹介


大谷祐司（おおたにゆうじ）

--------------------------------------

株式会社シーエー・アドバンス技術責任者。
技術大好き、プログラム大好きです。

山口県下関市出身で、大学時代から東京在住。
9月16日で32歳になります。

趣味はコンピュータ関連全般と
プログラミング、そして車です。


本日のアジェンダ

① シーエー・アドバンスとNoSQL

② NoSQLについてのおさらい

③ NoSQLの特徴

④ CAP定理について

⑤ シーエー・アドバンスで検証したNoSQLの

紹介

⑥ 最後に


① シーエー・アドバンスとNoSQL


シーエー・アドバンスってどんな会社？

2008年に、サイバーエージェントの子会社として設立。

インターネットメディアや広告の運用に関連する事業を中心に
行っている会社です。

従業員数は約300人で、東京と沖縄に事業所があります。
(東京約50名、沖縄約250名)

私も毎月沖縄出張しています(オフィスとホテルの往復です
が・・・)


シーエー・アドバンスってどんな会社？

現在メインで行っているのは、

・インターネット広告の運用

・Webサービスの画像・テキスト監視

・Webサービスのカスタマーサポート

・システムのデバッグ

これらを中心に事業展開をしています。


なぜシーエー・アドバンスがNoSQLを
調査・研究しているのか。

シーエー・アドバンスは最新技術を調査・研究する「技術推進グループ」
を立ち上げ、NoSQLの実戦導入に向けた検証を行っています。

それは、業務で扱う大容量のデータを効率よく扱えるようにするためです。


シーエー・アドバンスが扱う大容量データ

①リスティング広告の広告・キーワード、レポートデータ

サイバーエージェントは日本最大級のネット広告代理店として、多くのマーケティ
ングデータを扱っています。

その中でも特にYahoo!, Googleをプラットフォームとしたリスティング広告は大量
の「広告・キーワード」「レポート」を扱うことになります。

レポート
広告・キーワード



②サイト監視対象の画像、テキストデータ

日本最大のブログメディア「Ameba」や「アメーバピグ」など、サイバーエージェ
ントは多くのBtoCサービスを運営しています。

毎日ユーザから大量の投稿が行われ、それらをシーエー・アドバンスがチェックし
ています。それらのチェックを効率的に行うためのデータ整理や、データを分析す
るためにシステム化を推進しています。



③システム運用に関する各種ログデータ

サイバーエージェントがインターネットビジネスを行っていく中で、大量のログ
データが発生します。

サイバーエージェントと協力して、例えば「どんな人がこういう発言をしているの
か」「サイトをA訪問した人が、サイトBを訪問する可能性はどれくらいか」などを
分析して、サービスの改善に役立てています。


①リスティング広告の広告・キーワード、レポートデータ

以上３つのデータは非常に大きいため、既存のDB(MySQL)だと読み込み、書
き出しの性能に限界を感じていました。

処理にたくさんの時間がかかったり、サーバの負荷がとても大きかったり。
シーエー・アドバンスはまだまだ会社としては小さく、どんどんサーバを増
やせる環境でもありません。

限られたサーバ資産でこれらの大容量データを効率的に扱うため、NoSQLを
活用することを考えました。



一言でNoSQLと言ってもかなりの種類があり、またスタンダードなものが存
在しない状態です。そこで色々なNoSQLを試してみて、どういうケースで何
が最適かを検証することにしました。

インターネット上に参考になる情報も多くありましたが、実際の業務を想定
して何が最適かを自分たちで確かめたいと思ったのです。



そして新しい技術にアンテナを張るという観点からも、NoSQLの調査・検証
は会社にとってとても有益であると考えました。

現在私たちが標準の言語として使用している、PHPとの相性が良いという点
も重視しました。


シーエー・アドバンスで扱うデータはど
れくらい大容量なの?

①リスティング広告のキーワード・広告、レポートデータ
○レポートデータ
1日600万～1500万レコードくらいずつ増加。

現在はMySQLを使用して、アカウント/日付単位でシャー
ディングして対応。

○キーワード・広告
全部で約20億レコードを保持。毎日10%位が更新される。

現在はMySQLを使用して、アカウント単位でシャーディン
グして対応。



○画像/テキストデータ
1日500万～1000万レコードくらいずつ増加。

現在はMySQLを使用して、日付単位でシャーディングして対
応。



○各種ログデータ
1日2,000万レコードくらいずつ増加。

現在はMySQLを使用して、サービス/日付単位でシャーディ
ングして対応。


シーエー・アドバンスのメンバーは、
どんな環境で開発しているの？

いわゆる「LAMP環境」を標準環境として採用しています。
(今後は変わる可能性が高いです。詳しくはエグジニアブログをご参考ください)

○ OS ：Linux(CentOS 5)
○ 言語：PHP5.3
○ Webサーバ：Apache2.2
○ DB ：MySQL5.5
○ キャッシュ：memcache1.4

上記が標準の環境です。


ところでみなさん、NoSQL使っていますか？

来場者の方で、すでにNoSQLを使っている方どれくら
いいるのでしょうか。

会場で、既にNoSQLを使っている方に聞いてみたいと
思います。



NoSQLを「仕事で使ったことがある」という方は
挙手をお願いします。



NoSQLを「仕事以外で使ったことがある」という方は
挙手をお願いします。


② NoSQLについてのおさらい


注意とお願い

皆さんもご存じの通り、NoSQLには多くの製品があり、また
日々新しい技術や製品が生まれています。

本日お話しする内容は、あくまでシーエー・アドバンスが
調査を行ったものであり、一般的なNoSQLについての内容と
捉えていただければと思います。

私たちもまだまだまだ勉強中ですので、もし「ここ間違っ
ているよ」とか「新しい～を使用すればこれは解決できる
よ」等がありましたら、是非教えてください。


NoSQLについてのおさらい

NoSQLとは、RDBではないデータベースの幅広い呼称です。
特定のDBを指しているわけではなく、対象は幅広く存在し
ています。

正式な文書では構造型ストレージ (structured storage)と呼
ばれることが多いようです。


NoSQLについてのおさらい

NO!SQL というSQLの否定ではなく、
Not Only SQLという解釈が好ましいとされています。

NoSQLとRDBはお互いに全く異なる特性を持っているた
め、適材適所で活用されるのが望ましいと思います。


③ NoSQLの特徴


NoSQLの特徴

○固定されたスキーマに縛られない

○関係モデルの結合操作を利用しない

○水平スケーラビリティが確保しやすい事が多い

○トランザクションを利用できないものが多い

○ SQLではない方法でデータを操作する


NoSQLの特徴

○固定されたスキーマに縛られない

スキーマレス：列単位で自由にカラム定義ができる。

KVS ：キーと値をセットで保持する。


NoSQLの特徴

○関係モデルの結合操作を利用しない

テーブル間のJOINを行うことができない。

必要であればアプリケーション側で実装する。


NoSQLの特徴

○水平スケーラビリティが確保しやすい事が多い

サーバの追加が容易

自動的に負荷分散を行ってくれるケースが多い


NoSQLの特徴

○トランザクションを利用できないものが多い

データの一貫性よりも速度を重視。

必要ならアプリケーション側で実装する必要がある。


NoSQLの特徴

○ SQLではない方法でデータを操作する

memcachedプロトコル等の汎用的なものを使用

独自のコマンドで操作を行う


NoSQLが苦手なこと



○データを結合させて取り出す（SQLでいうjoin）

○データの整合性を完全に保つ

○柔軟な検索/集計/並び替え



○データを結合させて取り出す（SQLでいうjoin）

KVSではデータをキーの単位でしか操作できない。

階層モデルはテーブル間の結合ができない。



○データの整合性を完全に保つ
複数サーバにデータが分散している場合、サーバ間の整合性
が保証されないケースが多い。

サーバA, Bに存在する同じデータに更新をかけた場合、サー
バAは更新完了しているが、サーバBは更新完了していないと
いう事象が起こります。



○柔軟な検索/集計/並び替え

SQLのように、値に対しての操作は苦手。

例) MongoDB
検索用のコマンドは用意されているが、実行速度が非常に遅
くなる。
シェルを使ったMapReduceで集計すると早いが、シェル作成の
手間がかかる。

例) KVS
そもそも値に対して操作ができない。一度値を取得してから
プログラム側で操作する必要がある。


NoSQLの種類


NoSQLの種類

一般的にNoSQLは、大きく次の3種に分類されます。

○分散KVS

○列指向データベース

○ドキュメント指向データベース


NoSQLの種類

分散KVS
データをkey（キー）とvalue（値）のペアにして管理するデータ
ベース。高速な読み書きが可能だが、複雑な検索処理には向いてい
ない。

・memcached
・Couchbase
・okuyama
・Amazon Dynamo
・Kyoto Cabinet


NoSQLの種類

列指向データベース
データを列単位でひとまとめにして管理するデータベース。
大容量データに対して検索を行うなど、処理の負荷が高くてRDBMSで
は高性能を期待できない場面でも、高速な読み書きが可能になって
いる。

・Google Bigtable
・Amazon SimpleDB
・HBase
・Cassandra


NoSQLの種類

ドキュメント指向データベース
特定のスキーマを持たないデータベース。構造が複雑なオブジェク
トをそのまま保存しやすい。
スケーラビリティが高く、サーバを容易に追加することができる。

・MongoDB
・CouchDB


④ CAP定理について


CAP定理について

NoSQLの解説で有名なのが、カリフォルニア大学教授のEric Brewer
氏が提唱したCAP定理を基にしたデータベースの分類です。

CAP定理とは、分散システムにおいては後述の3つの要素のうち2つしか
満たすことができない、という定理です。

NoSQLを選定するうえで参考になると思いますので、簡単に紹介しま
す。



C：Consistency （一貫性）
A：Availability （可用性）
P：Partition Tolerance （ネットワーク分断への耐性）

Visual Guide to NoSQL Systems



全てのサーバにおいて、同時に同じデータが見えること。




どのような状態でも、データの参照が可能であること。




あるサーバへのネットワークが分断されても、別のサーバか
らデータが参照可能であること。




例)シングル構成のMySQL


一貫性（C）と可用性（A）をできるだけ保証する代わりに、ネットワーク
分断への耐性（P）を犠牲にしています。

C：サーバが単数なので、一貫性は保証されています。

A：ネットワークを超えた高頻度の読み込みロックは発生せず、高い可用性
が保障されています。

P：構成するネットワークが途中で切れたり大きく遅延した場合、そのシス
テムとしては動作が保証されなくなってしまいます。



例)Apache Cassandra


可用性（A）と耐性（P）をできるだけ保証する代わりに、一貫性（C）
を犠牲にしています。

C：複数サーバにデータが存在し、サーバ間のデータ同一性は保証されて
いません。

A：単一障害点となるノードが存在しません。同一のデータが複数サーバで
保持されています。

P：ネットワークが分断されても、同一ネットワーク内のノードで運用を
続ける事ができます。



CAP定理の話からも分かるように、NoSQLと一言でいっても様々な特徴を持った
ものがあります。

システムに求めるものは何か、NoSQL導入により解決したい問題は何かという
ことを意識して、選択することが重要なのではないでしょうか。


⑤ 弊社で検証したNoSQLの紹介


弊社で検証したNoSQLの紹介

今回の勉強会では、シーエー・アドバンスが調査・検証の対
象として選択した下記のNoSQLについて見ていきたいと思いま
す。


開発者：Facebook

公開日：2008年7月

実装言語：Java

開発体制：Apache Incubator

採用実績：楽天、NTTドコモ、Facebook、Twitter


Google BigTableのデータモデル
＋
Amazon Dynamoの分散システムデザイン

この２つを融合させてできた分散データベース。高可用性と
冗長性を併せ持っている。


Google BigTableのデータモデルとは

超大規模な列指向DBMSである。行ではなく、列からの高速な読み込みに焦点
を当てている。また、操作の履歴を残すことができる。

数百から数千台のサーバにおいて、ペタバイトまでのデータを扱い、システ
ムにサーバを簡単に増設して、再設定なしにそれらのリソースを自動的に利
用し始めるように設計されている。

常に1台のマスターサーバが存在し、 BigTable全体の管理を行う。


Amazon Dynamoの分散システムデザインとは

高い可用性と永続性を達成するため、Dynamoは複数のホストにデータを複製
します。レンジ内の各キーのローカル保存に加えて、コーディネーターはこ
れらのキーをリング上を時計回りに設定値-1個までのノードに複製します。


Cassandraの特徴

大規模データを扱えるように設計されている。

全ノードが同一の機能を持っており、管理サーバなどは存在しない。そのた
めに単一障害点のない、可能性の高いシステムが構築可能。

データは各ノードに自動的にレプリケーションが行われる。ノードを増やす
ことで容易にスケールアウトが可能。

ノードの追加、削除がダウンタイム無しで行うことができる。


データはすべて4次元または5次元の連想配列で保持する。

単純なKVSと比べてデータ保持方法がきちっと固められるので、
データベースの設計がしやすい。


開発者：Powerset社、Rapleaf社の社員
(Powerset ：シリコンバレーにあるIT企業。検索エンジン等を
(Rapleaf ：シカゴにあるIT企業。データマイニング等を行う)

実装言語：Java

公開日：2007年2月(プロトタイプ公開)

開発体制：Apache Software Foundation

採用実績：Facebook、サイバーエージェント


KVS型の分散データベース。

GoogleのBigTableを参考に設計された。

負荷に対して非常に高いスケーラビリティと性能を発揮。

シンプルで強い一貫性モデルを備えている。

自動ロードバランス、フェイルオーバー、自動シャーディン
グ。


シンプルで強い一貫性モデルとは

・行に対する操作はアトミック

・更新前の古いデータが見える事が無い。

・Read性能よりもWrite性能が重視されている
(MySQL等のRDBと逆)

・writeの動作は、リージョンサーバのメモリにバッファリング
され、
一定サイズに達したらディスクへ書き込み。


データは3階層で保持する。一般的なRDBと同じようなデータモデ
ル。


開発者： mixi平林氏

公開日： 2010年5月(ver1.0リリース)

実装言語： C++

開発体制： FAL labs

採用実績： mixi


mixiにより開発されたkey-valueストアの機能を持ったデータスト
レージ。それ以前にmixiで公開・採用されていたTokyo Cabinetに代
わるものとして開発された。

memcached互換プロトコルが実装されおり、memcachedからの比較的
容易な移行が可能。


memcachedとの違いは、

・データをファイルに書き出すことにより、永続性を持たせている。

・keyに対するvalueあたりの容量制限が無い。
(memcachedは1Mの制約あり)

・ keyだけでなく任意のvalueを条件としてデータの検索を行うことが
できる。

などがある。


開発者： 10gen社
(MongoDBのサポートやトレーニングを行う会社)

公開日： 2009年2月

実装言語： C++

開発体制： 10gen社

採用実績： SAP, MTV, SourceForge, GILT
Group, Disney,エレクトロニック・アーツ, サイバーエー
ジェント, NAVER 他多数


10gen社が開発した、ドキュメント指向データベース。

・スキーマレス
・シャーディングが容易
・レプリケーションが容易（自動的にハードウェアを切り替える）
・スケールアウトが簡単に行える。
・js実行エンジンを搭載しており、MapReduce等に利用できる。


Map Reduceとは？

大量データを分散処理させるために使用されるフレームワーク。MAP
で処理を多数のノードに分散し、Reduceで処理結果を集約して、結
果を出力する。


スキーマレスなデータベースとは?

リレーショナルデータベース管理システム（RDBMS）のように、デー
タを格納するテーブルの構造を事前しっかり決める必要がない。自
由な形式でデータを保存できる。


実際に試してみました。


弊社の大容量データ処理に関する課題を解決するために、何を採用す
べきかを検討すべくパフォーマンステストを行いました。

大前提として、弊社には何百台ものサーバは存在しません。

例えばリスティング広告のデータ蓄積用DB(MySQL)サーバは、マスタ1
台とスレーブ2台という構成です。

今回NoSQLに割り当てられるサーバは、ひとまず3台確保しました。
こういう限られた環境で開発を行っている方は、多いのではないで
しょうか。


テストに使用した実施環境は下記の通りです。

vmware playerを使用した仮想サーバ
OS ： CentOS6
プロセッサ： 2コア
メモリ： 12GB
ディスク： 120GB


各NoSQL/RDBのバージョンは、下記を使用しました。

Cassandra ： 1.0.8
Hbase ： 0.92.1
KyotoCabinet ： 1.2.75
mongoDB ： 2.0.7
memcached ： 1.4.4-3
MySQL ： 5.5.20


まずは書き込みの性能


DB別レコード書込時間

5,000 10,000 50,000 100,000 500,000
4.30 8.28 28.93 54.63 272.40
7.09 15.44 78.59 159.55 619.83
1.27 2.27 10.96 22.45 118.11
0.52 0.78 4.00 8.11 47.34
0.35 0.71 3.80 7.50 63.83
(InnoDB) 0.39 0.80 3.93 7.59 45.59
(MyIsam) 0.50 1.10 5.21 9.73 49.30


続いて読み込みの性能


DB別レコード読込件数

5,000 10,000 50,000 100,000 500,000
2.36 5.65 61.08 85.18 283.43
19.03 36.22 194.06 364.04 1859.66
0.08 1.06 0.77 2.12 11.35
0.07 0.16 0.80 1.63 6.08
0.09 0.21 1.16 2.32 10.89
(InnoDB) 0.08 0.02 0.73 1.33 7.02
(MyIsam) 0.06 0.14 0.74 1.57 6.65


色々検討した結果、
採用したのは・・・


システムのログ蓄積

MongoDB
○理由
多くの採用実績
大量データ操作時の安定したパフォーマンス
PHPに専用のアクセスクラスが存在した。


リスティング広告のレポートデータ蓄積

MySQL
○理由
枯れたDBであり、運用がしやすい。
データの一貫性と稼働率の高さを求められる
ため。


社内標準のキャッシュ用DB

KyotoCabinet
○理由
memcachedプロトコルのために既存のプログラム資産を活か
せる。


⑥ 最後に


まとめ

NoSQLの関連技術は非常に動きが速く、まだスタンダードなものが無
いような状態です。NoSQL導入にあたり「既存の問題点は何か」「導
入によって何を実現したいか」をしっかりと考えて選定するのが良い
のではないでしょうか。

そして今回の検証を通して、改めてMySQLの実力を見た気がします。
「NoSQL＝無条件に早い」というイメージがあったのですが、そうで
はない事が分かりました。


最後に、新しいNoSQLを１つご紹介します。


年内にも正式版のリリースが見込まれている
MySQL5.6に、memcached APIが搭載されます。

アプリケーションからmemcached APIを通じて
MySQLのデータストレージへダイレクトに
アクセスできます。

MySQLの長所を活かしてNoSQLを運用できるため、
非常に期待しています。

最後に宣伝させてください。

シーエー・アドバンスでは一緒に働いてくれるメンバーを募集中です。
興味をもたれた方は、気軽ご連絡いただければと思います。
(私に直接声をかけてもらってもOKです。)

メールでのお問い合わせは、

saiyo@ca-adv.co.jp
までお願いします。


発表は以上になります。

本日はお忙しい中、お越しいただきありがとうございました。


NoSQL勉強会

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie NoSQL勉強会

Ähnlich wie NoSQL勉強会 (20)

Mehr von Yuji Otani

Mehr von Yuji Otani (17)

NoSQL勉強会