Yep, our test HBase cluster was misconfigured (ntpd was disabled). After time
synchronisation I don't observe any delay between shell put and Phoenix select.
> On 25 Aug 2017, at 20:54, James Taylor wrote:
>
> Phoenix retrieves the server timestamp from the region
I've already tested currentSCN and I can confirm that delays are gone.
Going to check clocks on cluster nodes...
> On 25 Aug 2017, at 20:54, James Taylor wrote:
>
> Phoenix retrieves the server timestamp from the region server that hosts the
> system catalog table and
Phoenix retrieves the server timestamp from the region server that hosts
the system catalog table and uses that as the timestamp of the puts when
you do an UPSERT VALUE (FYI, this behavior will change in 4.12 and we'll
use latest timestamp everywhere). I suspect the puts you're doing are going
to
Its coming from scan time ragne. If i run sqlline with 'currentSCN' from the
future then select retrieve fresh data immediatly.
We already have software that write with HBase API. Now we build client that
works with data from HBase via Phoenix.
> On 25 Aug 2017, at 19:35, Josh Elser
Calls to put in the HBase shell, to the best of my knowledge, are
synchronous. You should not have control returned to you until the
update was committed by the RegionServers. HBase's data guarantees are
that once a call to write data returns to you, all other readers *must*
be able to see
Here is example:
CREATE TABLE IF NOT EXISTS test (
k VARCHAR NOT NULL,
v VARCHAR,
CONSTRAINT my_pk PRIMARY KEY (k)
);
0: jdbc:phoenix:> upsert into test(k,v) values ('1', 'a');
1 row affected (0.042 seconds)
0: jdbc:phoenix:> select * from test;
+++
| K | V |
+++
| 1 | a
Hello,
How to decrease or even eliminate delay between direct HBase put (for example
from HBase shell) and SELECT from Phoenix?
My table has only 1 VERSION and do not use any block cache ( {NAME =>
'invoice', COMPRESSION => 'LZO', BLOCKCACHE => 'false'} ), so i do not
understand where