Table of Contents
There are several ways to retrieve table rows from the store. You can:
Retrieve a single row at a time using the
Store.get()
method.
Retrieve rows associated with a shard key (which is based on
at least part of your primary keys) using
the Store.multi_get()
method.
Retrieve table rows that share a shard key, or an
index key, using the
Store.table_iterator()
method.
Retrieve and process records from each shard in parallel using
a single key as the retrieval criteria. Use one of the
TableAPI.tableIterator() or
TableAPI.tableKeysIterator() methods that
provide parallel scans.
Retrieve and process records from each shard in parallel using
a sequence of keys as the retrieval criteria. Use one of the
TableAPI.tableIterator() or
TableAPI.tableKeysIterator() methods that
provide bulk retrievals.
Each of these are described in the following sections.
Several errors can occur when you attempt a read operation
in the store. The first of these is
ConsistencyException.
This error indicates that the operation cannot be completed
because the consistency policy cannot be met. For more
information, see
Consistency Guarantees.
The second error is
RequestTimeoutException. This means that
the operation could not be completed within the amount of time
provided by the store's timeout property. This probably
indicates a store that is attempting to service too many read
requests all at once. Remember that your data is partitioned
across the shards in your store, with the partitioning
occurring based on your shard keys. If you designed your keys
such that a large number of read requests are occurring against
a single key, you could see request timeouts even if some of
the shards in your store are idle.
A request timeout could also be indicative of a network problem that is causing the network to be slow or even completely unresponsive.
To handle a RequestTimeoutException,
you could simply log the error and move on, or you could pause for
a short period of time and then retry the operation. You could
also retry the operation, but use a longer timeout value.
You can also receive an IllegalArgumentException,
which will be thrown if a Row that you
are writing to the store does not have a primary key or is
otherwise invalid.
You can also receive a general
FaultException, which indicates that
some error occurred which is neither a problem with
consistency nor a problem with the request timeout. Your only
recourse here is to either log the error and move along, or
retry the operation.
You can also receive a
MetadataNotFoundException, which indicates that
a client's metadata may be out of sync. It extends FaultException
and can be caught by applications to trigger the need for a refresh of
their metadata, and in particular, Table handles obtained via TableAPI.getTable().