I found their YouTube video, Machine Learning & The future of DevOps – An Intro
to Vorstella: https://www.youtube.com/watch?v=YZ5_LAXvUUo
From: Kenneth Brotman [mailto:kenbrot...@yahoo.com.INVALID]
Sent: Tuesday, March 05, 2019 11:50 AM
To: user@cassandra.apache.org
Subject: RE: Looking
Hi Bobbie,
as Kenneth already mentioned, you should model your schema based on what
queries you are expecting to do and read related literature. From what I
see your table is named "customer_sensor_tagids" so its quite possible you
would have tagids as a part of primary key? Something like:
You definitely don’t need a secondary index. A MV might be the answer.
How many tagids does a sensor have ?
Do you have to use a collection for tagids?
How many sensors would you expect to have a particular tagid?
Would you know the customerid and sensorid and be able to specify that in
Hi Bobbie,
You’re not giving enough information to model the data. With Cassandra it’s
based on the queries you are going to need. This link to Jeffrey Carpenter’s
book, Cassandra the Definitive Guide, Chapter 5, which is on how to do data
modeling for Cassandra, should be of help to you:
Hi
Could you help modelling this usecase
I have below table ..I will update tagid's columns set(bigit) based on
PK. I have created the secondary index column on tagid to query like below..
Select * from keyspace.customer_sensor_tagids where tagids CONTAINS
11358097;
this query is doing
Hayato,
I agree with what you are addressing as I’ve always thought the big elephant in
the room regarding Cassandra was that you had to use all these other tools,
each of which requires updating, configuring changes, and that too much
attention had to be paid to all those other tools
We probably will, that'll come soon-ish (a couple of weeks perhaps). Right
now we're limited by who we can engage with in order to collect feedback.
On Tue, Mar 5, 2019 at 11:34 AM Kenneth Brotman
wrote:
> Simulators will never get you there. Why don’t you let everyone plug in
> to the NOC in
Getting people to send data to us can be a little bit of a PITA, but it's
doable. We've got data from regulated/secure environments streaming in.
None of the data we collect is a risk, but the default is to say no and
you've got to overcome that barrier. We've been through the audit a bunch
of
Matt,
Do you anticipate having trouble getting clients to allow the collector to send
data up to your NOC? Wouldn’t a lot of companies be unable or uneasy about
that?
Your ML can only work if it’s got LOTS of data from many different scenarios.
How are you addressing that? How are
I see they have a website now at https://vorstella.com/
From: Matt Stump [mailto:mrevilgn...@gmail.com]
Sent: Friday, February 22, 2019 7:56 AM
To: user
Subject: Re: Looking for feedback on automated root-cause system
For some reason responses to the thread didn't hit my work email, I
Thanks jeff,
I will look at app configuration, that particular query will return some
where between 20k - 50k rows
Regards
Pranay
On Tue, Mar 5, 2019, 9:43 AM Jeff Jirsa wrote:
>
>
> > On Mar 5, 2019, at 7:08 AM, Pranay akula
> wrote:
> >
> > When a co-ordinator node request a replica node
> On Mar 5, 2019, at 7:08 AM, Pranay akula wrote:
>
> When a co-ordinator node request a replica node for data will it be requested
> over port 9042 or 7000
7000
>
> Recently I ran a query with allow filtering in lower environments as soon as
> I ran saw a spike in NTP active threads. I
When a co-ordinator node request a replica node for data will it be
requested over port 9042 or 7000
Recently I ran a query with allow filtering in lower environments as soon
as I ran saw a spike in NTP active threads. I was trying to understand was
that related to that query or not was app doing
Hi Kenneth,
Thanks for your interest to help. I had to take a decision quick because it
was a production cluster. So, long story short, I let the cluster finish
the decommission process before touching it. When decommissioned node left
the cluster I did a rolling restart and the nodes start
Awesome
Thank you very much
Cheers
Jean Carlo
"The best way to predict the future is to invent it" Alan Kay
On Tue, Mar 5, 2019 at 2:47 PM Jeff Jirsa wrote:
>
>
>
> > On Mar 5, 2019, at 5:32 AM, Jean Carlo
> wrote:
> >
> > Hello Jeff, thank you for the answer. But what will be the
Versions 2.0 and 2.1 were generally very stable, so I can understand a
reticence to move when there are so many other things competing for time and
attention.
Sean Durity
From: shalom sagges
Sent: Monday, March 04, 2019 4:21 PM
To: user@cassandra.apache.org
Subject: [EXTERNAL] Re: A
> On Mar 5, 2019, at 5:32 AM, Jean Carlo wrote:
>
> Hello Jeff, thank you for the answer. But what will be the advantage of
> GossipingPropertyFileSnitch over Ec2MultiRegionSnitch exactly ? The
> possibility to name the DCs ?
Yes
And if you ever move out of aws you won’t have any
Hello Jeff, thank you for the answer. But what will be the advantage of
GossipingPropertyFileSnitch over Ec2MultiRegionSnitch exactly ? The
possibility to name the DCs ?
And another question, are you telling me that GossipingPropertyFileSnitch
works fine in AWS and there is no need of Ec2Snitch?
Ec2 multi should work fine in one region, but consider using
GossipingPropertyFileSnitch if there’s even a chance you’ll want something
other than AWS regions as dc names - multicloud, hybrid, analytics DCs, etc
--
Jeff Jirsa
> On Mar 5, 2019, at 5:12 AM, Jean Carlo wrote:
>
> Hello
Hello everyone, I am preparing a cluster single dc in AWS. For the moment
there is not need to have a Multi DC cluster but I would like to avoid a
Snitch migration in the future. I would like to know if
Ec2MultiRegionSnitch works also for cluster single DC. Or The migration
Ec2Snitch to
20 matches
Mail list logo
