[
https://issues.apache.org/jira/browse/BOOKKEEPER-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13239842#comment-13239842
]
Flavio Junqueira commented on BOOKKEEPER-181:
---------------------------------------------
bq. in the proposal, the comparison operation is just applied in a cell
(located by (key,family,qualifier), while the set operation can be applied on
multiple cells.
for example, suppose we have two columns, one column is data column, which is
used to store actual data; while the other one is version column, which is used
to store a incremented number. the initial value is (oldData, 0). when we want
to update data column, we executed by CAS (key, 0, key, (newData, 1)). the
comparison is applied only on version column, is not on data column, which is
not expensive.
I was thinking that in the case of hbase, we have versions for the rows
already, so we could use those to perform the comparison: if the version passed
as input is not current, then we don't swap. I agree that it restricts the
kv-stores we could use, though. The approach you describe is more general.
bq. As my knowledge, zk#setData provides a conditional set over version, the
set operation succeeds only when the given matches the version of the znode,
which is a kind of CAS. CAS would be better to support more K/V stores.
Exactly, the comparison is performed using versions (int).
bq. I think I have put them in section 3, the operations required by a
MetaStore.
That's right, the beginning of Section 3 talks about it. I read it as the set
of operations that we execute against the metadata store as opposed to the
semantics we expect from the store.
bq. doesn't this case exit using zookeeper? it seems that there is still a gap
between hub crashed and znode deletion (session expired). in metastore-based
topic manager, this gap becomes hub crashed and other hub server got notified
about hub crashed.
Yes, it exists with zookeeper, but the current design document does not reflect
it. You may consider updating it.
bq. if a hub server is not crashed, other hub server would not receive the
notification from zookeeper about that hub crashed (can zookeeper guarantee
it?). so ownership would not change, since other hub server still see a same
zxid about that hub server.
It was not entirely clear to me that you're assuming zookeeper in the document
for this part. If that's the assumption, then it seems fine to me.
> Scale hedwig
> ------------
>
> Key: BOOKKEEPER-181
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-181
> Project: Bookkeeper
> Issue Type: Improvement
> Components: bookkeeper-server, hedwig-server
> Reporter: Sijie Guo
> Assignee: Sijie Guo
> Attachments: hedwigscale.pdf
>
>
> Current implementation of Hedwig and BookKeeper is designed to scale to
> hundreds of thousands of topics, but now we are looking at scaling them to
> tens to hundreds of millions of topics, using a scalable key/value store such
> as HBase.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
