[
https://issues.apache.org/jira/browse/HBASE-8763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14018385#comment-14018385
]
stack commented on HBASE-8763:
------------------------------
This patch seems to get us our speed back. Good on one [~jeffreyz]
Below do basic 1, 5, 25, and 200 threads test:
Here is nopatch, the current master branch:
{code}
nopatch1.1.txt:2014-06-04 12:11:52,176 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=1, iterations=1000000,
syncInterval=0 took 1224.313s 816.785ops/s
nopatch5.1.txt:2014-06-04 12:29:02,864 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=5, iterations=1000000,
syncInterval=0 took 1025.163s 4877.273ops/s
nopatch25.1.txt:2014-06-04 12:53:02,973 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=25, iterations=1000000,
syncInterval=0 took 1434.641s 17425.963ops/s
nopatch200.1.txt:2014-06-04 13:40:30,333 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=200, iterations=1000000,
syncInterval=0 took 2841.947s 70374.289ops/s
{code}
Here is w/ patch applied:
{code}
patch1.1.txt:2014-06-04 14:37:04,973 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=1, iterations=1000000,
syncInterval=0 took 1228.775s 813.819ops/s
patch5.1.txt:2014-06-04 14:53:53,623 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=5, iterations=1000000,
syncInterval=0 took 1003.234s 4983.882ops/s
patch25.1.txt:2014-06-04 15:17:17,952 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=25, iterations=1000000,
syncInterval=0 took 1398.927s 17870.840ops/s
patch200.1.txt:2014-06-04 15:47:36,297 INFO [main]
wal.HLogPerformanceEvaluation: Summary: threads=200, iterations=1000000,
syncInterval=0 took 1813.013s 110313.609ops/s
{code}
> [BRAINSTORM] Combine MVCC and SeqId
> -----------------------------------
>
> Key: HBASE-8763
> URL: https://issues.apache.org/jira/browse/HBASE-8763
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Enis Soztutar
> Assignee: Jeffrey Zhong
> Priority: Critical
> Attachments: HBase MVCC & LogSeqId Combined.pdf,
> hbase-8736-poc.patch, hbase-8763-poc-v1.patch, hbase-8763-v1.patch,
> hbase-8763-v2.patch, hbase-8763-v3.patch, hbase-8763-v4.patch,
> hbase-8763-v5.1.patch, hbase-8763-v5.patch, hbase-8763_wip1.patch
>
>
> HBASE-8701 and a lot of recent issues include good discussions about mvcc +
> seqId semantics. It seems that having mvcc and the seqId complicates the
> comparator semantics a lot in regards to flush + WAL replay + compactions +
> delete markers and out of order puts.
> Thinking more about it I don't think we need a MVCC write number which is
> different than the seqId. We can keep the MVCC semantics, read point and
> smallest read points intact, but combine mvcc write number and seqId. This
> will allow cleaner semantics + implementation + smaller data files.
> We can do some brainstorming for 0.98. We still have to verify that this
> would be semantically correct, it should be so by my current understanding.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
