Details
-
Bug
-
Status: Open
-
Critical
-
Resolution: Unresolved
-
2.5.5
-
None
-
None
-
Ubuntu 22.04.4 LTS - 64 Bit
Description
Steps to Reproduce :
1. Ensure the column family of the table is configured with MIN_VERSION = 1 and KEEP_DELETED_CELLS = true to ensure that deleted cells remain even after deletion (this is to ensure that flush/compaction doesn't remove deleted cells).
2. Add multiple column keys against a single row key. In this case, use a timestamp (SET1).
3. Use a GET call (GET1) with an iterator-based design to get all the keys. Use the ColumnPaginationFilter and RangeKeyFilter to achieve this (refer to the attached HbaseGet.java file for implementation details).
4. Note the time taken for GET1 (e.g., ~1 second for 100,000 entries).
5. Delete all the added column keys (SET1).
6. Add another set of 100,000 entries (SET2).
7. Use the GET call again (GET2) to retrieve the data and note the time taken.
Expected Behavior:
The time taken for GET2 should be similar to GET1, approximately ~1 second.
Actual Behavior:
The time taken for GET2 increases significantly, approximately 60 seconds, which is ~50 times longer than GET1.
Additional Information:
i) If, after the first delete (SET1), data with lexicographically prior characters (e.g., "0") are added before the deleted cells (timestamp), the GET call time remains consistent with GET1, approximately 1200 ms.
ii) If all 200,000 entries are retrieved without deleting the first set (SET1), the total time is around 2 to 3 seconds. However, deleting SET1 causes GET2 to take 50 times longer than GET1.
Suggested Fix:
Temporarily, to fix this issue, add a dummy column key with a lexicographically prior character (e.g., "0") to ensure consistent GET call times.
Note:
Please refer to the attached HbaseGet.java
, RegionserverFlameGraph and dataFlow for detailed steps to reproduce the issue.
