本文へスキップ
`Ctrl`+`K`

# 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_NO_KEY 参照。
`TABLE_HASH_KEY` | ハッシュテーブル。 TABLE_HASH_KEY 参照。
`TABLE_PAT_KEY` | パトリシアトライ。 TABLE_PAT_KEY 参照。
`TABLE_DAT_KEY` | ダブル配列トライ。 TABLE_DAT_KEY 参照。
`KEY_WITH_SIS` | 半無限文字列を有効にします。 `TABLE_PAT_KEY` と使う必要があります。
`KEY_LARGE` | 最大総キーサイズを4GiBから1TiBへ拡張します。 `TABLE_HASH_KEY` または `TABLE_PAT_KEY` と使う必要があります。

注釈

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.

注釈

これは実験的な機能です。現時点ではまだ安定しきっていません。

エクストラクターを「,」（カンマ）区切りで指定します。エクストラクターは、値をトークナイズしてインデックスする前に、HTMLやJSONなどの構造化されたデータからプレーンテキストや値を抽出します。

エクストラクターを語彙表に設定すると、その語彙表のインデックスが更新されるときに自動的に適用されます。複数のエクストラクターを指定した場合は、順番に適用されます。あるエクストラクターの出力は、次のエクストラクターの入力として渡されます。

`TABLE_NO_KEY` はキーをサポートしていないので、 `TABLE_NO_KEY` と `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` については 出力形式 を参照してください。

## 7.3.64.6. 参考

- テーブル

- column_create

- トークナイザー

- ノーマライザー

- エクストラクター

- 出力形式