1.2.1 - en to ja translation catalogue (296 entries)

en: Execution example::
ja: 実行例::

en: Summary
ja: 概要

en: ``column_create`` creates a new column in a table.
ja: ``column_create`` はテーブルに新しいカラムを作成します。

en: You need to create one or more columns to store multiple data in one record.
ja: 1つのレコードに複数の値を保存したい場合は1つ以上カラムを作成する必要があります。

en: Groonga provides an index as a column. It's different from other systems. An index is just an index in other systems. Implementing an index as a column provides flexibility. For example, you can add metadata to each token.
ja: Groongaはインデックスをカラムとして提供しています。これは他のシステムと異なります。他のシステムではインデックスはインデックスです。インデックスをカラムとして実装していることで高い柔軟性を実現しています。たとえば、各トークンにメタデータを追加することができます。

en: See :doc:`/reference/column` for column details.
ja: カラムの詳細は :doc:`/reference/column` を見てください。

en: Syntax
ja: 構文

en: This command takes many parameters.
ja: このコマンドにはたくさんの引数があります。

en: Most parameters are required::
ja: 多くの引数は必須です::

en: Usage
ja: 使い方

en: This section describes about the followings:
ja: このセクションでは次のことについて説明します。

en: Here is the ``People`` table definition. The ``People`` table is used in examples:
ja: 以下は ``People`` テーブルの定義です。例ではこの ``People`` テーブルを使います。

en: Create a scalar column
ja: スカラーカラムを作成

en: Groonga provides scalar column to store one value. For example, scalar column should be used for storing age into a person record. Because a person record must have only one age.
ja: Groongaは1つの値を保存する用途としてスカラーカラムを提供しています。たとえば、「人」レコードに「年齢」情報を保存するときはスカラーカラムが適切です。なぜなら「人」レコードは「年齢」を1つだけ持つからです。

en: If you want to store multiple values into a record, scalar column isn't suitable. Use :ref:`column-create-vector` instead.
ja: 1つのレコードに複数の値を保存したい場合には、スカラーカラムは適していません。代わりに :ref:`column-create-vector` を使ってください。

en: You must specify ``COLUMN_SCALAR`` to the ``flags`` parameter to create a scalar column.
ja: スカラーカラムを作成するには ``flags`` 引数に ``COLUMN_SCALAR`` を指定します。

en: Here is an example to create the ``age`` column to the ``People`` table. ``age`` column is a scalar column. It can store one ``UInt8`` (``0-255``) value as its value:
ja: 以下は ``People`` テーブルに ``age`` カラムを作成する例です。 ``age`` カラムはスカラーカラムです。このカラムには ``UInt8`` （ ``0-255`` ）の値を1つ保存できます。

en: You can store one value (``7``) by the following :doc:`load` command:
ja: 以下の :doc:`load` コマンドで1つの値（ ``7`` ）を保存できます。

en: You can confirm the stored one value (``7``) by the following :doc:`select` command:
ja: 以下の :doc:`select` コマンドで保存された1つの値（ ``7`` ）を確認できます。

en: Create a vector column
ja: ベクターカラムを作成

en: Groonga provides vector column to store multiple values. For example, vector column may be used for storing roles into a person record. Because a person record may have multiple roles.
ja: Groongaは複数の値を保存する用途としてベクターカラムを提供しています。たとえば、「人」レコードに複数の「役割」を保存する場合はベクターカラムが適切です。なぜなら「人」レコードは複数の「役割」を持つかもしれないからです。

en: If you want to store only one value into a record, vector column isn't suitable. Use :ref:`column-create-scalar` instead.
ja: もし1つのレコードに値を1つだけ保存したい場合はベクターカラムは向いていません。代わりに :ref:`column-create-scalar` を使ってください。

en: You must specify ``COLUMN_VECTOR`` to the ``flags`` parameter to create a vector column.
ja: ベクターカラムを作成するには ``flags`` パラメーターに ``COLUMN_VECTOR`` を指定します。

en: Here is an example to create the ``roles`` column to the ``People`` table. ``roles`` column is a vector column. It can store zero or more ``ShortText`` values as its value:
ja: 以下は ``People`` テーブルに ``roles`` カラムを作成する例です。 ``roles`` カラムはベクターカラムです。カラムの値として0個以上の ``ShortText`` の値を保存できます。

en: You can store multiple values (``["adventurer", "younger-sister"]``) by the following :doc:`load` command:
ja: 以下の :doc:`load` コマンドで複数の値（ ``["adventurer", "younger-sister"]`` ）を保存できます。

en: You can confirm the stored multiple values (``["adventurer", "younger-sister"]``) by the following :doc:`select` command:
ja: 保存した複数の値（ ``["adventurer", "younger-sister"]`` ）は以下の :doc:`select` コマンドで確認できます。

en: Create a weight vector column
ja: 重み付きベクターカラムの作成

en: Create a column that refers a table's record
ja: テーブルのレコードを参照するカラムを作成

en: Both scalar column and vector column can store reference to record of an existing table as column value. It's useful to store relationship between records.
ja: スカラーカラムもベクターカラムも既存のテーブルのレコードへの参照を保存することができます。これはレコード間の参照関係を保存する場合に便利です。

en: For example, using a column that refers a person record is better for storing a character into a book record. Because one person may be appeared in some books.
ja: たとえば、「本」レコードで登場人物を保存する場合は、「人」レコードを参照するカラムを使うとよいです。なぜなら、同じ「人」が複数の本に登場するかもしれないからです。

en: You must specify table name to be referenced to the ``type`` parameter to create a column that refers a table's record.
ja: テーブルのレコードを参照するカラムを作成するには ``type`` パラメーターに参照するテーブルの名前を指定します。

en: Here is an example to create the ``character`` column to the ``Books`` table. The ``character`` column refers the ``People`` table. It can store one ``People`` table's record.
ja: 以下は ``Books`` テーブルに ``character`` カラムを作成する例です。 ``character`` カラムは ``People`` テーブルを参照しています。 ``character`` カラムには ``People`` テーブルのレコードを1つ保存できます。

en: Here is the ``Books`` table definition:
ja: 以下が ``Books`` テーブルの定義です。

en: Here is the ``character`` column definition in the ``Books`` table. ``--type People`` is important:
ja: 以下は ``Books`` テーブルにある ``character`` カラムの定義です。 ``--type People`` がポイントです。

en: You can store one reference (``"alice"``) by the following :doc:`load` command. You can use key value (``People._key`` value) for referring a record:
ja: 以下の :doc:`load` コマンドで1つの参照（ ``"alice"`` ）を保存できます。レコードを参照するにはキーの値（ ``People._key`` の値）を使います。

en: You can confirm the stored reference (``"alice"`` record) by the following :doc:`select` command. It retrieves the ``age`` column and the ``roles`` column values:
ja: 保存した参照（ ``"alice"`` レコード）は以下の :doc:`select` コマンドで確認できます。以下の例では ``age`` カラムの値と ``roles`` カラムの値を取得しています。

en: Create an index column
ja: インデックスカラムを作成

en: Groonga provides index column for fast search. It doesn't store your data. It stores data for fast search.
ja: Groongaは高速に検索する用途としてインデックスカラムを提供しています。インデックスカラムはあなたのデータを保存しません。インデックスカラムは高速な検索に必要なデータを保存します。

en: You don't need to update index column by yourself. Index column is updated automatically when you store data into a data column (scalar column or vector column) that is marked as index target column. You can set multiple columns as index target columns to one index column.
ja: インデックスカラムは自分で更新する必要はありません。インデックス対象のデータカラム（スカラーカラムまたはベクターカラム）にデータを入れると、インデックスカラムは自動で更新されます。1つのインデックスカラムに複数のインデックス対象のカラムを指定することもできます。

en: If you make a new index, it is invisible until finishing of index build.
ja: 新規にインデックスを作成する場合、インデックスの構築が完了するまで、そのインデックスは無視されます。

en: If Groonga has an index column for the ``age`` column of the ``People`` table, Groonga can do fast equal search, fast comparison search and fast range search against ``age`` column values.
ja: もし、 ``People`` テーブルの ``age`` カラム用のインデックスカラムがあると、 ``age`` カラムの値に対する完全一致検索・比較検索・範囲検索を高速に処理することができます。

en: You must specify the following parameters to create an index column:
ja: インデックスカラムを作成するには次のパラメーターを指定します。

en: The ``flags`` parameter: ``COLUMN_INDEX``
ja: ``flags`` パラメーター： ``COLUMN_INDEX``

en: The ``type`` parameter: The table name of index target column such as ``People``
ja: ``type`` パラメーター： インデックス対象カラムのテーブル名（たとえば ``People`` ）

en: The ``source`` parameter: The index target column name such as ``age``
ja: ``source`` パラメーター：インデックス対象カラム名（たとえば ``age`` ）

en: You don't need additional flags to the ``flags`` parameter for equal search, comparison search and range search index column. You need additional flags to the ``flags`` parameter for full text search index column or multiple column index column. See :ref:`column-create-index-full-text-search` and :ref:`column-create-index-multiple-columns` for details.
ja: 完全一致検索・比較検索・範囲検索用のインデックスカラムには ``flags`` パラメーターに追加のフラグは必要ありません。全文検索用のインデックスカラム、マルチカラムインデックスカラムには追加のフラグが必要になります。詳細は :ref:`column-create-index-full-text-search` と :ref:`column-create-index-multiple-columns` を見てください。

en: Here is an example to create an index column for the ``age`` column of the ``People`` table.
ja: 以下は ``People`` テーブルの ``age`` カラム用のインデックスカラムを作成する例です。

en: First, you need to create a table for range index column. See :ref:`table-create-range-index-table` for details. This example creates the ``Ages`` table as :ref:`table-pat-key`:
ja: はじめに範囲インデックスカラム用のテーブルを作成します。詳細は :ref:`table-create-range-index-table` を見てください。この例では :ref:`table-pat-key` として ``Ages`` テーブルを作成します。

en: Now, you can create an index column for the ``age`` column of the ``People`` table. ``COLUMN_INDEX`` in the ``flags`` parameter, ``People`` in the ``type`` parameter and ``age`` in the ``source`` parameter are important:
ja: これで ``People`` テーブルの ``age`` カラム用のインデックスカラムを作れるようになりました。 ``flags`` パラメーターの ``COLUMN_INDEX`` 、 ``type`` パラメーターの ``People`` 、 ``source`` パラメーターの ``age`` がポイントです。

en: You can confirm that ``age > 5`` is evaluated by the ``Ages.people_age_index`` newly created index column from log. Groonga reports used index columns in ``info`` log level. You can change log level dynamically by :doc:`log_level` command.
ja: ログを確認すると、新しく作成した ``Ages.people_age_index`` インデックスカラムを使って ``age > 5`` を評価していることがわかります。Groongaは使用したインデックスカラムを ``info`` ログレベルでログに出力します。ログレベルは :doc:`log_level` コマンドを使うと動的に変更できます。

en: You can confirm that the ``Ages.people_age_index`` is used from the following log::
ja: 以下のログから ``Ages.people_age_index`` が使われたことを確認できます。

en: The log says ``Ages.people_age_index`` index column is used for range search.
ja: このログは範囲検索に ``Ages.people_age_index`` インデックスカラムを使ったことを示しています。

en: Create an index column for full text search
ja: 全文検索用のインデックスカラムを作成

en: There is a difference between for non full text search (equal search, comparison search or range search) index column and for full text search index column. You need to add ``WITH_POSITION`` to the ``flags`` parameter. It means that you need to specify ``COLUMN_INDEX|WITH_POSITION`` to the ``flags`` parameter. It's the difference.
ja: 非全文検索（完全一致検索・比較検索・範囲検索）用インデックスカラムと全文検索用インデックスカラムには1つ違いがあります。全文検索用インデックスカラムでは ``flags`` パラメーターに ``WITH_POSITION`` を追加する必要があります。つまり、 ``flags`` パラメーターに ``COLUMN_INDEX|WITH_POSITION`` を指定するということです。これが違いです。

en: Here is an example to create a full text search index column for the key of the ``People`` table.
ja: 以下は ``People`` テーブルのキー用の全文検索インデックスカラムを作成する例です。

en: First, you need to create a table for full text search index column. See :ref:`table-create-lexicon` for details. This example creates the ``Terms`` table as :ref:`table-pat-key` with :ref:`token-bigram` tokenizer and :ref:`normalizer-auto` normalizer:
ja: はじめに全文検索インデックスカラム用のテーブルを作成します。詳細は :ref:`table-create-lexicon` を見てください。この例では :ref:`table-pat-key` に :ref:`token-bigram` トークナイザーと :ref:`normalizer-auto` ノーマライザーを指定した ``Terms`` テーブルを作成しています。

en: Now, you can create a full text search index column for the key of the ``People`` table. ``COLUMN_INDEX|WITH_POSITION`` in the ``flags`` parameter, ``People`` in the ``type`` parameter and ``_key`` in the ``source`` parameter are important:
ja: これで ``Poeple`` テーブルのキー用の全文検索インデックスカラムを作成できるようになりました。 ``flags`` パラメーターの ``COLUMN_INDEX|WITH_POSITION`` 、 ``type`` パラメーターの ``People`` 、 ``source`` パラメーターの ``_key`` がポイントです。

en: You can confirm that ``--match_columns _key`` and ``--query Alice`` are evaluated by the ``Terms.people_key_index`` newly created full text search index column from log. Groonga reports used index columns in ``info`` log level. You can change log level dynamically by :doc:`log_level` command.
ja: ログを確認すると、新しく作成した ``Terms.people_key_index`` 全文検索インデックスカラムで ``--match_columns _key`` と ``--query Alice`` を処理していることがわかります。Groongaは使用したインデックスカラムを ``info`` ログレベルでログに出力します。ログレベルは :doc:`log_level` コマンドを使うと動的に変更できます。

en: You can confirm that the ``Terms.people_key_index`` is used from the following log::
ja: 以下のログから ``Terms.people_key_index`` を使ったことを確認できます。

en: The log says ``Terms.people_key_index`` index column is used for full text search. (To be precise, the index column is used for exact term search by inverted index.)
ja: このログは全文検索に ``Terms.people_key_index`` インデックスカラムを使ったことを示しています。（正確に言うと転置索引を使った完全一致検索にこのインデックスカラムを使っています。）

en: Create a multiple columns index column
ja: マルチカラムインデックスカラムを作成

en: You can create an index column for multiple columns. It means that you can do fast search for multiple columns with one index column. Multiple columns index column has better space efficiency than single column index column only when multiple columns have many same tokens. Multiple columns index column may be slower than single column index column. Because multiple columns index column will be a bigger index column.
ja: 複数のカラム用のインデックスカラムを作成できます。これは1つのインデックスカラムで複数のカラムに対して高速に検索できるということです。インデックス対象の複数のカラムが多くの同じトークンを共有しているときは、マルチカラムインデックスカラムはシングルカラムインデックスカラムよりも空間効率がよくなります。一方、検索速度はシングルカラムインデックスカラムの方が速くなることが多いです。理由はマルチカラムインデックスカラムは大きくなりがちだからです。

en: You can't use multiples columns in different tables as index target columns in the same multiple columns index column. You must specify columns in the same tables as index target columns to one multiple columns index column. For example, you can't create a multiple columns index for ``People._key`` and ``Books._key`` because they are columns of different tables. You can create a multiple columns index column for ``People._key`` and ``People.roles`` because they are columns of the same table.
ja: 1つのマルチカラムインデックスカラムで、異なるテーブルの複数のカラムをインデックス対象にすることはできません。1つのマルチカラムインデックスカラムでは同じテーブルの複数のカラムをインデックス対象に指定してください。たとえば、 ``People._key`` と ``Books._key`` をインデックス対象としたマルチカラムインデックスカラムは作成できません。なぜなら、違うテーブルのカラムだからです。 ``People._key`` と ``People.roles`` をインデックス対象としたマルチカラムインデックスカラムは作成できます。なぜなら同じテーブルのカラムだからです。

en: There is a difference between for single column index column and for multiple columns index column. You need to add ``WITH_SECTION`` to the ``flags`` parameter. It means that you need to specify ``COLUMN_INDEX|WITH_SECTION`` to the ``flags`` parameter. It's the difference.
ja: シングルカラムインデックスカラムとマルチカラムインデックスカラムでは違いがあります。マルチカラムインデックスカラムのときは ``flags`` パラメーターに ``WITH_SECTION`` を追加しなければいけません。つまり、 ``flags`` パラメーターに ``COLUMN_INDEX|WITH_SECTION`` と指定するということです。これが違いです。

en: If you want to create a multiple columns index column for full text search, you need to specify ``COLUMN_INDEX|WITH_POSITION|WITH_SECTION`` to the ``flags`` parameter. See :ref:`column-create-index-full-text-search` for full text search index column details.
ja: 全文検索用のマルチカラムインデックスカラムを作成する場合は ``flags`` パラメーターに ``COLUMN_INDEX|WITH_POSITION|WITH_SECTION`` と指定します。全文検索インデックスカラムの詳細は :ref:`column-create-index-full-text-search` を見てください。

en: Here is an example to create a multiple columns index column for the key of the ``People`` table and the ``roles`` column of the ``People`` table.
ja: 以下は ``People`` テーブルのキーと ``roles`` カラム用のマルチカラムインデックスカラムを作成する例です。

en: There is no difference between index table for single column index column and multiple columns index column.
ja: インデックス用のテーブルは、シングルカラムインデックスとマルチカラムインデックスカラムで違いはありません。

en: In this example, ``Names`` table is created for equal search and prefix search. It uses ``TABLE_PAT_KEY`` because ``TABLE_PAT_KEY`` supports prefix search. See :doc:`../tables` for details.
ja: この例では、完全一致検索と前方一致検索用に ``Names`` テーブルを作りました。このテーブルは ``TABLE_PAT_KEY`` を使っています。なぜなら ``TABLE_PAT_KEY`` は前方一致検索をサポートしているからです。詳細は :doc:`../tables` を参照してください。

en: You can create a multiple columns index column for the key of the ``People`` table and ``roles`` column of the ``People`` table. ``COLUMN_INDEX|WITH_SECTION`` in the ``flags`` parameter, ``People`` in the ``type`` parameter and ``_key,roles`` in the ``source`` parameter are important:
ja: ``People`` テーブルのキーと ``roles`` カラム用のマルチカラムインデックスカラムを作成します。 ``flags`` パラメーターの ``COLUMN_INDEX|WITH_SECTION`` 、 ``type`` パラメーターの ``People`` 、 ``source`` パラメーターの ``_key,roles`` がポイントです。

en: You can confirm that ``--filter 'roles @^ "Younger"`` is evaluated by the ``Names.people_key_roles_index`` newly created multiple columns index column from log. Groonga reports used index columns in ``info`` log level. You can change log level dynamically by :doc:`log_level` command.
ja: ログを確認すると、新しく作成した ``Names.people_key_roles_index`` インデックスカラムを使って ``--filter 'roles @^ "Younger"`` を評価していることがわかります。Groongaは使用したインデックスカラムを ``info`` ログレベルでログに出力します。ログレベルは :doc:`log_level` コマンドを使うと動的に変更できます。

en: You can confirm that the ``Names.people_key_roles_index`` is used from the following log::
ja: 以下のログから ``Names.people_key_roles_index`` を使ったことを確認できます。

en: The log says ``Names.people_key_roles_index`` index column is used for prefix search.
ja: このログは前方一致検索に ``Names.people_key_roles_index`` インデックスカラムを使ったことを示しています。

en: Create a small index column
ja: 小さなインデックスカラムを作成

en: If you know index target data are small, you can reduce memory usage for the index column. Memory usage is ``1/256`` of the default index column.
ja: もし、インデックス対象のデータが小さいことがわかっているならインデックスカラムが使用するメモリー量を減らせます。デフォルトのインデックスカラムと比べて ``1/256`` のメモリー使用量になります。

en: How many data are small? It depends on data. Small index column can't handle 1 billion records at least. If index target is only one scalar column with no text family type (``ShortText``, ``Text`` or ``LongText``), the maximum handleable records are depends of the number of kinds of index target data. If index target column has ``1``, ``1``, ``2`` and ``3``, the number of kinds of them are ``3`` (``1`` and ``2`` and ``3``). The following table shows the relationship between the number of kinds of index target data and the number of handleable records:
ja: ではどのくらいのデータなら小さいのでしょうか。それはデータによります。小さなインデックスカラムは少なくとも10億レコードを扱えません。もし、インデックス対象がテキスト系の型（``ShortText`` 、 ``Text`` 、 ``LongText`` のどれか）ではないスカラーカラムだけの場合、扱える最大レコード数はインデックス対象のデータの種類に依存します。もし、インデックス対象のカラムに ``1`` 、 ``1`` 、 ``2`` 、 ``3`` というデータが入っていたとすると、種類数は ``3`` （ ``1`` と ``2`` と ``3`` ）になります。以下の表はインデックス対象データの種類数と扱える最大レコード数の関係を示しています。

en: The number of kinds of index target data and the number of handleable records in a small index column
ja: インデックス対象データの種類数と小さなインデックスカラムで扱えるレコード数

en: The number of kinds of index target data
ja: インデックス対象のデータの種類数

en: The number of hanleable records
ja: 処理できるレコード数

en: You need to add ``INDEX_SMALL`` to the ``flags`` parameter such as ``COLUMN_INDEX|INDEX_SMALL`` to create a small index column.
ja: 小さなインデックスカラムを作成するには ``COLUMN_INDEX|INDEX_SMALL`` というように ``flags`` パラメーターに ``INDEX_SMALL`` を追加します。

en: If the ``People`` table has only 1 million records, you can use a small index column for the ``age`` column:
ja: ``People`` テーブルが100万レコードしかないなら、 ``age`` カラム用に小さなインデックスカラムを使うことができます。

en: Create a medium index column
ja: 中サイズのインデックスカラムを作成

en: If you know index target data are medium, you can reduce memory usage for the index column. Memory usage is ``5/24`` of the default index column.
ja: インデックス対象のデータが中サイズならインデックスカラムが使うメモリー使用量を減らすことができます。デフォルトのインデックスカラムよりも ``5/24`` のメモリー使用量になります。

en: How many data are medium? It depends on data.
ja: どのくらいのデータが中サイズのデータでしょうか。それはデータによります。

en: If index target is only one scalar column, a medium index column can handle all records.
ja: もし、インデックス対象がスカラーカラム1つだけであれば、中サイズのインデックスカラムはすべてのレコードを処理できます。

en: A medium index column may not handle all records at the following cases:
ja: 以下のケースでは中サイズのインデックスカラムはすべてのレコードを処理できないかもしれません。

en: Index target is one text family (``ShortText``, ``Text`` or ``LongText``) scalar column
ja: インデックス対象がテキスト系の型（ ``ShortText`` 、 ``Text`` 、 ``LongText`` のどれか）のスカラーカラム1つ

en: Index target is one vector column
ja: インデックス対象がベクターカラム1つ

en: Index targets are multiple columns
ja: インデックス対象が複数のカラム

en: Index table has tokenizer
ja: インデックステーブルにトークナイザーが付いている

en: You need to add ``INDEX_MEDIUM`` to the ``flags`` parameter such as ``COLUMN_INDEX|INDEX_MEDIUM`` to create a medium index column.
ja: 中サイズのインデックスカラムを作成するには ``COLUMN_INDEX|INDEX_MEDIUM`` というように ``flags`` パラメーターに ``INDEX_MEDIUM`` を追加します。

en: You can use a medium index column for an index column of the ``age`` column of the ``People`` table safely. Because it's one scalar column with ``UInt8`` type.
ja: ``People`` テーブルの ``age`` カラム用のインデックスカラムであれば中サイズのインデックスカラムでも安全です。なぜなら、 ``UInt8`` 型のスカラーカラム1つだからです。

en: Here is an example to create a medium index column:
ja: 以下は中サイズのインデックスカラムを作る例です。

en: Create a large index column
ja: 大きなインデックスカラムを作成

en: If you know index target data are large, you need to use large index column. It uses increases memory usage for the index column but it can accept more data. Memory usage is 2 times larger than the default index column.
ja: もし、インデックス対象のデータが大きいことがわかっているなら大きなインデックスカラムを使わなければいけません。このインデックスカラムが使用するメモリー量が増えますが、より多くのデータを扱えます。デフォルトのインデックスカラムと比べて2倍のメモリー使用量になります。

en: How many data are large? It depends on data.
ja: どのくらいのデータが大きなデータでしょうか。それはデータによります。

en: If index target is only one scalar column, it's not large data.
ja: もし、インデックス対象がスカラーカラム1つだけであれば、大きくありません。

en: Large data must have many records (normally at least 10 millions records) and at least one of the following features:
ja: 大きなデータは大量のレコード（通常は少なくとも1000万レコード以上）があり、少なくとも次のうちの1つ以上の特徴があります。

en: You need to add ``INDEX_LARGE`` to the ``flags`` parameter such as ``COLUMN_INDEX|INDEX_LARGE`` to create a large index column.
ja: 大きなインデックスカラムを作成するには ``COLUMN_INDEX|INDEX_LARGE`` というように ``flags`` パラメーターに ``INDEX_LARGE`` を追加します。

en: You can use a large index column for an index column of the ``_key`` of the ``People`` table and the ``role`` column of the ``People`` table.
ja: 以下は ``People`` テーブルのキーと ``roles`` カラム用に大きなインデックスカラムを作成する例です。

en: Here is an example to create a large index column:
ja: 以下は大きなインデックスカラムを作る例です。

en: Missing mode
ja: ミッシングモード

en: You can control how to process a nonexistent key in the specified new value of a reference column by a ``MISSING_*`` flag. Here are available ``MISSING_*`` flags:
ja: ``MISSING_*`` フラグを使うと参照カラムに指定した新しい値に存在しないキーがあったときにどう処理するかを制御できます。指定できる ``MISSING_*`` フラグは次のとおりです。

en: ``MISSING_ADD`` (default)
ja: ``MISSING_ADD`` （デフォルト）

en: You can't specify multiple ``MISSING_*`` flags for a column.
ja: 1つのカラムに複数の ``MISSING_*`` フラグを指定することはできません。

en: ``MISSING_*`` flags are meaningful only for a reference column.
ja: ``MISSING_*`` フラグは参照カラムでのみ意味があります。

en: The following table describes the differences between ``MISSING_*`` flags when a nonexistent key is specified to a reference scalar column:
ja: 次の表は参照スカラーカラムに存在しないキーを指定したときに ``MISSING_*`` フラグでどのような違いがあるかを説明しています。

en: Flag
ja: フラグ

en: Description
ja: 説明

en: An example given value
ja: 指定された値の例

en: An example set value
ja: セットされた値の例

en: The given nonexistent key is added to the referred table automatically and the ID of the newly added record is set.
ja: 指定された存在しないキーは参照されているテーブルに自動で追加されます。新しく追加されたレコードのIDが値としてセットされます。

en: This is the default.
ja: これがデフォルトです。

en: The record ID of the newly added record whose key is ``"nonexistent"``.
ja: キーの値が ``"nonexistent"`` の新しく追加されたレコードのID。

en: The given nonexistent key is ignored and ``0`` is set.
ja: 指定された存在しないキーは無視され、 ``0`` がセットされます。

en: There is no difference between ``MISSING_IGNORE`` and ``MISSING_NIL`` for a reference scalar column.
ja: 参照スカラーカラムでは ``MISSING_IGNORE`` と ``MISSING_NIL`` に違いはありません。

en: Here is an example to show differences between ``MISSING_*`` flags for a reference scalar column.
ja: 次の例は参照スカラーカラムが ``MISSING_*`` フラグでどう変わるかを示す例です。

en: First this example defines columns for all ``MISSING_*`` flags:
ja: 最初に、この例ではすべての ``MISSING_*`` フラグ用のカラムをそれぞれ定義します。

en: Then this example loads nonexistent keys to all columns. The specified nonexistent key for ``MISSING_ADD`` is only added to ``MissingModeScalarReferred`` automatically and the specified nonexistent keys for ``MISSING_IGNORE`` and ``MISSING_NIL`` aren't added to ``MissingModeScalarReferred``. ``missing_ignore``'s value and ``missing_nil``'s value are showed as ``""`` because they refer a record whose ID is ``0`` and record whose ID is ``0`` never exist:
ja: それから、この例では存在しないキーをすべてのカラムにロードします。 ``MISSING_ADD`` 付きのカラムに指定した存在しないキーだけが自動的に ``MissingModeScalarReferred`` に追加されます。 ``MISSING_IGNORE`` と ``MISSING_NIL`` 付きのカラムに指定した存在しないキーは ``MissingModeScalarReferred`` に追加されません。 ``missing_ignore`` の値と ``missing_nil`` の値は ``""`` と表示されます。なぜなら、これらのカラムの値はIDが ``0`` のレコードを参照しているからです。IDが ``0`` のレコードは必ず存在しないのでキーが存在しません。そのため、 ``""`` と表示されます。

en: The following table describes the differences between ``MISSING_*`` flags when a vector value that has a nonexistent key element is specified to a reference vector column:
ja: 次の表は参照ベクターカラムに存在しないキーを含むベクターを指定したときに ``MISSING_*`` フラグでどのような違いがあるかを説明します。

en: The given nonexistent key is added to the referred table automatically and the ID of the newly added record is used for the element.
ja: 指定された存在しないキーは参照されているテーブルに自動的に追加されます。その要素の値は新しく追加されたレコードのIDになります。

en: The record IDs of ``"existent1"``, ``"nonexistent"`` and ``"existent2"``.
ja: ``"existent1"`` と ``"nonexistent"`` と ``"existent2"`` のレコードのIDです。

en: The given nonexistent key element is ignored.
ja: 指定された存在しないキーの要素は無視されます。

en: The record IDs of ``"existent1"`` and ``"existent2"``.
ja: ``"existent1"`` と ``"existent2"`` のレコードIDです。

en: If ``INVALID_WARN`` or ``INVALID_IGNORE`` are also specified, the element is replaced with ``0``. If ``INVALID_ERROR`` is specified or no ``INVALID_*`` are specified, the element is ignored.
ja: ``INVALID_WARN`` あるいは ``INVALID_IGNORE`` も指定している場合は、この要素は ``0`` に置き換えられます。もし、 ``INVALID_ERROR`` を指定しているあるいはなにも ``INVALID_*`` を指定していない場合は、この要素は無視されます。

en: See also :ref:`column-create-invalid-mode`.
ja: :ref:`column-create-invalid-mode` も参照してください。

en: The record ID of ``"existent1"`` and ``0`` and the record ID of ``"existent2"`` for ``INVALID_WARN`` and ``INVALID_IGNORE``.
ja: ``INVALID_WARN`` と ``INVALID_IGNORE`` の場合は ``"existent1"`` のレコードIDと ``0`` と ``"existent2"`` のレコードIDです。

en: The record IDs of ``"existent1"`` and ``"existent2"`` for ``INVALID_ERROR`` and no ``INVALID_*``.
ja: ``INVALID_ERROR`` を指定している場合となにも ``INVALID_*`` を指定していない場合は ``"existent1"`` と ``"existent2"`` のレコードIDです。

en: Here is an example to show differences between ``MISSING_*`` flags for a reference vector column.
ja: 次の例は参照ベクターカラムに ``MISSING_*`` フラグを指定したときの違いを示しています。

en: Then this example loads a vector that includes a nonexistent key to all columns. The specified nonexistent key for ``MISSING_ADD`` is only added to ``MissingModeVectorReferred`` automatically and the specified nonexistent keys for ``MISSING_IGNORE`` and ``MISSING_NIL`` aren't added to ``MissingModeVectorReferred``. The specified nonexistent key element is removed from ``missing_ignore``'s value. The specified nonexistent key element is replaced with ``0`` in ``missing_nil``'s value because ``INVALID_IGNORE`` is also specified. And the element replaced with ``0`` is showed as ``""`` because it refers a record whose ID is ``0`` and record whose ID is ``0`` never exist:
ja: それからこの例はすべてのカラムに存在しないキーを含むベクターを設定します。 ``MISSING_ADD`` を指定したカラムの場合だけ、存在しないキーは自動的に ``MissingModeVectorReferred`` に追加されます。 ``MISSING_IGNORE`` と ``MISSING_NIL`` を指定したカラムの場合は ``MissingModeVectorReferred`` には追加されません。 ``missing_ignore`` の値では存在しないキーの要素は削除されます。 ``missing_nil`` の値では存在しないキーの要素は ``0`` に置き換えられます。なぜなら ``INVALID_IGNORE`` も指定されているからです。 ``0`` に置き換えられた要素は ``""`` と表示されます。なぜならこの要素はID ``0`` のレコードを参照することになるからです。IDが ``0`` のレコードは必ず存在しないのでキーが存在しません。そのため ``""`` と表示されます。

en: Invalid mode
ja: 不正モード

en: You can control how to process an invalid value in the specified new value of a data column by a ``INVALID_*`` flag. Here are available ``INVALID_*`` flags:
ja: ``INVALID_*`` フラグを使うことでデータカラムに指定した新しい値に不正な値があったときにどう処理するかを制御できます。指定できる ``INVALID_*`` フラグは次のとおりです。

en: ``INVALID_ERROR`` (default)
ja: ``INVALID_ERROR`` （デフォルト）

en: You can't specify multiple ``INVALID_*`` flags for a column.
ja: 1つのカラムに複数の ``INVALID_*`` フラグを指定することはできません。

en: ``INVALID_*`` flags are meaningful only for a ``COLUMN_SCALAR`` column and a ``COLUMN_VECTOR`` column.
ja: ``INVALID_*`` フラグは ``COLUMN_SCALAR`` と ``COLUMN_VECTOR`` でだけ使えます。

en: If the target column is a reference column, an invalid value depends on :ref:`column-create-missing-mode`. If you specify ``MISSING_IGNORE`` or ``MISSING_NIL``, a nonexistent key is an invalid value. Note that an empty string key and string keys that are empty strings by normalization aren't an invalid value with all ``MISSING_*`` flags. They are special.
ja: 対象のカラムが参照カラムの場合、どんな値が不正かどうかは :ref:`column-create-missing-mode` に依ります。もし、 ``MISSING_IGNORE`` あるいは ``MISSING_NIL`` を指定している場合は存在しないキーは不正な値です。ただし、空文字列キーあるいはノーマライズするとから文字列になるキーはどの ``MISSING_*`` フラグの値でも不正ではありません。これらは特別です。

en: If the target column isn't a reference column, an invalid value depends on column's value type. For example, ``"invalid"`` is an invalid value for an ``Int32`` scalar column.
ja: 対象のカラムが参照カラムでない場合はどんな値が不正かどうかはカラムの値の型に依ります。たとえば、 ``Int32`` スカラーカラムでは ``"invalid"`` は不正な値です。

en: The following table describes the differences between ``INVALID_*`` flags when an invalid value is specified to an ``Int32`` scalar column:
ja: 次の表は ``Int32`` スカラーカラムに不正な値を指定したときに ``INVALID_*`` フラグでどんな違いがあるかを説明します。

en: The given invalid value is reported as an error in :ref:`process-log` and by :doc:`load`.
ja: 指定された不正な値は :ref:`process-log` にエラーとして記録され、 :doc:`load` もエラーを返します。

en: The given invalid value isn't set.
ja: 指定された不正な値はセットされません。

en: The column isn't updated.
ja: このカラムは更新されません。

en: The given invalid value is reported as a warning in :ref:`process-log`.
ja: 指定された不正な値は :ref:`process-log` に警告として記録されます。

en: The given invalid value is replaced with the default value of the target scalar column. For example, ``0`` is the default value for an ``Int32`` scalar column.
ja: 指定された不正な値は対象のスカラーカラムのデフォルト値に置き換えられます。たとえば、 ``Int32`` スカラーカラムでは  ``0`` がデフォルト値です。

en: The given invalid value is ignored.
ja: 指定された不正な値はセットされません。

en: Here is an example to show differences between ``INVALID_*`` flags for an ``Int32`` scalar column.
ja: 次の例は ``Int32`` スカラーカラムで ``INVALID_*`` のフラグでどんな違いがあるかを示します。

en: First this example defines columns for all ``INVALID_*`` flags:
ja: 最初にこの例はすべての ``INVALID_*`` フラグ用のカラムをそれぞれ定義します。

en: Then this example loads ``29`` as initial values for all columns to show differences between them on update:
ja: それからこの例は初期値としてすべてのカラムに ``29`` をロードします。これは更新時でどのような違いがあるかを示すためです。

en: Then this example update existing column values with invalid values. The specified invalid value is reported as an error by :doc:`load` only with ``INVALID_ERROR``. And the existing value isn't updated only with ``INVALID_ERROR``. The existing value is updated with ``0`` with ``INVALID_WARN`` and ``INVALID_IGNORE``. You can't see differences between ``INVALID_WARN`` and ``INVALID_IGNORE`` with this example but a warning message is logged in :ref:`process-log` only with ``INVALID_WARN``:
ja: それからこの例は不正な値で既存のカラムの値を更新します。指定された不正な値は ``INVALID_ERROR`` のときだけ :doc:`load` はエラーを返します。そして ``INVALID_ERROR`` のときだけ既存の値は更新されません。 ``INVALID_WARN`` と ``INVALID_IGNORE`` のときは既存の値は ``0`` で更新されます。この例では ``INVALID_WARN`` と ``INVALID_IGNORE`` の違いはわかりませんが、 ``INVALID_WARN`` のときだけ :ref:`process-log` に警告メッセージが記録されています。

en: The following table describes the differences between ``INVALID_*`` flags when a vector value that has an invalid element is specified to an ``Int32`` vector column:
ja: 次の表は ``Int32`` ベクターカラムに不正な要素を含むベクターを設定したときに ``INVALID_*`` フラグによってどのような違いがあるかを説明します。

en: The given invalid element is reported as an error in :ref:`process-log` but :doc:`load` doesn't report an error.
ja: 指定された不正な要素は :ref:`process-log` にエラーとして記録されますが、 :doc:`load` はエラーを返しません。

en: If the target column is a reference vector column and ``MISSING_NIL`` flag is specified, invalid elements are replaced with ``0``. Invalid elements are ignored otherwise.
ja: もし対象のカラムが参照ベクターカラムで ``MISSING_NIL`` フラグが指定されていた場合は、不正な要素は ``0`` に置き換えられます。それ以外のフラグの場合は不正な要素は無視されます。

en: The given invalid element is reported as a warning in :ref:`process-log`.
ja: 指定された不正な要素は :ref:`process-log` に警告として記録されます。

en: The given invalid element is ignored.
ja: 指定された不正な要素は無視されます。

en: Here is an example to show differences between ``INVALID_*`` flags for a reference vector column.
ja: 次の例は参照ベクターカラムでは ``INVALID_*`` フラグでどのような違いがあるかを示します。

en: Then this example loads a vector that includes an invalid element to all columns. The all specified invalid elements are ignored regardless of ``INVALID_*`` flags. Messages in :ref:`process-log` are different by ``INVALID_*`` flags. If ``INVALID_ERROR`` is specified, an error message is logged in :ref:`process-log`. If ``INVALID_WARN`` is specified, a warning message is logged in :ref:`process-log`. ``INVALID_IGNORE`` is specified, no message is logged in :ref:`process-log`:
ja: それからこの例は不正な要素を含むベクターをすべてのカラムにロードします。すべての指定された不正な要素は ``INVALID_*`` フラグによらず無視されます。 :ref:`process-log` 内のメッセージは ``INVALID_*`` フラグによって違います。 ``INVALID_ERROR`` を指定している場合は :ref:`process-log` にエラーメッセージが記録されます。 ``INVALID_WARN`` を指定している場合は :ref:`process-log` に警告メッセージが記録されます。 ``INVALID_IGNORE`` を指定している場合は :ref:`process-log` にメッセージは記録されません。

en: Parameters
ja: 引数

en: This section describes all parameters.
ja: このセクションではすべての引数について説明します。

en: Required parameters
ja: 必須引数

en: There are some required parameters.
ja: いくつか必須の引数があります。

en: Specifies an existing table name for the new column.
ja: 新しいカラムを追加する対象となる既存のテーブル名を指定します。

en: Specifies the column name to be created.
ja: 作成するカラム名を指定します。

en: The column name must be unique in the same table.
ja: カラム名は同じテーブル内で一意でなければいけません。

en: Here are available characters:
ja: 利用可能な文字は以下の通りです。

en: ``0`` .. ``9`` (digit)
ja: ``0`` .. ``9`` （数字）

en: ``a`` .. ``z`` (alphabet, lower case)
ja: ``a`` .. ``z`` （アルファベット。小文字）

en: ``A`` .. ``Z`` (alphabet, upper case)
ja: ``A`` .. ``Z`` （アルファベット。大文字）

en: ``#`` (hash)
ja: ``#`` （シャープ）

en: ``@`` (at mark)
ja: ``@`` （アットマーク）

en: ``-`` (hyphen)
ja: ``-`` （ハイフン）

en: ``_`` (underscore) (NOTE: Underscore can't be used as the first character.)
ja: ``_`` （アンダースコア）（注: 最初の文字としてアンダースコアを使うことはできません。）

en: You need to create a name with one or more the above characters. Note that you can't use ``_`` as the first character such as ``_name``.
ja: 上記の文字を1つ以上使って名前を決めます。 ``_name`` というように、最初の文字に ``_`` を使えないことに注意してください。

en: Specifies the column type and column customize options.
ja: カラムの種類とカラムをカスタマイズするオプションを指定します。

en: Here are available flags:
ja: 指定可能なフラグは以下の通りです。

en: Scalar column. It can store one value. See also :doc:`/reference/columns/scalar` or :ref:`column-create-scalar`.
ja: スカラーカラム。値を1つ保存できます。 :doc:`/reference/columns/scalar` あるいは :ref:`column-create-scalar` も見てください。

en: Vector column. It can store multiple values. See also :doc:`/reference/columns/vector` or :ref:`column-create-vector`.
ja: ベクターカラム。複数の値を保存できます。 :doc:`/reference/columns/vector` あるいは :ref:`column-create-vector` も見てください。

en: Index column. It stores data for fast search. See also :doc:`/reference/columns/index` or :ref:`column-create-index`.
ja: インデックスカラム。高速に検索するためのデータを保存します。 :doc:`/reference/columns/index` あるいは :ref:`column-create-index` も見てください。

en: It enables column value compression by zlib. You need Groonga that enables zlib support.
ja: zlibを使ったカラム値圧縮機能を有効にします。zlibサポート付きのGroongaが必要です。

en: Compression by zlib is higher space efficiency than compression by LZ4. But compression by zlib is slower than compression by LZ4.
ja: zlibを使った圧縮はLZ4を使った圧縮よりも空間効率がよいです。しかし、zlibを使った圧縮はLZ4を使った圧縮よりも遅いです。

en: This flag is available only for ``COLUMN_SCALAR`` and ``COLUMN_VECTOR``.
ja: このフラグは ``COLUMN_SCALAR`` と ``COLUMN_VECTOR`` でだけ使えます。

en: It enables column value compression by LZ4. You need Groonga that enables LZ4 support.
ja: LZ4を使ったカラム値圧縮機能を有効にします。LZ4サポート付きのGroongaが必要です。

en: Compression by LZ4 is faster than compression by zlib. But compression by LZ4 is lower space efficiency than compression by zlib.
ja: LZ4を使った圧縮はzlibを使った圧縮よりも速いです。しかし、LZ4を使った圧縮はzlibを使った圧縮よりも空間効率が低いです。

en: It enables column value compression by Zstandard. You need Groonga that enables Zstandard support.
ja: Zstandardを使ったカラム値圧縮機能を有効にします。Zstandardサポート付きのGroongaが必要です。

en: Compression by Zstandard is faster than compression by zlib and the same space efficiency as zlib.
ja: Zstandardを使った圧縮はzlibを使った圧縮よりも速いです。しかも、Zstandardを使った圧縮はzlibを使った圧縮と同程度の空間効率です。

en: Here are a list of suitable data type for this filter.
ja: では、このフラグがどのようなデータに対して有効かを記載します。

en: This flag reorganize data based on a element of Nth byte.
ja: このフラグはNバイト目の要素に着目してデータを並び替えます。

en: First, 0th byte data of each element within the vector column would be gathered and be continuously placed. Then, 1st byte data would be handled as same as 0th byte data, and all byte data would be as so repeatedly.
ja: まず、ベクターカラム内の各要素の0バイト目だけのデータを集めて連続で配置します。その後、同様に1バイト目のデータだけを集めて連続で配置するということをすべてのバイトに対して繰り返します。

en: There are tendency for those compression algorithms such as  ``COMPRESS_ZLIB``,``COMPRESS_LZ4``,and  ``COMPRESS_ZSTD`` to have the higher compression rate when the data has same values in continuance. The point for this flag is to produce data having same values in continuance by reorganizing data for every N byte.
ja: ``COMPRESS_ZLIB`` や ``COMPRESS_LZ4`` や ``COMPRESS_ZSTD`` といった圧縮アルゴリズムは同じ値が連続しているデータだと圧縮率が高くなる傾向があります。

en: In particular, it would work as below.
ja: 具体的には、以下のように動作します。

en: For example, there is the vector column ``[1, 1051, 515]`` in ``UInt16``. It would be as below representing in the little endien byte column.
ja: 例えば、 ``UInt16`` のベクターカラム ``[1, 1051, 515]`` があるとします。 これをリトルエンディアンのバイト列で表現すると以下のようになります。

en: This flag is to produce the data as following by gathering values of `` Byte 0``, then of `` Byte 1`` from the above data. The action to gather values with every N Byte would be called shuffle from now on. Shuffling the above data would be as below.
ja: このフラグは、上記の ``Byte 0`` の値をまとめ、その後 ``Byte 1`` のデータをまとめて、以下のようなデータを作るフラグです。この、Nバイト毎にまとめる操作を以後、シャッフルと呼びます。上記のデータをシャッフルすると以下のようになります。

en: The point is whether there would be same values in continuance or not. Looking at the above example data, it is appeared to have no same values in continuance after shuffling. Those data are not suitable for this flag because it is not contributed to increase the compression rate even shuffling.
ja: ポイントは「同じ値が連続する箇所があるかどうか？」です。 上記の例を見てみると、シャッフル後のデータは同じ値が連続している箇所がありません。このようなデータでは、シャッフルしても圧縮率の向上に寄与しないため、このフラグを適用するには不向きなデータです。

en: On the other hand, the vector column ``[1, 2, 3]``  in ``UInt16`` would be as following after  shuffling. First for the explanation, ``[1, 2, 3]`` in ``UInt16`` would be represented as below in the little endien byte column.
ja: 一方で、 ``UInt16`` のベクターカラム ``[1, 2, 3]`` というデータでは、シャッフルすると以下のようになります。まず、説明のため ``UInt16`` の ``[1, 2, 3]`` を以下のようなリトルエンディアンのバイト列表現にします。

en: And, after shuffling ``[1, 2, 3]``  in ``UInt16``, the data would be as below.
ja: そして、 ``UInt16`` の ``[1, 2, 3]`` をシャッフルすると以下のようなデータになります。

en: After shuffling ``[1, 2, 3]`` in ``UInt16``, the date in ``Byte 1`` would be all ``0x00``. It means there are same values in continuance. Thus, this data pattern is suitable for this flag because it would contribute to increase the compression rate.
ja: ``UInt16`` の ``[1, 2, 3]`` というデータだと、シャッフル後に ``Byte 1`` のデータがすべて ``0x00`` になり、同じ値が連続することになります。したがって、このようなデータは圧縮率の向上に寄与するので、このフラグを適用するのに向いているデータです。

en: In case of a floating-point number, the data having same the code part and the exponent part would be corresponded. In case of the IEEE 754 type single-precision floating-point format, code part would be placed at 31st bit, and exponent part would be placed at 32nd bit. There would be same values in continuance after shuffling the data if the code part and the upper 7 bit of exponent bit become same because the highest byte would be structured with the code part and the upper 7 bit of exponent bit.
ja: 浮動小数点数であれば、符号と指数部が同じデータが該当します。IEEE 754 形式の単精度浮動小数点数の場合、符号は31ビット目に配置され、指数部は30ビット目から23ビット目に配置されます。符号ビットと指数部の上位7ビットで最上位のバイトが構成されるので符号ビットと指数部の上位7ビットが同じになれば、シャッフル後は同じ値が連続することになるからです。

en: For example, the data, ``[0.5, 0.6]`` in ``Float32``, would have same code bit and exponent part by representing in Single-precision floating-point format in IEEE 754 type as below.
ja: 例えば、 ``Float32`` の ``[0.5, 0.6]`` というデータは、IEEE 754 形式の単精度浮動小数点数で表現すると以下のように符号ビットと指数部が同一です。

en: Shuffling the given data would have same values in continuance for ``Byte 3`` as below.
ja: これを、シャッフルすると以下のようになり、 ``Byte 3`` に同じ値が連続することになります。

en: In case of the ``Float`` / ``Float32`` type data, please refer to explanations for ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` and ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTES`` since it is also possible to combine ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` or ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTES`` .
ja: ``Float`` / ``Float32`` 型のデータの場合は、 ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` または ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTES`` を組み合わせて使うこともできるので、 ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` と ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTES`` の説明も合わせて参照してください。

en: Here is what kind of the data being effective for this flag.
ja: では、このフラグがどのようなデータに対して有効かを記載します。

en: This flag is to calculate the difference between bytes of values to be compression targeted. As sample case of the vector column ``[1, 2, 3, 4, 5]`` in ``UInt8``, applying this flag would produce data would become ``[1, (2-1), (3-2), (4-3), (5-4)] = [1, 1, 1, 1, 1]``.
ja: このフラグは、圧縮対象の値のバイト間の差分を計算するフラグです。例えば ``UInt8`` のベクターカラム ``[1, 2, 3, 4, 5]`` というデータの場合、このフラグを適用すると ``[1, (2-1), (3-2), (4-3), (5-4)] = [1, 1, 1, 1, 1]`` というデータになります。

en: As noted above, it is trying to increase the compression rate by calculating increments and producing same values in continuance. The point is there would be same values in continuance after calculating the increments between each elements.
ja: 上記のように差分データを計算することで、同じ値が連続するデータを作り圧縮率を向上させることを狙っています。ポイントは、各要素間の差分を計算することで、同じ値が連続するデータを作り出すことにあります。

en: Thus, the data is not suitable to use for this flag if there would not be same values in continuance after  calculating the increments. Here is the list of data pattern to have same values in continuance after calculating increments.
ja: したがって、差分を計算しても同じ値が連続するデータを作り出すことができないデータは、このフラグを適用するには不向きなデータです。どのようなデータであれば、差分を計算して同じ値が連続するようになるのかを以下に記載します。

en: First pattern would be the data increased with constant interval such as ``[1, 2, 3, 4, 5]`` in ``UInt8``. The constant interval could be every ``10`` for ``[1, 11, 21, 31, 41]`` in ``UInt8`` as long as the interval is same.
ja: まずは、前述の例でもあげた、 ``UInt8`` の ``[1, 2, 3, 4, 5]`` というような一定のペースで値が増加していくデータです。一定のペースなので、 ``UInt8`` の ``[1, 11, 21, 31, 41]`` のように ``10`` ずつ値が増加するようなデータでも良いです。

en: Next pattern would be the data having same values in continuance such as ``[5, 5, 5, 5, 5]`` in ``UInt8``. There would be ``0`` in continuance after calculating the increments of this data. In opossite, ``[1, 255, 2, 200, 1]`` in ``UInt8`` is not suitable for this flag because the data would not have same value in continuance after calculating the increments.
ja: 次に、 ``UInt8`` の ``[5, 5, 5, 5, 5]`` のように同じ値が連続するデータです。このデータは差分を計算すると ``[5, 0, 0, 0, 0]`` となり、 ``0`` が連続するようになります。逆に、 ``UInt8`` の ``[1, 255, 2, 200, 1]`` のように差分を計算しても同じ値が連続しないデータは、このフラグには不向きなデータです。

en: There would be a case to be able to increase the compression rate by combining  ``COMPRESS_FILTER_SHUFFLE`` even though calculating increments would not have same value in continuance, or increments are too large.
ja: ただ、差分を計算しても同じ値が連続しなかったり、差分自体が大きい値になる場合でも、 ``COMPRESS_FILTER_SHUFFLE`` を合わせて使うことで圧縮率を向上させられるケースもあります。

en: For exapmle, ``[4526677, 4592401, 4658217, 4723879]`` in  ``UInt32`` would be ``[4526677, 65724, 65816, 65662]``  after only being applied ``COMPRESS_FILTER_BYTE_DELTA`` . This data would not have values in continuance, and increments are large.
ja: 例えば、 ``UInt32`` の ``[4526677, 4592401, 4658217, 4723879]`` では、単に ``COMPRESS_FILTER_BYTE_DELTA`` を適用しただけでは、 ``[4526677, 65724, 65816, 65662]`` になります。このデータでは同じ値は連続しませんし、差分自体も大きい値です。

en: But applying ``COMPRESS_FILTER_SHUFFLE``  to this data would be different. And it will be explained in following. First for the explanation, ``[4526677, 4592401, 4658217, 4723879]`` in ``UInt32`` would be represent the byte column in the little endien as below.
ja: しかし、このデータに ``COMPRESS_FILTER_SHUFFLE`` を適用すると以下のようになります。説明のため、まず以下のように ``UInt32`` の ``[4526677, 4592401, 4658217, 4723879]`` をリトルエンディアンのバイト列で表現します。

en: Applying ``COMPRESS_FILTER_SHUFFLE``  to this data would be following byte columns.
ja: このデータに対して、 ``COMPRESS_FILTER_SHUFFLE`` を適用すると以下のようなバイト列になります。

en: Pay attention to the data of ``Byte 1``, ``Byte 2``, and ``Byte 3`` after the shuffling. The data increments of ``Byte 1`` are ``[0x12, 0x01, 0x01, 0x00]`` . The data increments of ``Byte 2`` are  ``[0x45, 0x01, 0x01, 0x01]`` . The data increments of ``Byte 3`` are ``[0x00, 0x00, 0x00, 0x00]``. From those numbers, you can see the data increments have small values and have same values in continuance.
ja: シャッフル後の ``Byte1`` のデータと ``Byte2`` 、 ``Byte 3`` のデータに注目してください。 ``Byte 1`` のデータの差分は ``[0x12, 0x01, 0x01, 0x00]`` , ``Byte 2`` のデータの差分は ``[0x45, 0x01, 0x01, 0x01]`` , ``Byte 3`` のデータの差分は ``[0x00, 0x00, 0x00, 0x00]`` となり、差分の値が小さく、また同じ値が連続するようになります。

en: As you see these, the compression rate could be increase by combining ``COMPRESS_FILTER_SHUFFLE`` even if applying ``COMPRESS_FILTER_BYTE_DELTA`` did not change the rate.
ja: このように、 ``COMPRESS_FILTER_BYTE_DELTA`` を適用しただけでは圧縮率の向上が見込めないデータでも、 ``COMPRESS_FILTER_SHUFFLE`` と合わせて使うことで圧縮率の向上を見込めるケースがあります。

en: Please note that  ``COMPRESS_FILTER_SHUFFLE`` would not be effective for the 1 byte data because it is to gather the same byte from the data. (The 1 byte data would have same data column whether being shuffled or not.) Thus, in case of combining ``COMPRESS_FILTER_BYTE_DELTA`` and ``COMPRESS_FILTER_SHUFFLE``, please do not use data in ``Int8`` / ``UInt8``. Only use for other type.
ja: ただし、 ``COMPRESS_FILTER_SHUFFLE`` は同じバイトのデータを集めるフィルターなので、1バイトのデータに対して適用しても意味がありません。（1バイトのデータの場合は、シャッフルしてもしなくても同じデータ列になるためです。）したがって、 ``COMPRESS_FILTER_BYTE_DELTA`` と ``COMPRESS_FILTER_SHUFFLE`` を合わせて使う場合は、 ``Int8`` / ``UInt8`` 以外のデータに対して使用してください。

en: This flag can be used only for ``Float`` / ``Float32``. And it is expected to be combined with  ``COMPRESS_FILTER_SHUFFLE`` .
ja: このフラグは、 ``Float`` / ``Float32`` でのみ使用できます。また、 ``COMPRESS_FILTER_SHUFFLE`` と組み合わせて使うことを想定しています。

en: This flag would drop the 1 byte of fraction from each vector column elements of ``Float`` / ``Float32`` type. Dropping the fraction means making all of the lower 1 byte of the floating-point number ``0``.
ja: このフラグは、 ``Float`` / ``Float32`` 型のベクターカラムの各要素の精度を1バイト落とします。精度を落とすとは、浮動小数点数の最下位バイトをすべて0にすることです。

en: For example, ``[1.25, 3.67, 4.55]`` in ``Float32`` would be presented as following in the IEEE 754 format single-precision floating-point.
ja: 例えば、 ``Float32`` の ``[1.25, 3.67, 4.55]`` というデータは、IEEE 754 形式の単精度浮動小数点数で表現すると以下のように表現できます。

en: Applying this flag make all lower 1 byte ``0``. And the data would be as below. Pay attention to all ``0`` for lower 1byte of fixed-point part.
ja: このフラグを適用すると、最下位バイトをすべて0にするので以下のようなデータになります。仮数部の最下位バイトが0になっていることに注目してください。

en: These actions are what would be done for single flag usage. As noted, this flag is expected to be combined with ``COLUMN_FILTER_SHUFFLE`` . Thus, by shuffling the data it is to expected increasing the compression rate after using the flag.
ja: ここまでが、このフラグ単独で使用した時に実行される操作です。前述の通り、このフラグは ``COLUMN_FILTER_SHUFFLE`` と組み合わせて使うことを想定しています。そのため、ここから更にデータをシャッフルすることで、圧縮率の向上を期待しています。

en: Applying ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` then shuffling would produce data as below.
ja: ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` を適用したデータをシャッフルすると以下のようなデータになります。

en: Pay attention to the ``Byte 0``. You can find the value ``0`` in continuance for ``Byte 0``. If ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` was not applied and shuffled, the data would be as following table, there would be no same value in continuance for any bytes.
ja: ``Byte 0`` に注目してください。 ``Byte 0`` は ``0`` が連続するデータになります。``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` を適用せずにシャッフルすると以下のようなデータになり、どのバイトも同じ値は連続していません。

en: Applying ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` to those data can be expected to increase the compression rate even if those data cannot increase the compression rate only with shuffling. However, note the data may be inaccurate since the fraction of the floating-point number is dropped for 1 byte.
ja: このように単純にシャッフルしただけでは、圧縮率の向上が見込めないデータでも ``COMPRESS_FILTER_TRUNCATE_PRECISION_1BYTE`` を適用することで、圧縮率の向上が見込める場合があります。ただし、圧縮対象の浮動小数点数の精度が1バイト分落ちるので、その分不正確なデータになることに注意してください。

en: This flag can be used only for ``Float`` / ``Float32``. And it is expected to be combined with  ``COMPRESS_FILTER_SHUFFLE``.
ja: このフラグは、 ``Float`` / ``Float32`` でのみ使用できます。また、 ``COMPRESS_FILTER_SHUFFLE`` と組み合わせて使うことを想定しています。

en: This flag would drop the 2 bytes of fraction from each vector column elements of ``Float`` / ``Float32`` type. Dropping the fraction means making all of the lower 2 bytes of the floating-point number ``0``.
ja: このフラグは、 ``Float`` / ``Float32`` 型のベクターカラムの各要素の精度を2バイト落とします。精度を落とすとは、浮動小数点数の下位2バイトをすべて ``0`` にすることです。

en: Applying this flag make all lower 2 bytes ``0``. And the data would be as below. Pay attention to all ``0`` for lower 2 bytes of fixed-point part.
ja: このフラグを適用すると、下位2バイトをすべて ``0`` にするので以下のようなデータになります。仮数部の下位2バイトがすべて ``0`` になっていることに注目してください。

en: Applying ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTE`` then shuffling would produce data as below.
ja: ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTE`` を適用したデータをシャッフルすると以下のようなデータになります。

en: Pay attention to the ``Byte 0`` and ``Byte 1``. You can find the value ``0`` in continuance for ``Byte 0`` and ``Byte1``.
ja: ``Byte 0`` と ``Byte 1`` に注目してください。 ``Byte 0`` と ``Byte 1`` は ``0`` が連続するデータになります。

en: If ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTE`` was not applied and shuffled, the data would be as following table, there would be no same value in continuance for any bytes.
ja: ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTE`` を適用せずにシャッフルすると以下のようなデータになり、どのバイトも同じ値は連続していません。

en: Applying ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTE`` to those data can be expected to increase the compression rate even if those data cannot increase the compression rate only with shuffling.
ja: このように単純にシャッフルしただけでは、圧縮率の向上が見込めないデータでも ``COMPRESS_FILTER_TRUNCATE_PRECISION_2BYTE`` を適用することで、圧縮率の向上が見込める場合があります。

en: However, note the data may be inaccurate since the fraction of the floating-point number is dropped for 2 bytes.
ja: ただし、圧縮対象の浮動小数点数の精度が2バイト分落ちるので、その分不正確なデータになることに注意してください。

en: It enables section support to index column.
ja: インデックスカラムのセクションサポートを有効にします。

en: If section support is enabled, you can support multiple documents in the same index column.
ja: セクションサポートが有効になると、同じインデックスカラムで複数の文書をサポートできます。

en: You must specify this flag to create a multiple columns index column. See also :ref:`column-create-index-multiple-columns` for details.
ja: マルチカラムインデックスカラムを作成するときはこのフラグを指定しなければいけません。詳細は :ref:`column-create-index-multiple-columns` を見てください。

en: Section support requires additional spaces. If you don't need section support, you should not enable section support.
ja: セクションサポートを有効にするとインデックスカラムが使う領域が増えます。セクションサポートが必要ない場合は有効にしないでください。

en: This flag is available only for ``COLUMN_INDEX``.
ja: このフラグは ``COLUMN_INDEX`` でだけ有効です。

en: It enables weight support to vector column or index column.
ja: ベクターカラム・インデックスカラムの重みサポートを有効にします。

en: If weight support is enabled for vector column, you can add weight for each element. If weight support is enabled for index column, you can add weight for each posting. They are useful to compute suitable search score.
ja: ベクターカラムの重みサポートを有効にすると各要素に重みを追加できます。インデックスカラムの重みサポートを有効にすると各ポスティングに重みを追加できます。これらは検索スコアの調整に役立ちます。

en: You must specify this flag to use :ref:`select-adjuster`. See also :ref:`column-create-vector-weight` for details.
ja: :ref:`select-adjuster` を使う場合はこのフラグを指定します。詳細は :ref:`column-create-vector-weight` を見てください。

en: Weight support requires additional spaces. If you don't need weight support, you should not enable weight support.
ja: 重みをサポートすると使用する領域が増えます。重みが必要ない場合は有効にしないでください。

en: This flag is available only for ``COLUMN_VECTOR`` or ``COLUMN_INDEX``.
ja: ``COLUMN_VECTOR`` と ``COLUMN_INDEX`` でだけこのフラグは有効です。

en: You can use 32bit floating point instead of 32bit unsigned integer for weight value.
ja: 重みの値に32bit非負整数ではなく32bit浮動小数点を使います。

en: You also need to specify ``WITH_WEIGHT``.
ja: ``WITH_WEIGHT`` も指定する必要があります。

en: It enables position support to index column. It means that the index column is full inverted index. (Index column is implemented as inverted index.)
ja: インデックスカラムの位置情報サポートを有効にします。これはインデックスカラムを完全転置インデックスにするということです。（インデックスカラムは転置インデックスとして実装されています。）

en: If position support is enabled, you can add position in the document for each posting. It's required for phrase search. It means that index column for full text search must enable position support because most full text search uses phrase search.
ja: 位置情報サポートが有効だと各ポスティングにドキュメントでの出現位置を追加できます。この情報はフレーズ検索をするときに必要になります。全文検索用のインデックスは位置情報サポートを有効にしなければいけません。なぜなら、全文検索はフレーズ検索を使うからです。

en: You must specify this flag to create a full text search index column. See also :ref:`column-create-index-full-text-search` for details.
ja: 全文検索インデックスカラムを作成するときはこのフラグを指定してください。詳細は :ref:`column-create-index-full-text-search` を見てください。

en: Position support requires additional spaces. If you don't need position support, you should not enable position support.
ja: 位置情報をサポートすると使用する領域が増えます。位置情報サポートが必要ない場合は有効にしないでください。

en: It requires to create a small index column.
ja: 小さなインデックスを作成するときに指定します。

en: If index target data are small, small index column is enough. Small index column uses fewer memory than a normal index column or a medium index column. See also :ref:`column-create-index-small` for knowing what are "small data" and how to use this flag.
ja: インデックス対象のデータが小さいときは小さなインデックスカラムで十分です。小さなインデックスカラムは通常のインデックスカラム・中サイズのインデックスカラムよりも使用メモリーが少ないです。「小さいデータ」とはなにか、このフラグをどうやって使えばよいかは :ref:`column-create-index-small` を見てください。

en: It requires to create a medium index column.
ja: 中サイズのインデックスカラムを作成するときに指定します。

en: If index target data are medium, medium index column is enough. Medium index column uses fewer memory than a normal index column. See also :ref:`column-create-index-medium` for knowing what are "medium data" and how to use this flag.
ja: インデックス対象のデータが中サイズなら中サイズのインデックスカラムで十分です。中サイズのインデックスカラムは通常のインデックスカラムよりも使用メモリー量が少ないです。「中サイズのデータ」とはなにか、このフラグをどうやって使えばよいかは :ref:`column-create-index-medium` を見てください。

en: It requires to create a large index column.
ja: 大きなインデックスを作成するときに指定します。

en: If index target data are large, you need to use large index column. Large index column uses more memory than a normal index column but accepts more data than a normal index column. See also :ref:`column-create-index-large` for knowing what are "large data" and how to use this flag.
ja: インデックス対象のデータが大きいときは大きなインデックスカラムを使う必要があります。大きなインデックスカラムは通常のインデックスカラムよりもメモリーを使いますが、通常のインデックスカラムよりも多くのデータを扱えます。「大きなデータ」とはなにか、このフラグをどうやって使えばよいかは :ref:`column-create-index-large` を見てください。

en: You can't specify multiple ``MISSING_*`` flags. They are exclusive.
ja: 複数の ``MISSING_*`` フラグを指定することはできません。これらは排他です。

en: This is meaningful only for reference scalar and vector columns.
ja: これは参照スカラーカラムと参照ベクターカラムでのみ意味があります。

en: If this flag is specified and nonexistent key in the referred table is specified to the column's value, a new record is created in the referred table automatically.
ja: このフラグが指定されたカラムに、参照されているテーブルに存在しないキーを指定したら、参照されているテーブルに新しいレコードを自動的に作ります。

en: If you don't specify any ``MISSING_*`` flag, ``MISSING_ADD`` is used as the default.
ja: ``MISSING_*`` フラグを指定していない場合、デフォルトで ``MISSING_ADD`` が使われます。

en: See also :ref:`column-create-missing-mode`.
ja: :ref:`column-create-missing-mode` も参照してください。

en: If this flag is specified and nonexistent key in the referred table is specified to the column's value, the value is just ignored. If the column is a scalar column, ``GRN_ID_NIL`` (``0``) is stored because Groonga doesn't support the NULL value. If the column is a vector column, the element is just removed from the value. For example, ``["existent1", "nonexistent", "existent2"]`` is set to the vector column and ``"nonexistent"`` record doesn't exist in the referred table, ``["existent1", "existent2"]`` are set to the vector column.
ja: このフラグが指定されたカラムに、参照されているテーブルに存在しないキーを指定したら、その値は無視されます。もし、そのカラムがスカラーカラムなら ``GRN_ID_NIL`` （ ``0`` ）が格納されます。なぜならGroongaはNULL値をサポートしていないからです。もし、そのカラムがベクターカラムなら値からその要素は削除されます。たとえば、 ``["existent1", "nonexistent", "existent2"]`` がそのベクターカラムにセットされ、 ``"nonexistent"`` レコードが参照されているテーブルに存在しない場合、そのベクターカラムには ``["existent1", "existent2"]`` が設定されます。

en: If this flag is specified and nonexistent key in the referred table is specified to the column's value, the value is replaced with ``GRN_ID_NIL`` (``0``).
ja: このフラグが指定されたカラムに、参照されているテーブルに存在しないキーを指定したら、その値は ``GRN_ID_NIL`` （ ``0`` ）に置き換えられます。

en: You can't specify multiple ``INVALID_*`` flags. They are exclusive.
ja: 複数の ``INVALID_*`` フラグを指定することはできません。これらは排他です。

en: If this flag is specified and an invalid value is specified, an error is reported to :ref:`process-log`.
ja: このフラグを指定しているときに不正な値が指定されたら、 :ref:`process-log` にエラーログが記録されます。

en: For example, ``"STRING"`` for ``Int32`` column is an invalid value.
ja: たとえば、 ``Int32`` カラムの場合は ``"STRING"`` は不正な値です。

en: If the column is a scalar column, :doc:`load` also reports an error.
ja: カラムがスカラーカラムの場合は、 :doc:`load` もエラーを返します。

en: If the column is a vector column, :doc:`load` doesn't reports an error but invalid values in a vector value are removed or replaced with ``GRN_ID_NIL`` (``0``) depending on ``MISSING_*`` flag of the column.
ja: カラムがベクターカラムの場合、 :doc:`load` はエラーを返しませんが、ベクター内の不正な値は削除されるか ``GRN_ID_NIL`` （ ``0`` ）に置き換えられます。どっちになるかはこのカラムに指定された ``MISSING_*`` フラグに依ります。

en: This is an incompatible change at 12.0.2. :doc:`load` also reports an error for a vector column before 12.0.2.
ja: 12.0.2での非互換の変更です。12.0.2より前は :doc:`load` もエラーを返していました。

en: If you don't specify any ``INVALID_*`` flag, ``INVALID_ERROR`` is used as the default.
ja: ``INVALID_*`` フラグを指定しない場合はデフォルト値として ``INVALID_ERROR`` が使われます。

en: If this flag is specified and an invalid value is specified, a warning is reported to :ref:`process-log` but no error is reported.
ja: このフラグが指定されたカラムに不正な値が指定された場合は :ref:`process-log` に警告が記録されますがエラーは返りません。

en: If the column is a vector column, invalid values in a vector value are removed or replaced with ``GRN_ID_NIL`` (``0``) depending on ``MISSING_*`` flag of the column.
ja: このカラムがベクターカラムの場合は、不正な値が削除されるか ``GRN_ID_NIL`` （ ``0`` ）に置換されるかはこのカラムの ``MISSING_*`` フラグに依ります。

en: If this flag is specified and an invalid value is specified, it's just ignored.
ja: このフラグが指定されたカラムに不正な値が指定された場合、単に無視されます。

en: You must specify one of ``COLUMN_${TYPE}`` flags. You can't specify two or more ``COLUMN_${TYPE}`` flags. For example, ``COLUMN_SCALAR|COLUMN_VECTOR`` is invalid.
ja: ``COLUMN_${TYPE}`` フラグのどれかを必ず指定します。2つ以上の ``COLUMN_${TYPE}`` フラグを指定してはいけません。たとえば、 ``COLUMN_SCALAR|COLUMN_VECTOR`` は不正な指定です。

en: You can combine flags with ``|`` (vertical bar) such as ``COLUMN_INDEX|WITH_SECTION|WITH_POSITION``.
ja: ``WITH_SECTION|WITH_POSITION`` というように、 ``|`` （縦棒）で複数のフラグを組み合わせることができます。

en: Specifies type of the column value.
ja: カラムの値の型を指定します。

en: If the column is scalar column or vector column, here are available types:
ja: カラムがスカラーカラムかベクターカラムなら利用可能な型は次の通りです。

en: Builtin types described in :doc:`/reference/types`
ja: :doc:`/reference/types` で説明している組み込みの型

en: Tables defined by users
ja: ユーザーが定義したテーブル

en: If the column is index column, here are available types:
ja: カラムがインデックスカラムのときの利用可能な型は次の通りです。

en: See also the followings:
ja: 以下も見てください。

en: Optional parameters
ja: 省略可能引数

en: There is an optional parameter.
ja: 省略可能な引数があります。

en: Specifies index target columns. You can specify one or more columns to the ``source`` parameter.
ja: インデックス対象のカラムを指定します。 ``source`` パラメーターには1つ以上のカラムを指定できます。

en: This parameter is only available for index column.
ja: このパラメーターはインデックスカラムでだけ利用可能です。

en: You can only specify columns of the table specified as :ref:`column-create-type`. You can also use the ``_key`` pseudo column for specifying the table key as index target.
ja: :ref:`column-create-type` で指定したテーブルのカラムだけ指定できます。テーブルのキーをインデックス対象にしたい場合は ``_key`` 疑似カラムを指定します。

en: If you specify multiple columns to the ``source`` parameter, separate columns with ``,`` (comma) such as ``_key,roles``.
ja: ``source`` パラメーターに複数のカラムを指定するときは ``_key,roles`` というように ``,`` （コンマ）で区切ります。

en: Specifies a path for storing a column.
ja: カラムを格納するパスを指定します。

en: This option is useful if you want to store a column that you often use to fast storage (e.g. SSD) and store it that you don't often use to slow storage (e.g. HDD).
ja: このオプションは、高速なストレージ(SSDなど)によく使うカラムを格納し、低速なストレージ(HDDなど)にあまり使わないカラムを格納したいときに有用です。

en: You can use a relative path or an absolute path in this option. If you specify a relative path, it is resolved from the current directory for the ``groonga`` process.
ja: このオプションでは、絶対パスまたは相対パスを使えます。相対パスを指定した場合は、 ``groonga`` プロセスのカレントディレクトリーからパスを解決します。

en: The default value is none.
ja: デフォルト値はありません。

en: Return value
ja: 戻り値

en: ``column_create`` returns ``true`` as body on success such as::
ja: ``column_create`` が成功したときは以下のようにボディは ``true`` になります::

en: If ``column_create`` fails, ``column_create`` returns ``false`` as body::
ja: ``column_create`` が失敗したときはボディは ``false`` になります::

en: Error details are in ``HEADER``.
ja: ``HEADER`` にエラーの詳細が含まれます。

en: See :doc:`/reference/command/output_format` for ``HEADER``.
ja: ``HEADER`` については :doc:`/reference/command/output_format` を参照してください。

en: See also
ja: 参考

en: These flags are to increase compression rate of ``COMPRESS_ZLIB`` / ``COMPRESS_LZ4`` / ``COMPRESS_ZSTD`` to increase by filtering the data before the compression.
ja: このフラグは圧縮前にデータをフィルタリングすることで ``COMPRESS_ZLIB`` / ``COMPRESS_LZ4`` / ``COMPRESS_ZSTD`` の圧縮率を高めるためのフラグです。

en: However it could be effective or not depending on the data. It might decrease the compression rate.
ja: ただし、データによって効果があることもあれば効果がないこともあります。圧縮率が下がることもありえます。

en: Also, saving column and reference process are going to be slower because enabling these flags would require additional processing.
ja: また、このフラグを有効にすることで追加の処理が入るのでカラムの保存・参照処理は確実に遅くなります。

en: Regardless of setting ``COMPRESS_ZLIB`` , ``COMPRESS_LZ4`` , ``COMPRESS_ZSTD`` , these filters use `BloscLZ <https://www.blosc.org/pages/blosc-in-depth/#blosc-as-a-meta-compressor>`_ as the compression alogolizm, thus make the column size smaller than the noncompressed column in most cases.
ja: なお、 ``COMPRESS_ZLIB`` / ``COMPRESS_LZ4`` / ``COMPRESS_ZSTD`` を指定しない場合は `BloscLZ <https://www.blosc.org/pages/blosc-in-depth/#blosc-as-a-meta-compressor>`_ という圧縮アルゴリズムが使われるので、このフラグを有効にすることでほとんどの場合は未圧縮の場合よりもサイズが小さくなります。

en: Yet, there would be a case that some data would show sufficient work by only suetting ``COMPRESS_ZLIB`` , `COMPRESS_LZ4`` , ``COMPRESS_ZSTD`` . So it is advised to set suitable flags depending on the data.
ja: しかし、データによってはこのフラグを有効にせずに単に ``COMPRESS_ZLIB`` / ``COMPRESS_LZ4`` / ``COMPRESS_ZSTD`` を指定するだけで十分であることもあるため、実際のデータにあわせて適切にフラグを設定するようにしてください。

en: Note that ``COMPRESS_FILTER_SHUFFLE`` flag is ignored if Blosc support is invalid. Blosc support is valid in default in each packages. However, We need to valid Blosc support explicitly when we build Groonga from source. Please refer :doc:`/install/others` when we build Groonga from source.
ja: `COMPRESS_FILTER_SHUFFLE`` フラグはBloscサポートが有効になっていないと無視されることに注意してください。各種パッケージでは有効になっていますが、自分でビルドするときは明示的に有効にする必要があります。自分でビルドする場合は :doc:`/install/others` を参照してください。

en: These flags are only available with ``COLUMN_VECTOR`` and are ignored with ``COLUMN_SCALAR`` .
ja: このフラグは ``COLUMN_VECTOR`` でのみ使用できます。 ``COLUMN_SCALAR`` のときはこのフラグは無視されます。
