Containers are objects that hold other objects. In Skytable, we have two kinds of containers:
- Keyspaces: Keyspaces are containers that hold tables. The basic idea is to keep all the related tables for a given application in one logical collection.
- Tables: Tables are not tables. Funny, isn't it? Instead, tables are structures that contain the actual data. Be it key/value or the future data models — it's all in a table
To interact with containers, we need to use DDL actions like
Every container is an entity. A keyspace being a top-level entity and a table being a low-level entity. Hence a keyspace name or a table name can be called an entity or entity name.
All entity names have the following naming rules:
- Names are case sensitive
- Names must begin with an ASCII alphabet (A-Z or a-z) or an underscore (
- Names must be lesser than or equal to 64 characters long
- Names must not begin with a digit (0-9)
- Names can contain digits anywhere else (except for the first character)
The most important thing is an Entity Group which is also known as Fully Qualified
Entity Syntax (FQE Syntax). FQE syntax is used to describe the full path to a table. For example,
if you have a keyspace
supercyan and you have a table
cyan within it, then the FQE syntax will
This can be extremely helpful when running DDL queries.
When you connect to Skytable, you are connected to the
default keyspace which has a
default table or the
default keyspace cannot be dropped.
There is another keyspace called the
system keyspace which is not user-accessible and hence
cannot be modified or dropped.
Like we noted above, keyspaces are logical collections of tables and is known as a top level container. Creating a keyspace is as simple as:
CREATE KEYSPACE <name>
while you can drop keyspaces by running:
DROP KEYSPACE <name>
Note: Keyspaces can only be dropped if no other client is connected to it and if it contains no tables. This can be evaded by forcing removal through other DDL actions.
Tables contain your actual data: be it key/value, or anything else. Tables reside within keyspaces. To create a table, you'll need to run:
CREATE TABLE <entity> <model>(modelargs) <properties>
A table, apart from the data model's own properties, has some model-indpendent properties. Supplying these are optional.
The user-accessible property that you should know about is the
volatile property after your model arguments makes your table volatile. This means that the table itself will exist, but none of its data will persist after a restart. This makes volatile tables extremely useful for caching.
Don't worry too much about the model and modelargs now — the next section will tell you about models.
Just jump to the models section
A model defines what kind of data is stored in a table. You can think of it to be a type in a programming language.
A keymap model is the one you just interacted with in the earlier documents. A keymap is like an associated array: it maps a key to a value. More importantly, it maps a specific key type to a specific value type.
Warning: Everything after
CREATE TABLEis case sensitive!
This is how you create keymap tables:
CREATE TABLE <entity> keymap(<type>,<type>) <properties>
<entity>: is your table name (or the FQE syntax for your table)
<type>: is the data type
<properties>: are the optional properties discussed earlier
The keymap model supports the following types:
str: A valid unicode string
binstr: A binary string
(more types are expected to be shipped in future editions)
Let's create a keymap table with a
str type key and
binstr type value. We'll assume you'll
be creating it in the default keyspace with the name "mytbl", so there's no need to specify an FQE.
CREATE TABLE mytbl keymap(str,binstr)
With our goal to build a native multi-model database — we're working on several data models! All you need to do is hang around in our communities to know what is brewing!
Check out the DDL examples here