Thanks for your reply.
I will look around phoenix and tephra.
Best regards,
Minwoo Kang
보낸 사람: 张铎(Duo Zhang)
보낸 날짜: 2020년 1월 10일 금요일 15:14
받는 사람: hbase-user
제목: Re: How to avoid write hot spot, While using cross row transactions.
Maybe you need
Maybe you need Phoenix?
You need to use special algorithm to get cross region transactions on
HBase. IIRC, Phoenix has a sub project call Txxx, which implements the
algorithm described in the google percolator paper.
Thanks.
Reid Chan 于2020年1月10日周五 下午1:47写道：
> I think you need some more
Thanks for the reply.
It is a lot of help to me.
Best regards,
Minwoo Kang
보낸 사람: ramkrishna vasudevan
보낸 날짜: 2020년 1월 10일 금요일 14:35
받는 사람: Hbase-User
참조: Stack
제목: Re: Extremely long flush times
Hi
In your case you have large compactions going on and
I think you need some more coding works for fulfilling Atomicity in cross
region scenario, by aid of some third party softwares, like Zookeeper.
AFAIK, Procedure framework in Master may also have ability to do that, but I'm
not sure the details of it and if it supports client customized
Hi
In your case you have large compactions going on and at the same time heavy
reads happening. Since there are lot of deletes the scan is spending
sufficient time in file reads.
Since compactions/flushes happens every now and then the readers are
getting reset and that is causing the lock to be
Hello, users.
I use MultiRowMutationEndpoint coprocessor for cross row transactions.
It has a constraint that is rows must be located in the same region.
I removed random hash bytes in the row key.
After that, I suffer write hot-spot.
But cross row transactions are a core feature in my
Thank you for reply.
All Regions or just the one?
=> just one
Do thread dumps lock thread reading against hdfs every time you take one?
=> yes
Is it always inside in updateReaders? Is there a bad file or lots of files
to add to the list?
=> always inside in updateReaders.
Sorry for the
On Wed, Jan 8, 2020 at 7:39 AM etp wrote:
> Hi,
>
> I have a cluster running Hbase with 1 Master and 6 RS. Recently I noticed
> that Hbase commands are sort of queuing up and possibly hung(RUNNABLE
> state)
> for one table.
> When checking the state of the table, I an see that the table is
