- Is it possible to have sub-ms Latency of in-memory finely distributed query-by-primary-key tables ? Maybe even with follower reads ?
- I’ve seen some issues on github with concurrent updates/increment. What would be a safe value of doing updates/second that the db supports as of now for 1 particular row ? ( using same table as in 1, the updated column is in it’s own column family and not indexed)
- On 2, is the concurrency on the full row, single column, node ? Like if I split the counter into multiple columns+families (still single row) would it be better concurrency ?
3.1. Can increase concurrency by doing some config like group commit (or?)?
3.2. Can this be better with interleaving since each increment is also an insert into another table (so insert into child table, increment on parent row)?
- Better performance to work with autocommit from the drivers?
- Is it possible to get better select performance by reducing consistency or getting stale results ?
- Does the db early terminate when doing
SELECT FROM t WHERE article_id=x AND ID IN (2000 values) LIMIT 4? (primary_key=(article_id, id))
- Can it do a
select 10 articles BY ID, for each article array_agg(subquery comment ids with query above^))?
7.1. Can this be better with interleaving (some child collections may grow very large but most will have < 10K values)
- Is the cache a normal rocksdb block-cache or some other form (serialized full row etc ?) ?
Nodes will be on 128GB ram, 2xSSD drives, 24-cores.