You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Mario Micklisch <ma...@hpm-kommunikation.de> on 2011/06/04 19:27:46 UTC
problems with many columns on a row
Hello there!
I have ran into a strange problem several times now and I wonder if someone
here has an solution for me:
For some of my data I want to keep track all the ID's I have used. To do
that, I am putting the ID's as column into rows.
At first I wanted to put all ID's into one row (because the limit of 2
billion column seemed high enough) and then it happened:
For some reason I was no longer able to remove or update existing rows or
column. Adding new rows and removing them was possible, but write access to
the older rows did not longer work.
I have restarted the cluster, didn't help either. Only truncating the column
family helped.
Because this happened several times after creating rows with 5.000+ columns
I decided to reduce the number of columns to a maximum of 1.000 per row and
everything is now working perfectly.
I am working on version 0.8-rc1 and for testing purpose I am running only
one node with the default settings.
My questions are:
1) Because 0.8 is not marked as stable, is this a known problem?
2) Is there something in the configuration I need to change to handle a
bigger number of columns?
3) Can I check on the cassandra-cli why updates are failing? (there were no
error messages when trying deletes with the CLI manually)
4) Is there a recommended number of columns? (I guess this only depends on
my systems memory?)
Thanks to everyone who took some time to read!
Mario
Re: problems with many columns on a row
Posted by aaron morton <aa...@thelastpickle.com>.
Can you upgrade to the official 0.8 release and try again with logging set to DEBUG ?
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 6 Jun 2011, at 23:41, Mario Micklisch wrote:
> :-)
>
> There are several data Files:
>
> # ls -al *-Data.db
>
>
> -rw-r--r-- 1 cassandra cassandra 53785327 2011-06-05 14:44 CFTest-g-21-Data.db
> -rw-r--r-- 1 cassandra cassandra 56474656 2011-06-05 18:04 CFTest-g-38-Data.db
> -rw-r--r-- 1 cassandra cassandra 21705904 2011-06-05 20:02 CFTest-g-45-Data.db
> -rw------- 1 cassandra cassandra 3720201 2011-06-05 20:13 CFTest-g-46-Data.db
> -rw-r--r-- 1 cassandra cassandra 135684874 2011-06-05 20:14 CFTest-g-47-Data.db
> -rw-r--r-- 1 cassandra cassandra 4347351 2011-06-05 20:35 CFTest-g-48-Data.db
> -rw-r--r-- 1 cassandra cassandra 4341698 2011-06-05 20:56 CFTest-g-49-Data.db
> -rw-r--r-- 1 cassandra cassandra 4350949 2011-06-05 21:17 CFTest-g-50-Data.db
> -rw-r--r-- 1 cassandra cassandra 4346066 2011-06-05 21:38 CFTest-g-51-Data.db
> -rw-r--r-- 1 cassandra cassandra 17384858 2011-06-05 21:39 CFTest-g-52-Data.db
> -rw-r--r-- 1 cassandra cassandra 4342983 2011-06-05 21:59 CFTest-g-53-Data.db
> -rw-r--r-- 1 cassandra cassandra 4339771 2011-06-05 22:21 CFTest-g-54-Data.db
> -rw-r--r-- 1 cassandra cassandra 4349165 2011-06-05 22:42 CFTest-g-55-Data.db
> -rw-r--r-- 1 cassandra cassandra 30415571 2011-06-05 22:42 CFTest-g-56-Data.db
>
>
> Cheers,
> Mario
>
>
>
>
> 2011/6/6 aaron morton <aa...@thelastpickle.com>
> Ops, I misread "150 GB" in one of your earlier emails as "150 MB" so forget what I said before. You have loads of free space :)
>
> How many files do you have in your data directory ? If it's 1 then that log message was a small bug, that has been fixed.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 5 Jun 2011, at 23:51, Mario Micklisch wrote:
>
>> I found a patch for the php extension here:
>>
>> https://issues.apache.org/jira/browse/THRIFT-1067
>>
>> … this seemed to fix the issue. Thank you Jonathan and Aaron for taking time to provide me with some help!
>>
>> Regarding the compaction I would still love to hear your feedback on how to configure Cassandra accordingly.
>>
>> Here are my facts again:
>>
>> Data size on disk: ~1GB
>> Data Volume: ~150GB free storage
>> OS Volume: ~3GB free storage
>>
>> Tried:
>> nodetool --host localhost compact
>>
>> The logfiles said:
>> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,346 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,348 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,349 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,366 CompactionManager.java (line 539) Compacting Major: [SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-81-Data.db'), SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-80-Data.db'), SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-79-Data.db')]
>> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,502 CompactionIterator.java (line 186) Major@23231510(system, LocationInfo, 386/689) now compacting at 16777 bytes/ms.
>> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,713 CompactionManager.java (line 603) Compacted to /mnt/cassandra/data/system/LocationInfo-tmp-g-82-Data.db. 689 to 446 (~64% of original) bytes for 3 keys. Time: 346ms.
>> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>>
>> # du -hs /mnt/cassandra/
>> 886M /mnt/cassandra/
>>
>> # df -H
>> Filesystem Size Used Avail Use% Mounted on
>> /dev/sda1 8.5G 4.9G 3.6G 49% /
>> /dev/sda2 158G 1.2G 149G 1% /mnt
>>
>>
>> # nodetool --host localhost info
>> 130915841875673808436922706546793999597
>> Gossip active : true
>> Load : 1.48 MB
>> Generation No : 1307273982
>> Uptime (seconds) : 383
>> Heap Memory (MB) : 89.59 / 822.00
>>
>>
>> Thank you,
>> Mario
>>
>>
>>
>> 2011/6/5 Mario Micklisch <ma...@hpm-kommunikation.de>
>> I tracked down the timestamp submission and everything was fine within the PHP Libraries.
>>
>> The thrift php extension however seems to have an overflow, because it was now setting now timestamps with also negative values ( -1242277493 ). I disabled the php extension and as a result I now got correct microsecond timestamps: 1307270937122897
>>
>> I was using the latest version from http://www.apache.org/dist/thrift/0.6.1/ to build the extension without using any special parameters (just ./configure --enable-gen-php=yes and make install).
>>
>> Downloaded and re-compiled it, without any change. I can also see no compile parameters to set which might help.
>>
>>
>>
>> Any advise where to go from here?
>>
>>
>>
>> Thanks so far!
>>
>> Mario
>>
>>
>
>
Re: problems with many columns on a row
Posted by Mario Micklisch <ma...@hpm-kommunikation.de>.
:-)
There are several data Files:
# ls -al *-Data.db
-rw-r--r-- 1 cassandra cassandra 53785327 2011-06-05 14:44
CFTest-g-21-Data.db
-rw-r--r-- 1 cassandra cassandra 56474656 2011-06-05 18:04
CFTest-g-38-Data.db
-rw-r--r-- 1 cassandra cassandra 21705904 2011-06-05 20:02
CFTest-g-45-Data.db
-rw------- 1 cassandra cassandra 3720201 2011-06-05 20:13
CFTest-g-46-Data.db
-rw-r--r-- 1 cassandra cassandra 135684874 2011-06-05 20:14
CFTest-g-47-Data.db
-rw-r--r-- 1 cassandra cassandra 4347351 2011-06-05 20:35
CFTest-g-48-Data.db
-rw-r--r-- 1 cassandra cassandra 4341698 2011-06-05 20:56
CFTest-g-49-Data.db
-rw-r--r-- 1 cassandra cassandra 4350949 2011-06-05 21:17
CFTest-g-50-Data.db
-rw-r--r-- 1 cassandra cassandra 4346066 2011-06-05 21:38
CFTest-g-51-Data.db
-rw-r--r-- 1 cassandra cassandra 17384858 2011-06-05 21:39
CFTest-g-52-Data.db
-rw-r--r-- 1 cassandra cassandra 4342983 2011-06-05 21:59
CFTest-g-53-Data.db
-rw-r--r-- 1 cassandra cassandra 4339771 2011-06-05 22:21
CFTest-g-54-Data.db
-rw-r--r-- 1 cassandra cassandra 4349165 2011-06-05 22:42
CFTest-g-55-Data.db
-rw-r--r-- 1 cassandra cassandra 30415571 2011-06-05 22:42
CFTest-g-56-Data.db
Cheers,
Mario
2011/6/6 aaron morton <aa...@thelastpickle.com>
> Ops, I misread "150 GB" in one of your earlier emails as "150 MB" so forget
> what I said before. You have loads of free space :)
>
> How many files do you have in your data directory ? If it's 1 then that log
> message was a small bug, that has been fixed.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 5 Jun 2011, at 23:51, Mario Micklisch wrote:
>
> I found a patch for the php extension here:
>
> https://issues.apache.org/jira/browse/THRIFT-1067
>
> … this seemed to fix the issue. Thank you Jonathan and Aaron for taking
> time to provide me with some help!
> Regarding the compaction I would still love to hear your feedback on how to
> configure Cassandra accordingly.
>
> Here are my facts again:
>
> Data size on disk: ~1GB
> Data Volume: ~150GB free storage
> OS Volume: ~3GB free storage
>
> Tried:
> nodetool --host localhost compact
>
> The logfiles said:
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,346 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,348 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,349 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,366 CompactionManager.java
> (line 539) Compacting Major:
> [SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-81-Data.db'),
> SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-80-Data.db'),
> SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-79-Data.db')]
> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,502
> CompactionIterator.java (line 186) Major@23231510(system, LocationInfo,
> 386/689) now compacting at 16777 bytes/ms.
> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,713 CompactionManager.java
> (line 603) Compacted to
> /mnt/cassandra/data/system/LocationInfo-tmp-g-82-Data.db. 689 to 446 (~64%
> of original) bytes for 3 keys. Time: 346ms.
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
>
> # du -hs /mnt/cassandra/
> 886M /mnt/cassandra/
>
> # df -H
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda1 8.5G 4.9G 3.6G 49% /
> /dev/sda2 158G 1.2G 149G 1% /mnt
>
>
> # nodetool --host localhost info
> 130915841875673808436922706546793999597
> Gossip active : true
> Load : 1.48 MB
> Generation No : 1307273982
> Uptime (seconds) : 383
> Heap Memory (MB) : 89.59 / 822.00
>
>
> Thank you,
> Mario
>
>
>
> 2011/6/5 Mario Micklisch <ma...@hpm-kommunikation.de>
>
>> I tracked down the timestamp submission and everything was fine within the
>> PHP Libraries.
>>
>> The thrift php extension however seems to have an overflow, because it was
>> now setting now timestamps with also negative values ( -1242277493 ). I
>> disabled the php extension and as a result I now got correct microsecond
>> timestamps: 1307270937122897
>>
>> I was using the latest version from
>> http://www.apache.org/dist/thrift/0.6.1/ to build the extension without
>> using any special parameters (just ./configure --enable-gen-php=yes and
>> make install).
>>
>> Downloaded and re-compiled it, without any change. I can also see no
>> compile parameters to set which might help.
>>
>>
>> Any advise where to go from here?
>>
>>
>> Thanks so far!
>>
>> Mario
>>
>>
>
Re: problems with many columns on a row
Posted by aaron morton <aa...@thelastpickle.com>.
Ops, I misread "150 GB" in one of your earlier emails as "150 MB" so forget what I said before. You have loads of free space :)
How many files do you have in your data directory ? If it's 1 then that log message was a small bug, that has been fixed.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 5 Jun 2011, at 23:51, Mario Micklisch wrote:
> I found a patch for the php extension here:
>
> https://issues.apache.org/jira/browse/THRIFT-1067
>
> … this seemed to fix the issue. Thank you Jonathan and Aaron for taking time to provide me with some help!
>
> Regarding the compaction I would still love to hear your feedback on how to configure Cassandra accordingly.
>
> Here are my facts again:
>
> Data size on disk: ~1GB
> Data Volume: ~150GB free storage
> OS Volume: ~3GB free storage
>
> Tried:
> nodetool --host localhost compact
>
> The logfiles said:
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,346 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,348 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,349 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,366 CompactionManager.java (line 539) Compacting Major: [SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-81-Data.db'), SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-80-Data.db'), SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-79-Data.db')]
> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,502 CompactionIterator.java (line 186) Major@23231510(system, LocationInfo, 386/689) now compacting at 16777 bytes/ms.
> INFO [CompactionExecutor:2] 2011-06-05 11:44:39,713 CompactionManager.java (line 603) Compacted to /mnt/cassandra/data/system/LocationInfo-tmp-g-82-Data.db. 689 to 446 (~64% of original) bytes for 3 keys. Time: 346ms.
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
> ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>
> # du -hs /mnt/cassandra/
> 886M /mnt/cassandra/
>
> # df -H
> Filesystem Size Used Avail Use% Mounted on
> /dev/sda1 8.5G 4.9G 3.6G 49% /
> /dev/sda2 158G 1.2G 149G 1% /mnt
>
>
> # nodetool --host localhost info
> 130915841875673808436922706546793999597
> Gossip active : true
> Load : 1.48 MB
> Generation No : 1307273982
> Uptime (seconds) : 383
> Heap Memory (MB) : 89.59 / 822.00
>
>
> Thank you,
> Mario
>
>
>
> 2011/6/5 Mario Micklisch <ma...@hpm-kommunikation.de>
> I tracked down the timestamp submission and everything was fine within the PHP Libraries.
>
> The thrift php extension however seems to have an overflow, because it was now setting now timestamps with also negative values ( -1242277493 ). I disabled the php extension and as a result I now got correct microsecond timestamps: 1307270937122897
>
> I was using the latest version from http://www.apache.org/dist/thrift/0.6.1/ to build the extension without using any special parameters (just ./configure --enable-gen-php=yes and make install).
>
> Downloaded and re-compiled it, without any change. I can also see no compile parameters to set which might help.
>
>
>
> Any advise where to go from here?
>
>
>
> Thanks so far!
>
> Mario
>
>
Re: problems with many columns on a row
Posted by Mario Micklisch <ma...@hpm-kommunikation.de>.
I found a patch for the php extension here:
https://issues.apache.org/jira/browse/THRIFT-1067
… this seemed to fix the issue. Thank you Jonathan and Aaron for taking time
to provide me with some help!
Regarding the compaction I would still love to hear your feedback on how to
configure Cassandra accordingly.
Here are my facts again:
Data size on disk: ~1GB
Data Volume: ~150GB free storage
OS Volume: ~3GB free storage
Tried:
nodetool --host localhost compact
The logfiles said:
ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,346 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,348 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,349 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
INFO [CompactionExecutor:2] 2011-06-05 11:44:39,366 CompactionManager.java
(line 539) Compacting Major:
[SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-81-Data.db'),
SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-80-Data.db'),
SSTableReader(path='/mnt/cassandra/data/system/LocationInfo-g-79-Data.db')]
INFO [CompactionExecutor:2] 2011-06-05 11:44:39,502 CompactionIterator.java
(line 186) Major@23231510(system, LocationInfo, 386/689) now compacting at
16777 bytes/ms.
INFO [CompactionExecutor:2] 2011-06-05 11:44:39,713 CompactionManager.java
(line 603) Compacted to
/mnt/cassandra/data/system/LocationInfo-tmp-g-82-Data.db. 689 to 446 (~64%
of original) bytes for 3 keys. Time: 346ms.
ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
ERROR [CompactionExecutor:2] 2011-06-05 11:44:39,726 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
# du -hs /mnt/cassandra/
886M /mnt/cassandra/
# df -H
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 8.5G 4.9G 3.6G 49% /
/dev/sda2 158G 1.2G 149G 1% /mnt
# nodetool --host localhost info
130915841875673808436922706546793999597
Gossip active : true
Load : 1.48 MB
Generation No : 1307273982
Uptime (seconds) : 383
Heap Memory (MB) : 89.59 / 822.00
Thank you,
Mario
2011/6/5 Mario Micklisch <ma...@hpm-kommunikation.de>
> I tracked down the timestamp submission and everything was fine within the
> PHP Libraries.
>
> The thrift php extension however seems to have an overflow, because it was
> now setting now timestamps with also negative values ( -1242277493 ). I
> disabled the php extension and as a result I now got correct microsecond
> timestamps: 1307270937122897
>
> I was using the latest version from
> http://www.apache.org/dist/thrift/0.6.1/ to build the extension without
> using any special parameters (just ./configure --enable-gen-php=yes and
> make install).
>
> Downloaded and re-compiled it, without any change. I can also see no
> compile parameters to set which might help.
>
>
> Any advise where to go from here?
>
>
> Thanks so far!
>
> Mario
>
>
Re: problems with many columns on a row
Posted by Mario Micklisch <ma...@hpm-kommunikation.de>.
I tracked down the timestamp submission and everything was fine within the
PHP Libraries.
The thrift php extension however seems to have an overflow, because it was
now setting now timestamps with also negative values ( -1242277493 ). I
disabled the php extension and as a result I now got correct microsecond
timestamps: 1307270937122897
I was using the latest version from
http://www.apache.org/dist/thrift/0.6.1/to build the extension without
using any special parameters (just ./configure
--enable-gen-php=yes and make install).
Downloaded and re-compiled it, without any change. I can also see no
compile parameters to set which might help.
Any advise where to go from here?
Thanks so far!
Mario
2011/6/5 Mario Micklisch <ma...@hpm-kommunikation.de>
> Thanks for the feedback Aaron!
>
> The schema of the CF is default, I just defined the name and the rest is
> default, have a look:
>
> Keyspace: TestKS
> Read Count: 65
> Read Latency: 657.8047076923076 ms.
> Write Count: 10756
> Write Latency: 0.03237039791744143 ms.
> Pending Tasks: 0
> Column Family: CFTest
> SSTable count: 1
> Space used (live): 25671740
> Space used (total): 51349233
> Memtable Columns Count: 54
> Memtable Data Size: 21375
> Memtable Switch Count: 1
> Read Count: 65
> Read Latency: 657.805 ms.
> Write Count: 10756
> Write Latency: 0.032 ms.
> Pending Tasks: 0
> Key cache capacity: 200000
> Key cache size: 11
> Key cache hit rate: 6.777150522609133E-4
> Row cache: disabled
> Compacted row minimum size: 125
> Compacted row maximum size: 654949
> Compacted row mean size: 287
>
>
> I am using phpcassa in the latest (0.8. compatible) version. I was also
> wondering about the timestamp details the CLI has shown, on my last test run
> I opened the cassandra-cli in the terminal and did some get requests there
> to see how the data is changing while filling in my random test data.
>
> The timestamp was something around 87.000.000 at first and then grow
> to 2.147.442.124 (1.464.439.894 in the earlier example) for the tested row,
> it looked suspicious but since the data was not in clean ascii I was not so
> sure about that.
>
> I will check that now.
>
> What about the compact? Is this really because of the OS Volume beeing
> smaller than the data volume? There is plenty of space on the data volume,
> how can I make sure it is not using using the OS Volume for compaction?
>
> Cheers,
> Mario
>
>
> 2011/6/5 aaron morton <aa...@thelastpickle.com>
>
>> It is rarely a good idea to let the data disk get to far over 50%
>> utilisation. With so little free space the compaction process will have
>> trouble running http://wiki.apache.org/cassandra/MemtableSSTable
>>
>> As you are on the RC1 I would just drop the data and start again. If you
>> need to keep it you can use multiple data directories as specified in the
>> cassandra.yaml file. See the data_file_directories setting. (the
>> recommendation is to use 1 data directory) <http://wiki.apache.org/cassandra/MemtableSSTable>
>>
>> The exception looks pretty odd, something wacky with the column family
>> definition. Have you been changing the schema ?
>>
>> For the delete problem, something looks odd about the timestamps you are
>> using. How was the data inserted ?
>>
>> This is your data sample...
>>
>> [default@TestKS] get
>> CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
>> => (column=count, value=3331353030, timestamp=1464439894)
>> => (column=split, value=3334, timestamp=1464439894)
>>
>> Time stamps are normally microseconds since the unix epoch
>> http://wiki.apache.org/cassandra/DataModel?highlight=%28timestamp%29<http://wiki.apache.org/cassandra/DataModel?highlight=(timestamp)>
>>
>> This is what the CLI will use, e.g.
>>
>> [default@dev] set data[ascii('foo')]['bar'] = 'baz';
>> Value inserted.
>> [default@dev] get data['foo'];
>>
>> => (column=bar, value=62617a, timestamp=1307248484615000)
>> Returned 1 results.
>> [default@dev] del data['foo'];
>> row removed.
>> [default@dev] get data['foo'];
>> Returned 0 results.
>> [default@dev]
>>
>>
>> The higher numbers created by the client should still work, but I would
>> look into this first.
>>
>> Cheers
>>
>>
>> -----------------
>> Aaron Morton
>> Freelance Cassandra Developer
>> @aaronmorton
>> http://www.thelastpickle.com
>>
>> On 5 Jun 2011, at 10:09, Mario Micklisch wrote:
>>
>> Yes, checked the log file, no errors there.
>>
>> With debug logging it confirms to receive the write too and it is also in
>> the commitlog.
>>
>> DEBUG 22:00:14,057 insert writing local RowMutation(keyspace='TestKS',
>> key='44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573',
>> modifications=[CFTest])
>> DEBUG 22:00:14,057 applying mutation of row
>> 44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573
>>
>>
>> But doing compact with the nodetool triggered an error:
>>
>> ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,021
>> CompactionManager.java (line 510) insufficient space to compact even the two
>> smallest files, aborting
>> ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,024
>> CompactionManager.java (line 510) insufficient space to compact even the two
>> smallest files, aborting
>>
>> The data folder has currently a size of about 1GB, there are 150GB free
>> disk space on the volume where I pointed all cassandra directories but only
>> 3.5GB free disk space on the operating system disk.
>>
>> Could this be the reason? How can I set the environment variables to let
>> it only use the dedicated volume?
>>
>>
>> Trying to use sstable2json did not work (throws an exception, am I using
>> the wrong parameter?):
>>
>> # sstable2json ./CFTest-g-40-Data.db
>> log4j:WARN No appenders could be found for logger
>> (org.apache.cassandra.config.DatabaseDescriptor).
>> log4j:WARN Please initialize the log4j system properly.
>> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
>> more info.
>> {
>> Exception in thread "main" java.lang.NullPointerException
>> at org.apache.cassandra.db.ColumnFamily.<init>(ColumnFamily.java:82)
>> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:70)
>> at
>> org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:142)
>> at
>> org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:90)
>> at
>> org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:74)
>> at
>> org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:179)
>> at
>> org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:144)
>> at
>> org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:136)
>> at
>> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:313)
>> at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:344)
>> at
>> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:357)
>> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:415)
>>
>>
>>
>> Cheers,
>> Mario
>>
>> 2011/6/4 Jonathan Ellis <jb...@gmail.com>
>>
>>> Did you check the server log for errors?
>>>
>>> See if the problem persists after running nodetool compact. If it
>>> does, use sstable2json to export the row in question.
>>>
>>
>>
>
Re: problems with many columns on a row
Posted by Mario Micklisch <ma...@hpm-kommunikation.de>.
Thanks for the feedback Aaron!
The schema of the CF is default, I just defined the name and the rest is
default, have a look:
Keyspace: TestKS
Read Count: 65
Read Latency: 657.8047076923076 ms.
Write Count: 10756
Write Latency: 0.03237039791744143 ms.
Pending Tasks: 0
Column Family: CFTest
SSTable count: 1
Space used (live): 25671740
Space used (total): 51349233
Memtable Columns Count: 54
Memtable Data Size: 21375
Memtable Switch Count: 1
Read Count: 65
Read Latency: 657.805 ms.
Write Count: 10756
Write Latency: 0.032 ms.
Pending Tasks: 0
Key cache capacity: 200000
Key cache size: 11
Key cache hit rate: 6.777150522609133E-4
Row cache: disabled
Compacted row minimum size: 125
Compacted row maximum size: 654949
Compacted row mean size: 287
I am using phpcassa in the latest (0.8. compatible) version. I was also
wondering about the timestamp details the CLI has shown, on my last test run
I opened the cassandra-cli in the terminal and did some get requests there
to see how the data is changing while filling in my random test data.
The timestamp was something around 87.000.000 at first and then grow
to 2.147.442.124 (1.464.439.894 in the earlier example) for the tested row,
it looked suspicious but since the data was not in clean ascii I was not so
sure about that.
I will check that now.
What about the compact? Is this really because of the OS Volume beeing
smaller than the data volume? There is plenty of space on the data volume,
how can I make sure it is not using using the OS Volume for compaction?
Cheers,
Mario
2011/6/5 aaron morton <aa...@thelastpickle.com>
> It is rarely a good idea to let the data disk get to far over 50%
> utilisation. With so little free space the compaction process will have
> trouble running http://wiki.apache.org/cassandra/MemtableSSTable
>
> As you are on the RC1 I would just drop the data and start again. If you
> need to keep it you can use multiple data directories as specified in the
> cassandra.yaml file. See the data_file_directories setting. (the
> recommendation is to use 1 data directory) <http://wiki.apache.org/cassandra/MemtableSSTable>
>
> The exception looks pretty odd, something wacky with the column family
> definition. Have you been changing the schema ?
>
> For the delete problem, something looks odd about the timestamps you are
> using. How was the data inserted ?
>
> This is your data sample...
>
> [default@TestKS] get
> CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
> => (column=count, value=3331353030, timestamp=1464439894)
> => (column=split, value=3334, timestamp=1464439894)
>
> Time stamps are normally microseconds since the unix epoch
> http://wiki.apache.org/cassandra/DataModel?highlight=%28timestamp%29<http://wiki.apache.org/cassandra/DataModel?highlight=(timestamp)>
>
> This is what the CLI will use, e.g.
>
> [default@dev] set data[ascii('foo')]['bar'] = 'baz';
> Value inserted.
> [default@dev] get data['foo'];
>
> => (column=bar, value=62617a, timestamp=1307248484615000)
> Returned 1 results.
> [default@dev] del data['foo'];
> row removed.
> [default@dev] get data['foo'];
> Returned 0 results.
> [default@dev]
>
>
> The higher numbers created by the client should still work, but I would
> look into this first.
>
> Cheers
>
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> @aaronmorton
> http://www.thelastpickle.com
>
> On 5 Jun 2011, at 10:09, Mario Micklisch wrote:
>
> Yes, checked the log file, no errors there.
>
> With debug logging it confirms to receive the write too and it is also in
> the commitlog.
>
> DEBUG 22:00:14,057 insert writing local RowMutation(keyspace='TestKS',
> key='44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573',
> modifications=[CFTest])
> DEBUG 22:00:14,057 applying mutation of row
> 44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573
>
>
> But doing compact with the nodetool triggered an error:
>
> ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,021 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
> ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,024 CompactionManager.java
> (line 510) insufficient space to compact even the two smallest files,
> aborting
>
> The data folder has currently a size of about 1GB, there are 150GB free
> disk space on the volume where I pointed all cassandra directories but only
> 3.5GB free disk space on the operating system disk.
>
> Could this be the reason? How can I set the environment variables to let it
> only use the dedicated volume?
>
>
> Trying to use sstable2json did not work (throws an exception, am I using
> the wrong parameter?):
>
> # sstable2json ./CFTest-g-40-Data.db
> log4j:WARN No appenders could be found for logger
> (org.apache.cassandra.config.DatabaseDescriptor).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
> more info.
> {
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.cassandra.db.ColumnFamily.<init>(ColumnFamily.java:82)
> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:70)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:142)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:90)
> at
> org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:74)
> at
> org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:179)
> at
> org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:144)
> at
> org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:136)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:313)
> at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:344)
> at
> org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:357)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:415)
>
>
>
> Cheers,
> Mario
>
> 2011/6/4 Jonathan Ellis <jb...@gmail.com>
>
>> Did you check the server log for errors?
>>
>> See if the problem persists after running nodetool compact. If it
>> does, use sstable2json to export the row in question.
>>
>
>
Re: problems with many columns on a row
Posted by aaron morton <aa...@thelastpickle.com>.
It is rarely a good idea to let the data disk get to far over 50% utilisation. With so little free space the compaction process will have trouble running http://wiki.apache.org/cassandra/MemtableSSTable
As you are on the RC1 I would just drop the data and start again. If you need to keep it you can use multiple data directories as specified in the cassandra.yaml file. See the data_file_directories setting. (the recommendation is to use 1 data directory)
The exception looks pretty odd, something wacky with the column family definition. Have you been changing the schema ?
For the delete problem, something looks odd about the timestamps you are using. How was the data inserted ?
This is your data sample...
[default@TestKS] get CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
=> (column=count, value=3331353030, timestamp=1464439894)
=> (column=split, value=3334, timestamp=1464439894)
Time stamps are normally microseconds since the unix epoch http://wiki.apache.org/cassandra/DataModel?highlight=%28timestamp%29
This is what the CLI will use, e.g.
[default@dev] set data[ascii('foo')]['bar'] = 'baz';
Value inserted.
[default@dev] get data['foo'];
=> (column=bar, value=62617a, timestamp=1307248484615000)
Returned 1 results.
[default@dev] del data['foo'];
row removed.
[default@dev] get data['foo'];
Returned 0 results.
[default@dev]
The higher numbers created by the client should still work, but I would look into this first.
Cheers
-----------------
Aaron Morton
Freelance Cassandra Developer
@aaronmorton
http://www.thelastpickle.com
On 5 Jun 2011, at 10:09, Mario Micklisch wrote:
> Yes, checked the log file, no errors there.
>
> With debug logging it confirms to receive the write too and it is also in the commitlog.
>
> DEBUG 22:00:14,057 insert writing local RowMutation(keyspace='TestKS', key='44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573', modifications=[CFTest])
> DEBUG 22:00:14,057 applying mutation of row 44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573
>
>
> But doing compact with the nodetool triggered an error:
>
> ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,021 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
> ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,024 CompactionManager.java (line 510) insufficient space to compact even the two smallest files, aborting
>
> The data folder has currently a size of about 1GB, there are 150GB free disk space on the volume where I pointed all cassandra directories but only 3.5GB free disk space on the operating system disk.
>
> Could this be the reason? How can I set the environment variables to let it only use the dedicated volume?
>
>
> Trying to use sstable2json did not work (throws an exception, am I using the wrong parameter?):
>
> # sstable2json ./CFTest-g-40-Data.db
> log4j:WARN No appenders could be found for logger (org.apache.cassandra.config.DatabaseDescriptor).
> log4j:WARN Please initialize the log4j system properly.
> log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more info.
> {
> Exception in thread "main" java.lang.NullPointerException
> at org.apache.cassandra.db.ColumnFamily.<init>(ColumnFamily.java:82)
> at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:70)
> at org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:142)
> at org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:90)
> at org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:74)
> at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:179)
> at org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:144)
> at org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:136)
> at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:313)
> at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:344)
> at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:357)
> at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:415)
>
>
>
> Cheers,
> Mario
>
> 2011/6/4 Jonathan Ellis <jb...@gmail.com>
> Did you check the server log for errors?
>
> See if the problem persists after running nodetool compact. If it
> does, use sstable2json to export the row in question.
Re: problems with many columns on a row
Posted by Mario Micklisch <ma...@hpm-kommunikation.de>.
Yes, checked the log file, no errors there.
With debug logging it confirms to receive the write too and it is also in
the commitlog.
DEBUG 22:00:14,057 insert writing local RowMutation(keyspace='TestKS',
key='44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573',
modifications=[CFTest])
DEBUG 22:00:14,057 applying mutation of row
44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573
But doing compact with the nodetool triggered an error:
ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,021 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
ERROR [CompactionExecutor:8] 2011-06-04 21:47:44,024 CompactionManager.java
(line 510) insufficient space to compact even the two smallest files,
aborting
The data folder has currently a size of about 1GB, there are 150GB free disk
space on the volume where I pointed all cassandra directories but only 3.5GB
free disk space on the operating system disk.
Could this be the reason? How can I set the environment variables to let it
only use the dedicated volume?
Trying to use sstable2json did not work (throws an exception, am I using the
wrong parameter?):
# sstable2json ./CFTest-g-40-Data.db
log4j:WARN No appenders could be found for logger
(org.apache.cassandra.config.DatabaseDescriptor).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for
more info.
{
Exception in thread "main" java.lang.NullPointerException
at org.apache.cassandra.db.ColumnFamily.<init>(ColumnFamily.java:82)
at org.apache.cassandra.db.ColumnFamily.create(ColumnFamily.java:70)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:142)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:90)
at
org.apache.cassandra.io.sstable.SSTableIdentityIterator.<init>(SSTableIdentityIterator.java:74)
at
org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:179)
at
org.apache.cassandra.io.sstable.SSTableScanner$KeyScanningIterator.next(SSTableScanner.java:144)
at
org.apache.cassandra.io.sstable.SSTableScanner.next(SSTableScanner.java:136)
at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:313)
at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:344)
at org.apache.cassandra.tools.SSTableExport.export(SSTableExport.java:357)
at org.apache.cassandra.tools.SSTableExport.main(SSTableExport.java:415)
Cheers,
Mario
2011/6/4 Jonathan Ellis <jb...@gmail.com>
> Did you check the server log for errors?
>
> See if the problem persists after running nodetool compact. If it
> does, use sstable2json to export the row in question.
>
Re: problems with many columns on a row
Posted by Jonathan Ellis <jb...@gmail.com>.
Did you check the server log for errors?
See if the problem persists after running nodetool compact. If it
does, use sstable2json to export the row in question.
On Sat, Jun 4, 2011 at 3:21 PM, Mario Micklisch
<ma...@hpm-kommunikation.de> wrote:
> Thank you for the reply! I am not trying to read a row with too many columns
> into memory, the lock I am experiencing is write-related only and happening
> for everything added prior to an unknown event.
> I just ran into the same thing again and the column count is maybe not the
> real issue here (as I thought when writing the initial mail, too quickly
> assumed the wrong thing, sorry!), as this also happened after reducing the
> ID tracking rows to a maximum of 1.000 columns a row.
> I have just inserted about 30.000 rows in the last hour and I counted the
> values in a row too to keeping track of the number of data. It was
> read,incremented and updated for each new insert.
> Suddenly it was no longer updated while new data was still added.
> I used the cassandra-cli to try to delete that example row manually to be
> sure that the reason was not in my application:
> [default@TestKS] get
> CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
> => (column=count, value=3331353030, timestamp=1464439894)
> => (column=split, value=3334, timestamp=1464439894)
> [default@TestKS] del
> CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
>
> row removed.
> [default@TestKS] get
> CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
> => (column=count, value=3331353030, timestamp=1464439894)
> => (column=split, value=3334, timestamp=1464439894)
> … and it won't go away or be overwritten by new a new "set".
>
> What could be the reason for this or how can I identify the reason for this?
> Thanks,
> Mario
>
>
> 2011/6/4 Jonathan Ellis <jb...@gmail.com>
>>
>> It sounds like you're trying to read entire rows at once. Past a
>> certain point (depending on your heap size) you won't be able to do
>> that, you need to "page" through them N columns at a time.
>>
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: problems with many columns on a row
Posted by Mario Micklisch <ma...@hpm-kommunikation.de>.
Thank you for the reply! I am not trying to read a row with too many columns
into memory, the lock I am experiencing is write-related only and happening
for everything added prior to an unknown event.
I just ran into the same thing again and the column count is maybe not the
real issue here (as I thought when writing the initial mail, too quickly
assumed the wrong thing, sorry!), as this also happened after reducing the
ID tracking rows to a maximum of 1.000 columns a row.
I have just inserted about 30.000 rows in the last hour and I counted the
values in a row too to keeping track of the number of data. It was
read,incremented and updated for each new insert.
Suddenly it was no longer updated while new data was still added.
I used the cassandra-cli to try to delete that example row manually to be
sure that the reason was not in my application:
[default@TestKS] get
CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
=> (column=count, value=3331353030, timestamp=1464439894)
=> (column=split, value=3334, timestamp=1464439894)
[default@TestKS] del
CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
row removed.
[default@TestKS] get
CFTest['44656661756c747c65333332356231342d373937392d313165302d613663382d3132333133633033336163347c5461626c65737c5765625369746573'];
=> (column=count, value=3331353030, timestamp=1464439894)
=> (column=split, value=3334, timestamp=1464439894)
… and it won't go away or be overwritten by new a new "set".
What could be the reason for this or how can I identify the reason for this?
Thanks,
Mario
2011/6/4 Jonathan Ellis <jb...@gmail.com>
> It sounds like you're trying to read entire rows at once. Past a
> certain point (depending on your heap size) you won't be able to do
> that, you need to "page" through them N columns at a time.
>
>
Re: problems with many columns on a row
Posted by Jonathan Ellis <jb...@gmail.com>.
It sounds like you're trying to read entire rows at once. Past a
certain point (depending on your heap size) you won't be able to do
that, you need to "page" through them N columns at a time.
On Sat, Jun 4, 2011 at 12:27 PM, Mario Micklisch
<ma...@hpm-kommunikation.de> wrote:
> Hello there!
> I have ran into a strange problem several times now and I wonder if someone
> here has an solution for me:
>
> For some of my data I want to keep track all the ID's I have used. To do
> that, I am putting the ID's as column into rows.
> At first I wanted to put all ID's into one row (because the limit of 2
> billion column seemed high enough) and then it happened:
> For some reason I was no longer able to remove or update existing rows or
> column. Adding new rows and removing them was possible, but write access to
> the older rows did not longer work.
> I have restarted the cluster, didn't help either. Only truncating the column
> family helped.
> Because this happened several times after creating rows with 5.000+ columns
> I decided to reduce the number of columns to a maximum of 1.000 per row and
> everything is now working perfectly.
>
> I am working on version 0.8-rc1 and for testing purpose I am running only
> one node with the default settings.
>
> My questions are:
> 1) Because 0.8 is not marked as stable, is this a known problem?
> 2) Is there something in the configuration I need to change to handle a
> bigger number of columns?
> 3) Can I check on the cassandra-cli why updates are failing? (there were no
> error messages when trying deletes with the CLI manually)
> 4) Is there a recommended number of columns? (I guess this only depends on
> my systems memory?)
>
> Thanks to everyone who took some time to read!
> Mario
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com