There are 2 different approaches to deal with tables in Manticore:

Real-time mode requires no table definition in the configuration file, but presence of data_dir directive in searchd section is mandatory. Index files are stored inside the data_dir.

Replication is available only in this mode.

In this mode you can use SQL commands like CREATE TABLE, ALTER TABLE and DROP TABLE to create and change table schema and drop it. This mode is especially useful for real-time and percolate tables.

Table names are case insensitive in the RT mode.

In this mode you can specify table schema in config which will be read on Manticore start and if the table doesn't exist yet it will be created. This mode is especially useful for plain tables that are built upon indexing data from an external storage.

Dropping tables is only possible by removing them from the configuration file or by removing the path setting and sending a HUP signal to the server or restarting it.

Table names are case sensitive in this mode.

All table types are supported in this mode.

CREATE TABLE products(title text, price float) morphology='stem_en';

POST /cli -d "CREATE TABLE products(title text, price float)  morphology='stem_en'"

$index = new \Manticoresearch\Index($client);
$index->setName('products');
$index->create([
    'title'=>['type'=>'text'],
    'price'=>['type'=>'float'],
]);

utilsApi.sql('CREATE TABLE forum(title text, price float)')

res = await utilsApi.sql('CREATE TABLE forum(title text, price float)');

utilsApi.sql("CREATE TABLE forum(title text, price float)");

table products {
  type = rt
  path = tbl
  rt_field = title
  rt_attr_uint = price
  stored_fields = title
}

Query OK, 0 rows affected (0.00 sec)

{
"total":0,
"error":"",
"warning":""
}

• Add documents using the Add feature.
• Update attributes and full-text fields through the Update process.
• Delete documents using the Delete feature.
• Emptying the table using the Truncate process.
• Change the schema online using the ALTER command as described in Change schema online.
• Define the table in a configuration file as described in Define table.
• Use the UUID feature for automatic ID provisioning.

• Index data using the indexer feature.
• Connect it to sources for easy indexing from external storage.
• Update the killlist_target, as it is automatically managed by the real-time table.

The following table outlines the different file extensions and their respective descriptions in a real-time table:

For more information on the structure of disk chunks, refer to the plain table format)

source source {
  type             = mysql
  sql_host         = localhost
  sql_user         = myuser
  sql_pass         = mypass
  sql_db           = mydb
  sql_query        = SELECT id, title, description, category_id  from mytable
  sql_attr_uint    = category_id
  sql_field_string = title
 }

table tbl {
  type   = plain
  source = source
  path   = /path/to/table
 }

The speed at which a plain table is indexed depends on several factors, including:

• Data source retrieval speed
• tokenization settings
• The hardware specifications (such as CPU, RAM, and disk performance)

For small data sets, the simplest option is to have a single plain table that is fully rebuilt as needed. This approach is acceptable when:

• The data in the table is not as fresh as the data in the source
• The time it takes to build the table increases as the data set grows

For larger data sets, a plain table can be used instead of a Real-Time. The main+delta scenario involves:

• Creating a smaller table for incremental indexing
• Combining the two tables using a distributed table

This approach allows for infrequent rebuilding of the larger table and more frequent processing of updates from the source. The smaller table can be rebuilt more often (e.g. every minute or even every few seconds).

However, as time goes on, the indexing duration for the smaller table will become too long, requiring a rebuild of the larger table and the emptying of the smaller one.

The main+delta schema is explained in detail in this interactive course.

The mechanism of kill list and killlist_target directive is used to ensure that documents from the current table take precedence over those from the other table.

For more information on this topic, see here.

The following table outlines the various file extensions used in a plain table and their respective descriptions: | Extension | Description | | - | - | |.spa | stores document attributes in row-wise mode | |.spb | stores blob attributes in row-wise mode: strings, MVA, json | |.spc | stores document attributes in columnar mode | |.spd | stores matching document ID lists for each word ID | |.sph | stores table header information | |.sphi | stores histograms of attribute values | |.spi | stores word lists (word IDs and pointers to .spd file) | |.spidx | stores secondary indexes data | |.spk | stores kill-lists | |.spl | lock file | |.spm | stores a bitmap of killed documents | |.spp | stores hit (aka posting, aka word occurrence) lists for each word ID | |.spt | stores additional data structures to speed up lookups by document ids | |.spe | stores skip-lists to speed up doc-list filtering | |.spds | stores document texts | |.tmp* |temporary files during index_settings_and_status | |.new.sp* | new version of a plain table before rotation | |.old.sp* | old version of a plain table after rotation |