- row-level locking -> yes we use MVCC and take a row level write lock when necessary for consistency
- independent transaction coordinators at data nodes -> we have a tier called "aggregators" that act as transaction coordinators. These are the nodes you connect to. Under the hood leaf nodes in memsql also manage transactions.
- pruned index scans -> Do you mean information retrieval? Our indexes support seeks and range scans if that's what you mean.
- network-aware transactions (with user-defined partition keys for tables) --> yes, we have user-defined partition keys (shard keys) and transactions work across multiple nodes on the network.
- any asynchronous/event API --> no, we don't have an event API
Most of our use cases are "pull" oriented which scales very well with MemSQL
Great. Lots of good stuff there.
Pruned index scans are index scans where the data is located on a single shard and the index scan doesn't flood all nodes in the DB.
I'll definitely be looking into MemSQL.
- independent transaction coordinators at data nodes -> we have a tier called "aggregators" that act as transaction coordinators. These are the nodes you connect to. Under the hood leaf nodes in memsql also manage transactions.
- pruned index scans -> Do you mean information retrieval? Our indexes support seeks and range scans if that's what you mean.
- network-aware transactions (with user-defined partition keys for tables) --> yes, we have user-defined partition keys (shard keys) and transactions work across multiple nodes on the network.
- any asynchronous/event API --> no, we don't have an event API Most of our use cases are "pull" oriented which scales very well with MemSQL