• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
なぜApache HBaseを選ぶのか? #cwt2013
 

なぜApache HBaseを選ぶのか? #cwt2013

on

  • 2,021 views

#cwt2013 ClouderaのJonathan Hsieh @jmhsieh によるHBaseの最新情報のスライドを公開しました。CDH5のHBase ...

#cwt2013 ClouderaのJonathan Hsieh @jmhsieh によるHBaseの最新情報のスライドを公開しました。CDH5のHBase 0.96では耐障害性が強化され、障害発生時も書き込みは数秒、読み込みは10秒以内に復旧します。

Statistics

Views

Total Views
2,021
Views on SlideShare
1,947
Embed Views
74

Actions

Likes
7
Downloads
34
Comments
0

2 Embeds 74

http://linux.wwing.net 50
https://twitter.com 24

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    なぜApache HBaseを選ぶのか? #cwt2013 なぜApache HBaseを選ぶのか? #cwt2013 Presentation Transcript

    • DO  NOT  USE  PUBLICLY   PRIOR  TO  10/23/12   なぜApache  HBaseを選ぶのか?   Headline  Goes  Here   Jonathan  Hsieh  |  @jmhsieh     Speaker  Name  or  Subhead  Goes  Here   SoHware  Engineer  at  Cloudera  |  HBase  PMC  Member     November  7th,  2013,  Cloudera  World  Japan  2013  
    • 自己紹介   •  Cloudera:   •  ソフトウェアエンジニア   •  Tech  Lead  HBase  Team   •  Apache  HBase  commiRer  /  PMC     •  Apache  Flume  founder  /  PMC   •  ワシントン大学:   •  分散システムの研究   2 11/7/13 Cloudera World Japan Jonathan Hsieh
    • Apache  HBaseとは?   Apache  HBaseはApache   Hadoop上で開発された オープンソースの,  分散型 非リレーショナルデータ ベース。低レイテンシで一 貫性の高い読み出し・書き 込み操作などランダムアク セスを実現する   3 11/7/13 Cloudera World Japan Jonathan Hsieh
    • HBaseはオープンソース   •  Apache  2.0ライセンス   •  さまざまな組織からのコミッターやコントリビューターで構成さ れたコミュニティプロジェクト   •  Facebook,  Cloudera,  Salesforce.com,  Huawei,  HortonWorks,   Intel…   •  コードライセンスとは、誰もがコードの利用・改変できることを 意味する   4 11/7/13 Cloudera World Japan Jonathan Hsieh
    • オープンソース開発者コミュニティ   •  活気がある   活動盛んな   コミュニティ   5 11/7/13 Cloudera World Japan Jonathan Hsieh
    • HBaseは低レイテンシなランダムアクセスを実現   •  書き込み:     •  •  読み出し:     •  •  •  1-­‐3ms,  1k-­‐10k  writes/sec  per  node   0-­‐3ms  キャッシュ,  10-­‐30msディスク   10k-­‐40k  reads  /  秒  /  node  from  cache   セルサイズ:     •  0000000000   4   1   2222222222   3333333333   5   4444444444   5555555555   0B-­‐3MB     6666666666   •  読み出し,  書き込み,  テーブルの 2   3   任意の箇所へのデータ挿入   6 1111111111   11/7/13 Cloudera World Japan Jonathan Hsieh 7777777777  
    • Apache  HBase  アーキテクチャ   設計と開発   7 11/7/13 Cloudera World Japan Jonathan Hsieh
    • Google  インフラストラクチャー  (2006年ごろ)   •  OSDI  2006  paper     •  目標:大量の準構造化データに対する迅速なランダムリード(読み込 み)/ライト(書き出し)アクセスの実現     •  8 Webやorkut、アナリティクス、Google  Earth、ブロガーへのGoogleク ローラー用データストア   11/7/13 Cloudera World Japan Jonathan Hsieh
    • バックエンド   フロントエンド   Web  アプリケーション アーキテクチャ   9 HTTP   App   DB   フィルタ   ログ 処理   App  data   アプリケーションおよび   HTTPログ   レポート     機械学習   11/7/13 Cloudera World Japan Jonathan Hsieh
    • バックエンド   フロントエンド   Web  アプリケーション アーキテクチャ   10 HTTP   HTTP   App   App   DB   アプリケーション   データ   HTTP   App   HTTP   HTTP   App   App   ログ   フィルタ   アプリケーションおよび   HTTPのログ   11/7/13 Cloudera World Japan Jonathan Hsieh …   HTTP   App   ログ処理   レポート、   機械学習  
    • バックエンド   フロントエンド   Web  アプリケーション アーキテクチャ   11 HTTP   HTTP   App   App   DB   アプリケーション   データ   HTTP   App   HTTP   HTTP   App   App              HDFS   アプリケーションおよび   HTTPログ   11/7/13 Cloudera World Japan Jonathan Hsieh …   HTTP   App   Hadoop   MapReduce   レポート、   機械学習  
    • バックエンド   フロントエンド   Web  アプリケーション アーキテクチャ   12 HTTP   HTTP   App   App   HTTP   App   HTTP   HTTP   App   App              HDFS   アプリケーション   データ   アプリケーションおよび   HTTPログ   11/7/13 Cloudera World Japan Jonathan Hsieh …   HTTP   App   Hadoop   MapReduce   レポート、   機械学習  
    • 今日のプレゼン:  Apache  HBase  0.96.0   •  HBaseのフォールト・トレラント機能   Reliable   Highly  Available   •  HDFSで永続性実現   •  データの遺失がない   •  HBaseの高度な高可用性     •  障害からの迅速な復旧   Predictability   13 •  予測可能なパフォーマンスに向けた改善   •  99%タイルを向上し、平均値は上々   11/7/13 Cloudera World Japan Jonathan Hsieh
    • 実際に利用中のApache  HBase  アプリケーション   •  Inbox   •  ストレージ   •  Web   •  Search   •  分析   •  モニタリング         14 さらに詳しいケーススタディ→  hRp://www.hbasecon.com/agenda/   11/7/13 Cloudera World Japan Jonathan Hsieh
    • HBaseの依存関係   •  Apache  Hadoop  HDFS  による永続性と信頼性 の実現  (先行書き込みログ)   •  Apache  ZooKeeperによる分散協調の実現   •  Apache  Hadoop  MapReduce  によるデータの抽 出・インポートを行うMapReduceジョブの実行 App   MR   ZK   HDFS     15 11/7/13 Cloudera World Japan Jonathan Hsieh
    • クラスタ上のHBase   HDFSネームノード   HBaseマスター   Rack  1   ZooKeeper      Quorum   Slave  Boxes  (DN  +  RS)   Name   node   Rack  2   Name   node   16 11/7/13 Cloudera World Japan Jonathan Hsieh
    • バージョンごとのサマリー   0.90  (CDH3)   0.92  /0.94  (CDH4)   0.96  (CDH5)   次期バージョン   新機能   安定性    信頼性     継続性   マルチテナンシー   MTTR   数時間内の   復旧   数分以内の復旧   書き込みは数秒以内、 数秒以内の復旧 読み出しは10秒以内 (reads/writes両方)   の復旧   Perf   ベースライン   スループットの改善   パフォーマンス   最適化   予測可能な   パフォーマンス   ユーザ ビリティ   HBase   開発者   専門家   HBase  運用経験   分散システムの   管理経験   アプリケーションの   開発経験   平均復旧   時間   17 11/7/13 Cloudera World Japan Jonathan Hsieh
    • HBase  データモデル   Rows,  Columns  Families  and  Qualifiers   18 11/7/13 Cloudera World Japan Jonathan Hsieh
    • ソートマップデータストア  (論理ビュー)   Row  key   roles:hadoop   cugng   ‘9H’   ‘CA’   ‘Founder’   tlipcon   19 info:  height   info:state   ‘5H7’   ‘CA’   ‘PMC’   @ts=2011     ‘CommiRer’   @ts=2010       11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase   ‘CommiRer’  
    • ソートマップデータストア(論理ビュー)   RDBMS観点における   暗黙のプライマリーキー   Row  key   roles:hadoop   cugng   ‘9H’   ‘CA’   ‘Founder’   tlipcon   20 info:  height   info:state   ‘5H7’   ‘CA’   ‘PMC’   @ts=2011     ‘CommiRer’   @ts=2010       11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase   ‘CommiRer’  
    • ソートマップデータストア(論理ビュー)   RDBMS観点における   暗黙のプライマリーキー   HBaseではデータはすべて byte[]   Row  key   roles:hadoop   cugng   ‘9H’   ‘CA’   ‘Founder’   tlipcon   21 info:  height   info:state   ‘5H7’   ‘CA’   ‘PMC’   @ts=2011     ‘CommiRer’   @ts=2010       11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase   ‘CommiRer’  
    • ソートマップデータストア(論理ビュー)   RDBMS観点における   暗黙のプライマリーキー   HBaseではデータはすべて byte[]   Row  key   info:  height   info:state   roles:hadoop   cugng   ‘9H’   ‘CA’   ‘Founder’   tlipcon   ‘5H7’   ‘CA’   ‘PMC’   @ts=2011     ‘CommiRer’   @ts=2010       単一のセルは、   異なるタイムスタ ンプで異なる値を 持つ場合がある   22 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase   ‘CommiRer’  
    • ソートマップデータストア(論理ビュー)   RDBMS観点における   暗黙のプライマリーキー   HBaseではデータはすべて byte[]   Row  key   info:  height   info:state   roles:hadoop   cugng   ‘9H’   ‘CA’   ‘Founder’   tlipcon   ‘5H7’   ‘CA’   ‘PMC’   @ts=2011     ‘CommiRer’   @ts=2010       単一のセルは、   異なるタイムスタ ンプで異なる値を 持つ場合がある   23 11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase   ‘CommiRer’   異なる行は   異なる列セットを 持つこともある   (テーブルはま ばら)  
    • ソートマップデータストア(論理ビュー)   RDBMS観点における   暗黙のプライマリーキー   カラムフォーマットファミリー:修飾子   Row  key   info:  height   info:state   roles:hadoop   cugng   ‘9H’   ‘CA’   ‘Founder’   tlipcon   ‘5H7’   ‘CA’   ‘PMC’   @ts=2011     ‘CommiRer’   @ts=2010       単一のセルは、   異なるタイムスタ ンプで異なる値を 持つ場合がある   24 HBaseではデータはすべて byte[]   11/7/13 Cloudera World Japan Jonathan Hsieh roles:hbase   ‘CommiRer’   異なる行は   異なる列セットを 持つこともある   (テーブルはま ばら)  
    • ソートマップデータストア(物理ビュー)   info Column  Family   Row  key   Cell  value   info:height   1273516197868   9H   cugng   info:state   1043871824184   CA   tlipcon   info:height   1273878447049   5H7   tlipcon   info:state   1273616297446   CA   Row  key   25 Timestamp   cugng   行キー、   列キー、   降順タイムス タンプで   ディスクに ソート   Column  key   Column  key   Timestamp   Cell  value   cugng   roles:Hadoop   1183746289103   Founder   tlipcon   roles:Hadoop   1300062064923   PMC   tlipcon   roles:Hadoop   1293388212294   CommiRer   tlipcon   roles:HBase   128432513215   CommiRer   roles Column  Family   UNIX時代からミリ秒   11/7/13 Cloudera World Japan Jonathan Hsieh
    • どうやってデータを配置するべきか?   rowkeyを複合した   Tall  skinny  Table   •  同形のデータを表している!   rowkey   行修飾子を利用したShort  Fat  Table   Rowkey   d:col1   d:col2   d:col3   d:col4   bob   aaaa   bbbb   cccc   dddd   jon   eeee   ffff   gggg   hhhhh   行修飾子を利用したShort  Fat  Table   d:   bob-­‐col1   aaaa   bob-­‐col2   bbbb   bob-­‐col3   cccc   bob-­‐col4   dddd   jon-­‐col1   eeee   Rowkey   col2:   col3:   col4:   jon-­‐col2   ffff   bob   aaaa   bbbb   cccc   dddd   jon-­‐col3   gggg   jon   26 col1:   eeee   ffff   gggg   hhhhh   jon-­‐col4   hhhh   11/7/13 Cloudera World Japan Jonathan Hsieh
    • どうやってデータを配置するべきか?   rowkeyを複合した   Tall  skinny  Table   •  同形のデータを表している!   は   に   rowkey   d:   行修飾子を利用したShort  Fat  Table   力 きな が伴う! bob-­‐col1   aaaa   大 d:col3  任 d:col4   Rowkey   d:col1   d:col2   bob-­‐col2   bbbb   な責 dddd   る?   bob   aaaa   bbbb  き cccc   大 bob-­‐col3     hhhhh   やすくな cccc   jon   eeee   ffff   gggg   使い bob-­‐col4   dddd   行修飾子を利用したShort  Fat  Table   ーに jon-­‐col1   eeee   ーザ col4:   Rowkey   col1:   col2:  ユ col3:   ば jon-­‐col2   ffff   れbbbb   cccc   dddd   す bob   どう aaaa   jon-­‐col3   gggg   jon   27 eeee   ffff   gggg   hhhhh   11/7/13 Cloudera World Japan Jonathan Hsieh jon-­‐col4   hhhh  
    • Impala   HDFS(とHBase!)に対してスケーラブルな低レイテンシSQL クエリを実行   •  ODBC/JDBCドライバ インターフェース   •  特長     •  •  •  •  •  Open  sourced  by  ClouderaClouderaによるオープンソース   •  28 Hiveメタストアと、そのhbase-­‐hbaseコネクタ設定を利用規則   ネイティブコードの実装では、クエリの実行最適化に際して JITを利用   Kerberosのサポートによる認証   hRps://github.com/cloudera/impala   11/7/13 Cloudera World Japan Jonathan Hsieh
    • Phoenix   •  •  •  低レイテンシクエリ分野ではHBaseより優れたSQL     JDBC  SQLインターフェイス   特長   •  •  •  •  •  Salesforce.comによるオープンソース   •  •  29 データ型の追加   複合行キーのエンコーディングを操作     開発中の二次インデックス   プッシュダウン集計(コンプレッサー)を提供   James  Taylor,  Jesse  Yatesその他の方々の成果   hRps://github.com/forcedotcom/phoenix   11/7/13 Cloudera World Japan Jonathan Hsieh
    • HBase  とその他NoSqlとの比較   Cassandra,  MongoDB  とM7  Tablesとの比較   30 11/7/13 Cloudera World Japan Jonathan Hsieh
    • 支持されているNoSQLは?   •  システムを考慮すると   •  HBase   •  MongoDB   •  Cassandra   •  M7  Tables   31 11/7/13 Cloudera World Japan Jonathan Hsieh
    • BrewerのCAP理論   •  Consistency(一貫性):   •  DBとACID特性の分離の保証   •  Availability(可用性):   •  データを返す前に障害から復旧する か?   •  復旧を待つ代わりに、古いデータを 返すか?   Parrron  tolerance   •  ParZZon  Tolerance(パーティー ション・トレランス):   •  32    ノードが落ちても、システムは稼働   11/7/13 Cloudera World Japan Jonathan Hsieh Consistency   5   4   3   2   1   0   Availability  
    • NoSQL  との機能比較   HBase   その他の選択肢   可用性を上回る強力な一貫性   •  パフォーマンスを上回る安全性   •  シンプルな障害セマンティック   •  整備されたレンジパーティーション     •  数千ノードにスケール   •  ばらつきのあるカラムストレージ   •  Apacheライセンス   •  •  33   強力な一貫性を上回る可用性     •  安全性を上回るパフォーマンス   •  複雑な設定が必要なセマンティック   •  分散ハッシュ   •  数十ノードのスケール   •  Btrees   •  GPLもしくはプロプライエタリなライセ ンス   11/7/13 Cloudera World Japan Jonathan Hsieh
    • 何がHBaseの書き込みを保証するのか?   client     R  value   RS   1   2   3   •  HBaseは強力な一貫性を持つ   Acked書き込みは3つの永続的なレプリカを持つ   •  Nacked  書き込みはロールバック可能   •  マシン障害はセマンティックを変更しない   •  •  開発者やアーキテクトが望んでいたシンプルなセマンティック 34 11/7/13 Cloudera World Japan Jonathan Hsieh  
    • 何がHBaseの書き込みを保証するのか?   client     R  value   RS   1   2   3   •  HBaseは強力な一貫性を持つ   Acked書き込みは3つの永続的なレプリカを持つ   •  Nacked  書き込みはロールバック可能   •  マシン障害はセマンティックを変更しない   •  •  開発者やアーキテクトが望んでいたシンプルなセマンティック 35 11/7/13 Cloudera World Japan Jonathan Hsieh  
    • 何がHBaseの書き込みを保証するのか?   client     R  value   RS   1   2   3   •  HBaseは強力な一貫性を持つ   Acked書き込みは3つの永続的なレプリカを持つ   •  Nacked  書き込みはロールバック可能   •  マシン障害はセマンティックを変更しない   •  •  開発者やアーキテクトが望んでいたシンプルなセマンティック 36 11/7/13 Cloudera World Japan Jonathan Hsieh  
    • Cassandraでは何が書き込みを保証するのか?   client     R  value   W  client   Subtle:  Write   Write  client  success,  acks  on  quorum;   client  received  nack  but   read  quorum   Read  client  quorum  reports  green  value.   reports  purple  value!?   Subtle:  Write  client  received  nack  but   Write  client   Gossip  /  read  repair   success,  acks  on  quorum;   ould  report  purple  value!?   read   alue.   Read  client  quorum  reports  blue  vany  c 1   2   3   •  Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持   •  •  •  •  一貫性の調整が可能(ほとんどがAckを使用,  または  “Quorum”)   Acked書き込みは多数の永続レプリカを必要とする   Nacked書き込みは永続レプリカを必要としない (最終的には必要になる!)   書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障 害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保 持し続ける)”*   hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html     37 11/7/13 Cloudera World Japan Jonathan Hsieh
    • Cassandraでは何が書き込みを保証するのか?   client     R  value   W  client   Subtle:  Write  client  received  nack  but   read  quorum  reports  purple  value!?   1   2   3   •  Subtle:  Write  client  received  nack  but   read  any  could  report  purple  value!?   Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持   •  •  •  •  一貫性の調整が可能(ほとんどがAckを使用,  または  “Quorum”)   Acked書き込みは多数の永続レプリカを必要とする   Nacked書き込みは永続レプリカを必要としない (最終的には必要になる!)   書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障 害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保 持し続ける)”*   hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html     38 11/7/13 Cloudera World Japan Jonathan Hsieh
    • Cassandraでは何が書き込みを保証するのか?   client     R  value   W  client   Subtle:  Write  client  received  nack  but   read  quorum  reports  purple  value!?   1   2   3   •  Gossip  /  read  repair   Cassandraは最後の書き込みがポリシーに勝っている限り、ほぼ一貫性を保持   •  •  •  •  一貫性の調整が可能(ほとんどがAckを使用,  または  “Quorum”)   Acked書き込みは多数の永続レプリカを必要とする   Nacked書き込みは永続レプリカを必要としない (最終的には必要になる!)   書き込みのロールバックはなし “Cassandraにはクライアントへの書き込み操作障 害時にクライアントへのレポート機能があるが、実際にはレプリカへの書き込みを保 持し続ける)”*   hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html     39 Subtle:  Write  client  received  nack  but   read  any  could  report  purple  value!?   11/7/13 Cloudera World Japan Jonathan Hsieh
    • Cassandraでは何が書き込みを保証するのか?   client     R  value   W  client   1   2   3   •  Gossip  /  read  repair   Cassandra  is  eventually  consistent  with  a  Last  Write  Wins  policy   •  •  •  •  Tunable  consistency  (most  use  One  Ack,  also  has  “Quorum”)   Acked  writes  has  required  number  of  durable  replicas     Nacked  writes  does  not  have  required  durable  replicas  (but  may  eventually  win!)   No  rollback  the  writes.    “It  is  possible  in  Cassandra  to  have  a  write  operaron  report  a   failure  to  the  client,  but  srll  actually  persist  the  write  to  a  replica.”*   hRp://www.datastax.com/documentaron/cassandra/1.2/webhelp/cassandra/dml/dml_about_transacrons_c.html     40 11/7/13 Cloudera World Japan Jonathan Hsieh
    • MongoDB  はどうやって書き込みを保証するのか?   Parrron!  Split  brain!   client  2   Subtle:  Replica  with  latest  logs  wins.     Either  yellow  or  orange  data  is   revoked/lost!   client  1   1   2   3   •  promoted   MongoDB  (2.4.8+)  はデフォルトでacksを利用するが、永続的なログの書き込みはない   •  •  demoted   マシン障害は必ずしもデータ破損ではない   “Write  concerns”  for  higher  reliability   •  •  •  Acked  のレプリカ:  #  ack前にリモートノードにレプリカ   Journaledack前にログ先行書き込みバッファ(フラッシュ間に100ms)   ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる*   *  hRp://docs.mongodb.org/manual/core/replica-­‐set-­‐rollbacks/   41 11/7/13 Cloudera World Japan Jonathan Hsieh
    • MongoDB  はどうやって書き込みを保証するのか?   Parrron!  Split  brain!   client  2   Subtle:  Replica  with  latest  logs  wins.     Either  yellow  or  orange  d ay   i ave   Because  of  network  split,  we  mata  hs   revoked/lost!   to  primaries  at  the  same  rme.   client  1   1   2   3   •  promoted   MongoDB  (2.4.8+)  はデフォルトでacksを利用するが、永続的なログの書き込みはない   •  •  demoted   マシン障害は必ずしもデータ破損ではない   “Write  concerns”  for  higher  reliability   •  •  •  Acked  のレプリカ:  #  ack前にリモートノードにレプリカ   Journaledack前にログ先行書き込みバッファ(フラッシュ間に100ms)   ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる*   *  hRp://docs.mongodb.org/manual/core/replica-­‐set-­‐rollbacks/   42 11/7/13 Cloudera World Japan Jonathan Hsieh
    • MongoDB  はどうやって書き込みを保証するのか?   Parrron!  Split  brain!   client  2   Subtle:  Replica  with  latest  logs  wins.     Either  yellow  or  orange  data  is   revoked/lost!   client  1   1   2   3   •  promoted   MongoDB  (2.4.8+)  はデフォルトでacksを利用するが、永続的なログの書き込みはない   •  •  demoted   マシン障害は必ずしもデータ破損ではない   “Write  concerns”  for  higher  reliability   •  •  •  Acked  のレプリカ:  #  ack前にリモートノードにレプリカ   Journaledack前にログ先行書き込みバッファ(フラッシュ間に100ms)   ただし、強力な設定のイベントではAcked書き込みはフェールオーバー時に失われる*   *  hRp://docs.mongodb.org/manual/core/replica-­‐set-­‐rollbacks/   43 11/7/13 Cloudera World Japan Jonathan Hsieh
    • まとめ   45 11/7/13 Cloudera World Japan Jonathan Hsieh
    • なぜApache  HBaseを選ぶのか?   ビジネス面から見た理由   技術面から見た理由   Apache  ライセンス   •  複数のベンダがサポート   •  多様なコミュニティ   •  多くの人の支持、増加中     •  HBase多くの企業がHBaseを拡張し てビジネスを構築   •  ディザスタ・リカバリ機能   •  強力なセキュリティ機能   •  •  46   可用性を上回る強力な一貫性   •  パフォーマンスを上回る安全性   •  シンプルな障害セマンティック   •  数千・数百ノードへのスケール   •  データを破損することなくリカバリ ー   11/7/13 Cloudera World Japan Jonathan Hsieh
    • Quesrons?   @jmhsieh   47 明日11月8日18時半〜   HBase Meetupを開催します。   ぜひご参加ください! 11/7/13 Cloudera World Japan Jonathan Hsieh