odes. It's a totally different situation today.
>
>
> On Thu, Apr 5, 2018 at 11:17 AM benjamin roth <brs...@gmail.com> wrote:
>
> > That would be totally awesome!
> >
> > Not sure if it helps here but for completeness:
> > We completely "dumped"
That would be totally awesome!
Not sure if it helps here but for completeness:
We completely "dumped" regular repairs - no matter if 'nodetool repair' or
reaper - and run our own tool that does simply CL_ALL scraping over the
whole cluster.
It runs now for over a year in production and the only
Hi Josh,
Who is "we" in this case?
Best,
Ben
2017-07-24 15:41 GMT+02:00 Josh McKenzie :
> >
> > The initial contributors turned their back on MVs
>
>
> We're working on the following MV-related issues in the 4.0 time-frame:
> CASSANDRA-13162
> CASSANDRA-13547
>
Hi Kurt,
First of all thanks for this elaborate post.
At this moment, I don't want to come up with a solution for all MV issues
but I would like to point out, why I was quite active some time ago and why
I pulled myself back.
As you also mentioned in different words, it seems to me that MVs are
Absolutely
+ Separate repos for separate modules also separate responsibility. IMHO it
makes a heterogenuous structure more manageable. Both in a technical and a
human or insitutional way.
2017-05-15 13:54 GMT+02:00 Jonathan Haddad :
> There's a handful of issues I can think
Isn't there a way to script that with just a few lines of python or
whatever?
2017-03-17 21:03 GMT+01:00 Jeff Jirsa :
>
>
> On 2017-03-17 12:33 (-0700), Stefan Podkowinski wrote:
>
> > As you can see there's a large part about using GitHub for editing on
> >
I think you can refactor any project with little risk and increase test
coverage.
What is needed:
Rules. Discipline. Perseverance. Small iterations. Small iterations. Small
iterations.
- Refactor in the smallest possible unit
- Split large classes into smaller ones. Remove god classes by
Contribution Guide +1
Github WebUI +1
Pull requests +1
Rest: Inspect + Adapt
2017-03-13 19:38 GMT+01:00 Stefan Podkowinski :
> Agreed. Let's not give up on this as quickly. My suggestion is to at
> least provide a getting started guide for writing docs, before
> complaining
First: I am positively surprised how many guys would like to contribute to
docs.
Some days ago I posted to the dev-list about doc-contribution. I think this
applies here again. From my point of view "in-tree docs" are a good choice
for technical references that go closely with the code
Sun, Mar 5, 2017 at 9:23 AM, benjamin roth <brs...@gmail.com> wrote:
>
> > Sorry. Answer was to fast. Maybe you are right.
> >
> > Am 05.03.2017 09:21 schrieb "benjamin roth" <brs...@gmail.com>:
> >
> > > No. You just change the partitioner.
Not maybe. You are absolutely right. Bad idea. Hmpf.
Am 05.03.2017 09:23 schrieb "benjamin roth" <brs...@gmail.com>:
> Sorry. Answer was to fast. Maybe you are right.
>
> Am 05.03.2017 09:21 schrieb "benjamin roth" <brs...@gmail.com>:
>
>> No. Yo
Sorry. Answer was to fast. Maybe you are right.
Am 05.03.2017 09:21 schrieb "benjamin roth" <brs...@gmail.com>:
> No. You just change the partitioner. That's all
>
> Am 05.03.2017 09:15 schrieb "DuyHai Doan" <doanduy...@gmail.com>:
>
>> &qu
ind the user_id that corresponds to email
> 'xxx' so that your MV partitioner idea can work ?
>
>
>
> On Sun, Mar 5, 2017 at 9:05 AM, benjamin roth <brs...@gmail.com> wrote:
>
> > While I was reading the MV paragraph in your post, an idea popped up:
> >
While I was reading the MV paragraph in your post, an idea popped up:
The problem with MV inconsistencies and inconsistent range movement is that
the "MV contract" is broken. This only happens because base data and
replica data reside on different hosts. If base data + replicas would stay
on the
Hi,
Can anyone tell the difference between consistent + inconsistent range
movements?
What exactly makes them consistent or inconsistent?
In what situations can both of them occur?
It would be great to get a correct and deep understanding of that for
further MV improvments. My intuition tells me
Sorry - it was my fault. I introduced a bug and was blinded by the tons of
debug output of dtests.
2017-03-01 17:20 GMT+01:00 benjamin roth <brs...@gmail.com>:
> Hi again,
>
> I wanted to run some dtests (e.g. from materialized_views_test.py) to
> check my changes. A while ago,
Hi again,
I wanted to run some dtests (e.g. from materialized_views_test.py) to check
my changes. A while ago, everything worked fine but today I ran into a lot
of errors like this:
https://gist.github.com/brstgt/114d76769d97dc72059f9252330c4142
This happened on 2 different machines (macos +
Hi guys,
I started working on 13066. My intention is to offer a table-setting that
allows a operator to optimize MV streaming in some cases or simply "on
purpose - i know what i do".
MV write path streaming can be ommitted e.g. if:
- data is append only
- no PK is added to MV so no stale data
017-02-20 21:35 (-0800), Benjamin Roth <benjamin.r...@jaumo.com>
> wrote:
> > Stupid question:
> > Why do you rate limit a database, especially writes. Wouldn't that cause
> a
> > lot of new issues like back pressure on the rest of your system or
> timeouts
> >
any kind of support.
Thanks folks!
--
Benjamin Roth
Prokurist
Jaumo GmbH · www.jaumo.com
Wehrstraße 46 · 73035 Göppingen · Germany
Phone +49 7161 304880-6 · Fax +49 7161 304880-1
AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
For MVs regarding this threads question only the partition key matters.
Different primary keys can have the same partition key. Which is the case
in the example in your last comment.
Am 10.02.2017 20:26 schrieb "Kant Kodali" <k...@peernova.com>:
@Benjamin Roth: How do y
mutations.
2017-02-10 19:58 GMT+01:00 DuyHai Doan <doanduy...@gmail.com>:
> See my blog post to understand how MV is implemented:
> http://www.doanduyhai.com/blog/?p=1930
>
> On Fri, Feb 10, 2017 at 7:48 PM, Benjamin Roth <benjamin.r...@jaumo.com>
> wrote:
>
> > Sam
The below would be different partition keys according to you right?
>
> PRIMARY KEY ((a, b), c, d) and
> PRIMARY KEY ((a, b), d, c, e)
>
> On Fri, Feb 10, 2017 at 10:48 AM, Benjamin Roth <benjamin.r...@jaumo.com>
> wrote:
>
> > Same partition key:
> >
> >
Kodali <k...@peernova.com>:
> Okies now I understand what you mean by "same" partition key. I think you
> are saying
>
> PRIMARY KEY(col1, col2, col3) == PRIMARY KEY(col2, col1, col3) // so far I
> assumed they are different partition keys.
>
> On Fri, Fe
n additional column
> (which is allowed as of today)
>
> On Fri, Feb 10, 2017 at 10:23 AM, Benjamin Roth <benjamin.r...@jaumo.com>
> wrote:
>
> > It depends on your model.
> > If the base table + MV have the same partition key, then the MV mutations
> > are applied synch
immediately I do
> a read through MV but prior to MV getting the update from the base table.
> so there isn't any way to make sure to read after MV had been successfully
> updated. is that correct?
>
> On Fri, Feb 10, 2017 at 6:30 AM, Benjamin Roth <benjamin.r...@jaumo.com>
Hi Kant
Is it clear now?
Sorry for the confusion!
Have a nice one
Am 10.02.2017 09:17 schrieb "Kant Kodali" <k...@peernova.com>:
thanks!
On Thu, Feb 9, 2017 at 8:51 PM, Benjamin Roth <benjamin.r...@jaumo.com>
wrote:
> Yes it is
>
> Am 10.02.2017 00:46 schrieb &
cify a Consistency Level on wrote for the Materialized View. So, you
> cannot apply the R+W>RF formula.
> >
> > >Brian
> >
> >> On Feb 10, 2017, at 3:17 AM, Kant Kodali <k...@peernova.com> wrote:
> >>
> >> thanks!
> >>
> >&g
Materialized View as a table, you cannot specify
> a Consistency Level on wrote for the Materialized View. So, you cannot
> apply the R+W>RF formula.
>
> >Brian
>
> > On Feb 10, 2017, at 3:17 AM, Kant Kodali <k...@peernova.com> wrote:
> >
> > thanks!
> >
Yes it is
Am 10.02.2017 00:46 schrieb "Kant Kodali" :
> If reading from materialized view with a consistency level of quorum am I
> guaranteed to have the most recent view? other words is w + r > n contract
> maintained for MV's as well for both reads and writes?
>
> Thanks!
>
Btw this isn't the Bronx either. It's not incorrect to be polite.
Am 07.02.2017 13:45 schrieb "Bernardo Sanchez" <
bernard...@pointclickcare.com>:
> guys this isn't twitter. stop your stupid posts
>
> From: benjamin.le...@datastax.com
> Sent: February 7, 2017 7:43 AM
> To:
to
> >> > vet
> >> > > 3.10 as the last tick-tock release. Stick a fork in it, it’s
> > done. No
> >> > > more tick-tock.
> >> > >
> >> > > I further suggest that in place of tick tock we go back to our
> > old
> >> model
> >> > of
> >> > > yearly-ish releases with as-needed bug fix releases on stable
> > branches,
> >> > > probably bi-monthly. This amortizes the release validation
> > problem
> >> over
> >> > a
> >> > > longer development period. And of course we remain free to ramp
> > back
> >> up
> >> > to
> >> > > the more rapid cadence envisioned by the other proposals if we
> > increase
> >> > our
> >> > > pool of QA effort or we are able to eliminate flakey tests to
> > the point
> >> > > that a long validation process becomes unnecessary.
> >> > >
> >> > > (While a longer dev period could mean a correspondingly more
> > painful
> >> test
> >> > > validation process at the end, my experience is that most of the
> >> > validation
> >> > > cost is “fixed” in the form of flaky tests and thus does not
> > increase
> >> > > proportionally to development time.)
> >> > >
> >> > > Thoughts?
> >> > >
> >> > > --
> >> > > Jonathan Ellis
> >> > > co-founder, http://www.datastax.com
> >> > > @spyced
> >> > >
> >> >
> >>
> >
> >
> >
> >
>
--
Benjamin Roth
Prokurist
Jaumo GmbH · www.jaumo.com
Wehrstraße 46 · 73035 Göppingen · Germany
Phone +49 7161 304880-6 · Fax +49 7161 304880-1
AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
ng them
> work any better during bootstrap / etc? Any idea of fixing them is a major
> undertaking?
>
> Jon
>
> On Fri, Jan 13, 2017 at 9:39 AM Benjamin Roth <benjamin.r...@jaumo.com>
> wrote:
>
> +1 also I appreciate any effort on MV stability. It is an official 3.
+1 also I appreciate any effort on MV stability. It is an official 3.x
feature but not production ready for the masses.
Am 13.01.2017 18:34 schrieb "Jonathan Ellis" :
> +1
>
> On Fri, Jan 13, 2017 at 11:21 AM, Aleksey Yeschenko
> wrote:
>
> > Hi all!
> >
>
Grmpf! 1000+ consecutive must be wrong. I guess I mixed sth up. But it
repaired over and over again for 1 or 2 days.
2016-12-07 9:01 GMT+01:00 Benjamin Roth <benjamin.r...@jaumo.com>:
> Hi Paolo,
>
> First of all thanks for your review!
>
> I had the same concerns
behavior for MV streaming originating from
> repair.
> - Create new ticket to include only the base tables and not MVs in
> keyspace-level repair, since repairing the base already repairs the views
> to avoid people shooting themselves in the foot.
>
> Please let me know what do you t
> > https://issues.apache.org/jira/browse/CASSANDRA-6226
> > >
> > >On Mon, Dec 5, 2016 at 12:15 PM, Jan <cne...@yahoo.com.invalid> wrote:
> > >
> > >> HI Folks;
> > >> is there a way for 'Collecting slow queries' in the Apache Cassandra.
&g
/fix them!
>
> [0] https://github.com/riptano/cassandra-dtest/pull/1399
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20CASSANDRA%20AND%20labels%20%3D%20test-failure%20AND%
> 20resolution%20%3D%20unresolved
>
> --
> Kind regards,
> Michael Shuler
&
enjoy writing fixing, tweeking, tests so pinge offline or
> whatever.
>
> On Saturday, December 3, 2016, Benjamin Roth <benjamin.r...@jaumo.com>
> wrote:
>
> > Excuse me if I jump into an old thread, but from my experience, I have a
> > very clear opinion about situations li
s ways
> > >
> > > On Mon, Nov 21, 2016 at 11:31 AM sankalp kohli <kohlisank...@gmail.com
> >
> > > wrote:
> > >
> > > > Hi,
> > > > We should not cut a releases if Dtest are not passing. I won't
> > block
> >
is immense
and maybe will be a huge step to get MVs production ready.
Thank you very much,
Benjamin
-- Forwarded message --
From: Benjamin Roth <benjamin.r...@jaumo.com>
Date: 2016-11-29 17:04 GMT+01:00
Subject: Streaming and MVs
To: dev@cassandra.apache.org
I don't know wher
hat period, not only
the base table
3. Rebuild
Same like bootstrap, isn't it?
Did I forget any cases?
What do you think?
--
Benjamin Roth
Prokurist
Jaumo GmbH · www.jaumo.com
Wehrstraße 46 · 73035 Göppingen · Germany
Phone +49 7161 304880-6 · Fax +49 7161 304880-1
AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
42 matches
Mail list logo