Forum: Building VoltDB Applications

Post: Replication Pattern lockup all the patterns

Replication Pattern lockup all the patterns
tony7889
Dec 22, 2011
Hi,

I know that the current volt db version treats the replicated pattern as a big whole dataset and it fire the query to all nodes and parallel processing the query. But the problem is it locks up all the nodes.
For my case, there are several pattern must be patterned together and it is not possible to split them. So that the replicated pattern is the only way to solve it.

Finally, my question is any road map for VoltDB to use the Replicated pattern without blocking all nodes?
Or there is other good approach to solve the problem with a big replicated pattern?

Tony :)
Replicated and partitioned tables
rbetts
Dec 22, 2011
I'm not sure what you mean by "replicated pattern". There are two table types: replicated and partitioned. Replicated tables exist in full at each partition. Updating or writing them is a multi-partition procedure. The second table type, partitioned tables, store a subset of data at each partition.

If you need to store multiple items at the same partition, the only way to do this in voltdb is to give them all the same partition column value.

If you are trying to solve a large graph problem, like a social graph, where there are arbitrary relationships (edges) between different rows (nodes), it will be difficult to map to volt efficiently -- graph problems do not partition easily. We might be able to help more specifically if you shared your schema / application logic with us.
Yes I mean Replicated table.
tony7889
Dec 28, 2011
I'm not sure what you mean by "replicated pattern". There are two table types: replicated and partitioned. Replicated tables exist in full at each partition. Updating or writing them is a multi-partition procedure. The second table type, partitioned tables, store a subset of data at each partition....


Yes I mean Replicated table.

Our existing system involves 3 different logical items, Owner, Stock, Gateway (which the Stock goes through to our warehouse).
So when a Stock comes in, we have to keep the record of the stock, calc the balance of the Owner account, and calc the balance of the warehouse for stock check.

So one atomic transaction involved 3 different logical unit, So we design to
1. Owner (Patterned)
2. Stock (Patterned with the Owner)
3. Gateway (Replicated), but the Gateway is quite a lot in number and any stock can come in through any gateway.

So the Gateway seems to be the obstacle. And the questions for me are
1. To make it atomic in a transaction, the "Gateway" table must be locked up that it is replicated. Is it correct?
2. Actually I only update 1 record from the Replicated Gateway table, seems not efficient to lock it up right? Any good recommendation?
3. Any Roadmap for Voltdb to make a transaction acrossing 2 partitions? so
I can also make the "Gateway" table as Partitioned.
Thanks and Merry Christmas~

Tony :)
Hi Rbetts, In my Case, the
tony7889
Jan 8, 2012
I'm not sure what you mean by "replicated pattern". There are two table types: replicated and partitioned. Replicated tables exist in full at each partition. Updating or writing them is a multi-partition procedure. The second table type, partitioned tables, store a subset of data at each partition...


Hi Rbetts,

In my Case, the database schema is pretty the same as TPC-C the multiple tables access, the same problem for "new order" that remote warehouse may be involved in a atomic transaction.

So if the VoltDB can handle the TPC-C benchmark "New Order" and "Payment" scenario, then I believe the our question can be answered.

So Can VoltDB now handle the TPC-C benchmark?
Or There is Road Map for VoltDB for handling TPC-C multiple partition transaction in future?

Thanks,
Tony :)