Precautions

1. User-defined timestamps

1. Your use case requires writing data with specific timestamps.

2. Data is synchronized to ApsaraDB for HBase from Big Data Service (BDS), such as in primary/standby replication or incremental imports from ApsaraDB for RDS. BDS might add a write timestamp during this process.

To enable support for user-defined timestamps, use HBase Shell to access an ApsaraDB for HBase cluster to change the table's MUTABILITY property to MUTABLE_ALL. Enabling this feature introduces a minor performance overhead, but it is typically not significant.

# Enable support for user-defined timestamps
hbase(main):002:0> alter 'testTable', MUTABILITY=> 'MUTABLE_ALL'
# Disable support for user-defined timestamps
hbase(main):002:0> alter 'testTable', MUTABILITY=> 'MUTABLE_LATEST'

2. Multiple versions

If a Search index is configured for an ApsaraDB for HBase table that uses multiple versions, data inconsistency can occur between ApsaraDB for HBase and the Search instance. To prevent this, you must use HBase Shell to access an ApsaraDB for HBase cluster to explicitly set the number of versions for the table to 1. Additionally, you cannot delete a specific version of a cell. For example:

    // Deletes the entire row if the Delete object is created without a family or qualifier. This is supported.
    Delete delete = new Delete(Bytes.toBytes("row"));
    // Deletes all versions of the column f:q1. This is supported.
    delete.addColumns(Bytes.toBytes("f"), Bytes.toBytes("q1"));
    // Deletes all versions of the column f:q1 with a timestamp less than or equal to ts1. This is supported only if user-defined timestamps are enabled (MUTABILITY is 'MUTABLE_ALL').
    delete.addColumns(Bytes.toBytes("f"), Bytes.toBytes("q1"), ts1);
    // Deletes all columns in the family f. This is supported.
    delete.addFamily(Bytes.toBytes("f"));
    // Deletes all versions of all columns in family f with a timestamp less than or equal to ts1. This is supported only if user-defined timestamps are enabled (MUTABILITY is 'MUTABLE_ALL').
    delete.addFamily(Bytes.toBytes("f"), ts1);
    // Deletes only the latest version of the column f:q1. This is not supported.
    delete.addColumn(Bytes.toBytes("f"), Bytes.toBytes("q1"));
    // Deletes a specific version of the column f:q1 with the timestamp ts1. This is not supported.
    delete.addColumn(Bytes.toBytes("f"), Bytes.toBytes("q1"), ts1);

Note: To prevent data inconsistency, when you delete a row in ApsaraDB for HBase, the corresponding document in the Search index is not deleted. Instead, all fields are removed from the document except for the id field, which maps to the ApsaraDB for HBase rowkey. Typically, user queries include conditions and will not match these id-only documents. However, if your query returns a document that contains only an id field, it indicates the corresponding row has been deleted from ApsaraDB for HBase. You must filter out these documents in your application logic. We plan to use the Search TTL feature in the future to automatically delete these residual documents.

3. TTL

Both ApsaraDB for HBase and the Search service support Time to Live (TTL) to automatically expire data. However, their TTL mechanisms work differently. ApsaraDB for HBase applies TTL to individual cells (key-value pairs), while the Search service applies it at the document level, which corresponds to an entire ApsaraDB for HBase row. Because of this difference, expiration times may not be synchronized. If your use case requires TTL, contact the ApsaraDB for HBase support team or submit a ticket for assistance.