vFabric SQLFire Glossary

bucket

The container for data that determines its storage site (or sites when there is redundancy), and the unit of migration for rebalancing.

colocation

A relationship between two tables whereby the buckets that correspond to the same values of their partitioning fields are guaranteed to be physically located in the same SQLFire server or peer. In SQLFire, a table configured to be colocated with another table has a dependency on the other table. If the other table needs to be dropped, then the colocated tables must to be dropped first.

data store

A FabricServer or a peer client process that is connected to the distributed system and has the host-data property set to true. A data store is automatically part of the default server group, and may be configured to be part of other server groups.

default colocation

A colocation relationship that is set up automatically between tables when there is no COLOCATED WITH clause in the CREATE TABLE statement. The default colocation policy is described here.

default server group

The anonymous server group that implicitly includes all fabric servers in the distributed system. This is the server group that hosts the data for a table where there is no SERVER GROUPS clause in the CREATE TABLE statement, and there were no server groups specified in the CREATE SCHEMA statement for the schema that this table belongs to.

distributed system

A typical SQLFire deployment is made up of a number of distributed processes that connect to each other to form a peer to peer network. These member processes may or may not host any data. The GemFire JDBC client process and all fabric servers are always peer members of the distributed system. The members discover each other dynamically through a built-in multicast based discovery mechanism or using the GemFire locator service when TCP is more desirable. Sometimes a distributed system is also referred to as a SQLFire cluster.

hash-partitioning

A partitioning strategy based on the hashcode of one or more fields, such that all the values with the same hashcode are placed into the same bucket.

horizontal vs. vertical partitioning

Horizontal partitioning refers to partitioning strategies where a table is split by rows so that a bucket always contains entire rows. Vertical partitioning refers to strategies where a table is split by columns so that a bucket always contains entire columns. SQLFire currently only supports horizontal partitioning strategies.

list-partitioning

A partitioning strategy based on specified lists of values of one or more fields. For example, a table could be list-partitioned on a string-valued field such that all the values for a specified list of string values are placed in the same bucket.

locator

A locator facilitates discovery of all members in a distributed system. This is a component that maintain a registry of all peer members in the distributed system at any given moment. Though typically started as a separte process (with redundancy for HA), this can also be embedded in any peer member (like a Fabric Server). This opens a TCP port and all new members connect to this process to get the initial membership information. Learn more about the GemFire distributed system including locators here.

partitioned table

A table that manages large volumes of data by partitioning it into manageable chunks and distributing it across all the servers in its hosting server groups. Partitioning attributes, including the partitioning strategy can be specified by supplying a PARTITION BY clause in a CREATE TABLE statement. See also Replicated Table, Partitioning Strategy.

partitioning strategy

The policy used to determine the specific bucket for a field in a partitioned table. SQLFire currently only supports horizontal partitioning , so an entire row is stored in the same bucket. You can hash-partition a table based on its primary key or on an internally-generated unique row id if the table has no primary key. Other partitioning strategies can be specified in the PARTITION BY clause in a CREATE TABLE statement. The strategies that are supported by SQLFire include hash-partitioning on columns other than the primary key, range-partitioning , and list-partitioning.

peer client

Also known as the embedded client, this is a process that is connected to the distributed system using the GemFire Peer Driver. The member may or may not host any data depending on the configuration property host-data. By default, all peer clients will host data. Configuration describes how this property can be set at connection time. Essentially, the peer client can be configured to just be a "pure" client or can be a client as well as a data store. When hosting data, the member can be part of one or more server groups.

peer driver

JDBC driver packaged in sqlfire.jar. The client connects to the distributed system using the SQLFire driver using the URL jdbc:sqlfire: and doesn't specify a host and port in the URL. This driver provides single-hop access to all the data managed in the distributed members. (The SQLFire JDBC thin-client driver also supports one-hop access for lightweight client applications.)

query coordinator

The process that executes the query and determines the overall plan. It may distribute the query to the appropriate fabric servers that host the data. When using a Peer Client , the query coordinator is the Peer Client itself. When using a Thin Client, the query coordinator is the server member to which the client is connected.

range-partitioning

A partitioning strategy based on specified contiguous ranges of values of one or more fields. For example, a table could be range-partitioned on a date field such that all the values within a range of years are placed into the same bucket.

replicated table

A table that keeps a copy of its entire dataset locally on every fabric server in its server groups. SQLFire creates replicated tables by default if you do not specify a PARTITION BY clause. See also Partitioned Table.

server

A JVM started with the sqlf server command, or any JVM that calls the FabricServer.start method. A SQLFire server may or may not also be a data store, and may or may not also be a network server.

server group

A logical grouping of SQLFire servers, used for specifying which members will host data for table. Also used for load balancing thin client connections.

thin client

A process that is not part of the distributed system but is connected to it through a thin driver. The thin client connects to a single server in the distributed system which in turn may delegate requests to other members of the distributed system. JDBC thin clients can also be configured to provide one-hop access to data for lightweight client applications.

thin client driver

The JDBC thin driver bundled in the product (sqlfireclient.jar). A process that is not part of the distributed system but is connected to it through a thin driver. The connection URL for this driver is of the form jdbc:sqlfire://hostname:port/.