（３時間無料セミナー）NoSQLのApache Cassandraを知ろう！に行ってきた！その内容をメモメモ
NoSQLのApache Cassandraを知ろう！
Apache CassandraとはIoT向けデータベース
Google BigTable
Amazon DynamoDB
この論文からＮｏＳＱＬきてる
Apache Cassandra 2010年ごろ盛り上がる
→facebookが作った
元気なくなる
→Facebookがやめた
実際のところ、インスタグラム、ゲームなどの裏ではつかってる
タイムラインでは使っていない
最近盛り返す
→Appleが大々的に発表 27000台、数十ペタバイト
また注目
→Sony PS4のマイプレイステーションの
内容は変わらない：大量のデータをスケーラブルで
必要のないときマシン削除できる→クラウド向け
アメリカの小売店：ブラックマンデー
ＰＯＳメインフレームを使ってた→その日だけ１００％
Cassandraに変えると・・サーバー倍にして処理
ＤａｔａＳｔａｘ
Cassandraはオープンソースで無料
サポートとかをカバーするのがDatastax
→Apache Cassandraのディストリビューション
すぱーく
そらー
たいたん：グラフＤＢ
などをつける
DSE(でーたすたっくえんたーぷらいず）製品
Linux→Cassandra
RedHat→DSE
レガシーＲＤＢＭＳ not ビッグデータ？
３つのＶ
Volume（量）：桁違いのデータ量
Velocity（頻度）：高頻度でのデータの発生
Variety（多様性）：様々な種類のデータ
そもそも、ＲＤＢでできるのか？
ＮｏＳＱＬって何？位置づけ
ＯＬＴＰ ＤＷＨ
ＲＤＢＭＳ （ＲＤＢＭＳ）
ExaData ８億をなんだいも・・
↓
NoSQL Hadoop
ＯＬＴＰ ＤＷＨ
ＲＤＢＭＳ （ＲＤＢＭＳ）
ＲＤＢとは違う段階、違うニーズ
ＲＤＢで大変だったところをHadoopで
ＮｏＳＱＬは大量のデータでないと必要ないの？
・・１Ｔ、２Ｔでいいケース：ありま～す
そこを見極めないとデスマーチ
Relational？ NoSQLって何
NoSQL＝Not only SQL？
データベース≠RDBMS
OR
Post Relationalだとおもっています
オペレーショナルＤＢ ＶＳ 分析ＤＢ
Operational Database
２００６
２００７
ＮｏＳＱＬ
分析ＤＢ
２００３ Ｈａｄｏｏｐ Ｇｏｏｇｌｅファイルシステム
２００４ ＭａｐＲｅｄｕｃｅ
ＤＢで使えるようになるのは７年
ブリティッシュ Ｇａｓ
地に付いたＤＢ
The 451 group.com
RelationalにするかNoSQLにするか
Relational
論理データモデル
物理データモデル
テーブル
テーブルがあってＳＱＬを作る
Ｗｅｂ系、ゲーム系：毎日スキーマが変わる
ＩｏＴデバイス：各マシンのフォーマットは違う
→ＲＤＢだとマスタマネジメント必要
→ＮｏＳＱＬ：そのままつっこめ
→渋谷かいわいでＮｏＳＱＬを使う理由
そのほうがわかりやすい
→でーたのヂュプリケートがおこる
→データは２重持ちしちゃいなさい
メインフレーム：非正規化
リレーショナル：正規化
ＮｏＳＱＬ：二重もち、大福帳
オペレーショナルデータベース
トラでショナル：ＲＤＢＭＳ
どうでもいいもの
ＩＯＴ：ＲＤＭＳ以外
↓
全部ＲＤＢＭＳ？
繋がるネット時代の新技術
１９７０年代 階層ＤＢ
１９８０年代 リレーショナル
２０１０移行 コンテンツ・データを中心に
■NoSQLのApache Cassandraを知ろう！
Cassandraとは
Ｇｏｏｇｌｅ
スキーマ
めむてーぶる
こんぱくしょん
ＳＳてーぶる
こみっとろぐ
Ａｍａｚｏｎ
あーきてくちゃ
分散
レプリケーション
ごしっぷ（ぷろとこる）
おもしろいかんがえ
・マスターというのがない→単一障害点がない
・クラウド、オンプレミス共用にできる
・リニアなスケーラビリティ→マスタがないから
It's Always On
・Net Flix
カオスモンキー：ランダムに殺す
ＡＷＳのリブート：１００％サービス
ゲーム会社：初日がピーク
レイテンシーは変わらない
なぜＤＳＥ
開発用ドライバー無料
ＧＵＩは半分無償半分有償
有償
セキュリティ
ＱＡされた
もう一こ上
インメモリー
分散エンジン
全文検索エンジン
エンタープライズ・セキュリティ
あなたはすでにDataStaxを使っているはず
ニュースサイト
オンラインショッピング
：
：
■Cassandraの用語
・Cassandraノード
サーバーまたはマシーンまたはバーチャルインスタンス
１つのJVMが動く環境
Cassandraはコモディティサーバーで使うように作られている
SANとかでなく
マシンは別々→安いサーバーでいい
・クラスター
＝データベース
３ノードの１クラスターＤＢといういいかた
最悪１台のノードで１クラスター→それなら、Mongoのほうが。。
ＨＡなら、最低３台がいいのでは→クラウド上なら
オンプレの場合、４台のマシンが１ヶ月しんでも
・データセンター
アメリカとＪａｐａｎ：べつべつのところにデータを置く
→１クラスターの中でできる
Create Tableするときにできる
論理データセンター
物理データセンター
・ワークロードでのデータセンターでの分割
データセンター３箇所（東京、サンフランシスコ、クラウド）
東京でオペレーション＆分析→遅くなる
３箇所に分析をかける→いままではＥＴＬかゴールデンゲート
接続先は？
アプリケーションを書くときに、どこに接続するか意識して書く
ただし、ローカルの場合、ローカルファースト
・クラスタ
８台のノード：データ分散して持っている
ケータイ：うらがCassandra→５個コピー
・Cassandraのデータ・パーティション分割の概要
分散ストラテジ２つ
ランダム→デフォルト
順序指定→偏ってしまう
レプリケーション係数（ファクター）
１：１台 ５：５台
クラスターの中で、どっかにもつ
キーにハッシュをかけてトークンを作る→どこに行くのか決まる
・レプリケーションストラテジー
データセンターのどこのラックに持たせるまで指定できる
→ネットワークトポロジー（あんまり使わないかな・・）
Create Keyspaceをするときに指定できる
・スニッチ
順番を決める
・ゴシップ：ノード間のコミュニケーション
「あいつ死んでるらしいぜ！」というのを各マシンへ
→伝えていく
・ロードバランス
ラウンド・ロビン
データセンター認識ラウンドロビン
ローカルを先に認識、なかったらリモート
・容量の追加：かんたん
・バーチャルノード(Vnodes,仮想ノード）
追加したとき５台に１台ついか ５分の１づつ渡す
場所に依存しない
・１つのノードがダウン
→何個に書き込めたら良いのか・・
調整可能なデータ整合性
もし、ＡＬＬとやってしまったら、２フェーズコミットと同じ
Ｏｎｅ
Ｑｕｏｒｕｍ
・データが一致しないとき
タイムスタンプを見て判断
ヒントつきハンドオフ→タイムアウト有り
リペアで整合性
いつかは同期する
・ＡＰＩのコネクターとドライバー
・ＤａｔａＳｔａｘＯｐｓＣｅｎｔｅｒ
■Cassandraスキーマ
・カラム及びその構成要素
・テーブル
・キースペース
概観
・キースペース
テーブル：複数の行、パーティションから
パーティション：桁
カラム
カラムの構成要素
・カラムはＣａｓｓａｎｄｒａの基本的なデータのタイプ
カラム名
カラム値
タイムスタンプ
ＴＴＬ（任意）
カラム名
・必須
・任意の値、任意の型→タイムスタンプをカラム名にしてもＯＫ
・テーブルで一意
・かならず値とともに格納
カラム値
・任意の値、型
・空でもＯＫだが、必須
カラム値のデータ型はバリデータ
カラム名のデータ型はコンパレータ
データ型はいろいろ
カラムのタイムスタンプ
６４ビット整数
ベストプラクティス
：すべてのクライアントで一貫性のある形で作成
必須
カラムのＴＴＬ
Insert時に定義
期限を整数値で定義（秒単位）
特殊なカラム型
カウンター
加算／減算が可能
コレクション
以下の２つのコレクション型
ＳＥＴ：ＣＱＬのコンパレータでソート
Ｌｉｓｔ：順序を指定して
ＭＡＰ：キーはコンパレータでソート
テーブル（カラム・ファミリー）
・ＲＤＢにおけるテーブルに似ている
パーティション（行）の集まり
調整可能な整合性
非正規化
Ｉ／Ｏの回避
読み取りパスを簡素化するため
静的または動的
静的なテーブル
・ＲＤＢのテーブルに似ている
動的なテーブル
・Wide Rows(横に伸びていく）
パーティションのクエリーに対して応答が得られるように構造化
ＣＱＬ行とストレージ行（パーティション）
キーの構造
パーティション（行）キー
クラスタ化キー
クラスターか順序
何もしなくてもディスク上でカラムをソート
順序は変更可能
ソート
クラスター化カラムはORDER BYの対象にできる
複合パーティションキー
Initial Token
先頭トークン値から次のノードのトークン値までが担当になる
静的カラム
１つのパーティションの中で、同じパーティションの全ての行によって共有される特殊なカラム
たとえば、キーに対する名前など
サイズ制限
・テーブルのサイズ上限＝クラスターのサイズ上限
・１つのパーティション→１つのノードに収まる必要アリ
・理論上は２０億まで、カラムをもてます
・カラム値（セル）の最大サイズは２Ｇ（現実派１０Ｍ程度が妥当）
・ヒープサイズ
１個テーブルをもつと、１メガバイト→テーブル数を増やさない
キースペース
・テーブル（カラムファミリー）の集合体
・レプリケーションストラテジ設定
・レプリケーション係数を設定
Cassandra Query Language CQL
・ＲＤＢのＳＱＬに似ている
Datastax DevCenter
CQL分を作成して実行できる無償のビジュアル・クエリー・ツール
バッチの構文
→一階書き込んで実行
LWT(Lightweight Transaction)IF notができる
■データ・モデリング
クエリーを基準としたデータモデリング
・クエリーから考える：どういったデータを引っ張りたいのか
非正規化する
データが重複してよい
・ユースケース
製品カタログ
ＩｏＴ
レコメンデーション
不正検知
■ショッピングカーと
・ダウンタイムが発生しない
・オンラインの買い物客はスピード大事
・スケールすることも重要
・Cassandraでは、必要な情報を全て１つのテーブルのパーティションに保持する
・利用者はそれぞれ１つまたは複数のショッピングカートを持てる
→ユーザー名とカートの複合パーティション
■ユーザー・アクティビティの追跡
・挙動にリアルタイムで反応
・バッチでは遅すぎる
ユーザーアクティビティのモデル
長期の行動データはバッチに持っていける
ユーザーが行った行動のテーブル
ユーザー名
時間
ＴＴＬを入れておく
永続的データ
書き込みは早い
モデルを使う
■ログ収集
・全てのログデータを高速で収集
・ログの生成場所に近いCqassandraを使う
複数データセンターの利用
・ダッシュボード、参照など
・データを収集して様々なテーブルに振り分ける
・参照用のテーブル
・ログ：ダッシュボード
■インデックスの作成
→あんちパターン（できるけど）
・テーブルを使用したインデックス作成
・部分ワード・インデックス
・店番号と商品番号：複合行キー
・ビットマップインデックス
挿入時に可能性を全部入れておく
■サーチ（検索）
・Solrの統合
・非常に高速なパフォーマンス
・solrの自動シャーディング（Cassandraレプリケーションによる）
■アナリティクス
・Hadoopとのインテグレーション
・Spark
■Javaドライバ
・ＣＱＬ３
昔のすりふと(Thrift)ベースのＡＰＩよりはるかに早い
英語でJavadocあるので見てね！
■まとめ
http://docs.datastax.com/ja/index.html
