Aerospike 集群中的多个集合（表）上的多个操作

Question

Current system state:

Currently, I maintain three sets (tables, equivalent in RDBMS) in my aerospike namespace (database, equivalent in RDBMS) backed by RESTful service.

Use-case:

I want to perform CRUD operations on at least one set and sometimes at most on all sets based on some bulk inputs into my system.

Expectation:

I want to perform all these CRUD operations in an atomic manner (means either all happen or none. This also contains an edge-case where some sets are successfully updated with their respective latest updates, and later on even a single set is un-successful. I would want to rollback my data to the previous state in each set.)

My workaround:

1. First I tried to find the equivalent of InsertOnSubmit in aerospike to use the approaches explained on this answer of StackOverflow , but seems like that doesn't exist.

2. Second, I thought of creating an intermediate rollback workflow module. Psuedo code shown below:

   1. Temporarily save the new data in some data-type segregated set-wise.
   2. Loop through set-wise data, and pick the primary key from them and get the older data from aerospike and save it into some other data-type again segregated set-wise.
   3. Loop through all the sets one-by-one from first data-type and start performing CRUD operation accordingly. IF[everything runs till the end]: GOTO step 6; ELSE: GOTO step 4 IF[everything runs till the end]: GOTO step 6; ELSE: GOTO step 4 .
   4. Start rolling-back by looping through all the sets one-by-one from second data-type and start performing CRUD operation. IF[everything runs till the end]: GOTO step 7; ELSE: GOTO step 5 IF[everything runs till the end]: GOTO step 7; ELSE: GOTO step 5 .
   5. Log the error including all the details and report this error to alert system. Someone will get paged for it to have a look. GO TO step 7;
   6. Terminate, operation successful.
   7. Terminate, operation un-successful.

Help Needed:

1. Is there any chance to incoperate InsertOnSubmit behaviour on Aerospike cluster without creating my own roll-back workflow?
2. If not, then is there any better way to optimize my second approach?

Answer 1

1 - No. Aerospike offers atomicity only at a single record level. While inserting Master record and then replicating its copy to another node do follow true 2-phase commit semantics in Aerospike's Strong Consistency (SC) mode, any multi-record transaction has to be implemented at the application level.

2 - Any scheme implementing multi-record transactions, such as one you are thinking of, typically involves - creating some kind of "lock" bin in a record that you set, do the multi-record updates, build a before and after state of your data, have some kind of a maximum time to complete so you can rollback and clear abandoned operations and lock by the client application. Any of these schemes will only work reliably under Aerospike's Strong Consistency mode.