In general, Avatica is just an abstraction of JDBC over an RPC mechanism
via a standalone server. Presently that RPC mechanism is HTTP with
Avatica "protocol" data serialized using JSON or Protocol Buffers.
The general approach I've been trying to follow (agreed upon with Nick a
while back) was to try to keep Avatica horizontally scalable, not
requiring clients to be sticky. Avatica servers do not need to
communicate with each other and should be capable of operating in
parallel with other servers. It is an important caveat that clients
should still try to be sticky (for performance reasons), but it's been a
goal to not make this a requirement. I've done some preliminary testing
with Avatica behind HAProxy with initial success.
Long term, I'd love to provide an array of libraries/drivers for
interfacing with Avatica in the language of your choice. We have the
Java-based implementation (reference implementation) that Avatica
directly provides in the form of a JDBC driver. We've also seen a Python
driver, targeted for Phoenix, that implements the Python Database 2.0
API. ODBC is also a moving target that we can hopefully nail down some day.
If you have more specific questions WRT architecture/performance, I'd be
happy to try to answer them, Maxime!
- Josh
<snip/>
Josh, Can you weigh in on options for scaling out Avatica?
Julian
On Mar 17, 2016, at 2:32 PM, Maxime Jattiot<[email protected]> wrote:
<snip/>
- Also you said you are a framework but can you work as an engine that is
queried through ODBC/JDBC ? Is that the purpose of Avatica ? If yes can we
cluster it to handle many clients queries ?
<snip/>
