REPLACE vs UPDATE

You can modify existing data in an RT or PQ table by either updating or replacing it.

UPDATE replaces row-wise attribute values of existing documents with new values. Full-text fields and columnar attributes cannot be updated. If you need to change the content of a full-text field or columnar attributes, use REPLACE.

REPLACE works similarly to INSERT except that if an old document has the same ID as the new document, the old document is marked as deleted before the new document is inserted. Note that the old document does not get physically deleted from the table. The deletion can only happen when chunks are merged in a table, e.g., as a result of an OPTIMIZE.

UPDATE vs partial REPLACE

Both UPDATE and a partial REPLACE can change the value of a field, but they operate differently:

  • UPDATE can only change fields that are neither columnar nor full-text. This process is done in-place, which is typically faster than REPLACE.
  • A partial REPLACE can change any field in a document, but it requires that all fields in the table be set to "stored" (though this is the default setting). This is not necessary with UPDATE.

REPLACE

REPLACE works similarly to INSERT, but it marks the previous document with the same ID as deleted before inserting a new one.

If you are looking for in-place updates, please see this section.

SQL REPLACE

The syntax of the SQL REPLACE statement is as follows:

To replace the whole document:

REPLACE INTO table [(column1, column2, ...)]
    VALUES (value1, value2, ...)
    [, (...)]

To replace only selected fields:

REPLACE INTO table
    SET field1=value1[, ..., fieldN=valueN]
    WHERE id = <id>

Note, you can filter only by id in this mode.

NOTE: Partial replace requires Manticore Buddy. If it doesn't work, make sure Buddy is installed.

Read more about UPDATE vs. partial REPLACE here.

See the examples for more details.

JSON REPLACE

  • /replace:

    POST /replace
{
  "index": "<table name>",
  "id": <document id>,
  "doc":
  {
    "<field1>": <value1>,
    ...
    "<fieldN>": <valueN>
  }
}

    /index is an alias endpoint and works the same.

  • Elasticsearch-like endpoint <table>/_doc/<id>:

    PUT/POST /<table name>/_doc/<id>
{
  "<field1>": <value1>,
  ...
  "<fieldN>": <valueN>
}

    NOTE: Elasticsearch-like replace requires Manticore Buddy. If it doesn't work, make sure Buddy is installed.

  • Partial replace:

    POST /<table name>/_update/<id>
{
"<field1>": <value1>,
...
"<fieldN>": <valueN>
}

    NOTE: Partial replace requires Manticore Buddy. If it doesn't work, make sure Buddy is installed.

See the examples for more details.

‹›
  • SQL
  • REPLACE SET
  • JSON
  • Elasticsearch-like
  • Elasticsearch-like partial
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
REPLACE INTO products VALUES(1, "document one", 10);
‹›
Response
Query OK, 1 row affected (0.00 sec)

REPLACE is available for real-time and percolate tables. You can't replace data in a plain table.

When you run a REPLACE, the previous document is not removed, but it's marked as deleted, so the table size grows until chunk merging happens. To force a chunk merge, use the OPTIMIZE statement.

Bulk replace

You can replace multiple documents at once. Check bulk adding documents for more information.

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
REPLACE INTO products(id,title,tag) VALUES (1, 'doc one', 10), (2,' doc two', 20);
‹›
Response
Query OK, 2 rows affected (0.00 sec)

UPDATE

The UPDATE command changes row-wise attribute values of existing documents in a specified table with new values. Note that you can't update the contents of a fulltext field or a columnar attribute. If there's such a need, use REPLACE.

Attribute updates are supported for RT, PQ, and plain tables. All attribute types can be updated as long as they are stored in the row-wise storage.

Note that the document ID cannot be updated.

It's important to be aware that updating an attribute disables its secondary index. If maintaining secondary index continuity is critical, consider fully or partially replacing the document instead.

Read more about UPDATE vs. partial REPLACE here.

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
UPDATE products SET enabled=0 WHERE id=10;
‹›
Response
Query OK, 1 row affected (0.00 sec)

Multiple attributes can be updated in a single statement. Example:

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
UPDATE products
SET price=100000000000,
    coeff=3465.23,
    tags1=(3,6,4),
    tags2=()
WHERE MATCH('phone') AND enabled=1;
‹›
Response
Query OK, 148 rows affected (0.0 sec)

When assigning out-of-range values to 32-bit attributes, they will be trimmed to their lower 32 bits without a prompt. For example, if you try to update the 32-bit unsigned int with a value of 4294967297, the value of 1 will actually be stored, because the lower 32 bits of 4294967297 (0x100000001 in hex) amount to 1 (0x00000001 in hex).

UPDATE can be used to perform partial JSON updates on numeric data types or arrays of numeric data types. Just make sure you don't update an integer value with a float value as it will be rounded off.

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
insert into products (id, title, meta) values (1,'title','{"tags":[1,2,3]}');

update products set meta.tags[0]=100 where id=1;
‹›
Response
Query OK, 1 row affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

Updating other data types or changing property type in a JSON attribute requires a full JSON update.

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
insert into products values (1,'title','{"tags":[1,2,3]}');

update products set data='{"tags":["one","two","three"]}' where id=1;
‹›
Response
Query OK, 1 row affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

When using replication, the table name should be prepended with cluster_name: (in SQL) so that updates will be propagated to all nodes in the cluster. For queries via HTTP, you should set a cluster property. See setting up replication for more information.

{
  "cluster":"nodes4",
  "index":"test",
  "id":1,
  "doc":
  {
    "gid" : 100,
    "price" : 1000
  }
}
‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
update weekly:posts set enabled=0 where id=1;

Updates via SQL

Here is the syntax for the SQL UPDATE statement:

UPDATE table SET col1 = newval1 [, ...] WHERE where_condition [OPTION opt_name = opt_value [, ...]] [FORCE|IGNORE INDEX(id)]

where_condition has the same syntax as in the SELECT statement.

Multi-value attribute value sets must be specified as comma-separated lists in parentheses. To remove all values from a multi-value attribute, just assign () to it.

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
UPDATE products SET tags1=(3,6,4) WHERE id=1;

UPDATE products SET tags1=() WHERE id=1;
‹›
Response
Query OK, 1 row affected (0.00 sec)

Query OK, 1 row affected (0.00 sec)

OPTION clause is a Manticore-specific extension that lets you control a number of per-update options. The syntax is:

OPTION <optionname>=<value> [ , ... ]

The options are the same as for the SELECT statement. Specifically for the UPDATE statement, you can use these options:

  • 'ignore_nonexistent_columns' - If set to 1, it indicates that the update will silently ignore any warnings about trying to update a column which does not exist in the current table schema. The default value is 0.
  • 'strict' - This option is used in partial JSON attribute updates. By default (strict=1), UPDATE will result in an error if the UPDATE query tries to perform an update on non-numeric properties. With strict=0, if multiple properties are updated and some are not allowed, the UPDATE will not result in an error and will perform the changes only on allowed properties (with the rest being ignored). If none of the SET changes of the UPDATE re permitted, the command will result in an error even with strict=0.

Query optimizer hints

In rare cases, Manticore's built-in query analyzer may be incorrect in understanding a query and determining whether a table by ID should be used. This can result in poor performance for queries like UPDATE ... WHERE id = 123. For information on how to force the optimizer to use a docid index, see Query optimizer hints.

Updates via HTTP JSON

Updates using HTTP JSON protocol are performed via the /update endpoint. The syntax is similar to the /insert endpoint, but this time the doc property is mandatory.

The server will respond with a JSON object stating if the operation was successful or not.

‹›
  • JSON
JSON
📋
⚙
POST /update
{
  "index":"test",
  "id":1,
  "doc":
   {
     "gid" : 100,
     "price" : 1000
    }
}
‹›
Response
{
  "_index": "test",
  "_id": 1,
  "result": "updated"
}

The ID of the document that needs to be updated can be set directly using the id property, as shown in the previous example, or you can update documents by query and apply the update to all the documents that match the query:

‹›
  • JSON
JSON
📋
⚙
POST /update

{
  "index":"test",
  "doc":
  {
    "price" : 1000
  },
  "query":
  {
    "match": { "*": "apple" }
  }
}
‹›
Response
{
  "_index":"products",
  "updated":1
}

The query syntax is the same as in the /search endpoint. Note that you can't specify id and query at the same time.

Flushing attributes

FLUSH ATTRIBUTES

The FLUSH ATTRIBUTES command flushes all in-memory attribute updates in all the active tables to disk. It returns a tag that identifies the result on-disk state, which represents the number of actual disk attribute saves performed since the server startup.

mysql> UPDATE testindex SET channel_id=1107025 WHERE id=1;
Query OK, 1 row affected (0.04 sec)

mysql> FLUSH ATTRIBUTES;
+------+
| tag  |
+------+
|    1 |
+------+
1 row in set (0.19 sec)

See also attr_flush_period setting.

Bulk updates

You can perform multiple update operations in a single call using the /bulk endpoint. This endpoint only works with data that has Content-Type set to application/x-ndjson. The data should be formatted as newline-delimited JSON (NDJSON). Essentially, this means that each line should contain exactly one JSON statement and end with a newline \n and, possibly, a \r.

‹›
  • JSON
JSON
📋
⚙
POST /bulk

{ "update" : { "index" : "products", "id" : 1, "doc": { "price" : 10 } } }
{ "update" : { "index" : "products", "id" : 2, "doc": { "price" : 20 } } }
‹›
Response
{
   "items":
   [
      {
         "update":
         {
            "_index":"products",
            "_id":1,
            "result":"updated"
         }
      },
      {
         "update":
         {
            "_index":"products",
            "_id":2,
            "result":"updated"
         }
      }
   ],
   "errors":false
}

The /bulk endpoint supports inserts, replaces, and deletes. Each statement begins with an action type (in this case, update). Here's a list of the supported actions:

  • insert: Inserts a document. The syntax is the same as in the /insert endpoint.
  • create: a synonym for insert
  • replace: Replaces a document. The syntax is the same as in the /replace.
  • index: a synonym for replace
  • update: Updates a document. The syntax is the same as in the /update.
  • delete: Deletes a document. The syntax is the same as in the /delete endpoint.

Updates by query and deletes by query are also supported.

‹›
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
📋
⚙
POST /bulk

{ "update" : { "index" : "products", "doc": { "coeff" : 1000 }, "query": { "range": { "price": { "gte": 1000 } } } } }
{ "update" : { "index" : "products", "doc": { "coeff" : 0 }, "query": { "range": { "price": { "lt": 1000 } } } } }
‹›
Response
{
  "items":
  [
    {
      "update":
      {
        "_index":"products",
        "updated":1
      }
    },
    {
      "update":
      {
        "_index":"products",
        "updated":3
      }
    }
  ],
  "errors":false
}

Keep in mind that the bulk operation stops at the first query that results in an error.

Settings related with updates

attr_update_reserve

attr_update_reserve=size

attr_update_reserve is a per-table setting that determines the space reserved for blob attribute updates. This setting is optional, with a default value of 128k.

When blob attributes (MVAs, strings, JSON) are updated, their length may change. If the updated string (or MVA, or JSON) is shorter than the old one, it overwrites the old one in the .spb file. However, if the updated string is longer, updates are written to the end of the .spb file. This file is memory-mapped, which means resizing it may be a rather slow process, depending on the OS implementation of memory-mapped files.

To avoid frequent resizes, you can specify the extra space to be reserved at the end of the .spb file using this option.

‹›
  • SQL
  • JSON
  • PHP
  • Python
  • javascript
  • Java
  • C#
  • TypeScript
  • Go
  • CONFIG
📋
create table products(title text, price float) attr_update_reserve = '1M'

attr_flush_period

attr_flush_period = 900 # persist updates to disk every 15 minutes

When updating attributes the changes are first written to in-memory copy of attributes. This setting allows to set the interval between flushing the updates to disk. It defaults to 0, which disables the periodic flushing, but flushing will still occur at normal shut-down.