Batch operations

[AnaNek]

Right now CRUD cannot provide batch insert/upsert/replace with full consistency.
CRUD offers batch insert/upsert with partial consistency. That means
that full consistency can be provided only on single replicaset
using box transactions.

Proposed API is the following:

-- Batch insert tuples
local result, err = crud.insert_many(space_name, tuples, opts)
-- Batch insert objects
local result, err = crud.insert_object_many(space_name, objects, opts)
-- Batch upsert tuples
local result, err = crud.upsert_many(space_name, tuples, operations, opts)
-- Batch upsert objects
local result, err = crud.upsert_object_many(space_name, objects, operations, opts)
-- Batch replace tuples
local result, err = crud.replace_many(space_name, tuples, opts)
-- Batch replace objects
local result, err = crud.replace_object_many(space_name, objects, opts)

For insert_many/insert_object_many:

Returns metadata and array contains inserted rows, array of errors (
one error corresponds to one replicaset for which the error occurred).
Error object can contain tuple field. This field contains the tuple
for which the error occurred.

For upsert_many/upsert_object_many:

Returns metadata and array of empty arrays, array of errors (
one error corresponds to one replicaset for which the error occurred).
Error object can contain tuple field. This field contains the tuple
for which the error occurred.

For replace_many/replace_object_many:

Returns metadata and array contains inserted/replaced rows, array of errors (
one error corresponds to one replicaset for which the error occurred).
Error object can contain tuple field. This field contains the tuple
for which the error occurred.

Perf test run on MacBook Pro (2017) i7/16Gb/512SSD
According to results as the number of inserted tuples increases
the average call time grows faster for insert() then
for batch_insert(). For example with batch size == 10000 tuples
insert() is ~26 times slower then batch_insert().

==== BATCH COMPARISON PERFORMANCE REPORT ====

== SUCCESS REQUESTS ==
(The higher the better)

	1	10	100	1000	10000
insert	68892	11171	1205	120	13
batch_insert	76141	46159	16627	2276	317

== SUCCESS REQUESTS PER SECOND ==
(The higher the better)

	1	10	100	1000	10000
insert	2296.39	372.33	40.15	4.00	0.40
batch_insert	2538.01	1538.62	554.22	75.84	10.56

== ERRORS ==
(Bad if higher than zero)

	1	10	100	1000	10000
insert	0	0	0	0	0
batch_insert	0	0	0	0	0

== AVERAGE CALL TIME ==
(The lower the better)

	1	10	100	1000	10000
insert	0.434 ms	2.684 ms	24.907 ms	250.079 ms	2484.446 ms
batch_insert	0.393 ms	0.649 ms	1.803 ms	13.183 ms	94.658 ms

== MAX CALL TIME ==
(The lower the better)

	1	10	100	1000	10000
insert	10.472 ms	8.554 ms	49.886 ms	294.954 ms	2540.472 ms
batch_insert	10.572 ms	5.614 ms	10.994 ms	31.748 ms	130.214 ms

"insert" was planned for 30 seconds with 1 connections and 1 fibers total.
"batch_insert" was planned for 30 seconds with 1 connections and 1 fibers total.

Closes #193

[akudiyar]

Hi @AnaNek!
Thank you very much for implementing this, it's a very important problem. Here are my thoughts about the possible implementation, I hope you will consider them too:

• Inserting tuple-by-tuple is not very efficient. When there's a task of butch inserting/replacing, in most of the cases that means operating with one bucket / one Tarantool node in a transaction, for the most efficiency
• If we have a storage name and a bucket ID, we can efficiently do batch replacing on a storage node.
• We can split the incoming tuples on the router by bucket ID, pack them into batches and send batches to the storage nodes.
• The result of the operation must be consistent (but it may be chosen by the user) -- e.g., if one tuple fails to insert, the whole pack is considered failed and a comprehensive error is returned to the user. Also when inserting large sets of data we need to consider lowering the network traffic impact -- thus, we need to provide the ability to switch off returning the results and do some research about the minimization of extra data (metadata) transferring between client/router and router/storage.

[ligurio]

Thanks for the patches!

[Totktonada]

My comments on insert.

[DifferentialOrange]

Thank you for your patch! The comparison graph seems astounding. I don't see such improvements every day.

I left some comments after review. I haven't got to review some details yet, but I think there are already plenty of crucial question that we need to resolve.

[DifferentialOrange]

Oh, and if you have any questions about sharding reload, feel free to ask me any time. It may really be complicated.

[AnaNek]

I am going to change upsert_many()/upsert_object_many() API but other operations done.

[DifferentialOrange]

Should be ok. I have left several comment about README, feel free to ignore or fix.

[Totktonada]

Just in case, my expectations:

1. Issue re noreturn (see Batch operations #232 (comment)). Added to Add new flag "return nothing" in options for DML operations #267.
2. Issue re returning index of a tuple in the error (it should ease client's code in tt crud import).
3. In upsert_many(): don't return rows.
4. In upsert_many(): accept an array of {tuple, ops} tables as input (instead of tuples and ops arrays separately).

I'm going to look at insert/replace now.

[Totktonada]

LGTM except the upsert API (see above).

I'm not completely sure that I understand how the schema/shading info reload works in different cases, but, well, it is covered by tests and if there are some tricky cases, there is no sense to stop here for a month in attempts to find them.

[Totktonada]

I glanced on the new upsert_many() implementation and I don't see any problems visually. I think the patchset is ready to go.

Thank you for the hard work!

[iimos]

@AnaNek what storage engine did you use in benchmarks?

[DifferentialOrange]

@AnaNek what storage engine did you use in benchmarks?

We use memtx for the benchmarks.