riak で bitcask を使用すると、キー フィルターを使用して map-reduce クエリでフィルター処理しているキー名を明確に定義できます。これは、bitcask でキー フィルターを使用して 2i 機能を実現するための実験を目的としています (その後、セカンダリ インデックスとキー フィルターを使用したアプリケーションのパフォーマンスを比較します)。
名前が次のようにフォーマットされたキーを含むバケットを考えるとversion_type_user_timestamp
、次のようなキーになります。
GET /riak/my_example_bucket?keys=stream HTTP/1.1
Host: localhost
Accept: application/json
{
"keys": [
"v0.3_demo.type.1_user12345_1375315200000",
"v0.3_demo.type.1_user10000_1375315200973",
"v0.3_demo.type.4_user00288_1375315101004",
...
]
}
{
"keys": [
"v0.3_demo.type.2_user12777_1375315211000",
"v0.3_demo.type.1_user12777_1375315211782",
"v0.3_demo.type.2_user50121_1375315101004",
...
]
}
...
次のようなキー フィルターを作成しています。アイデアは、事前にキーで結果をフィルタリングすることにより、値の検索を少なくすることです。
{
"bucket": "my_example_bucket",
"key_filters": [
[
"or",
[
[
"tokenize",
"_",
2
],
[
"eq",
"demo.type.1"
]
],
[
[
"or",
[
[
"tokenize",
"_",
2
],
[
"eq",
"demo.type.2"
]
],
[
[
"or",
[
"tokenize",
"_",
2
],
[
"eq",
"demo.type.3"
]
]
]
]
]
]
]
}
["or", [...], [...]]
この手法は機能しますが、すべての句でキーをトークン化する方法に注目してください。私の仮説は、一度トークン化して、その結果をor
句のパイプラインにフィードし、受け入れられたトークンのバリエーションをすべてテストすることができれば、map-reduce クエリの主要なフィルター部分が行う作業が少なくなるというものです (したがって、map のフィルタリング部分は-reduce クエリのほうが時間がかかりません)。
次のようなリクエストの書式設定を試みましたが、うまくいかないようです。
{
"bucket": "my_example_bucket",
"key_filters": [
[
"tokenize",
"_",
2
],
[
"or",
[
"eq",
"demo.type.1"
],
[
"or",
[
"eq",
"demo.type.2"
],
[
"eq",
"demo.type.3"
]
]
]
]
}
or
すべての句で再トークン化せずにこれを行う方法はありますか?