Apache HBase Agent for Gluesync: Features Overview
Platform supported features
| Feature | Support | Notes |
|---|---|---|
Target role |
✅ |
Writes to HBase using the native Java client. |
Source role |
✅ |
Uses HBase |
Snapshots |
✅ |
Full-table scans replicate snapshot data before CDC. |
CDC |
✅ |
Incremental scans detect new/updated rows between offsets. |
CDC type |
Scan-based polling |
Relies on lightweight range scans with row-key bookmarking. |
Bulk load |
N/A |
HBase client already batches writes; no staging-table workflow. |
Source persisted internal cache |
N/A |
Offsets/row keys stored in Core Hub metadata only. |
Target persisted internal cache |
N/A |
Writes go directly to HBase via the Java SDK. |
Driver / connector |
HBase Java SDK |
Gluesync bundles the official client libraries. |
Chains |
N/A |
Not supported being it a NoSQL database. |
Truncate operation support (reading) |
N/A |
Scan-based CDC does not emit TRUNCATE events. |
Truncate operation support (writing) |
N/A |
Gluesync does not issue table truncations automatically. |
Q&A
I have got Phoenix running on top of my HBase deployment, is it supported? Sure, Gluesync doesn’t make use of any other component other than plain HBase. You can still make use of Phoenix while Gluesync migrates and offloads your data from the datastore.
My company has more than a Petabyte of data inside our deployment, does it work with Gluesync? How many resources do I have to dispose of to ensure it will work well? Resource amount is based on a few key driving factors:
-
Network bandwidth;
-
Storage performance;
-
CPU;
-
RAM.
We will take care of gathering these KPIs and provide you with the proper sizing of the needed resource allocation for the Gluesync instances. There is no amount of data that scares Gluesync: when properly sized your data will smoothly flow into the other end, consistently and safely.