+1
On 24 Apr 2015 21:34, Joshua McKenzie (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/CASSANDRA-9104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511672#comment-14511672
]
Joshua McKenzie commented on CASSANDRA-9104:
Vote passes with 7 binding and 4 non-binding +1 votes and no vetoes.
Thank you all. JIRA ticket will be opened soon.
Regards,
Branimir
On Fri, Aug 20, 2021 at 10:41 AM Sam Tunnicliffe wrote:
> +1
>
> > On 19 Aug 2021, at 17:10, Branimir Lambov wrote:
> >
> > Hell
Hello everyone,
I am proposing the CEP-11 (Pluggable memtable implementations) for adoption
Discussion thread:
https://lists.apache.org/thread.html/rb5e950f882196764744c31bc3c13dfbf0603cb9f8bc2f6cfb976d285%40%3Cdev.cassandra.apache.org%3E
The vote will be open for 72 hours.
Votes by PMC
---
> > >>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>> --
> > >>> Jonathan Ellis
> > >>> co-founder, http://www.datastax.com
> > >>> @spyced
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >>
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > > For additional commands, e-mail: dev-h...@cassandra.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> > For additional commands, e-mail: dev-h...@cassandra.apache.org
> >
> >
>
--
Branimir Lambov
e. branimir.lam...@datastax.com
w. www.datastax.com
ope the
> maintenance
> >> of
> >>>>>>> these interfaces (we should not assume “tribal knowledge” will
> work).
> >>>>>>>
> >>>>>>> I am not trying to ask for something large or something requiring a
> &
Hi everyone,
I would like to start a vote on this CEP.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API
Discussion:
https://lists.apache.org/thread.html/r636bebcab4e678dbee042285449193e8e75d3753200a1b404fcc7196%40%3Cdev.cassandra.apache.org%3E
The
18:05, Joshua McKenzie a
> > écrit :
> >
> >> +1
> >>
> >> On Tue, Nov 16, 2021 at 10:14 AM Andrés de la Peña <
> adelap...@apache.org>
> >> wrote:
> >>
> >>> +1
> >>>
> >>> On Tue, 16 Nov 2021 at 08:39,
Does anyone have any further comments or questions on the proposal, or are
we ready to move forward to a vote?
Regards,
Branimir
On Tue, Nov 2, 2021 at 7:15 PM David Capwell
wrote:
> > I apologize I did not mention those things explicitly. All the places
> where
> > sstable files are accessed
As Jacek is not a committer, this proposal needs a shepherd. I would be
happy to take this role.
> to me the interfaces has to be at the SSTable level, which then expose
readers/writers, but also has to expose the other things we do outside of
those paths
Could you give some detail on what these
Proposal for a mechanism for plugging in memtable implementations:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-11%3A+Pluggable+memtable+implementations
The proposal supports using custom memtable implementations to support
development and testing of improved alternatives, but also
gt; - Micke
>
> On Wed, 21 Jul 2021 at 08:24, Berenguer Blasi
> wrote:
>
> > +1. De-tangling, going more modular and clean interfaces sgtm.
> >
> > On 20/7/21 21:45, Nate McCall wrote:
> > > Yay for pluggable memtables!! I havent gone over this in detail yet,
> bu
emtable must be able to receive an address into a commit log entry and
> to adopt partial ownership over the entry’s lifecycle.
>
>
> From: Branimir Lambov
> Date: Wednesday, 21 July 2021 at 14:28
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSS] CEP-11: Plugg
g (opt out of commit log only).
On Thu, Jul 22, 2021 at 4:00 PM Michael Burman wrote:
> On Wed, 21 Jul 2021 at 17:24, Branimir Lambov <
> branimir.lam...@datastax.com>
> wrote:
>
> > > Why is flushing control bad to do in CFS and better in the
> > memtable?
>
gt;>>
> >>
> https://gitbox.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=NEWS.txt;hb=refs/tags/4.0.0-tentative
> >>>>>>
> >>>>>>
> -
> >>>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>> -
> >>>>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >>>>> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>>>>
> >>>>>
> >>>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> >> For additional commands, e-mail: dev-h...@cassandra.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>
--
Branimir Lambov
e. branimir.lam...@datastax.com
w. www.datastax.com
We would like to contribute our TrieMemtable to Cassandra.
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
This is a new memtable solution aimed to replace the legacy implementation,
developed with the following objectives:
- lowering the on-heap
tes without
> forcing all tables to use the same template specified by the YAML.
>
>
> On 09/02/2022 09:43, bened...@apache.org wrote:
>
> Why not have some default templates that can be specified by the schema
> without touching the yaml, but overridden in the yaml as ne
Hi everyone,
I'd like to propose CEP-19 for approval.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-19%3A+Trie+memtable+implementation
Discussion: https://lists.apache.org/thread/fdvf1wmxwnv5jod59jznbnql23nqosty
The vote will be open for 72 hours.
Votes by committers are
Berenguer Blasi wrote:
>> > +1
>> >
>> > On 16/2/22 23:50, Joseph Lynch wrote:
>> >> +1 nb
>> >>
>> >> Really excited for this, Thank you Branimir!
>> >>
>> >> -Joey
>> >>
>> >> On Wed, Feb 16, 202
n rate / memory pressure, read & write
> latencies, etc. compared to existing implementation.
>
> Dinesh
>
> On Jan 18, 2022, at 2:13 AM, Branimir Lambov wrote:
>
> The memtable pluggability API (CEP-11) is per-table to enable memtable
> selection that suits specific workflows.
ion. I
> am for maintaining a pluggable API for various components.
>
> Dinesh
>
> On Feb 7, 2022, at 8:39 AM, Branimir Lambov wrote:
>
> Added some performance results to the ticket:
> https://issues.apache.org/jira/browse/CASSANDRA-17240
>
> Regards,
> Branimir
&
o a user can test per table, but this changes every host in a
> cluster, so the impact of a bug/regression is much higher.
>
>
> On Jan 10, 2022, at 1:30 AM, Branimir Lambov wrote:
>
>
> We would like to contribute our TrieMemtable to Cassandra.
>
>
> https://cwiki.apache
Hello Amit,
This paper may be of interest to you:
https://www.vldb.org/pvldb/vol15/p3359-lambov.pdf
We did a range of tests that are similar to your scenario and realized
several things early on:
- Memory-mapping the commit log in combination with memory-mapped data
or index files causes
Hi everyone,
CASSANDRA-17240 (Trie memtable implementation) introduces a dependency on
the agrona library (https://github.com/real-logic/agrona).
Does anyone have any objections to adding this dependency?
Regards,
Branimir
KjcbIGBN7PBunbg$>
> and |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org
> <https://urldefense.com/v3/__https://pgp.mit.edu/pks/lookup?search=derek*40chen-becker.org__;JQ!!PbtH5S7Ebw!cY9TyIm1RqAGMkhgyKDjzQcOq6Cy6kzMj_VjvMm40JG9VMm6JgFfH9omG1Spx0UmlkEcGJcFmDtKjcbIGBPzYoayyA$>
> |
> | Fngrprnt: EB8A 6480 F0A3 C8EB C1E7 7F42 AFC5 AFEE 96E4 6ACC |
> +---+
>
>
--
Branimir Lambov
e. branimir.lam...@datastax.com
w. www.datastax.com
t;> wrote:
>>
>> +1
>>
>> On Mon, 19 Dec 2022 at 8:30, J. D. Jordan
>> wrote:
>>
>> +1 nb
>>
>> > On Dec 19, 2022, at 7:07 AM, Brandon Williams wrote:
>> >
>> > +1
>> >
>> > Kind Regards,
>> > Brand
Hi everyone,
I'd like to propose CEP-25 for approval.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format
Discussion: https://lists.apache.org/thread/3dpdg6dgm3rqxj96cyhn58b50g415dyh
The vote will be open for 72 hours.
Votes by committers are
Hello everyone,
I would like to open the discussion on our proposal for a unified
compaction strategy that aims to solve well-known problems with compaction
and improve parallelism to permit higher levels of sustained write
throughput.
The proposal is here:
reaming to an old node, but since we
> don’t generally stream between versions I don’t see any major issue anyway).
>
>
> On 21 Nov 2022, at 12:43, Branimir Lambov wrote:
>
>
> Hi everyone,
>
> We would like to put CEP-25 for discussion.
>
> https://cwiki.apache.o
> On 21 Nov 2022, at 13:29, Branimir Lambov wrote:
>
>
> There is no intention to introduce any new versions of the format
> specifically for DSE. If there are any further changes to the format, they
> will be OSS-first. In other words this support only extends to preexisting
&
Hi everyone,
We would like to put CEP-25 for discussion.
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-25%3A+Trie-indexed+SSTable+format
The proposal describes DSE's Big Trie-indexed SSTable format, which
replaces the primary index with on-disk tries to improve lookup performance
and
oduction in
> our Astra Serverless cloud service since it was launched in March 2021. The
> version described by the CEP therefore already incorporates some
> improvements based on observed production behaviour.
>
> Henrik
>
> On Mon, 19 Dec 2022, 15:41 Branimir Lambov, wr
CEPs 25 (trie-indexed sstables) and 26 (unified compaction strategy) should
both be ready for review by mid-April.
Both are around 10k LOC, fairly isolated, and in need of a committer to
review.
Regards,
Branimir
On Mon, Mar 6, 2023 at 11:25 AM Benjamin Lerer wrote:
> Sorry, I realized that
en-finalize approach. I would also support automatic finalization
> based on a time threshold or similar, to balance the priorities of safe and
> straightforward upgrades. Users need to be aware of the range of SSTable
> formats supported by a given version, and how to handle when their SSTables
> wouldn't be supported by an upcoming upgrade.
>
> --
> Abe
>
--
Branimir Lambov
e. branimir.lam...@datastax.com
w. www.datastax.com
Hi everyone,
There has been a discussion lately about changes to the sstable format in
the context of being able to abort a cluster upgrade, and the fact that
changes to sstables can prevent downgraded nodes from reading any data
written during their temporary operation with the new version.
>>> then we can rewrite them in the latest version. This optimizes the storage
>>>> and opens up new functionality. This means new features that can work with
>>>> old on-disk structures will be available while others that strictly require
>>>> new versions of the d
.@gmail.com> wrote:
>>> > > >>>>
>>> > > >>>> +1 nb, will be great to have this in the codebase - it will
>>> make nearly every table's compaction work more efficiently. The only
>>> possible exception is tables that are well suited fo
Hi everyone,
I would like to put CEP-26 to a vote.
Proposal:
https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-26%3A+Unified+Compaction+Strategy
JIRA and draft implementation:
https://issues.apache.org/jira/browse/CASSANDRA-18397
Up-to-date documentation:
It seems I have created some confusion.
This version of UCS (let's call it V2) is ahead of the one in DSE (V1),
with the main difference that it no longer uses a fixed number of shards.
Because of this, V2 acts similar to LCS in the required extra space,
because the sstables it constructs aim to
eriod of time is not the same cognitive burden as flakies.
>> There are currently other broken tests in 5.0: VectorUpdateDeleteTest,
>> upgrade_through_versions_test; are these compounding to the frustrations ?
>>
>> It's also been questioned about why we don't just enable settings we
>> recommend. These are settings we recommend for new clusters. Our existing
>> cassandra.yaml needs to be tailored for existing clusters being upgraded,
>> where we are very conservative about changing defaults.
>>
>>
--
Branimir Lambov
e. branimir.lam...@datastax.com
w. www.datastax.com
Hi All,
CASSANDRA-18753 introduces a second set of defaults (in a separate
"cassandra_latest.yaml") that enable new features of Cassandra. The
objective is two-fold: to be able to test the database in this
configuration, and to point potential users that are evaluating the
technology to an
these tests? No…. When we have
> failing tests people do not spend the time to figure out if their logic
> caused a regression and merge, making things more unstable… so when we
> merge failing tests that leads to people merging even more failing tests...
>
> On Feb 13, 2024, a
41 matches
Mail list logo
