is "upgradesstables" required upon "update column family with
compression_options" (or "compaction_strategy") ?
for compaction strategy no, not use about other one.
On Thu, Jul 26, 2012 at 6:00 PM, Илья Шипицин wrote:
> is "upgradesstables" required upon "update column family with
> compression_options" (or "compaction_strategy") ?
It is not required, no. If you change compression_options, the new
settings will only apply to newly created sstables. upgradess
Thanks!
This worked fine!
*Tamar Fraenkel *
Senior Software Engineer, TOK Media
[image: Inline image 1]
ta...@tok-media.com
Tel: +972 2 6409736
Mob: +972 54 8356490
Fax: +972 2 5612956
On Sat, Jul 28, 2012 at 7:10 AM, Joaquin Casares wrote:
> Oh you're right, sorry about that. The con
Thanks Tamar and all.. :)
Since I want to do queries like SELECT * FROM counters WHERE
CounterColumnName>1; I want to index my counter columns, and I use the
following code. But I get the following error
Exception in thread "main"
me.prettyprint.hector.api.exceptions.HInvalidRequestException:
Inval
On Sat, Jul 28, 2012 at 10:46 PM, Ertio Lew wrote:
> Is it possible to set Replication Factor on per column family basis so that
> I can avoid replicating large text data or other not-so-important data in
> CFs with low RF?
>
> I use hector API.
Replication factor is keyspace bound, not CF bound.
I heard that it is* not highly recommended* to create more than a single
keyspace for an application or on a single cluster !?
Moreover I fail to understand that why Cassandra puts this limitation to
set RF on keyspace when, I guess, it makes more sense to do this on per CF
basis !?
