2015年8月31日に開催されたCouchbase Live Tokyoで利用した資料です。間もなくリリースされるCouchbase Server 4.0、N1QL、インデクシング、MDS (Multi-Dimensional-Scalability)、ForestDB、セキュリティといった新機能についてご紹介しました。
このWhat’s New in Couchbase Server 4.0のセッションにご参加くださりありがとうございます。
多くのエンジニアにより、開発、テスト、ドキュメントが記載された、Couchbase 4.0の新機能について紹介します。
このセッションのゴールは皆さまに4.0リリースについて驚いていただき、β版をダウンロードして、新しいアプリケーションを開発して、フィードバックをいただけるようにすることです。
I am Chin and I am the head of product management at Couchbase.
Many of the engineers who develop, test, and document CB 4.0 are here at the conference, and it is an honor for me to represent their work to you.
My goal today is to get you all excited about the 4.0 release so that you will download the beta and start developing new applications with it, and share your feedback with us.
4.0は私たちの、最も大きなリリースとなり、数百年分のエンジニアの努力が注がれています。この30分のセッションでは、中でも最も重要な5つの機能について紹介します。
新しいクエリ言語、N1QLを利用して、今までは難しかったアプリケーションをどのように開発できるのかを説明します。
また、4.0で追加された全く新しいインデックスにより、クエリやアプリケーションを高速化できます。
多くの皆さんは、NoSQLに対してスケーラビリティを求めていると思いますが、4.0からは別次元でのスケーラビリティが加わっています。この多次元スケーリングがなぜユニークで重要なのかを解説します。
RocksDB, WiredTigerなど、クールなストレージエンジンが多く存在しますが、我々も独自のストレージエンジンとしてForestDBを開発しています。ストレージエンジン市場の概要を説明し、これらとForestDBがどのように異なるのかを簡単に説明します。
セキュリティも重要な要素です。我々もセキュリティエリアに多くを投資しており、これからも継続して向上させていきます。ここでは4.0で追加されたセキュリティ機能をご紹介します。
6月に米国で開催されたCouchbase Connectでは、アーキテクトやリードデベッロッパーによる、4.0にフォーカスした、多くのセッションが発表されました。このセッション中に関連するセッションもあわせてご紹介します。Connectのセッションは録画され、スライドも公開されているので、ご興味のあるテーマについてごらんください。
4.0 is our biggest release so far with hundreds of person years of efforts behind it. I am only covering 5 key features in the 30 minutes I have.
I will explain why you can now build many new applications not possible before with our new query capabilities with N1QL
I will talk about the new indexing capabilities in 4.0 to make your queries and applicatons run faster.
Many of you come to NoSQL database for easy scalability, and we have taken it to another dimension. I will explain what multi-dimensional scaling is and why it is unique and important.
The storage engine area has many products with cool names: RocksDB, WiredTiger, and we have our very own ForestDB. I will give you an overview of the common storage engines in the market, and compare ForestDB to these engines.
Security is an area that are important to all of you. We have been investing in the security area heavily and will continue to do so. I will highlight what’s new in security in 4.0.
There are many sessions in the conference dedicated to 4.0 given by the architects and leads that developed these features, I will highlight the relevant sessions during my presentation so you know which ones to go to if you are interested.
このセッションでは先の5つの機能についてフォーカスしていますが、それ以外にも、4.0ではクールな新機能がたくさん追加されています。
XDCR フィルタリング: はキーの条件を指定してデータ中の特定のサブセットをXDCRでレプリケートできます。例えば、特定のロケーションやアプリケーション固有のデータのみを、特定のデータセンターにレプリケーションすることができます。
Bloom Filter: はCouchbase Serverで、ドキュメントがデータベースに存在するかをディスクにアクセスせずに判断するためのものです。これにより、メモリ内にすべてのメタデータを保持しない、DGMのユースケースで劇的に性能が改善されます。
Breakpad: は軽量な”minidump”ファイルにクラッシュ情報を記録するライブラリで、サポートやエンジニアリングチームでこれらのminidumpからスタックトレースを確認し、トラブルシューティングに活かすためのものです。
SUSE support … など、より多くのOSがサポート対象に加わりました!
XDCR filtering allows you to replicate a subset of the data based on the criteria you specify on the key. For example, you may want to replicate just location or application specific data in your various data centers.
Bloom Filter is an algorithm to allow Couchbase Server to determine if a document is in the database without having to do any unnecessarily disk access. This significantly improves the performance of DGM use case where a low percentage of the metadata is kept in the memory.
Breakpad is a library that records crashes in compact "minidump" files, and allow our support and engineering team to review the stack traces from these minidumps to help trouble shoot issues reported by our customers.
++++++++++++++++
Bloom Filter
A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. False positive matches are possible, but false negatives are not, thus a Bloom filter has a 100% recall rate. In other words, a query returns either "possibly in set" or "definitely not in set". Elements can be added to the set, but not removed (though this can be addressed with a "counting" filter). The more elements that are added to the set, the larger the probability of false positives.
Bloom proposed the technique for applications where the amount of source data would require an impracticably large hash area in memory if "conventional" error-free hashing techniques were applied. He gave the example of a hyphenation algorithm for a dictionary of 500,000 words, out of which 90% follow simple hyphenation rules, but the remaining 10% require expensive disk accesses to retrieve specific hyphenation patterns. With sufficient core memory, an error-free hash could be used to eliminate all unnecessary disk accesses; on the other hand, with limited core memory, Bloom's technique uses a smaller hash area but still eliminates most unnecessary accesses. For example, a hash area only 15% of the size needed by an ideal error-free hash still eliminates 85% of the disk accesses (Bloom (1970)).
Let’s start with N1QL..
先のKeynoteで説明したように、N1QLは我々が開発した新規のクエリ言語で、SQLのパワーと、JSONのフレキシビリティをうまく融合させています。
N1QLは両テクノロジの良いとこをを組み合わせ、アプリケーションをより簡単に、より高速に開発可能とします。
SQLはデータベースのクエリの標準となっています。
成熟し、広く認められており、この30年以上、エコシステムの中核として君臨し続けています。
JSONはWeb, Mobile, IoTアプリケーションのデファクトスタンダードとなり、
柔軟で – 半構造化データに対する理想的なフォーマットです。
N1QL - SQL + JSON
多くの方にとって、SQLは古くから慣れ親しんだ言語でしょう、そして一目見ただけで、N1QLにも親しみを覚えていただけるでしょう。
加えてN1QLにはJSONをネイティブに扱えるという強みも加わっています。これは、JSONを利用したCouchbase Serverの柔軟なデータモデルに対しSQLを実行でき、クエリの結果もJSONで返します。アプリケーションとデータベースを通して、リッチにオブジェクトを表現することが可能です。
N1QLはベーシックなデータ型のサポートに加え、ネイティブに配列やサブドキュメント型を扱うことができます。
完全なSQLの実装として期待される多くの機能をすでに実装しています、JOIN、サブクエリ、NEST/UNNEST、により、クライアントサイドで実装する必要のあった複雑なコードを、N1QLにより劇的にシンプルに実装することができるのです!
As Ravi explained in the keynote earlier this morning, N1QL is our new query language that combines the power of SQL with the flexibility of JSON.
N1QL basically combines the best of both of these technology to make it easier and faster for you to develop your applications.
SQL is the standard for querying databases
It’s established and proven
It’s the foundation for an entire ecosystem built over the last three decades
JSON is the preferred data format
It’s the de facto standard for web, mobile, and IOT apps
It’s flexible – ideal for dealing with semi-structured data
N1QL - SQL + JSON
For many of you, SQL is an old friend and, at first glance, you will find Couchbase Server N1QL very familiar. However, N1QL has some additional tricks up its sleeve. N1QL knows native JSON. That is, SQL for Document works on the flexible Couchbase Server data model (i.e. document data based on JSON) and returns JSON to give applications full fidelity representations of objects both in their apps and in the database. N1QL goes beyond the basic data type support with native array and subdocument types with matching verbs to manipulate them easily in the language. Many capabilities you would expect from a fully functional SQL implementation is also there: JOINs, Subqueries, and NEST/UNNEST that will eliminate many operations that complicated client side code in the past. To sum up, N1QL will greatly simplify your application code!
クエリ言語を評価する際には、三つの重要な要件があります。
まずは、そのクエリ言語がどれだけ表現力を持っているのか。これは言語の制限を克服するためにたくさんのカスタムコードを記述することなく、取得したい結果をうまく表現できるか、ということです。
そして、その言語が宣言型か命令型かを評価するべきでしょう。宣言型言語はシステムに何が欲しいかを伝えるだけで、それを効率的に実行するために複雑な処理がどのように実行されるかを意識する必要がありません。
これらに加えて重要な要件として、言語を取り囲むエコシステムがどれだけ成熟しているか、があります。これはその言語をサポートするアプリケーションやツールのエコシステムだけでなく、どれだけその言語に精通したユーザやデベロッパーコミュニティが存在するかを含みます。
When one evaluates and compares query languages, there are three key requirements.
First you evaluate how expressive the query language is – it basically means whether you can express what you need to get done without having to write a lot of custom code to work around its limitations.
Then you need to evaluate whether it is declarative or procedural. A declarative language allows you to tell the system WHAT you need, and not have to worry about the complexity of HOW to do it efficiently.
The other important requirement is evaluating how big the ecosystem is around the language. This includes the user and developer community who are familiar with the language, and also the application and tools ecosystem supporting the language.
Let’s me explain these three key requirements further
SQL++ paper - http://arxiv.org/pdf/1405.3631v7.pdf
Paper on Expressiveness of SQL - http://homepages.inf.ed.ac.uk/libkin/papers/icdt01.pdf
Lecture on Relational Calculus - http://inst.eecs.berkeley.edu/~cs186/sp07/Spring07Lectures/06-RelationalCalculus-07.ppt
The relational model has rigorously defined query languages that are simple and powerful.
Algebra and safe calculus have same expressive power
Relational algebra is more operational
useful as internal representation for query evaluation plans.
… they’ll be baa-aack….
Relational calculus is more declarative
users define queries in terms of what they want, not in terms of how to compute it.
Almost every query can be expressed several ways
and that’s what makes query optimization fun!
N1QLはSQLを拡張しています、そして関係論理と代数といった数学的な本質に基づいています。
このため高い表現力を持っています。いくつかの例でご紹介しましょう。
まずはeコマースの例です。
Eコマースサイトを運営していて、売上トップ10の商品を検索したいと仮定すると…
このようなSQL文でトップ10の商品を検索できます。基本的には、これは全ての購入情報を利用し、購入明細に含まれる全ての商品をUNNEST句により展開し、各アイテムをJOINにより商品データと結合し、その商品ごとにグループ化して、商品単位の売上数を計算し、売上数によって結果をソートして、LIMIT句により10件のトップ10に絞り込んでいます。
ここであなたの上司がやってきて、月次の売上情報を求められました… プログラムを書く代わりに、別のシンプルなSQL文を使ってこのレポートを生成してみましょう…
ここでのデータモデルは、月ごとの売上を商品でグループ化し、年と月を購入履歴からSUBSTRを使って抽出し、2015-03のようにします。
そして月でソートし、月次の売上を百万単位で集計します。SQLの知識がすでにあれば、5分程度でボスを満足させ、あなたが優秀だと思い知らせることができるでしょう。
この例はオンラインのN1QLチュートリアルで利用可能です。ぜひお試しください!
N1QL extends SQL, and is based on mathematical foundation of relational calculus and algebra.
That means it is very expressive and Let me illustrate the expressiveness of N1QL with a few examples …
Let’s start with a couple of ecommerce examples …
Let’s say you are running an ecommerce site and you want to find out what the top 10 best selling products are …
Here is the SQL statement the return your top 10 selling products. Basically it takes all purchase orders, flatten out all the line items nested in the purchase order using the UNNEST operator, link each of the line item to the product using JOIN, and then you group all the line items by product, sum up the how many items sold per product, and order the results by the number of units sold, and then show the top 10 results using the LIMIT operator.
Now the your boss come to you and ask about monthly sales data… instead of writing a program to do that, you can use another simple SQL statement to generate the report…
Same data model, this time you group the products by the month sold, shown here by extracting the year and month in the purchase order using SUBSTR, basically extracting 2015-03 for example. You then order the result by months and sum up the monthly sales in millions. 5-min of effort if you are familiar with SQL and your boss thinks that you are a genius.
The examples are available at the online N1QL tutorial at query.couchbase.com/tutorial. I encourage you to check it out.
前の二つの例は多くの皆さまに親しみのある、典型的な業務データへのクエリーですが、もう一つ、大きく異なるドメインでの例をご紹介しましょう。
ここでも、N1QLがいかに表現力豊かなのかをご説明します。
Metanautixのエンジニアが元となる画像からモザイクアートを作成するためにSQLを利用する例です。
これが元の画像で、こちらが最終的に作成されたモザイクアートです、ズームすると、このモザイクアートを作成するために利用されたオリジナル画像のギャラリーを閲覧できます。
モザイクアルゴリズムの中核には、元となる画像のピクセルを全てループして、中間色として最も類似するギャラリー画像の検索があります。
この画像検索をSQLのJOINを利用して、RGBの値にマッチする画像を効率的に表現できます。
N1QLがどれだけ表現力豊かなのか少しでも伝わったでしょうか、N1QLを利用してどんなアプリケーションが作れるかと思うと、ワクワクしてきますね!
The previous two examples are typically queries on business data many of you are familiar with… let me show you another example that is in a very different domain… again to demonstrate how expressive N1QL is…
Here is another example where the folks at Metanautix show how you use SQL to create a mosaic image from a set of source images by running a sequence of standard SQL queries. Here is the source image, here is the final mosaic created, and if you zoom in, you can see the gallery images used to create the mosaic image.
At the heart of the mosaic algorithm, we loop through all the source image pixels and lookup the closest gallery image in terms of its mean color. We can express this image lookup efficiently using a SQL join that matches on (r,g,b) values. The query will find the matching gallery image for each source pixel.
Now I hope you realize how expressive and powerful N1QL is, and what new applications you can build using it!
https://metanautix.com/blog/creating-pretty-pictures-with-quest/
Creating Mosaics
A mosaic is an image constructed from a set of photo gallery tiles. Every tile in the mosaic matches closely in color to the corresponding region of the source image.
My interest in mosaic images stems back to my previous job as a Workflow Director at DreamWorks Animation. After each production wrapped, we created a souvenir mosaic from a signature moment in the movie. Every tile image of the mosaic was itself a production frame from the film. The mosaic was created by a custom script that was run overnight on our render farm. Sadly, the script was not maintained and the tradition stopped sometime during the Shrek era.
With Quest, we create high-resolution mosaic images from a set of source images by running a sequence of standard SQL queries. Some of the image processing operations required to create the final mosaic include:
Cropping and scaling: we resize all of the gallery images to be square.
Calculating the average or mean color of an image: we construct a table of mean colors for each gallery image.
Image table joins: we join the table source pixels with the mean color of the gallery images to find the right tiles.
Color adjustment: we adjust the color for each selected tile to better match the original source image pixels.
Image creation: we generate the final mosaic images from the selected tiles.
At the heart of the mosaic algorithm (step 3), we loop through all the source image pixels and lookup the closest gallery image in terms of its mean color. We can express this image lookup efficiently using a SQL join that matches on (r,g,b) values. GalleryMeans is a table of mean (r,g,b) values for gallery images, and SourcePixels is the table of source pixels. The query will find the closest gallery image for each source pixel.
SELECT
m.image AS gallery_image, s.image AS source_image, s.x, s.y,
m.r AS gallery_r, m.g AS gallery_g, m.b AS gallery_b,
s.r AS source_r, s.g AS source_g, s.b AS source_b,
FROM
GalleryMeans m JOIN SourcePixels s
ON
s.r=m.r AND s.g=m.g AND s.b=m.b
After finding the best tile matches for each pixel, Quest stitches together all the tiles to create a new high resolution mosaic image. The mosaic below was generated from a source image of resolution 2800 x 4800 (Figure 4a). The final mosaic image (Figure 4b) was constructed from 21,600 gallery tiles each with a resolution of 75 x 75 pixels, producing an image with resolution of 9,000 x 13,500 pixels. Figure 4c shows a close up of the gingerbread woman’s eyes, which exposes the individual gallery tiles. The gallery of tile images was provided by Adam Blazczak.
There are many sessions on N1QL at the conference.
We have to Introducing N1QL by N1QL architect, Gerald, One later this morning, and then we repeat it tomorrow.
Deep Dive into N1QL will take you under the hood and look at some of the advanced features and internals or N1QL engine.
We also have a session for developer on how to work with N1QL in your favorite languages this afternoon in the Developer track.
For those who wants to take advantage of the flexibility and scalability of Couchbase Server, we have a session tomorrow to help you to migrate your applications from MySQL to N1QL.
We also have a session on tuning query performance tomorrow, as well as a survey and comparison of the various query languages.
クエリ言語に求められる二つ目の要件を見てみましょう。
N1QLは宣言型、declarativeであり、あなたが何をしたいのかを指定すると、システムが最も効率的な方法でその結果を得る方法を探し出します。
N1QLは関係論理と関係代数に基づいています。先にお見せしたN1QLのステートメントは関係論理をベースにし、何をしたいのかを指定しています。Couchbase Serverの内部では、N1QLステートメントを関係代数の演算パイプラインに分解し、クエリに対する結果を効率的に計算します。
Let’s look at the second key requirements for a query language.
N1QL is declarative, meaning that you specify WHAT you want, and the system will figure out HOW to get the results to you in the most efficient way.
N1QL is based on relational calculus and relational algebra. The N1QL statement I showed you earlier is based on relational calculus, and it specifies WHAT you want to accomplish. Inside Couchbase Server, we break the N1QL statement into a pipeline of relational algebraic operators that crunch through the data efficiently to calculate the results on your queries.
先ほどのモザイクアートの例をもう一度見てみましょう。この単一のN1QLステートメントが数百万のピクセルを処理し、最も適切なギャラリーイメージを探し出して、モザイクアートを生成します。
これは宣言型クエリ言語のパワーをよく表していますね。ユーザが欲しいものを伝えると、数百万のオペレーションを利用可能なシステムリソースに割り当てて、最も高速な方法で実行します。
N1QLのような宣言型言語は、業務ドメインは理解しているけれども、そこまで技術には明るくない、データサイエンティストやビジネスアナリストが直接記述でき、データの操作や分析を行うことができます。宣言型であるため、アプリケーションコードを大量に記述しなくても、データベースシステムに難しい最適化の処理を任せて、クエリで最高のスループットと最短のレイテンシを得ることができます。
Let’s review the earlier example on generating the mosaic image. Here the single N1QL statement actually results in operations on millions of pixels to find the right gallery images for each pixel to create the mosaic.
This shows the power of a declarative query language. The user specifies what she wants, and the system will figure out the fastest way to execute the millions of operations leveraging the available system resources allocated to it.
A declarative language like N1QL allows a non-technical user who understands her domain, like a data scientist or a business analyst, to use the query language to manipulate and analyze her data. Being declarative allows the database system to do the hard work on optimizing the queries to achieve highest throughput and lowest latency without a lot of application coding.
There are many sessions on N1QL at the conference.
We have to Introducing N1QL by N1QL architect, Gerald, One later this morning, and then we repeat it tomorrow.
Deep Dive into N1QL will take you under the hood and look at some of the advanced features and internals or N1QL engine.
We also have a session for developer on how to work with N1QL in your favorite languages this afternoon in the Developer track.
For those who wants to take advantage of the flexibility and scalability of Couchbase Server, we have a session tomorrow to help you to migrate your applications from MySQL to N1QL.
We also have a session on tuning query performance tomorrow, as well as a survey and comparison of the various query languages.
第三の、クエリ言語における非常に重要な要件として、エコシステムがあります。N1QLは標準的なデータベースクエリ言語のSQLをベースとしているので、標準的なODBC/JDBCドライバを通して、Couchbase Server内に保存したデータを、他のユーザ、アプリケーション、ツールといったより大きなエコシステムに連携できます。N1QLをExcelから実行し、リアルタイムにアドホッククエリを発行してビジネスに役立てたりできます。N1QLを通して多くの重要なパートナーシップを結んでいます。Connectでも多くのパートナー企業がセッションを発表しました。
The third and very important requirement for a query language is the ecosystem. Because N1QL is based on SQL, which is THE standard database query language, and through the standard ODBC/JDBC drivers, you can now connect the data in your Couchbase Server to a large ecosystem of users, applications, and tools. You just heard from Vince from Roomlia on how N1QL with integration with Excel, enables their business analysts to analyze data in real-time and to generate ad hoc reports to support their business needs. We have announced many important partnerships today with N1QL and many of our partners are presenting at the conference.
+++++++++++++
SDKs and Connectivity with ODBC & JDBC
The native Couchbase Server SDKs integrate with N1QL and all the new capabilities we’re shipping. Simply download the latest version of your favorite SDK and you are connected! You don't have to stop there, however... Relational SQL has a long history and is prevalent in many existing tools for data management, reporting and visualization from Tableau to Microsoft Office or to SAP Business Objects. If you want to build a composite experience with existing tools on top of Couchbase Server, Simba technologies is also now shipping developer previews for ODBC and JDBC drivers for SQL-92 standard data access to Couchbase Server 4.0..
“Couchbase and Tableau have partnered to make it even easier for business to analyze, visualize and share insights gained from enterprise data,” said Dan Jewett, Vice President of Product Management, Tableau. “The addition of N1QL to Couchbase Server gives Tableau’s customers a familiar SQL-like interface to NoSQL data. For the first time, this really opens NoSQL to the enterprise application eco-system and that should accelerate enterprise adoption of NoSQL as a mission critical data store.”
“The Looker Connector for Couchbase makes it easier to leverage Looker for real time access to enterprise data that is critical to corporate growth,” said XYZ. “Couchbase Server with N1QL will change the game for NoSQL. N1QL makes it possible for the rest of the enterprise eco-system to access data by querying Couchbase Server through a familiar SQL interface – this eliminates many of the concerns that have existed around using NoSQL for mission critical applications.” this eliminates one of the major barriers around using NoSQL for mission critical applications.”
“Increasingly enterprises are adopting NoSQL to support mission critical applications – which means data stored in NoSQL has to be accessible by the rest of the enterprise eco-system,” said XYZ. “With N1QL, Couchbase is delivering a familiar SQL-like interface that makes it faster and easier for our customers to manage and transform data between Couchbase Server and any other relational or big data system.
“NoSQL is rapidly emerging as a key player in the data supply chain. For NoSQL to gain equal standing with other data stores, it needs to be easy to query and it needs to make query results easily accessible,” said XQY. “With N1QL, Couchbase is the first NoSQL vendor to provide a query language that joins the proven and widely used power of SQL with the flexibility of JSON. With N1QL, Metanautix can connect data queried via N1QL to any other BI solution or application in the enterprise data supply chain.”
“Couchbase and Simba Technologies have been partners for more than a year, working closely together to ensure that enterprises have the best tools possible leverage their data,” said George Chow, CTO Simba Technologies. “With the upcoming release of N1QL, Couchbase is once again showing its innovation lead in making NoSQL the best choice for enterprise data management. N1QL with Simba’s ODBC and JDBC connectors empower enterprises to access their NoSQL data—and more importantly, explore, report, and act upon it—from their analytics and data integration tools of choice.”
Metanautix - Founded by big data pioneers from Google and Facebook. We believe we have some of the best minds in the industry. And we have one goal — to simplify your data supply chain. Led by the former Google engineer who headed the development of Dremel, the company aims to dissolve product and technology barriers by “re-imagining” SQL at the heart of an emerging big data supply chain.
On top of that, we have sessions on N1QL by our customers and partners.
I encourage you to check out the sessions by our customers Nielsen and DIRECTV on how they use N1QL, and the various presentations by our N1QL partners.
Let’s talk about Indexing
Couchbase 4.0には4種類のインデックスがあります。これらのインデックスについて、図書館の例で説明しましょう
We have 4 different index types in Couchbase 4.0, let me explain what these index types are using the Library as an example…
本はISBNコードで管理されています。よってISBNはプライマリインデックスとなり、お探しの本のISBNが置いてある本棚を探せば、簡単に希望の本を見つけることができます。
では、特定の著者の作品を探すにはどうしたらよいでしょう? すべての本を一つずつ手にとって探すという方法がありますが、気の遠くなる作業です。もしくは図書カタログを見て、著者の名前で文献情報を探すこともできるでしょう。この図書カタログがまさに二次インデックスであり、本の属性から本を探すことができます。
もし、あなたの近隣に住む著者が書いた作品を探してみたくなったらどうでしょう? この場合、空間インデックス、スペイシャルインデックスと呼んでいるもので、多次元の情報から検索できます。
もしCouchbase Serverに書かれたすべての書籍を探したいなら? この場合、テキストインデックスを活用した検索エンジンが必要になります。
Book are organized by their ISBN codes. So the primary index is on ISBN and you can easily locate the book by first looking up the shelf containing the ISBN of the book you are looking for, and then look within the shelf to locate the book.
What if you want to locate books written by an author? You have to option of looking up the books by examine all the books one at a time, which will take you forever to do. Or you can go to the library catalog that allows you to look up book information by the name of the author. The library catalog is basically the secondary index that allows you to look up a book by its attributes.
What if you are interested in all the books written by anyone that lives within a mile of you? In this case, you need what we call a spatial index, that allows you to look up information by multiple dimensions.
What if you want to look up all the books written on Couchbase Server? In this case, you need to use a search engine that relies on a text index to allows you to look up objects based on its text contents.
Couchbase Serverはローカルとグローバルのセカンダリインデックスをサポートしています。
ローカルインデックスは、M/R Viewで作成され、データと同じ場所に配置されます。このため、高い更新スループットを得ることができます。
しかしながら、クエリのレイテンシとスループットは、”scatter-gather”を行うため、最高の性能とはなりません – クエリの実行にはすべてのノードへ問い合わせ、各ノードの結果を集約し、結合して最終的な結果を作成しなくてはなりません。
4.0で新しく追加されたグローバルインデックスは、”scatter-gather”が不要であり、クエリのレイテンシとスループットについてより高い性能を提供します。
グローバルインデックスは個別にスケール、分割することができ、KVのオペレーションとは分離されています。この、多次元スケーリングについては後ほど紹介します。
Couchbase server support local and global secondary indexes.
Local indexes are created as M/R views and they are co-colocated with the data, and because of the co-location, you can achieve good write throughput.
However query latency and throughput tends to be suboptimal as you have to do what we call “scatter-gather” – you have to go to all the nodes to do the query, gather the results from each node, and then combine them into the final results.
Global indexes are new in 4.0, and they have higher query latency and throughput as you avoid the need to do “scatter-gather”.
Global indexes can also be independently scaled and partition, and they are isolated from KV operations, as we will explain in multi-dimensional scaling later.
空間インデックスは、3.0では試験的に利用可能でしたが、4.0から正式にサポートされます。
空間インデックスを利用すると、多次元上でのクエリを実行できます。
例えば、バウンディングボックス内のすべてのオブジェクトを探したり、
バウンディングボックスを利用して交差するオブジェクトを探したり、
要するに、多次元における範囲を元にオブジェクトをクエリできます。
必ずしもGeoデータ、である必要はなく、収入、年齢、教育レベルなど、いかなる数値データ、
もしくはGeoデータを他のデータと組み合わせ、サンフランシスコの18歳から24歳までの住人を探したりできます。
Spatial indexes were experimental in 3.0 and will now be officially supported in 4.0.
With spatial indexes, you can issue queries on multiple dimensions
For example, you can find all objects within a bounding box,
Or use a bounding box to find intersection objects
Or more generally query objects based on ranges in multiple-dimensions..
Not necessarily Geo-Data but any numeric data, line income, age, and education level
Or combine Geo data with other data like finding everyone that lives in San Francisco that is between 18 to 24
http://geojson.org/
http://geojson.org/
CouchbaseはElastic, Solr, Lucidworksのコネクタをサポートしていますが、これらはまた別のシステム、クラスタとして管理する必要があります。
多くのユースケースでは8割程度の機能が利用でき、シンプルに連携できるソリューションが求められます。
我々もテキストインデックスへの対応を進めており、Developer Previewが今年の秋頃に利用可能になる予定です。
テキストインデックスとは、転置インデックスのことです。ドキュメント内のコンテンツを受け取り、トークナイザ、フィルタ、ステミングを行い、キーワードに対する転置インデックスを作成します。インデックス内の各キーワードはドキュメントのリストと、ドキュメント内のキーワード出現位置と関連付けられています。
テキストクエリを実行すると、検索語に対しても同様の処理を行い、インデックスを利用して検索語のキーワードを含むドキュメントを検索します。
Couchbase supports connectors Elastic, Solr, Lucidworks, but yet another system & cluster to manage. For many use cases, customers want simple integrated solutions that provides 80% of the features. We are developing support for text indexes and it will be available for Developer Preview sometime in Q3.
A text index is basically an inverted index. It takes the content of a document, apply tokenizer, filter, and stemming to create inverted index for keywords. Each keyword in the index is associated with a list of documents and positions in the documents that the keyword appears in.
When you submit a text query, the same process is applied to your search keywords, and the index is used to look up the documents containing your search keywords.
In computer science, an inverted index (also referred to as postings file or inverted file) is an index data structure storing a mapping from content, such as words or numbers, to its locations in a database file, or in a document or a set of documents.
Inverted index - Wikipedia, the free encyclopedia
We talked about N1QL query support and indexing in Couchbase 4.0,
Let’s talk about how you manage and scale the data, query, and index services
多くの皆様はCouchbase Serverの水平スケーリングについてご存知でしょう。
基本的には、同一スペックの1台以上のノードにデータセットを分散配置します。
すべてのノードは同一で、同様に複数種別のワークロードを処理します。
より多くのキャパシティが必要となった場合、ノードを追加してクラスタを水平方向にスケールします。
You are all familiar with the typical horizontal scaling of Couchbase Server
Basically you partition dataset onto one or more homogenous nodes
All nodes are identical and running the same mixed workloads
When you need more capacity, you add another node and scale cluster horizontally
すべてのサービスを同一のノードで稼働させることの問題は、サービスごとに異なるリソースや性能要件があるという点です。
例えば、
Data Serviceはメモリ、ネットワークインテンシブで、データオペレーションはミリ秒未満で行う必要があります
Index Serviceはインデックスの探索に高速なストレージが必要になるでしょう
一方、Query ServiceはCPUインテンシブで、1秒以内にアドホックなクエリを実行できるのが理想です
Couchbase 4.0では、MDSを導入し、data、query、index service単位での、個別のスケールを可能としています。
The issue with running all the different services on the same nodes is that services have different resource and performance requirements
For example,
data service is memory and network intensive and data operations need to run in sub-msec
index service may need a fast storage system for index traversal
while query may be cpu intensive and it may be acceptable for ad hoc queries to run in sub-seconds, rather than msecs
With Couchbase 4.0, we introduce MDS to allow independent scaling and provisioning of data, query, and index services.
MDSを利用すると、data、query、index serviceを分離し、お互いの干渉を最小化できます。
多くの環境では、ミッションクリティカルなKVデータ操作に、アドホッククエリが影響を与えないようにすることが重要なはずです。
With MDS, you can isolate the data, query, and index services to minimize interference.
In many deployments, it is important that ad hoc queries do not impact the mission critical KV data operations
各サービスの持つ異なるリソース、性能要件をもとに、
MDSは異なるHWをサービスごとに利用できます。
例えば、Data Serviceを水平方向にスケールアウトし、QueryとIndex Serviceにはよりハイスペックなサーバを利用するなどです。
MDSはシステム運用により高い柔軟性を与え、システム全体の性能を最適化できます。
So based on the different resource and performance requirements of each service,
MDS allows you to provision different HW for different services.
For example, you can scale out the data services horizontally, and decide to scale-up with bigger boxes for query and index services..
MDS gives the operations team more flexibility to optimize the overall system performance.
Couchbase Serverは高速なメモリ、高速なネットワーク、高速なストレージを活用した高性能でスケーラビリティを求めて設計されています。
このため、ストレージエンジンはアーキテクチャ内の非常に重要なコンポーネントです。
我々の開発した次世代のストレージエンジンの概要をご紹介しましょう。
Couchbase Server is architected for high performance and scalability leveraging fast memory, fast network, and fast storage.
So storage engine is a very critical component in our architecture and I want to give you an overview of our next-generation storage engine.
グローバルなスケールで稼働するモダンなWebやモバイルのアプリケーションは、数億のユーザやデバイスに対応する必要があり、これらのクライアントから膨大な量の非構造化データが生成され、その頻度は増加するばかりです。
このようなアプリケーションでは、高い性能と非常に良好なレスポンスを、データベースが肥大化し続ける中でも継続して維持しなくてはなりません。
巨大なデータベースと、大量の同時接続ユーザをサポートするために、次世代のストレージエンジンの開発に取り組んでいます。
Modern web and mobile applications at global scale need to support, in some cases, hundreds of millions of users and devices, and these users/devices are generating large volume of unstructured data at ever increasing rate
These applications need to maintain high performance and very fast response time as the database grows larger and larger
To support massive databases and large number of concurrent users, we have been working on our next-generation of storage engine…
ここで、現在のストレージエンジン界隈の様子を見てみましょう。
基本的には二つの主要なストレージ構造があります。B+ TreeとLSM Treeです。
B+ Treeはすべてのleaveノードがrootノードから同一の距離を持つようなツリー構造です。BはBalancedの略です。
これは浅いツリーの場合良好な参照性能を持ちますが、ツリーが深くなった場合には性能が悪化します。
Leaveノードの更新はディスク上でランダムに散らばってしまうため、更新は一般的に低速です。
Let’s take a look at the current state-of-the-art storage engines in the industry…
Basically there are two main storage structures, B+ Tree and LSM Tree.
B+ Tree is basically an tree structure where all the leave nodes are of the same distance from the root node. B is the short-hand for Balanced. It has good read performance if you have a short tree and suffers when the tree has too many levels. Writes are typically slower because the leave nodes updated are randomly scattered on the disk.
LSMでは、メモリ内とディスクベースのインデックスツリーを管理します。
参照では複数のLSMツリーを探索し、適切なレコードを探すため一般的には低速となります。
更新に関しては、LSMはメモリ内のインデックスツリーを更新し、定期的にこれをWALと呼ばれるシーケンシャルなログに出力して更新性能を向上させています。
要するに、参照に最適化されたB+ Treeと、更新に最適化されたものがLSM Treeということです。
どちらも可変長のキーや、長いキーに対してはツリーがより深くなってしまう悪影響があります。
With LSM, you maintain a memory-resident index tree and several disk-based trees. So reads may require traversing multiple LSM trees to find the right record so it is typically slower. For writes, LSM updates the memory-resident index tree and periodically flush it out in a a sequential log known as WAL to improve write performance.
So you have B+ Tree that is optimized for reads, and LSM Tree that is optimized for writes. Both suffers when you have variable-length keys or long keys as the trees become taller.
数年前から、高速なストレージへの要件を根本から考え直しました。
モダンなアプリケーションの多様なデータを扱うための、高速なストレージエンジンが必要だと気付き、参照にも更新にも強い単一のエンジンが必要だと考えるようになりました。そして小さなデバイスから大きなサーバまでスケールできるのが理想です。
また、高性能が要求されるシステムで利用される最新のSSDストレージ技術に対する最適化も必要です。
我々の開発したエンジンはForestDBと呼んでいます。
なぜなら、B+ Trie Treeの階層構造をベースに、B+ treeやLSM treeよりもコンパクトなインデックス構造を提供できるからです。
We started to fundamentally rethink the requirements for fast storage a couple of years ago..
We want a fast storage engine that can handle the variety of data of modern applications, and we want to have a single engine that works well for reads and writes, and scale from small devices to large servers. We also want to optimize the the new SSD storage technology that is becoming in high performance deployments…
We called our engine ForestDB because it is based on a hierarchy of B+Trie trees that provides a more compact index structures than B+ tree and LSM tree
ForestDBのインデックス構造はTrie treeをベースとしています。Trie treeは長い可変長のキーを効率的に扱うプリフィックスツリーです。
各ノードのTrie treeはB+ treeをベースにしていて、小さなB+ treeの集合となります、この結果、全体の構造はB+ treeやLSM treeと比較してよりコンパクトになります。
ForestDBのインデックス構造は2011年のACM SIGMODコンテストで発表されたものです … ACM SIGMODは世界中のデータベース研究者が注目しているグループです。
ここでは、これ以上の階層型B+ Trie treeの詳細には触れませんが、ご興味のある方は、Connectで発表されたForestDBのセッションをご覧ください。
The index structure for ForestDB is based on a Trie tree, which is basically a prefix tree for efficiently dealing with long variable-length keys.
Each node of the Trie tree is based on a B+ tree, so you have a collection of small B+ tree, and the results of that is more compact overall structures compared to the plain B+tree and LSM tree
ForestDB index structure was originally proposed at the ACM SIGMOD contest in 2011… For those of you who are not familiar with ACM SIGMOD, it is basically the special interest of group on databases for researchers all over the world.
I won’t go into the details on the Hierarchical B+ Trie tree. To learn about this amazing innovation, you need to go to the dedicated session on ForestDB…
内部で実施したベンチマークでは、ForestDBはLevelDBやRocksDBと比べ、6倍高速、ストレージサイズは1/5という結果となり、SSDテクノロジーにも最適化されています。
Based on internal benchmarks, with ForestDB, we are seeing up to 6x faster in performance, and up to 5x less in storage relative to LevelDB and RocksDB, and it is optimized for SSD technology.
To learn more about ForestDB…
Please attend the session on ForestDB by the architect of the ForestDB team, Chiyoung.
The session of Optimizing ForestDB for SSDs is a joint presentation with Prof Lee from a top university in Korea.
We also have a session on the joint work we are doing with Intel, on share the data from the Intel high-performance cluster lab on ForestDB.
Simplified Security Compliance
Security is a top concern and many enterprises impose internal controls or have to comply with external rules and regulations. With Couchbase Server 4.0, you get simplified security controls for compliance with security standards from PCI to HIPAA to FISMA and more. Version 4.0 comes with native LDAP integration for admin account management and the new auditing capability lets you track admin actions with great level of detail. This is all in addition to our existing security capabilities such as the encryption of data at rest and on the wire.
多くのセキュリティ機能を過去のリリースで追加してきました …
We have added many security features in the past releases …
Password protection
Admin access
Secure communication
Encryption – on the wire and data-at-rest
Access log – track admin access to couchbase server
Let’s look at the two key security features in 4.0 …
Lightweight Directory Access Protocol (LDAP) integration for identify management
4.0では、LDAPを利用してユーザとパスワードを集中管理し、LDAPユーザをCouchbaseの異なる管理者権限にマッピングできます。
これらのLDAPユーザを利用してCouchbase Server 4.0では監査ログも出力できます。
With 4.0, you can use LDAP to centrally manage your users and passwords, and map the LDAP users to the different admin roles within Couchbase.
We will track these LDAP users in the new auditing features in Couchbase Server 4.0
誰が、何を、いつ、どのように実行したのか、といった監査ログを設定可能です。
ログイン、クラスタ設定、バケット操作、といった管理操作の監査ログを出力できます。
監査ログのレコードはJSON形式で、簡単に3rdパーティのログ管理ツールと連携できます。
Configurable audit trails that capture who does what, when they do it, and how they do it
Audit administrative events – Login, cluster configurations, bucket operations, admin operations
The audit records are in JSON format and it is very easy to integrate with third-party log management tools
Configurable audit trails that capture who does what, when they do it, and how they do it