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

Real-time mode requires no index 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 index schema and drop it. This mode is especially useful for real-time and percolate indexes.

Index names are case insensitive in RT mode.

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

Dropping indexes 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.

Index names are case sensitive in this mode.

All index types are supported in this mode.

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

POST /sql -d "mode=raw&query=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('mode=raw&query=CREATE TABLE forum(title text, price float)')

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

utilsApi.sql("mode=raw&query=CREATE TABLE forum(title text, price float)");

index products {
  type = rt
  path = idx
  rt_field = title
  rt_attr_uint = price
  stored_fields = title
}

Query OK, 0 rows affected (0.00 sec)

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

• Add documents
• Update attributes and full-text fields
• Delete documents
• Truncate index
• Change schema online with help of command ALTER
• Define index in a configuration file
• Use UUID for automatic ID provisioning

• Index data with help of indexer
• Link it with sources for easy indexing from external storages
• Update it's killlist_target, it's just not needed as the real-time index takes controls of it automatically

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
 }

index idx {
  type   = plain
  source = source
  path   = /path/to/index
 }

Speed of plain indexing depends on several factors:

• how fast the source can be providing the data
• tokenization settings
• your hardware (CPU, amount of RAM, disk performance)

In the simplest usage scenario, we would use a single plain index which we just fully rebuild from time to time. It works fine for smaller data sets and if you are ready that:

• the index will be not as fresh as data in the source
• indexing duration grows with the data, the more data you have in the source the longer it will take to build the index

If you have a bigger data set and still want to use a plain index rather than Real-Time what you can do is:

• make another smaller index for incremental indexing
• combine the both using a distributed index

What it can give is you can rebuild the bigger index seldom (say once per week), save the position of the freshest indexed document and after that use the smaller index to index anything new or updated from your source. Since you will only need to fetch the updates from your storage you can do it much more frequently (say once per minute or even each few seconds).

But after a while the smaller indexing duration will become too high and that will be the moment when you need to rebuild the bigger index and empty the smaller one.

This is called main+delta schema and you can learn more about it in this interactive course.

When you build a smaller "delta" index it can get documents that are already in the "main" index. To let Manticore know that documents from the current index should take precedence there's a mechanism called kill list and corresponding directive killlist_target.

More information on this topic can be found here.