Couchbase Advent Calendar、12/10分の記事です。そろそろネタも尽きたかー!?っと思った矢先、出ましたよ、Couchbase Server 4.1が! リリースをお知らせするCouchbase社ブログの翻訳記事です。

ランドマークとなる4.0のリリースは、ドキュメントデータベースとしてCouchbaseが対応できるユースケースを劇的に広げました、その土台に乗り、Couchbase Server 4.1はさらに大きなクエリ機能と性能を向上し、デベロッパーとエンタープライズにとってますます魅力的になっています。

Couchbase Server 4.1は我々エンジニアリングチームにとって誓約でした - Couchbase Server 4.0がリリースされて3ヶ月足らず、200を超える機能向上はより高いスケーラビリティとより良いクエリ性能をもたらしました。 多くのお客様がすでにN1QLを利用してCouchbaseの新しいユースケースを開発している最中で、4.1のリリースではN1QLをいち早くエンハンスしたいと願っていました。

4.1リリースの主なハイライトを紹介します -

N1QL: バッチ、OLTP向けのSQL CRUDサポートをN1QLで完成させる

INSERT、UPDATE、DELETE、MERGE、そしてUPSERTがCouchbase Server 4.1から完全にサポートされます。これを利用して、SQLでテーブルを更新するように、JSONドキュメントをN1QLで操作でき、エンタープライズWeb、モバイル、IoTアプリケーションのクエリ要件を全て満たすことができます。

N1QLのINSERTステートメントは単一、また複数のドキュメントの挿入ができます。 UPDATEとDELETEは特定の条件に基づいたドキュメントの集合を操作することができます。 これらの両ステートメントはインデックスが利用できれば、効率的に更新対象のドキュメントを特定できます。 UPSERTとMERGEステートメントは指定した条件に基づく二つのドキュメントセットをマージします。これらすべてのトラディショナルなSQLステートメントがJSONドキュメントに対応しています。

SQLステートメントはCouchbase SDK、REST API、Simba JDBC/ODBCドライバで完全にサポートされています。

カバーリングインデックス

カバーリングインデックスとは、特定のクエリで必要となるフィールドのすべてを保持しているインデックスのことです。これは、アプリケーションにとって、カバーリングインデックスはクエリを拘束に実行できることを意味します。通常のインデックスでは、クエリ実行フローはインデックスサービスをスキャンした後、クエリを完了するために、加えてデータサービスをスキャンする時間が必要です。カバーリングインデックスを利用すると、データアクセスに必要なのはカバーリングインデックスをスキャンすることだけです。 結果として、クエリのレイテンシは低くなり、より高速に動作するアプリケーションとなります。

N1QLクエリは効率的にクエリを実行するために、対応するインデックスを利用します。ユースケースによっては、2-3倍のクエリレイテンシとスループット性能の向上が見られました。 これは選択されたインデックスのキー属性だけを参照すればよく、クエリの結果を返すために完全なドキュメントをフェッチことを回避できるからです。 加えて、N1QLクエリエンジンはORDER BY句とインデックスキーが一致する場合、データのソートをスキップすることができます。

N1QLのオプティマイザは自動的にインデックスがクエリの結果を返せるかを認識します。カバーリングインデックスの利用によって性能が向上する典型的なクエリは、多数の行を処理するクエリです。例えば、次のような集計を行うクエリです:

CREATE INDEX idxstatecountry ON `beer-sample`(state, country) USING GSI;

SELECT country, max(state)
FROM `beer-sample` USE INDEX (idxstatecountry)
WHERE STATE LIKE 'C%'
GROUP BY country;

ORDER BYを利用してソートする場合にも、カバーリングインデックスはすでにソートされているため、クエリエンジンが直接ソート済みのカバーリングインデックスを結果の生成に利用できます。

プリペアードステートメント

プリペアードステートメントは何回も実行する同一、または類似のクエリを、クエリの解析と準備を繰り返すことなく、効率的に実行できます。 多くのアプリケーションでは事前に定義されたクエリを、パラメータのみ変更して繰り返し実行する必要があるでしょう。 これらの繰り返し実行されるクエリをアドホックなクエリとして実行すると、クエリの解析、実行計画を毎回計算する必要があります。 プリペアードステートメントのテンプレートを利用すれば、実行計画は固定で、特定の変数だけを置換してクエリを実行し、頻繁に繰り返されるクエリの解析や実行計画のコンパイルに必要なオーバヘッドを回避できます。 結果として、レイテンシが小さくなり、CPUサイクルが削減されます - すなわちより高速に動作するアプリケーションとなるのです。

多くのお客様が以前はmap-reduceとviewを利用していたクエリをN1QLに置き換えています - 同時に、以前のCouchbaseで可能だったものより複雑なクエリを必要とする新規のアプリケーションを開発しています。

サポート対象プラットフォームの追加

Couchbase Server 4.1は正式にWindows 10とOSX El Captainプラットフォームでの動作をサポートします。

さぁ、今すぐはじめましょう!

4.1 GAを開始するにあたって、役立つリソースを紹介します:

• What’s New in Couchbase Server 4.1 documentation
• Download Couchbase Server 4.1
• Couchbase Server documentation 
• Release Notes for 4.1
• Couchbase ODBC and JDBC Drivers with SQL Connector

Developer Previewを試して、コンスタントにテストを行い、特にN1QLに関するフィードバックを提供してくれた、素晴らしいコミュニティの皆様に感謝します。 是非、4.1をエンジョイしていただき、いつもの様にフィードバックお寄せください。

Couchbase 4.1を利用したアプリケーション開発の成功を願っています!

訳者あとがき

DMLが完全にサポートされたのはかなりデカいですね! 今まではViewで更新対象のドキュメントを検索して、一つ一つアプリケーションから更新のAPIを叩かなければならなかったのが、WHERE句の条件にマッチするドキュメントを一括で更新できるようになったんですから!

カバーリングインデックスの登場で、Viewが得意としていた集計のクエリの一部も、N1QLだけで十分実装できるようになりました。また、ORDER BYをインデックスによりスキップできるのもありがたいっすね! でも、一台のIndexサービスに収まらないくらい大量のドキュメントを対象として集計を行うバッチなんかは、まだViewの方に軍配があがるのかなーって気がしてます。大量の更新が発生する状況では、一箇所にまとまったGSIへの反映がネックになることもありそうですね。そこはうまくGSI作成時にWHERE句でパーティショニングするのが良さげかな?

みなさん色々使ってみて、フィードバックをください! 私のTwitterでも、FBでも、なんでも良いので :)