Forum: VoltDB Architecture

Post: please clarify - sites vs parititions

please clarify - sites vs parititions
ypcx
Sep 2, 2011
Hello.


The documentation seems to use the term "multi-sited node" to describe a node where multiple hardware threads can each work on one site (roughly) - that is, if I understand that right.


Then, the documentation on "Using VoltDB / 5.1.1. Determining How Many Partitions to Use" - talks about number of partitions per node, in relation of how many CPU cores are on the node.


It is really suggested that there should be one hardware thread assigned to one partition on one node? This seems a bit wasteful, since that partition doesn't have to be active at all times. (Partition being a single table on a single node.)


So this seems to me that by partitions here really are meant the "sites" - (a site being a collection of partitions) - is that true?


Or what is the difference between a partition and a site?


Sorry for the confusing wording, just trying to understand the architecture a bit better.


Thanks!
Hi, The documentation seems
aweisberg
Sep 2, 2011
Hi,


The documentation seems to use the term "multi-sited node" to describe a node where multiple hardware threads can each work on one site (roughly) - that is, if I understand that right.


I couldn't find the term "multi-sited node" in the documentation, but I did find references to multi-sited transactions which refer to distributed transactions. Distributed transactions are executed serially like single partition transactions, but they are executed everywhere at the same time without being interleaved with other transactions so they are effectively single threaded even though the execution of SQL is distributed and parallelized.


Then, the documentation on "Using VoltDB / 5.1.1. Determining How Many Partitions to Use" - talks about number of partitions per node, in relation of how many CPU cores are on the node.


It is really suggested that there should be one hardware thread assigned to one partition on one node? This seems a bit wasteful, since that partition doesn't have to be active at all times. (Partition being a single table on a single node.)


A node can host multiple partitions, and the deployment file has you specify the number of partitions per node not the number of partitions total. A partition always has a single dedicated thread that executes stored procedures and plan fragments against the data contained in that partition. A partition doesn't contain a single table, it contains a copy of all replicated tables, and a subset of the data of each partitioned table.


So this seems to me that by partitions here really are meant the "sites" - (a site being a collection of partitions) - is that true?

Or what is the difference between a partition and a site?

Sorry for the confusing wording, just trying to understand the architecture a bit better.


A site is a single thread of execution associated with a partition. There can be multiple replicas of a partition on different nodes, and each replica will have an associated site and thread of execution.


-Ariel
Terminology
rbetts
Sep 2, 2011
To expand on Ariel's response:


Your DDL defines a schema. Your project file specifies which tables in that schema are partitioned and which are replicated.


A partition is a copy of each replicated table and a unique set of rows from each partitioned table. Partitions are also the unit of data replication in VoltDB. I think of partitions as logical collections and "partition replicas" as physical instances of those logical collections.


A site is a partition replica plus the associated SQL executors and transaction queues. Each site is serviced by one unique OS thread. You configure the number of sites per host in your deployment file.


When a cluster boots, it figures out how many sites it has available in total, reads the replication factor (k-factor) from the deployment file, and assigns each available site a partition replica.


A single-partition-transaction is a transaction that accesses data from a single logical partition each time it runs. Each single partition procedure includes a java annotation that specifies which parameter to that procedure's run method should be used to map invocations of the procedure to the necessary partition replica. When a single partition procedure arrives at the cluster, the value for the partition parameter is hashed to a logical partition id. The system then routes a work unit to each site that owns a replica of that partition. The Java code for a single partition procedure executes at each of these sites.


A multi-partition transaction access data from more than one partition. The java for a multi-partition transaction runs at one randomly selected site, which sends and receives work units from the other sites in the system as required to run the procedure's SQL.
Thanks much for your
ypcx
Sep 3, 2011
Thanks much for your explanations.


I have confused the act of "partitioning a table" (by specifying one of its columns), with the actual runtime division of a node into more executing partitions.