you'll get "column name must not be empty" if you specify a list of
columns, rather than a slicepredicate.
it sounds like you might be trying to specify slices, of a set of
supercolumns? you can't do that; you can specify slices of a single
columnparent. if that is the CF then you get multiple s
That would be surprising (and it is not what you said in the first
message). I suspect something is wrong with your test methodology.
On Mon, Jun 7, 2010 at 11:23 AM, Arya Goudarzi wrote:
> But I am not comparing reading 1 column vs 100 columns. I am comparing
> reading of 100 columns in loop i
Would you please tell the performance you measured? Although I don't
have any experience relating to flash-drive, I'm very interested in
switching to SSD.
So far from my benchmark, the bottleneck of cassandra just doesn't seem
to be disk_io, but memory.
Kevin Yuan,
Supertool Corp.
www.yuan-s
I have a structure like this:
CF:"Status"
{
Row("Component42")
{
SuperColumn(1275948636203) (epoch millis)
{
sub columns...
}
}
}
The supercolumns are dropped in periodically by system A, which is using Hector.
System B uses a lightweight perl/Thrift client to reduce proce
On Mon, Jun 7, 2010 at 3:09 PM, Ian Soboroff wrote:
> I was going to say, if ordered trees are your problem, Cassandra is not your
> solution. Try building something with Berkeley DB.
Also -- while there are no official plans for this, there have been
discussions on Voldemort list, wrt. possible
I was going to say, if ordered trees are your problem, Cassandra is
not your solution. Try building something with Berkeley DB.
Ian
On Jun 7, 2010, at 17:30, Tatu Saloranta wrote:
On Mon, Jun 7, 2010 at 12:06 AM, David Boxenhorn
wrote:
I wonder if there is a robust algorithm for maintain
Thanks. Hopefully one of our phrasings helped someone :)
--
/ Peter Schuller
On Mon, Jun 7, 2010 at 12:06 AM, David Boxenhorn wrote:
> I wonder if there is a robust algorithm for maintaining b-trees that doesn't
> require atomicity? How about if you create the three new super columns
> first, then attach them to the parent, then delete the old super column? If
> it fails,
It should take roughly 30 seconds (please clarify--not minutes) to
join the cluster.
Gary.
On Mon, Jun 7, 2010 at 08:23, Stephan Pfammatter
wrote:
> I still have one open issue: My cluster has only 3 local nodes with 1 CF (5
> rows).
> The initial start works fine. I can see the replicated dat
On Jun 7, 2010, at 6:05 PM, Benjamin Black wrote:
> There is no 'master' so all copies are replicas. RF=1 means 1 node
> has the data, RF=2 means 2 do, etc.
>
Okay, thanks (and thanks to Ran also).
I guess 0 doesn't make sense then, and that RF=1 is a bad idea if I want some
protection again
But I am not comparing reading 1 column vs 100 columns. I am comparing reading
of 100 columns in loop iterations (100 consecutive calls) vs reading all 100 in
batch in one call. Doing the loop is faster than doing the batch call. Are you
saying this is not surprising?
- Original Message --
Reads, ok.. What about Compactions? Is the cost of compacting going to be
ever increasing with the number of columns?
On Sat, Jun 5, 2010 at 7:30 AM, Jonathan Ellis wrote:
> #16 is very simple: it allows you to make very large rows. That is all.
>
> Other things being equal, doing reads from
There is no 'master' so all copies are replicas. RF=1 means 1 node
has the data, RF=2 means 2 do, etc.
On Mon, Jun 7, 2010 at 4:16 AM, Per Olesen wrote:
> Hi,
>
> I am unclear about what the ReplicationFactor value means.
>
> Does RF=1 mean that there is only one single node that has the data in
Hey All,
First of all I'll start with some questions on the default behavior of
get_range_slices method defined in the thrift API.
Given a keyrange with start-key "kstart" and end-key "kend", assuming
kstartkend? Will I get an empty
result list?
Secondly, I have use case where I need to access t
Hi everyone.
I wanted to know if anybody has had any experience with cassandra on
flash storage. At work we have a cluster of 6 machines running
Tokyotyrant on flash-io drives (320GB) each, but performance is not what
we expected, and we'are having some issues with replication and
availabilit
I still have one open issue: My cluster has only 3 local nodes with 1 CF (5
rows).
The initial start works fine. I can see the replicated data and can do all
admin tasks I want, successfully.
Now I'm simulating a node failure by stopping Cassandra. I remove
(a) commit log
(b) content in system
to have two copies you need RF=2.
RF=0 doesn't make sense as far as I understand it.
On Mon, Jun 7, 2010 at 2:16 PM, Per Olesen wrote:
> Hi,
>
> I am unclear about what the ReplicationFactor value means.
>
> Does RF=1 mean that there is only one single node that has the data in the
> cluster (ac
Hi,
I am unclear about what the ReplicationFactor value means.
Does RF=1 mean that there is only one single node that has the data in the
cluster (actually no replication), or, does it mean, that there are two copies
of the data - one "actual" and one "replica" (as in "replicated one time")?
I
> Ben Browning wrote...
>
>[snip/]
>...
> I've been able to read columns out of Cassandra at
>an order of magnitude higher than what you're seeing here but there
>are too many variables to directly compare.
I've been reading with ConsistencyLevel QUORUM in my timings.
If I change to Consis
Oops. No crawler. My mistake.
On Mon, Jun 7, 2010 at 10:56 AM, David Boxenhorn wrote:
> Is there a way to not use the Solr's web crawler (we have our own) and just
> use Solr for indexing and serving content?
>
> On Mon, Jun 7, 2010 at 12:51 AM, Abhi Yerra wrote:
>
>> I created a web crawler us
The next time you encounter such a problem, check with JMX
whether any compactions are pending on the sending node.
Compaction and anticompaction are run in the same stage IIRC,
so when a long-running compaction is in progress, all anticompaction
on the same node has to wait.
Martin
> -Origi
Is there a way to not use the Solr's web crawler (we have our own) and just
use Solr for indexing and serving content?
On Mon, Jun 7, 2010 at 12:51 AM, Abhi Yerra wrote:
> I created a web crawler using Cassandra as the datastore and push to a
> bunch of Solr shards. It works well.
>
> -Abhi
>
>
How big you data is? Try to zip the content before store it, text can
get a good zip rate.
On Mon, Jun 7, 2010 at 12:13 PM, Jared Laprise wrote:
> I just experienced a weird issue where writing a large amount of text to a
> column caused my script to crash and hang without any error output. I’m
>
I wonder if there is a robust algorithm for maintaining b-trees that doesn't
require atomicity? How about if you create the three new super columns
first, then attach them to the parent, then delete the old super column? If
it fails, it would leave junk, but that could be cleaned up every once in a
25 matches
Mail list logo
