7.3.64. table_create#
7.3.64.1. 概要#
table_create は現在のデータベースに新しいテーブルを作成します。データを保存したり検索したりするために、1つ以上のテーブルを作成する必要があります。
テーブルの詳細は テーブル を見てください。
7.3.64.2. 構文#
このコマンドにはたくさんの引数があります。
必須の引数は name だけで、残りは省略できます:
table_create name
[flags=TABLE_HASH_KEY]
[key_type=null]
[value_type=null]
[default_tokenizer=null]
[normalizer=null]
[token_filters=null]
[extractors=null]
[path=null]
7.3.64.3. 使い方#
このセクションでは次のことについて説明します。
7.3.64.3.1. データ保存用テーブルの作成#
データ保存用のテーブルにはどの種類のテーブルでも使えます。テーブルの種類については テーブル を参照してください。
テーブルの型は TABLE_${TYPE} を flags 引数に指定します。
以下は TABLE_NO_KEY テーブルを使う例です。
実行例:
table_create Logs TABLE_NO_KEY
# [[0,1337566253.89858,0.000355720520019531],true]
この table_create コマンドは Logs という名前で TABLE_NO_KEY 型のテーブルを作成します。
キーでレコードを検索しないのであれば、 TABLE_NO_KEY 型のテーブルが適切です。なぜなら、 TABLE_NO_KEY はキーをサポートしていませんが、速くて小さいサイズのテーブルだからです。ログをGroongaのデータベースに保存するという使い方はこのケースです。
キーでレコードを検索したり、カラムからレコードを参照したりする場合は、 TABLE_NO_KEY 型は適していません。全文検索用の語彙表として使うケースはこのケースです。
7.3.64.3.2. 大きなデータ保存用テーブルの作成#
たくさんの大きなキーを保存したいとき、テーブルにすべてのキーを保存できないかもしれません。もし、総キーデータが4GiBより大きいなら、デフォルトではすべてのキーデータをテーブルに保存できません。
Added in version 15.1.5: TABLE_PAT_KEY も KEY_LARGE フラグをサポートしました。
KEY_LARGE フラグを使うと4GiBから1TiBに最大総キーサイズを拡張できます。 KEY_LARGE フラグは TABLE_HASH_KEY と TABLE_PAT_KEY を使っているときに使えます。 KEY_LARGE フラグは TABLE_NO_KEY と TABLE_DAT_KEY と一緒に使えません。
以下はたくさんの大きなキーを保存することができるテーブルを作る例です。
実行例:
table_create Paths TABLE_HASH_KEY|KEY_LARGE ShortText
# [[0,1337566253.89858,0.000355720520019531],true]
この table_create コマンドは、名前が Paths で TABLE_HASH_KEY 型のテーブルを作成します。 Paths テーブルはたくさんの大きなキーを保存できます。
上記の例は、 TABLE_HASH_KEY のケースですが、テーブルが TABLE_PAT_KEY であっても、 TABLE_HASH_KEY と同様に KEY_LARGE フラグを設定できます。
7.3.64.3.3. 語彙表の作成#
語彙表用のテーブルには TABLE_NO_KEY 以外の型のテーブルを使います。語彙表はキーをサポートしていないといけませんが、 TABLE_NO_KEY はキーをサポートしていません。
以下は TABLE_PAT_KEY テーブルを作る例です。
実行例:
table_create Lexicon TABLE_PAT_KEY ShortText --default_tokenizer TokenBigram --normalizer NormalizerAuto
# [[0,1337566253.89858,0.000355720520019531],true]
この table_create コマンドは以下のテーブルを作成します。
このテーブルは
Lexiconという名前です。このテーブルは
TABLE_PAT_KEY型のテーブルです。このテーブルのキーは
ShortText型です。このテーブルは正規化されたテキストからトークンを抽出するために
TokenBigramトークナイザーを使います。このテーブルはテキストを正規化するために
NormalizerAutoノーマライザーを使います。
語彙表には TABLE_PAT_KEY が適切なテーブルの型です。語彙表は全文検索に使われます。
全文検索では、あいまい検索をするために前方一致検索を使っています。前方一致検索は TABLE_PAT_KEY と TABLE_DAT_KEY がサポートしています。
全文検索対象のテキストには大量のトークンが含まれるので、語彙表のキーも大量になります。大量のキーを格納するテーブルの場合はテーブルのサイズを意識する必要があります。これは、大きなテーブルはそれだけ多くのメモリーを必要とするからです。多くのメモリーが必要になると、ディスクI/Oが発生することもあります。ディスクI/Oが発生すると高速に検索できなくなります。そのため、大量のキーがあるテーブルの場合はテーブルのサイズが重要になります。 TABLE_PAT_KEY は TABLE_DAT_KEY よりもテーブルのサイズが小さいです。
上記の理由から、 TABLE_PAT_KEY が語彙表に適したテーブルの型です。
7.3.64.3.4. タグインデックス用テーブルの作成#
タグインデックス用のテーブルには TABLE_NO_KEY 以外の型のテーブルを使えます。タグインデックス用のテーブルはキーのサポートが必要ですが、 TABLE_NO_KEY はキーをサポートしていません。
以下は TABLE_HASH_KEY 型のテーブルを作る例です。
実行例:
table_create Tags TABLE_HASH_KEY ShortText
# [[0,1337566253.89858,0.000355720520019531],true]
この table_create コマンドは Tags という名前で TABLE_HASH_KEY 型のテーブルを作ります。このテーブルのキーは ShortText 型です。
タグインデックス用のテーブルには TABLE_HASH_KEY あるいは TABLE_DAT_KEY が適切なテーブルの型です。
完全一致でタグを検索する機能だけが必要なら、 TABLE_HASH_KEY が適切です。多くの場合はこのケースです。
もし、前方一致検索機能も必要な場合（例えば、 "gr" というキーワードで "groonga" を検索する場合）は、 TABLE_DAT_KEY が適切です。 TABLE_DAT_KEY はサイズの大きなテーブルですが、タグの数はそれほど多くならないので、サイズは重要ではありません。
7.3.64.3.5. 範囲検索用のインデックステーブルの作成#
範囲検索用のインデックステーブルには TABLE_PAT_KEY 型と TABLE_DAT_KEY 型を使えます。範囲検索用のインデックステーブルは範囲検索をサポートしている必要がありますが、 TABLE_NO_KEY 型と TABLE_HASH_KEY 型はサポートしていません。
以下は TABLE_DAT_KEY テーブルを作成する例です。
実行例:
table_create Ages TABLE_DAT_KEY UInt32
# [[0,1337566253.89858,0.000355720520019531],true]
この table_create コマンドは Ages という名前で TABLE_DAT_KEY 型のテーブルを作成します。このテーブルのキーの型は UInt32 です。
範囲検索用のインデックステーブルには TABLE_PAT_KEY 型と TABLE_DAT_KEY 型が適切なテーブルの型です。
インデックス対象の項目が少なければ、 TABLE_DAT_KEY 型が適切です。前述の例では、年齢（age）用のインデックスがこのケースになります。年齢のインデックスはせいぜい0から100項目くらいにしかなりません。これは、人はそんなに長生きできないからです。
インデックス対象が大量にある場合は、 TABLE_PAT_KEY 型が適切です。なぜなら、 TABLE_PAT_KEY 型は TABLE_DAT_KEY 型よりもサイズが小さいからです。
7.3.64.4. 引数#
このセクションではすべての引数について説明します。
7.3.64.4.1. 必須引数#
必須の引数は1つです。
7.3.64.4.1.1. name#
作成するテーブル名を指定します。 name は必ず指定しなければいけません。
利用可能な文字は以下の通りです。
0..9（数字）a..z（アルファベット。小文字）A..Z（アルファベット。大文字）#（シャープ）@（アットマーク）-（ハイフン）_（アンダースコア）（注: 最初の文字としてアンダースコアを使うことはできません。）
上記の文字を1つ以上使って名前を決めます。 _name というように、最初の文字に _ を使えないことに注意してください。
7.3.64.4.2. 省略可能引数#
いくつか省略可能な引数があります。
7.3.64.4.2.1. flags#
テーブルの型とテーブルをカスタマイズするオプションを指定します。
指定可能なフラグは以下の通りです。
フラグ |
説明 |
|---|---|
|
配列テーブル。 TABLE_NO_KEY 参照。 |
|
ハッシュテーブル。 TABLE_HASH_KEY 参照。 |
|
パトリシアトライ。 TABLE_PAT_KEY 参照。 |
|
ダブル配列トライ。 TABLE_DAT_KEY 参照。 |
|
半無限文字列を有効にします。 |
|
最大総キーサイズを4GiBから1TiBへ拡張します。 |
注釈
Groonga 2.1.0から KEY_NORMALIZE フラグは非推奨になりました。代わりに、 normalizer オプションに NormalizerAuto を指定してください。
TABLE_${TYPE} フラグのどれか1つを指定します。 TABLE_${TYPE} フラグを2つ以上指定することはできません。例えば、 TABLE_NO_KEY|TABLE_HASH_KEY は不正な指定方法です。
TABLE_PAT_KEY|KEY_WITH_SIS というように、 | （縦棒）で複数のフラグを組み合わせることができます。
それぞれのテーブルの型の違いは テーブル を参照してください。
デフォルトのフラグは TABLE_HASH_KEY です。
7.3.64.4.2.2. key_type#
キーの型を指定します。
flags パラメーターに TABLE_HASH_KEY 、 TABLE_PAT_KEY または TABLE_DAT_KEY を指定した場合は、 key_type オプションを指定する必要があります。
型の一覧は データ型 にあります。
デフォルト値はありません。
7.3.64.4.2.3. value_type#
値の型を指定します。
flags パラメーターに TABLE_NO_KEY 、 TABLE_HASH_KEY または TABLE_PAT_KEY を指定した場合は「値」を使うことができます。「値」の型は固定長でなければいけません。例えば、 UInt32 は使えますが、 ShortText は使えません。この場合は値ではなく、カラムを使ってください。
デフォルト値はありません。
7.3.64.4.2.4. default_tokenizer#
デフォルトトークナイザーを指定します。これは、検索時とデータロード時に使われます。
テーブルを全文検索インデックスの語彙表として使う場合は default_tokenizer を指定しなければいけません。利用可能なトークナイザーは トークナイザー を参照してください。全文検索する場合はこのリストの中からトークナイザーを選んでください。
次の場合は default_tokenizer を指定する必要はありません。
テーブルを語彙表として使わないとき。
テーブルを語彙表として使うが、全文検索をしないとき。例：
インデックス対象のデータが
Int32やTimeのようにテキストデータでないとき。完全一致検索や前方一致検索などだけが必要なとき。
TABLE_NO_KEY フラグと一緒に default_tokenizer を使うことはできません。これは、 TABLE_NO_KEY フラグを使っているテーブルは語彙表として使うことはできないからです。
テーブルを語彙表として使いたいときは、 flags に TABLE_HASH_KEY 、 TABLE_PAT_KEY 、 TABLE_DAT_KEY のどれかを指定してください。
デフォルト値はありません。
7.3.64.4.2.5. normalizer#
キーを正規化するために使うノーマライザーを指定します。
TABLE_NO_KEY はキーをサポートしていないので、 TABLE_NO_KEY と normalizer を一緒に指定することはできません。
ノーマライザーの一覧は ノーマライザー にあります。
デフォルト値はありません。
7.3.64.4.2.6. token_filters#
トークンフィルターを「,」（カンマ）区切りで指定します。トークンフィルターはトークンに所定の処理を行うために使われます。
TABLE_NO_KEY はキーをサポートしていないので、 TABLE_NO_KEY と token_filters を一緒に指定することはできません。
トークンフィルターの一覧は トークンフィルター にあります。
デフォルト値はありません。
7.3.64.4.2.7. extractors#
Added in version 16.0.6.
注釈
This is an experimental feature. Currently, this feature is still not stable.
Specifies extractors separated by ,. Extractors extract plain text
or values from structured data such as HTML and JSON before tokenizing
and indexing a value.
When extractors are set to a lexicon, they are applied automatically when an index of the lexicon is updated. If you specify multiple extractors, they are applied in order. The output of an extractor is passed to the next extractor as its input.
You cannot use extractors with TABLE_NO_KEY because
TABLE_NO_KEY doesn't support key.
See Extractors for all extractors.
デフォルト値はありません。
7.3.64.4.2.8. path#
Added in version 10.0.7.
テーブルを格納するパスを指定します。
このオプションは、高速なストレージ(SSDなど)によく使うテーブルを格納し、低速なストレージ(HDDなど)にあまり使わないテーブルを格納したいときに有用です。
このオプションでは、絶対パスまたは相対パスを使えます。相対パスを指定した場合は、 groonga プロセスのカレントディレクトリーからパスを解決します。
デフォルト値はありません。
7.3.64.5. 戻り値#
table_create が成功したときは以下のようにボディは true になります:
[HEADER, true]
table_create が失敗すると、エラーの詳細は HEADER に含まれます。
HEADER については 出力形式 を参照してください。