Explains how to create column families using either the Control System, the CLI, or the HBase shell.
There are several methods that you can use to create column families in HPE Ezmeral Data Fabric Database tables. To create column families, you must have the following permissions:
| Column Family Name | The name of the column family. |
| JSON Path | The path to the column family in dotted notation.
For example, suppose the table contained JSON
documents that were of this general structure:
If
you want to create a column family at the field
d nested within
b, your new path would be
a.b.d. Note: Ensure that the
field at which you want to create the column
family does not yet exist. If the field exists, it
could become inaccessible after the column family
is created.
|
| Compression | The compression setting to use for the column family. Valid options are off, lzf, lz4, and zlib. The default setting is the same as the compression setting for the directory where the table is located. To find out whether a directory is compressed and the type of compression, see Turning Compression On or Off on Directories Using the CLI. |
| Time-to-Live | Specifies whether to purge data when the age of the data
in this column family exceeds the value specified here. Data
can remain forever or can be purged after specified amount
of time (in seconds). Setting the value to 0 is equivalent
to allowing data to remain indefinitely or forever. Note: If
the value for an existing column family in a JSON table
is not 0, you cannot add another column family.
|
| In Memory | Determines whether preference is given to values of this
column family for storage with row keys. Because row keys
are cached in memory in preference to row data,
column-family data that is stored inline with the row keys
is also cached in memory. For all column families in a table together, up to 200 bytes of row data will be stored inline with each row key. Storing data inline with a row key might speed retrieval of the data from a column family because disk access can often be avoided. For each column family, up to 32 bytes can be stored inline with each row key even if this is disabled (No), but preference will be given to column families where this is enabled (Yes). A column family can have more than 32 bytes stored inline if this is enabled. If the total number of bytes for all column families together exceeds 200 for a row, then preference for inclusion within the inline storage for that row is given to column families that have this enabled. Note: All of the data for a column family
will be stored in-line with the row key, or none will
be. If the contents in a column family for a particular
row are larger than the maximum number of bytes that are
allowed to be stored for that column family, no data
will be stored in-line for that column family.
By
default, this is enabled. |
| Column Family Name | The name of the column family. |
| Version |
|
| Compression | The compression setting to use for the column family. Valid options are off, lzf, lz4, and zlib. The default setting is the same as the compression setting for the directory where the table is located. To find out whether a directory is compressed and the type of compression, see Turning Compression On or Off on Directories Using the CLI. |
| Time-to-Live | Specifies whether to purge data when the age of the data in this column family exceeds the value specified here. Data can remain forever or can be purged after specified amount of time (in seconds). Setting the value to 0 is equivalent to allowing data to remain indefinitely or forever. |
| In Memory | Determines whether preference is given to values of this
column family for storage with row keys. Because row keys
are cached in memory in preference to row data,
column-family data that is stored inline with the row keys
is also cached in memory. For all column families in a table together, up to 200 bytes of row data will be stored inline with each row key. Storing data inline with a row key might speed retrieval of the data from a column family because disk access can often be avoided. For each column family, up to 32 bytes can be stored inline with each row key even if this is disabled (No), but preference will be given to column families where this is enabled (Yes). A column family can have more than 32 bytes stored inline if this is enabled. If the total number of bytes for all column families together exceeds 200 for a row, then preference for inclusion within the inline storage for that row is given to column families that have this enabled. Note: All of the data for a column family
will be stored in-line with the row key, or none will
be. If the contents in a column family for a particular
row are larger than the maximum number of bytes that are
allowed to be stored for that column family, no data
will be stored in-line for that column family.
By
default, this is enabled. |
| Read Data | Can do column reads. Reads require permission both at the column-family level and at the field level. This permission is inherited by fields within the column family. |
| Write Data | Can do column writes. Writes require permission both at the column-family level and at the field level. This permission is inherited by fields within the column family. |
| Traverse Data | Can pass over fields in JSON documents. For
example, suppose that a JSON table contains
documents of this general
structure:Suppose
further that the user sjohnson has read permission
on a.b, but not on
a. For sjohnson to read
a.b, the user needs the traverse
permission on a. The user can
then pass over field a to
a.b. This permission is inherited
by fields within the column family. |
| Set Version | Can set or change the maximum and minimum number of versions of column values to keep. |
| Set Compression | Can set or change the compression setting for the column family. |
| Read Data | Can do column reads. Reads require permission both at the column-family level and at the field level. This permission is inherited by fields within the column family. |
| Write Data | Can do column writes. Writes require permission both at the column-family level and at the field level. This permission is inherited by fields within the column family. |
| Append Data | Can do column appends. Column appends require permission both at the column-family level and at the column level. |
| Set Version | Can set or change the maximum and minimum number of versions of column values to keep. |
| Set Compression | Can set or change the compression setting for the column family. |
to create a
copy of the associated access control setting. Click
to remove
the associated access control expression.p) or user (u),
group (g), and/or role (r) who have or do not have the
type of access using the following boolean expressions and subexpressions:! — Negation operator.& — AND operation.| — OR operation.(), parentheses, for subexpressions.Alternatively, click
associated
with the type of access to use the Access Control Expression
window to define access for public or users, group, and/or role. See Defining ACEs Using the Access Control Expression Builder for more information.
&) and negation
(!) operations that are supported by advanced settings are not supported in
the basic settings.| Read Data | Can read from the field. This permission extends to fields that are nested below as well unless explicitly denied on any of the nested fields. |
| Write Data | Can delete the field, insert a value into
the field, or overwrite the field's
value. Note: Deleting a field also deletes all
fields that are nested within that field, even
those fields on which the write permission is
explicitly denied.
|
| JSON Traverse | Can descend a hierarchy of fields to access the fields to read or write. |
| Read Data | Can do column reads. Reads require permission both at the column-family level and at the field level. This permission is inherited by fields within the column family. |
| Write Data | Can do column writes. Writes require permission both at the column-family level and at the field level. This permission is inherited by fields within the column family. |
| Append Data | Can do column appends. Column appends require permission both at the column-family level and at the column level. |
However, suppose that a table contains columns
col1 and col2 in column family
cf1, and these columns grant read and write
permission only to the table creator. A different user tries to
write data to these columns. HPE Ezmeral Data Fabric Database checks whether this user has
write permission on cf1 AND col1
AND col2. If the user does not have all three
permissions, HPE Ezmeral Data Fabric Database returns an error that says access for the write
is denied.
If this user were to try to read from the same two
columns, HPE Ezmeral Data Fabric Database would simply not return the data. If the user tried
to read from those two columns and additional columns on which the
user had read permissions, the results would contain the data for
those additional columns, but exclude the data for
col1 and col2.
to create a
copy of the associated access control setting. Click
to remove
the associated access control expression.p) or user (u),
group (g), and/or role (r) who have or do not have the
type of access using the following boolean expressions and subexpressions:! — Negation operator.& — AND operation.| — OR operation.(), parentheses, for subexpressions.Alternatively, click
associated
with the type of access to use the Access Control Expression
window to define access for public or users, group, and/or role. See Defining ACEs Using the Access Control Expression Builder for more information.
&) and negation
(!) operations that are supported by advanced settings are not supported in
the basic settings.-jsonpath and -force
:maprcli table cf create -path <path> -cfname <name_of_column_family> -jsonpath
<path> -force trueFor
the full list of options for this command, see table cf create.-jsonpath parameter specifies the path to the column family. The
path is in dotted notation. For example, suppose the table contained JSON
documents that were of this general structure:
{
"_id" : "ID",
"a" :
{
"b" :
{
"c" : "value",
},
"e" : "value"
}
}You want to create a column family at the field d
in the new path a.b.d because you plan to store image
files in fields in that column family. By default, every time you try to create a non-default column family in a JSON table,
this command fails and returns a warning message that you should ensure there is no
existing data at the specified path. Set the -force parameter to
true if you want to override this warning mechanism and create a column
family.
maprcli table cf create -path <path> -cfname <name_of_column_family>For
the full list of options for this command, see table cf create.The format of the value of the -path parameter depends on whether you are
creating a table on a local cluster or a remote cluster.
After starting the HBase shell, run the alter command. Type
help to see a list of commands and their syntax.