Things a changing in v0.7, the row keys are byte arrays.
Not sure I understand your other concerns.
Aaron
On 25 Sep 2010, at 08:10, Christian Decker wrote:
> Thanks for your quick answer, I think I'll use an affix to sort of cast the
> keys, ranges and others from their textual representatio
Looking further, I would expect your 36000 writes/sec to trigger a
memtable flush every 8-9 seconds (which is already crazy), but you are
actually flushing them every ~1.7 seconds, leading me to believe you
are writing a _lot_ faster than you think you are.
INFO [ROW-MUTATION-STAGE:21] 2010-09-24
The log posted shows _10_ pending in MPF stage, and the errors show
repeated failures trying to flush memtables at all:
INFO [GC inspection] 2010-09-24 13:16:11,281 GCInspector.java (line
156) MEMTABLE-POST-FLUSHER 110
You are also flushing _really_ small memtables to disk (l
On Sat, Sep 25, 2010 at 7:50 AM, Alvin UW wrote:
> Hello,
>
> 1.Does the current index support Super CF?
No.
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of Riptano, the source for professional Cassandra support
http://riptano.com
> My rows consist of only 60 columns and these 60 columns looks like this:
> ColumnName: Sensor59 -- Value: 434.2647915698039 -- TTL: 10800
The hotspot error log indicates the OOM is actually the result of a
*stack* overflow rather than a heap overflow. While the first OOM in
system.log indicates
Hello,
1.Does the current index support Super CF?
2. Does the system treat the index as the same as a common CF?
If not, what's the main difference between index and common CF?
Thanks
Alvin
Courtney this certainly sounds interesting and as Nate suggested we're
always looking for valuable contributions.
A few things to keep in mind:
- I'm curious, as Lucas has asked - is it possible to create an
efficient graph API over cassandra and what are the tradeoffs?
- If the API is general enou
