On 11/1/17 3:00 PM, Stack wrote:
Now that I'm thinking about it, I wonder if that's actually the proper
route forward for hbase-native-client too...
And backup?
For argument's sake, yes, that could be a route forward for it.
Architecturally, it could/should be no different than Phoenix: user API
(Java and CLI) with chores and observers deployed onto the cluster
(automatically via Java code and the rest via configuration). Our CP API
would hopefully provide enough breadth that we could have backups work
without needing access to all HBase internals/implementation details.
Now, when it comes to implementation, I don't know if that's 100% true
(using Phoenix as an analogy turned out to be an unexpectedly apt
comparison): I'd rely on Vlad and/or you and Ted (both heavy reviewers
at various points) to weigh in, or I need to just peruse the code
myself. That's one technical concern to such a separation.
The other is more of a "product" concern. Backing up a tables is a core
feature most databases. Snapshots are a great, light-weight "view" of a
table, but they fall short in space usage (deltas-only) and high-level
semantics (e.g. I want to backup the web-indexing group's tables at
$schedule). As such, I think the scope of the general "backup work"
makes sense to treat as a core feature of HBase rather than something
that people would have to opt into (for installation).
