[
https://issues.apache.org/jira/browse/CASSANDRA-17240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17622781#comment-17622781
]
Josh McKenzie edited comment on CASSANDRA-17240 at 10/23/22 11:56 AM:
----------------------------------------------------------------------
{quote}I don't think that we should default to consider experimental everything
that hasn't been tested with Harry
{quote}
{quote}flag new features *_beyond a certain scope_*
{quote}
Emphasis added. New features that are very large and have correctness / data
loss implications, to be more specific. The reason I bring this up here is that
I recall hearing that Branimir and Caleb were discussing the value in Harry
testing the Trie memtables.
Edit: (sorry for hijacking your ticket Branimir) - I'm thinking this points to
something that could be valuable for the project as well as Harry adoption.
Something in the How To Commit / develop / contribute documentation and our
culture around:
# The use of feature flags (likely via guardrails?)
# When should a feature be flagged as experimental vs. promoted
# When to test something with Harry
# How to test something with Harry (much of which I expect we can forklift
from the [readme |https://github.com/apache/cassandra-harry]or just link to it
directly)
Given the history w/the OG version of trie memtables running for years + it
being behind a config param on a table, I don't want to give the impression I'm
deeply worried about the work on the ticket here; I'm not. But I do think there
could be value to the project (+ helping Harry usage become more normalized and
integrated) by us thinking through some of these things.
was (Author: jmckenzie):
bq. I don't think that we should default to consider experimental everything
that hasn't been tested with Harry
bq. flag new features *_beyond a certain scope_*
Emphasis added. New features that are very large and have correctness / data
loss implications, to be more specific. The reason I bring this up here is that
I recall hearing that Branimir and Caleb were discussing the value in Harry
testing the Trie memtables.
> CEP-19: Trie memtable implementation
> ------------------------------------
>
> Key: CASSANDRA-17240
> URL: https://issues.apache.org/jira/browse/CASSANDRA-17240
> Project: Cassandra
> Issue Type: Improvement
> Components: Local/Memtable
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
> Priority: Normal
> Fix For: 4.2
>
> Attachments: SkipListMemtable-OSS.png, TrieMemtable-OSS.png,
> density_SG.html.gz, density_test_with_sharding.html.gz, latency-1_1-95.png,
> latency-9_1-95.png, throughput_SG.png, throughput_apache.png
>
> Time Spent: 13.5h
> Remaining Estimate: 0h
>
> Trie-based memtable implementation as described in CEP-19, built on top of
> CASSANDRA-17034 and CASSANDRA-6936.
> The implementation is available in this
> [branch|https://github.com/blambov/cassandra/tree/CASSANDRA-17240].
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
