And if we want to add a new DC ? I suppose we should add all nodes and alter
the replication factor of the keyspace after that, but if anyone can confirm it
and maybe give me some tips ?
FYI ,we have 2 DCs with between 10 and 20 nodes in each and a 2To database
(local replication factor
Hi Paul,
Sorry to hear you're having a low point.
We ended up not using the collection features of 1.2.
Instead storing a compressed string containing the map and handling client
side.
We only have fixed schema short rows so no experience with large row
compaction.
File
Hi Paul,
Concerning large rows which are not compacting, I've probably managed to
reproduce your problem.
I suppose you're using collections, but also TTLs ?
Anyway, I opened an issue here :
https://issues.apache.org/jira/browse/CASSANDRA-5799
Hope this helps
2013/7/24 Christopher Wirt
From my limited experience I think Cassandra is a dangerous choice for
an young limited funding/experience start-up expecting to scale fast.
Its not dangerous, just do not try to be smart and follow what other big
cassandra users like twitter, netflix, facebook, etc are using. If they
are
Hi,
I am Jan Algermissen (REST-head, freelance programmer/consultant) and
Cassandra-newbie.
I am looking at Cassandra for an application I am working on. There will be a
max. of 10 Million items (Texts and attributes of a retailer's products) in the
database. There will occasional writes
Hi,
second question:
is it recommended to set up Cassandra using 'RAID-ed' disks for per-node
reliability or do people usually just rely on having the multiple nodes anyway
- why bother with replicated disks?
Jan
From:
http://www.datastax.com/docs/1.2/cluster_architecture/cluster_planning
* RAID on data disks: It is generally not necessary to use RAID for the
following reasons:
* Data is replicated across the cluster based on the replication factor
you've chosen.
* Starting in version 1.2,
On 24 July 2013 15:36, Jan Algermissen jan.algermis...@nordsc.com wrote:
is it recommended to set up Cassandra using 'RAID-ed' disks for per-node
reliability or do people usually just rely on having the multiple nodes
anyway - why bother with replicated disks?
It's not necessary, due to
You have lot of questions there so I can't answer all but for the following:
*Can a user of the system define new jobs in an ad-hoc fashion (like a
query) or do map reduce jobs need to be prepared by a developer (e.g. in
RIAK you do a developer to compile-in the job when you need the perormance
of
Same type of error, but I'm not currently using TTL's. I am, however,
generating a lot of tombstones as I add elements to collections….
On Jul 24, 2013, at 6:42 AM, Fabien Rousseau fab...@yakaz.com wrote:
Hi Paul,
Concerning large rows which are not compacting, I've probably managed to
http://wiki.apache.org/cassandra/FAQ#unsubscribe
unsubscribe
Hi Chris,
Thanks for the response!
What kind of challenges did you run into that kept you from using collections?
I currently and running 4 physical nodes, same as I was with case 1.1.6. I'm
using size tiered compaction. Would changing to level tiered with a large
minimum make a big
Hey Radim,
I knew that it would take a while to stabilize, which is why I waited 1/2 a
year before giving it a go. I guess I was just surprised that 6 months wasn't
long enough…
I'll have to look at the differences between 1.2 and 2.0. Is there a good
resource for checking that?
Your
We found the performance of collections to not be great and needed a quick
solution.
We've always used the levelled compaction strategy where you declare a
sstable_size_in_mb not min_compaction_threshold. Much better for our use
case.
unsubscribe
Would it possible to delete this row and reinsert this row? By the way, how
large is that one row?
Jason
On Wed, Jul 24, 2013 at 9:23 AM, Paul Ingalls paulinga...@gmail.com wrote:
I'm getting constant exceptions during compaction of large rows. In fact,
I have not seen one work, even
Same thing here... Since #5677 seems to affect a lot of users what do
you think about releasing a version 1.2.6.1? I can patch myself, yeah,
but do I want to push this into production? Hmm...
Am 24.07.2013 18:58, schrieb Paul Ingalls:
Hey Radim,
I knew that it would take a while to
On Wed, Jul 24, 2013 at 11:37 AM, Steffen Rusitschka r...@megazebra.comwrote:
Same thing here... Since #5677 seems to affect a lot of users what do you
think about releasing a version 1.2.6.1? I can patch myself, yeah, but do I
want to push this into production? Hmm...
A better solution
That one is documented --
http://www.datastax.com/documentation/cassandra/1.2/index.html#cassandra/operations/ops_add_dc_to_cluster_t.html
On Wed, Jul 24, 2013 at 3:33 AM, Cyril Scetbon cyril.scet...@free.frwrote:
And if we want to add a new DC ? I suppose we should add all nodes and
alter
cas 2.0b2
https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob_plain;f=CHANGES.txt;hb=refs/tags/2.0.0-beta2-tentative
and as a small startup time is our most valuable resource…
use technology you are most familiar with.
Hi all,
I know the subject is not saying much but this is what I'm experiencing now
with my cluster.
After some years without any problem now I'm experiencing problems with
counters but, the most serious problem, is data loss immediately after a read.
I have some webservices that I use to
Sorry I forgot to tell
Apache Cassandra 1.07 on Ubuntu 10.04
The data that are disappearing are not Counters but common Rows
Messaggio originale
Da: cbert...@libero.it
Data: 24/07/2013 22.34
A: user@cassandra.apache.org
Ogg: Data disappear immediately after reading?
Hi all,
I know the
Carlo,
Do you read/write with the consistency levels according to your needs [1]?
Have you tried to see if it happens when using the cassandra-cli to get
that data?
[1] http://wiki.apache.org/cassandra/ArchitectureOverview
On Wed, Jul 24, 2013 at 5:34 PM, cbert...@libero.it
On Wed, Jul 24, 2013 at 1:34 PM, cbert...@libero.it cbert...@libero.itwrote:
After some years without any problem now I'm experiencing problems with
[not-actually-counters] but, the most serious problem, is data loss
immediately after a read.
Are secondary indexes involved? There are various
Hey Chris,
so I just tried dropping all my data and converting my column families to use
leveled compaction. Now I'm getting exceptions like the following once I start
inserting data. Have you seen these?
ERROR 13:13:25,616 Exception in thread Thread[CompactionExecutor:34,1,main]
It is pretty much every row that hits the large threshold. I don't think I can
delete every row that hits that…
you can see the db size in the stack trace, do you want a different type of
size?
On Jul 24, 2013, at 11:07 AM, Jason Wee peich...@gmail.com wrote:
Would it possible to delete
Hi all,
This morning I increased the SSTable size for one of my LCS via an alter
command and saw at least one compaction run (I did not trigger a compaction via
nodetool nor upgrades stables nor removing the .json file). But so far my data
sizes appear the same at the default 5 MB (see
what is output of show keyspaces from cassandra-cli, did you see the new value?
Compaction Strategy:
org.apache.cassandra.db.compaction.LeveledCompactionStrategy
Compaction Strategy Options:
sstable_size_in_mb: XXX
From: Keith Wright
That does not measure what the servers are doing though.
Track the number of reads per CF, it's exposed with nodetool cfstats and is in
ops centre as well.
Cheers
-
Aaron Morton
Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On 24/07/2013, at
There was no error stack, just that line in the log.
It's odd that the stack is not there.
This is an unhanded exception when running compaction. It may be related to the
assertions.
If you can reproduce it please raise a ticket at
https://issues.apache.org/jira/browse/CASSANDRA
Cheers
Too bad Rainbird isn't open sourced yet!
It's been 2 years, I would not hold your breath.
Remembered there are two time series open source projects out there
https://github.com/deanhiller/databus
https://github.com/Pardot/Rhombus
Cheers
-
Aaron Morton
Cassandra Consultant
New
I was watching some videos from the C* summit 2013 and I recall many people
saying that if you can some up with a design where you don't preform updates
on rows, that would make things easier (I believe it was because there would
be less compaction).
No entirely true.
There will always be
I guess my question #1 still there, that does this query create a big load on
the initial node that receive such request because it still has to wait for
all the result coming back from other nodes before returning to client?
sort of.
The coordinator always has to wait. Only one node will
Is it possible to reduce the response time (by tuning, adding more nodes) to
make a result available within a couple of minutes? Or will there most
certainly be a gap of 10 minutes or so and more?
Yes.
More nodes will split the task up and it will run faster.
How long it takes depends on
What sort of read are you making to get the data ?
There was a bug about secondary indexes being dropped if TTL was used
https://issues.apache.org/jira/browse/CASSANDRA-5079
Cheers
-
Aaron Morton
Cassandra Consultant
New Zealand
@aaronmorton
http://www.thelastpickle.com
On
35 matches
Mail list logo
