Soumettre la recherche
Mettre en ligne
SQLまで使える高機能NoSQLであるCouchbase Serverの勉強会資料
•
7 j'aime
•
6,650 vues
樽八 仲川
Suivre
Couchbase Serverの社内勉強会資料
Lire moins
Lire la suite
Ingénierie
Signaler
Partager
Signaler
Partager
1 sur 59
Télécharger maintenant
Télécharger pour lire hors ligne
Recommandé
ペアプロするならgit-duetを使おう
ペアプロするならgit-duetを使おう
Shinya Nakajima
JavaでCPUを使い倒す! ~Java 9 以降の CPU 最適化を覗いてみる~(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019...
JavaでCPUを使い倒す! ~Java 9 以降の CPU 最適化を覗いてみる~(NTTデータ テクノロジーカンファレンス 2019 講演資料、2019...
NTT DATA Technology & Innovation
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
Apache Airflow 概要(Airflowの基礎を学ぶハンズオンワークショップ 発表資料)
NTT DATA Technology & Innovation
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
深層学習フレームワークにおけるIntel CPU/富岳向け最適化法
MITSUNARI Shigeo
Consistent hash
Consistent hash
paulowniaceae
コンテナの作り方「Dockerは裏方で何をしているのか?」
コンテナの作り方「Dockerは裏方で何をしているのか?」
Masahito Zembutsu
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Kubernetesのしくみ やさしく学ぶ 内部構造とアーキテクチャー
Toru Makabe
Hadoop入門
Hadoop入門
Preferred Networks
Contenu connexe
Tendances
Marp Tutorial
Marp Tutorial
Rui Watanabe
MapReduce入門
MapReduce入門
Satoshi Noto
0から始めるコンテナの学び方(Kubernetes Novice Tokyo #14 発表資料)
0から始めるコンテナの学び方(Kubernetes Novice Tokyo #14 発表資料)
NTT DATA Technology & Innovation
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
takezoe
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
Tetsutaro Watanabe
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Takafumi ONAKA
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Masahito Zembutsu
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
Kenjiro Kubota
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
Preferred Networks
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
Yahoo!デベロッパーネットワーク
DockerとDocker Hubの操作と概念
DockerとDocker Hubの操作と概念
Masahito Zembutsu
MLflow + Kubeflow MLプラットフォーム事例 #sparktokyo
MLflow + Kubeflow MLプラットフォーム事例 #sparktokyo
Yahoo!デベロッパーネットワーク
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
NTT DATA Technology & Innovation
Apache Spark の紹介(前半:Sparkのキホン)
Apache Spark の紹介(前半:Sparkのキホン)
NTT DATA OSS Professional Services
PostgreSQL初心者がパッチを提案してからコミットされるまで(第20回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL初心者がパッチを提案してからコミットされるまで(第20回PostgreSQLアンカンファレンス@オンライン 発表資料)
NTT DATA Technology & Innovation
Katib
Katib
Yuji Oshima
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
NTT DATA Technology & Innovation
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
mosa siru
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Noritaka Sekiyama
Redisの特徴と活用方法について
Redisの特徴と活用方法について
Yuji Otani
Tendances
(20)
Marp Tutorial
Marp Tutorial
MapReduce入門
MapReduce入門
0から始めるコンテナの学び方(Kubernetes Novice Tokyo #14 発表資料)
0から始めるコンテナの学び方(Kubernetes Novice Tokyo #14 発表資料)
そんなトランザクションマネージャで大丈夫か?
そんなトランザクションマネージャで大丈夫か?
初心者向けMongoDBのキホン!
初心者向けMongoDBのキホン!
エンジニアの個人ブランディングと技術組織
エンジニアの個人ブランディングと技術組織
Dockerfileを改善するためのBest Practice 2019年版
Dockerfileを改善するためのBest Practice 2019年版
Akkaとは。アクターモデル とは。
Akkaとは。アクターモデル とは。
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
わかる!metadata.managedFields / Kubernetes Meetup Tokyo 48
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
HDFSのスケーラビリティの限界を突破するためのさまざまな取り組み | Hadoop / Spark Conference Japan 2019 #hc...
DockerとDocker Hubの操作と概念
DockerとDocker Hubの操作と概念
MLflow + Kubeflow MLプラットフォーム事例 #sparktokyo
MLflow + Kubeflow MLプラットフォーム事例 #sparktokyo
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
YugabyteDBを使ってみよう(NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料)
Apache Spark の紹介(前半:Sparkのキホン)
Apache Spark の紹介(前半:Sparkのキホン)
PostgreSQL初心者がパッチを提案してからコミットされるまで(第20回PostgreSQLアンカンファレンス@オンライン 発表資料)
PostgreSQL初心者がパッチを提案してからコミットされるまで(第20回PostgreSQLアンカンファレンス@オンライン 発表資料)
Katib
Katib
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
Apache Spark on Kubernetes入門(Open Source Conference 2021 Online Hiroshima 発表資料)
マイクロにしすぎた結果がこれだよ!
マイクロにしすぎた結果がこれだよ!
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Hadoop/Spark で Amazon S3 を徹底的に使いこなすワザ (Hadoop / Spark Conference Japan 2019)
Redisの特徴と活用方法について
Redisの特徴と活用方法について
En vedette
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
Couchbase Japan KK
The Graph Traversal Programming Pattern
The Graph Traversal Programming Pattern
Marko Rodriguez
「GraphDB徹底入門」〜構造や仕組み理解から使いどころ・種々のGraphDBの比較まで幅広く〜
「GraphDB徹底入門」〜構造や仕組み理解から使いどころ・種々のGraphDBの比較まで幅広く〜
Takahiro Inoue
負荷試験入門公開資料 201611
負荷試験入門公開資料 201611
樽八 仲川
Neo4j の「データ操作プログラミング」から 「ビジュアライズ」まで
Neo4j の「データ操作プログラミング」から 「ビジュアライズ」まで
Keiichiro Seida
脱RESTful API設計の提案
脱RESTful API設計の提案
樽八 仲川
Nosqlの基礎知識(2013年7月講義資料)
Nosqlの基礎知識(2013年7月講義資料)
CLOUDIAN KK
Webアプリケーション負荷試験実践入門
Webアプリケーション負荷試験実践入門
樽八 仲川
失敗事例で学ぶ負荷試験
失敗事例で学ぶ負荷試験
樽八 仲川
En vedette
(9)
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
今日から使えるCouchbaseシステムアーキテクチャデザインパターン集
The Graph Traversal Programming Pattern
The Graph Traversal Programming Pattern
「GraphDB徹底入門」〜構造や仕組み理解から使いどころ・種々のGraphDBの比較まで幅広く〜
「GraphDB徹底入門」〜構造や仕組み理解から使いどころ・種々のGraphDBの比較まで幅広く〜
負荷試験入門公開資料 201611
負荷試験入門公開資料 201611
Neo4j の「データ操作プログラミング」から 「ビジュアライズ」まで
Neo4j の「データ操作プログラミング」から 「ビジュアライズ」まで
脱RESTful API設計の提案
脱RESTful API設計の提案
Nosqlの基礎知識(2013年7月講義資料)
Nosqlの基礎知識(2013年7月講義資料)
Webアプリケーション負荷試験実践入門
Webアプリケーション負荷試験実践入門
失敗事例で学ぶ負荷試験
失敗事例で学ぶ負荷試験
Similaire à SQLまで使える高機能NoSQLであるCouchbase Serverの勉強会資料
Introduce couchbase server
Introduce couchbase server
Koji Kawamura
Couchbaseの紹介 2015/03/05
Couchbaseの紹介 2015/03/05
Couchbase Japan KK
Azure aws違い
Azure aws違い
Masanobu Sato
Windows azureって何
Windows azureって何
Kana SUZUKI
Couchbase introduction-20150611
Couchbase introduction-20150611
Couchbase Japan KK
Amazon RDS (MySQL) 入門
Amazon RDS (MySQL) 入門
Manabu Shinsaka
SQL Beginners Day #1 - SQL Server および Azure SQL のインストールと管理
SQL Beginners Day #1 - SQL Server および Azure SQL のインストールと管理
Oshitari_kochi
地方企業がソーシャルゲーム開発を成功させるための10のポイント
地方企業がソーシャルゲーム開発を成功させるための10のポイント
Kentaro Matsui
初心者向け負荷軽減のはなし
初心者向け負荷軽減のはなし
Oonishi Takaaki
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Daichi Ogawa
オンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみた
Masayuki Ozawa
Let's join in OpsWorks world!
Let's join in OpsWorks world!
Shigeo Nakano
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
terurou
Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219
Cloudera Japan
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
GoAzure
デスクトップ仮想化の実践 - powered by Windows Server 2016 & Azure - (Microsoft de:code 2016)
デスクトップ仮想化の実践 - powered by Windows Server 2016 & Azure - (Microsoft de:code 2016)
Takamasa Maejima
PPT Full version: 世界中のゲーム分析をしてきたPlayFabが大進化!一緒に裏側の最新データ探索の仕組みを覗いてみよう
PPT Full version: 世界中のゲーム分析をしてきたPlayFabが大進化!一緒に裏側の最新データ探索の仕組みを覗いてみよう
Daisuke Masubuchi
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Cloudera Japan
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
Microsoft Azure Japan
【dots. IT勉強会】開発環境のDocker化
【dots. IT勉強会】開発環境のDocker化
Yuki Kanazawa
Similaire à SQLまで使える高機能NoSQLであるCouchbase Serverの勉強会資料
(20)
Introduce couchbase server
Introduce couchbase server
Couchbaseの紹介 2015/03/05
Couchbaseの紹介 2015/03/05
Azure aws違い
Azure aws違い
Windows azureって何
Windows azureって何
Couchbase introduction-20150611
Couchbase introduction-20150611
Amazon RDS (MySQL) 入門
Amazon RDS (MySQL) 入門
SQL Beginners Day #1 - SQL Server および Azure SQL のインストールと管理
SQL Beginners Day #1 - SQL Server および Azure SQL のインストールと管理
地方企業がソーシャルゲーム開発を成功させるための10のポイント
地方企業がソーシャルゲーム開発を成功させるための10のポイント
初心者向け負荷軽減のはなし
初心者向け負荷軽減のはなし
Windows Server 2012 のストレージ強化とエンタープライズへの活用
Windows Server 2012 のストレージ強化とエンタープライズへの活用
オンプレのDbaがazureのデータベースを使ってみた
オンプレのDbaがazureのデータベースを使ってみた
Let's join in OpsWorks world!
Let's join in OpsWorks world!
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
スマートフォン×Cassandraによるハイパフォーマンス基盤の構築事例
Cloudera大阪セミナー 20130219
Cloudera大阪セミナー 20130219
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
A 1-3 awsのクラウドデザインパターンをwindows-azureに持ってきてみた
デスクトップ仮想化の実践 - powered by Windows Server 2016 & Azure - (Microsoft de:code 2016)
デスクトップ仮想化の実践 - powered by Windows Server 2016 & Azure - (Microsoft de:code 2016)
PPT Full version: 世界中のゲーム分析をしてきたPlayFabが大進化!一緒に裏側の最新データ探索の仕組みを覗いてみよう
PPT Full version: 世界中のゲーム分析をしてきたPlayFabが大進化!一緒に裏側の最新データ探索の仕組みを覗いてみよう
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
Impala + Kudu を用いたデータウェアハウス構築の勘所 (仮)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
S08 Microsoft Azure SQL Server の活用 (IaaS 環境における設定や運用)
【dots. IT勉強会】開発環境のDocker化
【dots. IT勉強会】開発環境のDocker化
SQLまで使える高機能NoSQLであるCouchbase Serverの勉強会資料
1.
Couchbase Serverを 半年使ってみた (株)ゆめみ 仲川樽八
2.
本スライドの目的 本スライドは(株)ゆめみ社内でCouchbaseServerに興味を持ってもらうための勉強会で使用し た資料の公開版となります。 社内で、システムのメンテナーを増やすことで自分が楽をしたいという個人的な狙いが主目的と なりますが、こういった形で情報共有することにより、国内での利用がもっと盛り上がってもらえ ればそれに越したことはありません。
3.
What is Couchbase Server
4.
Couchbase Serverの特徴 (その1)
5.
Couchabe 3.x系 • NoSQL •
他のNoSQL製品と比べても速いよ • ノード追加でどこまでもスケールするよ • データ量 • CPU資源・メモリー資源 • データ冗長度を高く設定できるよ。(AZ間で持てるのでZone障害でデータロストしない) • XDCRという機能があって、リージョン感で双方向レプリケーションできるよ。(海外に待機系シス テムを構築すれば東京リージョン全滅でも大丈夫) • elasticsearch連携すれば横断検索も出来る • SDKの完成度が高くて信頼性があるよ。 • WebConsoleの出来が異様にいいよ。
7.
Couchbase 4.x系 2015年10月頃に正式リリース • NoSQLなのに、N1QLというSQLが使える!! まさにNot
Only SQL NoSQLなのに、ドキュメントを横断検索した結果でUpdateなんてことも出来る。 いろいろ妄想が広がる • Couchbase3.x系→4.x系のバージョンアップもXDCR機能などを使えばダウンタイムゼロで可 能!!
8.
良いことだらけじゃないか!!
9.
Why Japanese Peopleは もっとCouchbase
Server使わない の?
10.
と切れる前に、
11.
それ、RDBで出来ない?
12.
ソリューション選定の鉄則
13.
候補ソリューションの メリットに目を奪われてははならない。
14.
必須要件の中に出来ないことが一つでもあるのであれ ば、そのソリューションは選んではならない。 それを忘れたものは地獄の業火に焼かれるであろう。 Taruhachi (1975~)
15.
Couchbase Serverの特徴 (その2)
16.
特徴(地雷) • 大事なデータを扱おうとするとライセンス版がほぼ必須。 • 冗長化すると最小構成でもかなりリッチな構成になる。 •
Couchbase社、日本法人撤退しちゃった。 • トランザクションレス(多くの場合致命的) • データの中身の検索が弱い。Unique 制約等が貼れない。 • elasticsearch連携できるが、、、。 • N1QLでSQLが使えるが、、、。 • データの外部連携が面倒。
17.
結論から先に言うと、 どうしてもNoSQLでないといけない案件の時には積極的に検討したい。 ただし、RDBが使えるのであれば、悪いことは言わないので使っておこ う。
18.
それでも茨の道を歩みたい人、 歩まなければならない運命を持った人 は続きのスライドをどうぞ。
19.
各地雷は ・アプリケーションの実装で踏み抜く ・運用でカバーする のいずれかで対応する必要があります
20.
大事なデータを扱おうとすると ライセンス版がほぼ必須。 特徴(地雷)
21.
以下の機能はノード単位でライセンス費用が必要となる。 ※ Oracleよりはかなり安いですが、、、small startな案件には厳しいかも。 •
XDCR機能 複数のCouchbaseCluster間でデータのレプリケーションを行う機能 リージョンをまたいで双方向のレプリケーションも可能 ダウンタイム無しでのバージョンアップや、CouchbaseClusterの切り替えなどにも便利 • クラスタ中のノードのグループ化する機能 ノードをグループ化することにより、該当ノードのデータの複製先を必ず別のグループのノードに割り当てる という指定が可能。AZ(データセンターに相当)を指定することでAZ障害においてもデータが欠損しなくなる。
22.
冗長化すると最小構成でも かなりリッチな構成になる 特徴(地雷)
23.
各AZに2台のノードを配置、それを複数AZに展開することで初めて十分な冗長化とオートフェールオーバー 機能が利用できる。 ※Split Brain状態を防ぐため、オートフェールオーバーが機能するのは最初の1台のダウンだけ。 Availability Zone
Availability Zone 最小構成で4ノード、4ライセンス ※ただし、バケット数の制限はないので複数の 案件でクラスタを共有することは可能
24.
Couchbase社日本法人撤退しちゃった 特徴(地雷)
25.
日本における先行きは不透明な感じ。 特にCommunity版の将来は日本語ドキュメント量にかかってきそう。 ただし、英語ドキュメントならそれなりにあるので頑張れば日本でのコ ミュニティーも存続できるかも!!
26.
トランザクションレス 特徴(地雷) Foundation DB という、 NoSQL
but ACIDを標榜していた製品があったのですが、、、。
27.
トランザクションレス • (NoSQL製品では当たり前ですが、)トランザクション使えません。 • 複数のデータオブジェクト間のデータ整合性は取れません。 ※CASは使える、AtomicCounterも使える •
お客様にもいろいろ諦めて頂く必要がある。 • 何を諦めて頂く必要があるかは具体的に全て洗い出して、個別で了承をとって頂く。 • 、、、こうすればNoSQLでもデータ整合性を担保できる系の記事は全部眉に唾つけて読んでいます。 • 全ての更新をキューに入れて、成功するまで更新操作を繰り返すという実装は不採用。 ※この方法でも新たに別の問題が発生するのでその問題を踏み抜くメリットとの相談。
28.
トランザクションレス データの更新順序などを厳密に定義して、それぞれの不整合状態を洗い出し、不整合発生後も自動的に修復を図れ るようにアプリケーション側で全て実装する。 ※これを全てのデータ操作に関して定義、確認した上で実装も正しくされていることを担保する必要がある。 Doc A Doc B Doc C Doc D Doc A 更新中ステータスにする 更新 新規追加
削除 更新完了状態にする この間で発生したデータ不整合は 失敗とみなし、アプリケーションには失敗ステータスを返す この間で発生したデータ不整合は 成功とみなし、アプリケーションには成功ステータスを返す 次回のアクセスで自動修復する 例
29.
トランザクションレス 構築されたシステム内のデータの整合性を基本的に信用出来ない。 • 外部システム側で発生したエラーも全て内部のデータ調査が必要となるが、KVSなので都度調査ス クリプトを作成する必要がある。 • 身の潔白を証明する責任が非常に大きい。(だいたい緊急調査) •
最後のデータの突き合わせ調査が終わるまでは自分自身が疑心暗鬼。 • 実際に不整合データが発生していたら、場合によっては完全に終わる。 →データ不整合修正プログラムを作って頑張る。
30.
データの中身の検索が弱い。 Unique 制約等が貼れない。 特徴(地雷)
31.
• データはJSONドキュメントとして保存しますが、JSONドキュメント中の特定のvalueを利用して の検索ができません。(Viewという機能はあるけど非同期であり使いどころが難しい) • また、Valueに対するユニークキーなども貼れないため、ユニークであることを担保するために は別に逆引きのIndexドキュメントを作成しなければなりません。(テーブル間のリレーション毎 に逆引きのためのカラムを別途設ける) •
上記の理由により、本来同一で良いドキュメントが複数に分割されますので、更新しなければ ならないドキュメント数は増えるのですが、ここで先程述べたトランザクションレスの呪いが降り かかります。
32.
elasticsearchとの連携ができるが、、、 特徴(地雷)
33.
XDCR機能で、Couchbaseの更新を 全てelasticsearchにレプリケーションする事が可能だが、 実データ Index data XDCRデータ更新 横断検索なんて出来ねぇよ!! 横断検索は任された!!
34.
XDCR該当ドキュメントの更新さえすれば良い 該当ドキュメントを展開して各 valueをNgramでインデックス 化 古いインデックスも全て整理 Couchbaseの仕事量 <<
elasticserachの仕事量 検索要件を絞り込んでおかないと、全てにIndexを張る 必要が出てくるため、、、
35.
• Couchbaseの高い更新能力にelasticsearchのIndex更新能力が全くついてこれない。 • 当然大きなレプリケーション遅延が発生する。 •
ElasticSearch側のIndexとCouchbase上の実データの乖離が大きくなりすぎるのをアプリケー ションで担保しなければならなくなる。 →使えねぇ!!!!!ということで使いませんでした。 →じゃぁ、どうやって検索要件を満たしたかは後述
36.
N1QLでクエリが使えるが、、、 特徴(地雷)
37.
• N1QLを使うなら、1テーブル =
1バケットの考え方で実装しておきたい。 • JOINが面倒、コストが高い(JOIN先は必ず別のドキュメントのキーである必要がある) • 検索要件に合わせてIndexを増やすと、物理メモリを大量に消費するので高コストとなる。 • Selectされる結果セットが数万件以上になると異様に遅くなり実用に耐えない。 • すぐにタイムアウトする • Index更新が非同期でSelect条件と得られる結果がズレたりする • 大量データのExportには向かない。 (巨大なJSONドキュメントとして結果が得られる。落ちる、ページングしてる間にデータが更新される。) • N1QLのご利用は計画的に
38.
データの外部連携が面倒 特徴(地雷)
39.
VIEW機能も使いにくいし、 N1QL使っても大量データ出力には向かない。 →RDB(MySQL)にデータ連携しちゃえ
40.
RDBなら • トランザクションが使える!! • 比較的安価 •
柔軟なSQLがあとからいくらでも書ける • 大量データ出力に強い(行フェッチが可能) • 開発者多い • N1QLとは比較にならないくらい高速 • レプリケーションも楽 • 調査が楽 • データの断面が取れる • ぶっちゃけ何やるにも楽
41.
Couchbaseのデータを RDBにレプリケーションしよう
42.
RDBへのデータ連携が出来ると後が楽 外部システム A 外部システム B S3 Embulk等 Semi
Realtime Replication Couchbase利用システ ム 横断検索 Search API FTP MySQL Replication データ外部連携システム 外部システム C ※このAPIも外出しは可能 ※更新差分データ提供
43.
問題はここの部分だけ Semi Realtime Replication Couchbase利用システ ム
44.
基本的な考え方 1. Couchbase上のドキュメントを更新する際にレプリケーション対象としたいドキュメント(※)には全て _microtimeという更新時刻を残すようにアプリケーションを構築する。 ※逆引き用Indexなどはレプリケーション対象とする必要がないので不要。 2. 既にRDBに存在する最新の_microtimeより新しい更新時刻を持つドキュメントを、_microtimeのより古い方 からN件取得する。(N1QLを利用する) 3.
上記のドキュメントをRDB上の対応するテーブルに同一トランザクション内でReplaceをかける。 ※失敗時にはロールバックさせて次のプロセスの処理対象とする。 → 2. へ戻る
45.
レプリケーションをもう少し詳しく言うと、 N1QLで更新差分データのみをN件抽出 例:1000件毎 Data Service Index Service 非同期でIndex更新 同一トランザクションでN件全部Replace Couchbase利用システ ム Query
Service
46.
ところが、 N1QLで更新差分データのみをN件抽出 Data Service Index Service 非同期でIndex更新 同一トランザクションでN件全部Replace Index更新遅 延 Couchbase利用システ ム Query
Service 川
47.
レプリケーションされないデータが出てきた。 Couchbase上の更新はN1QLのIndex更新キューに積まれ、その後実際にIndexが更新されるが、 アプリケーション側から入れた_microtimeは実際にキューに入った順番とは異なる可能性がある。 ※アプリケーションサーバが複数台あるため この時、既にレプリケーションされたデータより古いデータが後から届くことがあるが、それは次回の検 索対象とはならない。 Index更新の最終行付近のデータが信用出来ないので、N1QLのIndex更新が実際にはどこまで終 わっているかを正確に知る必要がある。 → 更新チェック用のドキュメントを作成、それをバッチで毎秒更新した上でN1QLのIndex上の時刻 を調査することで対応。した。
48.
N1QL Index上のデータ参照方法 USE INDEXを利用したクエリを発行し、SELECTの中身にINDEX中で指定したカラムのみを指定することで、実 データへのアクセスをせずに、Index上のデータを取得することが可能。(Explainで確かめる) Explain
SELECT max(_microtime) FROM `【バケット名】` USE INDEX (`idx_doctype_microtime`) WHERE doctype='N1QL_INDEX_CHECKER’; → “expr”: “cover((`accountpf-ph1`.`_microtime`))”となっている場合は、Index上のデータをそのまま利 用している。 そうなっていない場合は実データへのアクセスが発生している。
49.
それでも、やっぱりRDBへの投入って遅れるよね N1QLで更新差分データのみをN件抽出 Data Service Index Service 非同期でIndex更新 同一トランザクションでN件全部Replace データ更新遅延 高負荷時においても 5分以内に更新完了 Couchbase利用システ ム Query
Service
50.
リソース使用状況 (RDSレプリケーション用WRITEスループット) 予めcouchbaseバケットに対して各テーブル 1000万件程度のデータを投入していた状態 のレプリケーション状況。 RDS for MySQLを利用した場合、レプリケー ション開始から暫くの間は数千records/sec でのレプリケーションがされるが、途中から Write
Operationに上限が観測され、 300records/sec程度でのレプリケーション しか行えなくなっている。 これをインスタンスタイプをスケールダウンし、 1000PIOPSを確保すると、スループットの向 上が見受けられ、2000req/sec程度のレプ リケーションが可能となった。 MySQL r3.2xlarge MySQL m4.xlarge 1000PIOPS Write operationに上限が観測され る 暫くは速い 安いインスタンスのほうが速い
51.
RDS for MySQLは高負荷状態が続くと WriteOperation速度に制限がかかってしまう。 ※短期間の場合はOKであることに注意 →インスタンスタイプを下げてでもPIOPSを購入することでこの状態の 解消が可能だが、この状態ではまだ遅い。
52.
ついでにRDS for Auroraも試してやれ
53.
リソース使用状況 (RDSレプリケーション用ネットワークスループット) 予めCouchbaseバケットに対して各 テーブル1000万件程度のデータを投 入していた状態のレプリケーション状況。 ※Auroraの方が安いインスタンス 全体的にAuroraの方がスループットが 高く、先にレプリケーションが完了してい ることがわかる。 Aurora5時間、 MySQL 9時間 Aurora r3.xlarge MySQL m4.xlarge レプリケーション完了
54.
リソース使用状況 (レプリケーション用RDS空きメモリ) Auroraの方が空きメモ リに余裕がある状態で あるため、検索用index がオンメモリとなることが 多い。 ※どちらもメモリから落ち た時は検索にかなりの 時間が必要となる。 Aurora r3.xlarge MySQL m4.xlarge
55.
Auroraなら安いインスタンスでもレプリ ケーション遅延がほとんど発生しない!! ※フロントのAPIに対して数万req/sec の負荷試験を行っている状態。(更新は数千req/sec)
56.
ベストソリューションの選定は やってみないとわからないので 簡単なものならまずやってみよう。 ※試験段階なら、RDS for MySQL
と AURORAの変更はすぐ
57.
ただし 更新データの検知をレプリケーションするというこの方法では、物理削 除されたデータがレプリケーション対象とならないことに注意する。 →どうせCouchbase上でリレーションデータは相互に握っているので そちらもレプリケーションさせて後から突き合わせる等の対策が必要。
58.
結論 重要なデータをNoSQLに格納するという使い方は、必要に迫 られないかぎり敢えて手を出さないのが無難。 でも、どうしても使いたい場合にCouchbaseServerは非常 に良い選択肢となりうる。 なぜならば、Couchbase→MySQLへのレプリケーションをす るというソリューションを手に入れたから。
59.
素材は http://www.irasutoya.com/ さんのものを利用させて頂きました。
Télécharger maintenant