Cloud Spanner V1 Client - Class Tablet (2.2.0)

Reference documentation and code samples for the Cloud Spanner V1 Client class Tablet.

A Tablet represents a single replica of a Group . A tablet is served by a single server at a time, and can move between servers due to server death or simply load balancing.

Generated from protobuf message google.spanner.v1.Tablet

Constructor.

The UID of the tablet, unique within the database. Matches the tablet_uids and leader_tablet_uid fields in Group .

The UID of the tablet, unique within the database. Matches the tablet_uids and leader_tablet_uid fields in Group .

The address of the server that is serving this tablet -- either an IP address or DNS hostname and a port number.

The address of the server that is serving this tablet -- either an IP address or DNS hostname and a port number.

Where this tablet is located. This is the name of a Google Cloud region, such as "us-central1".

Where this tablet is located. This is the name of a Google Cloud region, such as "us-central1".

The role of the tablet.

The role of the tablet.

incarnation indicates the freshness of the tablet information contained in this proto. Incarnations can be compared lexicographically; if incarnation A is greater than incarnation B, then the Tablet corresponding to A is newer than the Tablet corresponding to B, and should be used preferentially.

incarnation indicates the freshness of the tablet information contained in this proto. Incarnations can be compared lexicographically; if incarnation A is greater than incarnation B, then the Tablet corresponding to A is newer than the Tablet corresponding to B, and should be used preferentially.

Distances help the client pick the closest tablet out of the list of tablets for a given request. Tablets with lower distances should generally be preferred. Tablets with the same distance are approximately equally close; the client can choose arbitrarily.

Distances do not correspond precisely to expected latency, geographical distance, or anything else. Distances should be compared only between tablets of the same group; they are not meaningful between different groups. A value of zero indicates that the tablet may be in the same zone as the client, and have minimum network latency. A value less than or equal to five indicates that the tablet is thought to be in the same region as the client, and may have a few milliseconds of network latency. Values greater than five are most likely in a different region, with non-trivial network latency. Clients should use the following algorithm:

• If the request is using a directed read, eliminate any tablets that do not match the directed read's target zone and/or replica type.
• (Read-write transactions only) Choose leader tablet if it has an distance <=5.
• Group and sort tablets by distance. Choose a random tablet with the lowest distance. If the request is not a directed read, only consider replicas with distances <=5.
• Send the request to the fallback endpoint. The tablet picked by this algorithm may be skipped, either because it is marked as skip by the server or because the corresponding server is unreachable, flow controlled, etc. Skipped tablets should be added to the skipped_tablet_uid field in RoutingHint ; the algorithm above should then be re-run without including the skipped tablet(s) to pick the next best tablet.

Distances help the client pick the closest tablet out of the list of tablets for a given request. Tablets with lower distances should generally be preferred. Tablets with the same distance are approximately equally close; the client can choose arbitrarily.

Distances do not correspond precisely to expected latency, geographical distance, or anything else. Distances should be compared only between tablets of the same group; they are not meaningful between different groups. A value of zero indicates that the tablet may be in the same zone as the client, and have minimum network latency. A value less than or equal to five indicates that the tablet is thought to be in the same region as the client, and may have a few milliseconds of network latency. Values greater than five are most likely in a different region, with non-trivial network latency. Clients should use the following algorithm:

• If the request is using a directed read, eliminate any tablets that do not match the directed read's target zone and/or replica type.
• (Read-write transactions only) Choose leader tablet if it has an distance <=5.
• Group and sort tablets by distance. Choose a random tablet with the lowest distance. If the request is not a directed read, only consider replicas with distances <=5.
• Send the request to the fallback endpoint. The tablet picked by this algorithm may be skipped, either because it is marked as skip by the server or because the corresponding server is unreachable, flow controlled, etc. Skipped tablets should be added to the skipped_tablet_uid field in RoutingHint ; the algorithm above should then be re-run without including the skipped tablet(s) to pick the next best tablet.

If true, the tablet should not be chosen by the client. Typically, this signals that the tablet is unhealthy in some way. Tablets with skip set to true should be reported back to the server in RoutingHint.skipped_tablet_uid ; this cues the server to send updated information for this tablet should it become usable again.

If true, the tablet should not be chosen by the client. Typically, this signals that the tablet is unhealthy in some way. Tablets with skip set to true should be reported back to the server in RoutingHint.skipped_tablet_uid ; this cues the server to send updated information for this tablet should it become usable again.