UNSUBSCRIBE
Because the data format has changed, you’ll need to read it out and write it
back in again.
This means using either a driver (java, python, c++, etc), or something like
spark.
In either case, split up the token range so you can parallelize it for
significant speed improvements.
From:
Hi All:
We have a table defined only one partition key and some cluster key.
CREATE TABLE test1 (
attribute text,
partner text,
app text,
"timestamp" bigint,
event text,
PRIMARY KEY ((attribute), partner, app, "timestamp")
)
And now we want to split original test1 table to 3
Well...
I think that pretty much is showing the problem. The problem I'd say is a
bad data model. Your read query is perfect, it hits a single partition and
that's the best situation, but on the other hand, it turns out that there
are one or two huge partitions and fully reading them is extremely
Hi All ,
Please let me know if there are any disadvantages of using Object Mapping
instead of writing direct CQL queries.
Ashish
Hi!
I'm using Cassandra 2.2 for my home-grown SAAS and currently
evaluating prospect of adding columns to tables on user requests.
So I have a couple of questions regarding ALTER TABLE statement:
1) how adding/removing columns implemented on cluster level?
2) in case of column addition how soon
Are the clocks synchronized across the cluster - probably, but I thought I
would ask :)
On Wed, Oct 21, 2015 at 3:35 AM, Brice Figureau <
brice+cassan...@daysofwonder.com> wrote:
> Hi,
>
> On 20/10/2015 19:48, Carlos Alonso wrote:
> > I think also having the output of cfhistograms could help.
Hi,
On 20/10/2015 19:48, Carlos Alonso wrote:
> I think also having the output of cfhistograms could help. I'd like to
> know how many sstables are being hit during reads.
Ooops, my bad I thought you mentioned proxyhistograms.
Here's the worst node cfhistograms:
nodetool cfhistograms akka
