目次

まえがき

本書の構成
リポジトリーについて
表記関係について
免責事項
底本について

プロローグ: データベース選択を巡る対話

はじめに

Couchbaseについて
Couchbase Serverについて
エディションとオープンソースプロジェクト
関連データベース技術

第1章 Couchbase Serverとは何か

1.1 Couchbase Serverの歴史
1.2 NoSQLと現在の技術動向
1.3 メモリーファーストアーキテクチャー
1.4 JSONデータベース
1.5 トランザクションとNewSQL
1.6 第一正規化制約を超えて

第2章 Couchbase Serverを使ってみる

2.1 インストール
2.2 Dockerコンテナ利用
2.3 クラスター初回構築
2.4 Webコンソールの使い方
2.5 クラスター構成変更

第3章 データ

3.1 ドキュメント
3.2 バケット
3.3 スコープとコレクション
3.4 有効期限設定

第4章 N1QLクエリ

4.1 基本構造
4.2 ドキュメントキーの利用
4.3 フィールドから値のみを取り出す
4.4 複数の値をまとめて扱う
4.5 配列へのアクセス
4.6 配列を検索条件に利用
4.7 サブドキュメントの階層操作
4.8 データ型
4.9 比較演算
4.10 結合(JOIN)
4.11 ユーザー定義関数

第5章 インデックス

5.1 概要
5.2 プライマリインデックス
5.3 セカンダリインデックス
5.4 配列インデックス
5.5 インデックス論理設計
5.6 インデックス物理設計
5.7 先行属性マッチと性能最適化

第6章 アーキテクチャー

6.1 分散アーキテクチャー
6.2 スマートクライアント
6.3 XDCR(Xross Data Center Replication)
6.4 サーバーグループ

第7章 Couchbase Serverの構成要素

7.1 Dataサービス
7.2 Queryサービス
7.3 Indexサービス
7.4 クラスターマネージャー
7.5 マスターサービス

第8章 セキュリティー

8.1 主要なセキュリティー要素
8.2 セキュリティー管理項目
8.3 認証
8.4 認可
8.5 暗号化

第9章 フェイルオーバー

9.1 フェイルオーバー概観
9.2 自動フェイルオーバー
9.3 手動フェイルオーバー

第10章 運用

10.1 監視
10.2 バックアップ

第11章 コマンドライン操作

11.1 基本
11.2 クラスター管理: couchbase-cli
11.3 クエリ: cbq
11.4 データのインポート: cbimport
11.5 データのエクスポート: cbexport
11.6 バックアップ: cbbackupmgr

第12章 ユーティリティ

12.1 概要
12.2 ストレステストツール
12.3 その他のツール

第13章 環境設定

13.1 メモリーからのデータ排出(Ejection)
13.2 コンパクション
13.3 代替アドレス

第14章 SDKと外部システム連携

14.1 SDK
14.2 外部システム連携

第15章 Node.jsアプリケーション開発

15.1 なぜ、Node.jsとCouchbase Serverの組み合わせなのか
15.2 キーバリュー操作
15.3 データ一貫性(Consistency)
15.4 サンプルアプリケーション紹介
15.5 Node.js SDKを開発に利用する
15.6 ODMフレームワーク Ottoman.js
15.7 開発の実践に向けて

付録A NoSQL性能評価: MongoDB、Cassandraとの比較

A.1 ベンチマーク概要
A.2 検証パターン別詳細
A.3 結論

付録B データマイグレーションツール

B.1 GlueSync
B.2 Couchgres
B.3 SqlServerToCouchbase

まえがき

本書の構成

 本書は表現や内容、あるいは直接的に想定されている読者層について、傾向の異なるいくつかの部分からなります。

 本書の導入部は「プロローグ」と題されており、二人の登場人物の対話の形式で書かれています(底本には含まれていない新規書き下ろし部分になります)。ここでは、実践的な観点から特に重要と思われる情報を効率的に、そして願わくば親しみやすさとともに伝えることが目指されています。

 プロローグに続く、「はじめに」では、以降の章を読み進めるにあたっての前提を整理しています。

 第1章は、第2章以降とは若干趣が違う内容となっています。ここでは、Couchbase Serverの存在意義を伝えることに主眼が置かれています。そのため、Couchbase Serverがその潮流の一部であるような、現在の技術的背景の記述についても多くを充てています。Couchbase Serverの存在意義を一面的に語ることができないことを反映し、この章を構成する節は相互に独立し、基本的には、別々に読まれても成立する内容になっています。

 第2章以降については、一般的な解説書の構成と大きく異ならないものとなっているかと思います。

 第2章では、初めてCouchbase Serverを利用するユーザー向けに、検証・開発環境を構築する方法を説明しています。

 第3章から第5章は、データベース利用者(開発者)にとって必要となる情報、すなわちデータの論理構造、クエリ操作、そしてクエリ実行の前提となるインデックスに関する章となっています。

 第6章から第8章は、アーキテクチャー、Couchbase Serverを構成する要素(コンポーネント)、そしてセキュリティーについて解説しており、Couchbase Serverの全体像把握に資する内容です。

 第9章から第13章は、フェイルオーバーやバックアップ等の運用や環境設定に関する内容に充てられています。

 第14章は、Couchbase Server SDKと、外部システム連携のためのコネクターを紹介する短い章となっています。

 最後の章となる15章は、具体的なアプリケーション開発を主題としています。

リポジトリーについて

 本書で紹介しているサンプルアプリケーションのソースコードを以下のURLで公開しています。また、このリポジトリーを、本書に関する情報共有のために、必要に応じ更新・活用する予定です。


 https://github.com/YoshiyukiKono/Couchbase_Server_First_Step_Guide.git

表記関係について

 本書に記載されている会社名、製品名などは、一般に各社の登録商標または商標、商品名です。会社名、製品名については、本文中では©、®、™マークなどは表示していません。

免責事項

 本書の文責は著者にあり、所属する組織とは関係ありません。

 また、本書に記載された内容は、情報の提供のみを目的としています。正確かつ適切な情報を届けるため配慮を尽くしていますが、本書の内容の正確性、有用性等に関しては、一切保証するものではありません。したがって、本書の情報を用いた開発、運用、コンサルティング等、いかなる実践も必ずご自身の責任と判断によって行ってください。本書の情報を参照した行為の結果について、著者はいかなる責任も負いません。

底本について

 本書籍は、2021年7月10日から25日まで開催された技術系同人誌即売会「技術書展11」で頒布された「オープンソースJSONデータベース Couchbase Server ファーストステップガイド」を底本とし、2021年7月末にリリースされたCouchbase Server 7.0にあわせた情報の更新を行った他、全面的に改訂しています。

プロローグ: データベース選択を巡る対話

 ここはある技術系ミートアップ会場、有志によるLT(ライトニングトーク)が行われた後のフリータイムに、各所で思い思いの会話がなされています。

 その一角で、また新しい対話が始まります。


 「先ほど発表された内容、とても勉強になりました」

 「ありがとうございます。あなたの新しいアプリケーションの構想も、なかなか興味深かったですよ」

 「そうですか!まだ、アイディアでしかないんですけどね。ところで、少し相談させてもらってもいいですか?」

 「自分でよければ」

 「ありがとうございます!かなり漠然とした相談になってしまうのですが、先ほど発表したアプリケーションのプロトタイプを開発するに当たって、どのデータベースを使うか悩んでいます。データベースについて、広い知見をお持ちのようでしたので……」

 「広いかどうかはわからないけど。どんな部分で悩んでいますか?右も左もわからないという感じではなさそうだけど」

 「あまり深く考えずに、とりあえず作り始めるとしたら、何か適当なRDBを使うと思うんですよね……」

 「はい」

 「プロトタイプを作っている間、データモデルについては試行錯誤すると思うんです。それだけなら、テーブル定義を修正しながら進めてもいいんですが……」

 「ふんふん」

 「プロトタイプとはいっても、可読性と保守性の高いコードを維持したいんです。これは絶対に!」

 「いいですね」

 「だから、ドメインエンティティーを素直に反映したデータモデルでコーディングを進めたくて、RDBでデータを扱う際の制約とは切り離しておきたいんです」

 「わかります」

 「それで、ORM(オブジェクトリレーショナルマッピング)について考え始めると、特定の技術への偏りと、そのための負担が、煩わしくなってくるんですよね」

 「そういうことですね。今の話を聞くと、すでに何かRDB以外で検討していそうだけど、どうですか?」

 「はい。ドキュメント指向データベースというんですか?JSONを保存できるデータベースなら、アプリケーションで扱っているエンティティーと同じ構造のデータを保存できると思ったんですが……」

 「そうですよね。だけど?」

 「それはそれで、実際に開発を始めようとすると、また別の技術的な偏向というか、負担が気になるんですよね……」

 「ドキュメント指向データベースは、開発の面について、SQLのように標準化されているわけではないですからね」

 「そうなんです!仕方がないんですかね?」

 「それでは、まず確認ですが、クラウド利用については、どう考えていますか?」

 「もちろん、いずれクラウドは有効に活用したいと思っていますが、今は、特定のクラウドベンダーに縛られたくはなくて。開発中は、ラップトップで完結させたいと思っています」

 「それでは、クラウドベンダー独自の技術は自ずと除外されるとして……」

 「何か思い当たりますか?」

 「Couchbaseって、聞いたことあるかな?」

 「う〜ん、名前だけは聞いたことがあるような……Apacheプロジェクトでしたっけ?」

 「いや、Apache CouchDBというのはあるけど、それとは別のオープンソースのデータベースです」

 「知ったかぶりして恥ずかしい!」

 「いやいや。たぶん、名前はどこかで聞いていたんでしょうね」

 「改めて、何も知らないものとして教えてもらえますか?」

 「それでは、お話を伺って、興味を持たれるかもしれないと思ったCouchbaseの特徴について挙げていきますね」

 「お願いします!」

 「まずは、JSONドキュメントを扱うドキュメント指向データベースの中でも、多くのプラットフォームで稼働するオープンソースのテクノロジーであるということ」

 「それは、私の希望しているところでもあります」

 「それから、開発の面で、SQLを使えるところ……」

 「そこを詳しく教えてもらえますか!いろいろなRDB以外のデータベースがクエリを使えると謳っていて、少し調べると、なんだか……」

 「期待していたものと違う」

 「そうなんです。よく理解できていないだけなのかもしれませんが……逆に、RDBがJSONに対応した、というケースもありますよね。どちらもなんだか、しっくりこないんです」

 「SQLをJSON用に拡張するときのひとつの方法として、JSONを扱うための関数を追加する、というものがあります。この場合、純粋なSQLのシンタックスは保持されますが、JSONデータから発想している開発者にとっては、期待しているものとのギャップがあるのではないかと思います」

 「はい」

 「一方で、関数の追加ではなく、SQLのシンタックス自体をJSONデータ構造用に拡張するというアプローチがあります」

 「全然違いますね」

 「JSONの特徴として、配列やネストされたデータが扱えるということがありますよね」

 「はい、わかります」

 「たとえば、SQLのクエリで直接、配列の表現が使えたり」

 「ははあ」

 「オブジェクトのプロパティーにドット表記でアクセスできたり、普段から開発者がプログラミングで用いている表現が使えれば直感的ですよね」

 「そうですね」

 「先ほど、期待していたものと違うという話がありましたが、何が一番ギャップとして大きいと感じますか?」

 「当然の質問だと思うんですが、正直、よく説明できないんですよね……」

 「意地悪な質問だったかもしれませんね。今、話したようなデータ構造の違いだけなら、関数でも吸収できるでしょう。だけど、データ単体ではなく、複数のデータを扱うことを考え始めると、話が違ってきます。端的にいえば、データを結合できるかどうかが問題になると思うんです」

 「何となくわかるような気がします」

 「JSONがネストした構造を持てるからといって、関係する全てのエンティティーをひとつのドキュメントとして保存するのは、現実的ではありませんよね」

 「確かに。できることと、やるべきことの違いですね」

 「参照キーでデータ間の関係を表現するのは、リレーショナルモデルの中心にある発想ですが、データモデルの設計としては、RDBのテーブルに限らず、他のデータ構造でも適用可能な考え方です」

 「それはそうですね」

 「後は、複数のデータを結合してデータを取り出せるかどうか?という話になってきます」

 「ふむふむ」

 「その点、CouchbaseのN1QL(ニッケル)は、期待されるものを実現しています」

 「ニッケル、ですか?」

 「Couchbaseのクエリの呼称です。Non 1st normal form Query Languageの略で、N1QLと書いて、ニッケルと読みます」

 「なるほど。JSONは、RDBのように第一正規化が必要ないから、非第一正規形クエリ言語、というわけですね」

 「そうそう。今、第一正規化が必要ない、といわれましたよね。必要ないだけで、逆に第一正規化されている、つまり普通の表形式のデータであっても何の問題もない、というのがポイントです」

 「というと?」

 「たとえば、既存のリレーショナルデータベースで扱っているデータを、データモデルを変えずに、JSONデータとしてCouchbaseに移植した場合には、RDBで使っていたのと全く同じSQLを使う、といったことも可能になってきます」

 「へえ。なんとなく、技術的に偏った方向に振れすぎる、という心配を解消してくれそうな気がしてきました」

 「うん、極端な話、Couchbaseでプロトタイプを作った後、RDBに移行するということも、設計次第で成立させられると思いますね。メリットがあるかどうかは別として」

 「面白いですね。実際にありそうではなくても、そういうことも考えられるくらい汎用性があって、標準的な知識を活かすことができる、というのは魅力的だと思います」

 「標準という意味では、SQL++1という準構造化データへのクエリに関する標準規格があって、ApacheプロジェクトにもAsterixDB2というSQL++を採用しているデータベースがあります。CouchbaseのN1QLは、SQL++と全く同じものではないけど、多くの共通する部分を持っています3

 「それは、悪くない情報ですね」

 「ご相談に直接関係する部分としては、こんなところですかね。お役に立てたでしょうか?」

 「はい、ありがとうございます」

 「あと、Couchbaseを使ったNode.jsのサンプルアプリケーションを持っていますが、見てみますか?」

 「ぜひ!」

 「Couchbaseとアプリケーションを起動しますね……画面はこんな感じです。ご覧の通り、とても単純なユーザー管理アプリケーションです」

 「これくらい簡潔だと、内部で行われていることを理解しやすそうですね」

 「これがソースです」

 「ユーザーのリスト表示に使っているクエリがこれですね。確かに普通のSQLと同じですね」

 「他には、ユーザーの追加と削除しか機能がありませんが、それはこのあたりです」

 「INSERTやDELETEのクエリを使うわけではないんですね」

 「使うこともできるけどね。データを直接操作して済むなら、わざわざ文字列でクエリを渡して、サーバーでそれを解析してから実行して……そんな必要はないということですね」

 「ORMを使っているときと似ているかも」

 「こういう部分、ORMではSQLを隠しますよね。ここではそういったラッパーを使っていないので、リソース消費の上でも、知識習得の面でも、余計なオーバヘッドを避けることができる、といえるんじゃないかな」

 「なるほど」

 「反対に、データを検索するときには、SQLの方が開発者にとって直感的なのに、ORMを使うために余計な苦労を強いられることもあるんじゃないですか?」

 「わかる気がします。私がRDBとORMの組み合わせを前提に開発を進めることに二の足を踏んでいたのも、そんなところです」

 「ここまでのところ、どうですか?」

 「プログラムを見せていただいたので、具体的にイメージが掴むことができました。コード量もこれだけで、他にフレームワークやライブラリーは使っていないんですよね?」

 「はい。データベースアクセスに関して、Couchbaseライブラリーのみを使っています。はじめにクラスターへの接続を確立しておいて、必要なところでデータ表示のためのN1QLクエリと、データ操作のためのAPIコールを行っています」

 「ここで使っているのはとても基本的なクエリですが、自分でもっと複雑なことをする場合もSQLが使えるから、応用が効きそうです」

 「役に立ちそうですか?」

 「はい!何より、シンプルなのが気に入りました」

 「それはよかった。そうそう、今見てもらったように、開発環境をラップトップで完結させたい、という要望にも適っていると思います」

 「ちなみに、本格的な運用ではどうなりますか?」

 「NoSQLという言葉は聞いたことがあると思いますが、Couchbaseは、NoSQLにカテゴライズされるデータベースです。他のNoSQLデータベースと同じように、複数のノードからなるクラスターとして構成されます」

 「ああ、それ!そのクラスターというところなんですが……やっぱり構築とか大変ですよね?」

 「そんなことありませんよ。Couchbaseのいいところは、他の分散データベースのように、マスターとワーカーとか、レプリカセットのような特別な構成が必要ないことです。全てのサーバーに同じものをインストールします」

 「すみません、構築が他のNoSQLより簡単ということですが、今ひとつ、どこが違うかがわからなくて……」

 「データベースを複数台で構成する利点として、データを複製して持つことと、データを分散して持つことがあります。この違いについては、わかりますか?」

 「データが複製されているからひとつが失われても大丈夫だし、データが分散されているから処理も分散できる、ということですよね」

 「そうですね。そして、多くのNoSQLでは、データを分散する方法がデータのキーの設計に関係してきます」

 「キーをどのように決めるかによって、複数のサーバーへのデータの散らばり方が変わってくるということですね。NoSQLでは、どんな検索条件が使われることになるかを踏まえてデータベースを設計する必要がある、という話を聞いた覚えがあります」

 「Couchbaseでは、物理的なデータの分散方法とキーの設計が独立しているのが特徴です。つまり、キーの設計による性能への影響がない、ということですね。これは、データの物理配置に影響を受けないアーキテクチャーになっているからです。それだけでなく、他のデータベースと比べて、性能面で優位なアーキテクチャーで……という話は、長い話になってしまうので置いておくとして……データ設計を行うアプリケーション開発者にとっては、分散環境の構成に関する知識を前提とする必要がない、という利点があります」

 「アーキテクチャーについての話も興味はありますが、まずはプロトタイプ開発なので、またそのうちに……データの論理設計と物理設計が切り離されているのはいいですね!」

 「それで、どこが違うかがわからないという話に戻ると、確かに本番環境の構築となると神経を使うところはあると思います。Couchbaseの場合、開発用に1ノードで構成されたクラスターを使っているときと、本番環境で複数ノードのクラスターを構築したときとで論理的な構成が変わらない、お言葉を借りるなら、シンプルなシステム構成になっています。これは、開発される立場から見てもそうであるように、構築する際にも利点となります」

 「なるほど、そういうことですね」

 「他に気になるところ、ありますか?」

 「今は大丈夫です。簡単に使い始められそうなので、まずは触ってみたいと思います」

 「そうですか。それでは、私からもいいですか?」

 「何でしょう?」

 「LTで発表されていたアプリケーションについて、聞いてみたいことがあるんですが……」

 「何でも聞いてください!」


 それぞれの関心を交差させながら、会話はさらに続くようです……

1. https://arxiv.org/abs/1405.3631

2. https://asterixdb.apache.org/

3. 上に紹介した論文でもN1QLに触れられており、「syntactic sugar over SQL++」という表現が見られます。

はじめに

Couchbaseについて

 Couchbaseという名称で名指される技術には、大きくいって、次のふたつがあります。


 ・Couchbase Server

 ・Couchbase Mobile


 Couchbase Serverは、分散JSONドキュメントデータベース(distributed JSON Document database)です(ここでの英語による引用は、Open Source Projects from Couchbase1より)。Couchbase Mobileは、Couchbase LiteとSync Gatewayというふたつの技術を包含する呼称です。Couchbase Liteは、モバイル端末および組み込みデバイス用のネイティブドキュメントデータベース(native document database for mobile and embedded devices)です。Sync Gatewayは、Couchbase MobileのデータをCouchbase Serverと同期するために使うことができるコンポーネント(components to sync to Couchbase Server)です。

Couchbase ServerとCouchbase Lite

 Couchbase Liteは、組み込み用ネイティブデータベースとして、プラットフォーム毎に開発されています。そこから明らかな通り、Couchbase ServerとCouchbase Liteはそれぞれ異なる技術を基盤としています。「ドキュメント指向データベース」であることは共通しているものの、Couchbase Serverに関する本書の記述を、Couchbase Liteへ援用することはできません。

Couchbase Serverについて

 Couchbase Serverは、ドキュメント指向データベースにカテゴライズされるNoSQLデータベースであり、シェアードナッシング型の分散アーキテクチャーを持ちます。

 NoSQLと呼ばれるデータベースは、ビッグデータの集計処理や、IoTのようなリアルタイムかつ大量のデータ投入等、データベース毎にカバーするユースケースが異なっています。Couchbase Serverはデータに対して、リード・ライトの両方のアクセスを、低遅延で実現する必要のある(つまり、インタラクティブな)アプリケーションのバックエンドとして用いられるために設計(最適化)されています。

本書で扱うCouchbase Serverのバージョン

 本書の記述は、2021年7月にリリースされた、Couchbase Server 7.02に基づきます。なお、本書執筆時点の最新バージョンは、2021年9月にリリースされた、バグフィックスを含むメンテナンスリリースである、Couchbase Server 7.0.13です。

エディションとオープンソースプロジェクト

 Couchbase Serverは、エンタープライズエディションとコミュニティーエディションの、ふたつの形態でバイナリが提供されており、その基盤としてオープンソースプロジェクト4が存在しています。

 コミュニティーエディションは、一部の特別な機能を除いて、エンタープライズエディションの主要な機能を利用することができ、それらの機能について移植性が確保されています。つまり、コミュニティーエディションを利用しているアプリケーションは、コードを変更することなく、エンタープライズエディションに移行可能です。一方でエンタープライズエディションには、エンタープライズレベルの高い性能要件を満たすために、内部機構において、コミュニティーエディションとの違いがいくつか存在しています。また、コミュニティーエディションでは、クラスターを構成するノード数についても制限(最大5ノードまで)があります。

 コミュニティーエディションは、エンタープライズエディションのメジャーリリースと同時にリリースされます。マイナーバージョンは数か月遅れてリリースされ、メンテナンスリリースについても、限定されています。

エディションに関する本書の記載方針

 本書の記述は、基本的にコミュニティーエディションに基づいていますが、エンタープライズエディション固有の機能についても、エディションによる差異を示しながら紹介しています。

関連データベース技術

 本書の記述は、データベース一般、特にリレーショナルデータベースについての知識を前提としています。

 また、Couchbase Serverとの比較対照のために他のNoSQLデータベースについて触れる場合、個々のデータベースについて精通していることは想定していませんが、NoSQL全般に関する一定の知識を前提としている部分があります。

 ここでは、このような関連するデータベース技術について素描を試みつつ、詳細情報への参照先を掲載します。

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

 ドキュメント指向データベース(Document-oriented database5)は、ドキュメントストアとも呼ばれます。ドキュメント指向データベースというカテゴリーには、XMLなどの様々なフォーマットを扱うデータベースが含まれますが、Couchbase Serverは、JSON形式のデータを扱うドキュメント指向データベースです。

キーバリューデータベース

 キーバリューデータベース(Key-value database6)は、キーバリューストアとも呼ばれ、KVSという略称も広く用いられています。連想配列、ディクショナリ、あるいはハッシュテーブルとも呼ばれるデータ構造で、データを管理するデータベースです。

インメモリーデータベース

 インメモリーデータベース(In-memory database7)は、メモリー内でデータを管理することによって、高速な応答性能を実現するデータベースです。一般に、データベースがデータ永続化装置(ハードディスク等)を用いた永続性を保証しているのに対して、インメモリーデータベースを利用する際には、永続化の要件は必要に応じ外部で実現されます。

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

 リレーショナルデータベース(Relational database8)は関係データベースとも呼ばれ、関係モデル(リレーショナルデータモデル)に基づいてデータを扱います。

 リレーショナルデータベースでは、データは(複数の)表として管理され、この表は「テーブル」と呼ばれます。一般に、表は行(カラム)と列(ロウ)からなりますが、テーブルの定義により決定される、単位データ(レコード)を構成する要素(フィールド)は「カラム」と呼ばれ、レコードは「ロウ」と呼ばれます。

クエリとインデックス

 データベースにおけるクエリ(Query9)は、データベース管理システムへの問い合わせ一般の表現として普通名詞化されています。リレーショナルデータベースに対するクエリの構文を定めた言語としてSQL10があります。クエリ言語を用いたデータベースへのクエリは、情報検索(データの抽出・集計)のみではなく、データの追加、削除、更新処理を含んでいます。

 データベースのインデックス(Index11)は、検索処理を高速化するためのデータ構造であり、インデックス情報を保管するためのストレージスペースと、データ書き込み時のインデックス情報更新のためのリソース消費を伴います。

トランザクション

 データベースにおけるトランザクション(Database transaction12)は、原子性、一貫性、分離性、永続性を備えたデータへの一連の操作をいいます。

試し読みはここまでです。
この続きは、製品版でお楽しみください。