So if my calculations are correct a terabyte sized database would require a
minimum of 15 nodes (RF = 3). That sound about right?
2000 / 400 * RF
From: aaron morton [mailto:aa...@thelastpickle.com]
Sent: Thursday, December 06, 2012 9:43 PM
To: user@cassandra.apache.org
Subject: Re: Freeing up
When you turn on compression which should be enabled, that should change quite
a bit as well. I am curious though how many nodes with RF=3 on average does
have a terabyte as you would hope it is a very low number if you plan on
scaling to a petabyte someday.
Later,
Dean
From: Poziombka, Wade
duh, sorry. That estimate is 2 TB would be 15 nodes rf = 3
From: Poziombka, Wade L [mailto:wade.l.poziom...@intel.com]
Sent: Friday, December 07, 2012 7:15 AM
To: user@cassandra.apache.org
Subject: RE: Freeing up disk space on Cassandra 1.1.5 with Size-Tiered
compaction.
So if my calculations
Good point . hadoop sprays its blocks around randomly. Thus if replication
factor nodes are down some blocks are not found. The larger the cluster the
higher chance nodes are down.
To deal with this increase rf once the cluster gets to be very large.
On Wednesday, December 5, 2012, Eric Parusel
Cassandra uses thrift messages to pass data to and from server. A batch is
just a convenient way to create such message. Nothing happens until you
send this message. Probably, this is what you call close the batch.
Thank you,
Andrey
On Fri, Dec 7, 2012 at 5:34 AM, Ben Hood 0x6e6...@gmail.com
Hi Eric,
Your concerns are perfectly valid.
We (Acunu) led the design and implementation of this feature and spent a
long time looking at the impact of such a large change.
We summarized some of our notes and wrote about the impact of virtual nodes
on cluster uptime a few months back:
Snapshots trigger a flush first, so data that's currently in the commit log
will be covered by the snapshot.
On Thu, Dec 6, 2012 at 11:52 PM, Andrey Ilinykh ailin...@gmail.com wrote:
On Thu, Dec 6, 2012 at 7:34 PM, aaron morton aa...@thelastpickle.comwrote:
For background
That's right. But when I have incremental backup on each CF gets flushed
independently. I have hot CF which gets flushed every several minutes and
regular CF which gets flushed every hour or so. They have references to
each other and data in sstables is definitely inconsistent.
On Fri, Dec 7,
On Thu, Dec 6, 2012 at 5:26 PM, Shahryar Sedghi shsed...@gmail.com wrote:
I am on 1.1.4 now (I can go to 1.1.6 if needed) and apparently it is
broken. I defined the table like this:
In general people on 1.1.x below 1.1.6 should upgrade to at least
1.1.6 ASAP, because all versions of 1.1.x
Right. I don't personally think incremental backup is useful beyond
restoring individual nodes unless none of your data happens to reference
any other rows.
On Fri, Dec 7, 2012 at 11:37 AM, Andrey Ilinykh ailin...@gmail.com wrote:
That's right. But when I have incremental backup on each CF
Agreed.
On Fri, Dec 7, 2012 at 12:38 PM, Tyler Hobbs ty...@datastax.com wrote:
Right. I don't personally think incremental backup is useful beyond
restoring individual nodes unless none of your data happens to reference
any other rows.
On Fri, Dec 7, 2012 at 11:37 AM, Andrey Ilinykh
trying to figure out if i'm doing something wrong or a bug. i am
creating a simple schema, inserting a timestamp using ISO8601 format,
but when retrieving the timestamp, the timezone is displayed
incorrectly. i'm inserting using GMT, the result is shown with
+, but the time is for my local
With 1.1.5, the TS is displayed with the local timezone and seems correct.
cqlsh:bat create table test (id uuid primary key, ts timestamp );
cqlsh:bat insert into test (id,ts) values (
'89d09c88-40ac-11e2-a1e2-6067201fae78', '2012-12-07T10:00:00-');
cqlsh:bat select * from test;
id
13 matches
Mail list logo
