The solution maybe work. However, the play list will grow over time and
somebody maybe has ten thousands that will slow down the query and sort . Do
you mean the oldest one should be removed when a new play is added?
BTW, the version is 2.1.16 in our live system.
BRs,
BEN
Hi,
the docs give me an impression that repairing should be run manually,
and not put in crontab for default. Should each repair run be monitored
manually?
If I would like to put "repair -pr" in crontab for each node, with a few
hour difference between the runs, are there any risks with such
Hi Kurt,
Thanks !
Lahiru
On Wed, Nov 9, 2016 at 12:02 AM, kurt Greaves wrote:
> What compaction strategy are you migrating from? If you're migrating from
> STCS it's likely that when switching to TWCS no extra compactions are
> necessary, as the SSTables will be put into
https://issues.apache.org/jira/browse/CASSANDRA-8844
On Wed, Nov 9, 2016 at 8:34 PM, sat wrote:
> Hi,
>
> We are doing POC on Cassandra for our business needs. We also need some
> kind of notification when a column/attribute is modified
> (insert/update/delete) of a
Hi,
We are doing POC on Cassandra for our business needs. We also need some
kind of notification when a column/attribute is modified
(insert/update/delete) of a table.
Thanks for sharing information about CDC. Could you please point us to some
example of how to implement this in Cassandra 3.9.
I don't want to change the log level. I want to add a trace to the log entry
Am 09.11.2016 15:22 schrieb "Vladimir Yudovin" :
> Hi,
>
> you can change log level with nodetool setlogginglevel command
>
> Best regards, Vladimir Yudovin,
>
> *Winguzone
Hi,
you can change log level with nodetool setlogginglevel command
Best regards, Vladimir Yudovin,
Winguzone - Hosted Cloud Cassandra
Launch your cluster in minutes.
On Wed, 09 Nov 2016 10:17:37 -0500Benjamin Roth
benjamin.r...@jaumo.com wrote
Hi!
Is there a way to
Hi!
Is there a way to tell logback to log the trace of a debug log? The
background is that i'd like to know from where a table flush is triggered.
Thanks guys!
They are production ready in the sens that they are fully functional. But
using them require a *deep* knowledge of Cassandra Internal Write path and
is dangerous because the write path is critical.
Alternatively if you need a notification system of new mutation, there is a
CDC feature, available
Hi,
Are Triggers in Cassandra production ready ?
Version: Cassandra 3.3.0
Thanks
Manoj
The keys however are dynamic in my case.
Why is it problem for you? As you said "if something related to 5 happened,
then i'd get the counter for 5 and increment / decrement it."
So do "UPDATE cnt SET value = value + SOMETHING where id = 5;"
If counter for event 5 exists it will be changed,
The only issue with the last 2 solutions is, they require knowing the key
in advance in order to look up the counters.
The keys however are dynamic in my case.
On Wed, Nov 9, 2016 at 5:47 PM, DuyHai Doan wrote:
> "Is there a way to do this in c* which doesn't require
"Is there a way to do this in c* which doesn't require creating 1 table per
type of map that i need?"
You're lucky, it's possible with some tricks
CREATE TABLE my_counters_map (
partition_key id uuid,
map_name text,
map_key int,
count counter,
PRIMARY KEY
Unfortunately it's impossible nor to use counters inside collections neither
mix them with other non-counter columns :
CREATE TABLE cnt (id int PRIMARY KEY , cntmap MAPint,counter);
InvalidRequest: Error from server: code=2200 [Invalid query] message="Counters
are not allowed inside
I have a use-case where I need to have a dynamic number of counters.
The easiest way to do this would be to have a map where the
int is the key, and the counter is the value which is incremented /
decremented. E.g if something related to 5 happened, then i'd get the
counter for 5
You are welcome! )
recent ten movies watched by the user within 30 days.
In this case you can't use PRIMARY KEY (user_name, video_id), as video_id is
demanded to fetch row, so all this stuff may be
CREATE TYPE play (video_id text, position int, last_time timestamp);
CREATE TABLE recent
What compaction strategy are you migrating from? If you're migrating from
STCS it's likely that when switching to TWCS no extra compactions are
necessary, as the SSTables will be put into their respective windows but
there won't be enough candidates for compaction within a window.
Kurt Greaves
17 matches
Mail list logo