Re: Built in trigger: double-write for app migration

[Rahul Singh]

Trigger based has worked for us in the past to get once only output of what’s 
happened - pushing this to Kafka and using Kafka Connect allowed to then direct 
the stream to to other endpoints.

CDC based streaming has the issue of duplicates which are technically fine if 
you don’t care that much about repeat changes coming from replicas.

I agree with Ben. If the goal is just to move a key space from one cluster to 
another that is active and can’t go down, his method will work for sure.

Also, is there a specific reason you need to split the cluster? Why not just 
have another DC and keep it part of the cluster? Do you have more than a 
hundred tables?


Rahul Singh
Chief Executive Officer
m 202.905.2818

Anant Corporation
1010 Wisconsin Ave NW, Suite 250
Washington, D.C. 20007

We build and manage digital business technology platforms.
On Oct 18, 2018, 4:35 PM -0400, Ben Slater , wrote:
> I might be missing something but we’ve done this operation on a few
> occasions by:
> 1) Commission the new cluster and join it to the existing cluster as a 2nd
> DC
> 2) Replicate just the keyspace that you want to move to the 2nd DC
> 3) Make app changes to read moved tables from 2nd DC
> 4) Change keyspace definition to remove moved keyspace from first DC
> 5) Split the 2DCs into separate clusters (sever network connections, change
> seeds)
>
> If it’s just a table you moving and not a whole keyspace then you can skip
> step 4 and drop the unneeded tables from either side after splitting. This
> might mean the new cluster needs to be temporarily bigger than the
> end-state during the migration process.
>
> Cheers
> Ben
>
> On Fri, 19 Oct 2018 at 07:04 Jeff Jirsa  wrote:
>
> > Could be done with CDC
> > Could be done with triggers
> > (Could be done with vtables — double writes or double reads — if they were
> > extended to be user facing)
> >
> > Would be very hard to generalize properly, especially handling failure
> > cases (write succeeds in one cluster/table but not the other) which are
> > often app specific
> >
> >
> > --
> > Jeff Jirsa
> >
> >
> > > On Oct 18, 2018, at 6:47 PM, Jonathan Ellis  wrote:
> > >
> > > Isn't this what CDC was designed for?
> > >
> > > https://issues.apache.org/jira/browse/CASSANDRA-8844
> > >
> > > On Thu, Oct 18, 2018 at 10:54 AM Carl Mueller
> > >  wrote:
> > >
> > > > tl;dr: a generic trigger on TABLES that will mirror all writes to
> > > > facilitate data migrations between clusters or systems. What is
> > necessary
> > > > to ensure full write mirroring/coherency?
> > > >
> > > > When cassandra clusters have several "apps" aka keyspaces serving
> > > > applications colocated on them, but the app/keyspace bandwidth and size
> > > > demands begin impacting other keyspaces/apps, then one strategy is to
> > > > migrate the keyspace to its own dedicated cluster.
> > > >
> > > > With backups/sstableloading, this will entail a delay and therefore a
> > > > "coherency" shortfall between the clusters. So typically one would
> > employ a
> > > > "double write, read once":
> > > >
> > > > - all updates are mirrored to both clusters
> > > > - writes come from the current most coherent.
> > > >
> > > > Often two sstable loads are done:
> > > >
> > > > 1) first load
> > > > 2) turn on double writes/write mirroring
> > > > 3) a second load is done to finalize coherency
> > > > 4) switch the app to point to the new cluster now that it is coherent
> > > >
> > > > The double writes and read is the sticking point. We could do it at the
> > app
> > > > layer, but if the app wasn't written with that, it is a lot of testing
> > and
> > > > customization specific to the framework.
> > > >
> > > > We could theoretically do some sort of proxying of the java-driver
> > somehow,
> > > > but all the async structures and complex interfaces/apis would be
> > difficult
> > > > to proxy. Maybe there is a lower level in the java-driver that is
> > possible.
> > > > This also would only apply to the java-driver, and not
> > > > python/go/javascript/other drivers.
> > > >
> > > > Finally, I suppose we could do a trigger on the tables. It would be
> > really
> > > > nice if we could add to the cassandra toolbox the basics of a write
> > > > mirroring trigger that could be activated "fairly easily"... now I know
> > > > there are the complexities of inter-cluster access, and if we are even
> > > > using cassandra as the target mirror system (for example there is an
> > > > article on triggers write-mirroring to kafka:
> > > > https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
> > > >
> > > > And this starts to get into the complexities of hinted handoff as well.
> > But
> > > > fundamentally this seems something that would be a very nice feature
> > > > (especially when you NEED it) to have in the core of cassandra.
> > > >
> > > > Finally, is the mutation hook in triggers sufficient to track all
> > incoming
> > > > mutations (outside of "shudder" other triggers generating data)
> > > >
> > >

Re: Built in trigger: double-write for app migration

[Ben Slater]

I might be missing something but we’ve done this operation on a few
occasions by:
1) Commission the new cluster and join it to the existing cluster as a 2nd
DC
2) Replicate just the keyspace that you want to move to the 2nd DC
3) Make app changes to read moved tables from 2nd DC
4) Change keyspace definition to remove moved keyspace from first DC
5) Split the 2DCs into separate clusters (sever network connections, change
seeds)

If it’s just a table you moving and not a whole keyspace then you can skip
step 4 and drop the unneeded tables from either side after splitting. This
might mean the new cluster needs to be temporarily bigger than the
end-state during the migration process.

Cheers
Ben

On Fri, 19 Oct 2018 at 07:04 Jeff Jirsa  wrote:

> Could be done with CDC
> Could be done with triggers
> (Could be done with vtables — double writes or double reads — if they were
> extended to be user facing)
>
> Would be very hard to generalize properly, especially handling failure
> cases (write succeeds in one cluster/table but not the other) which are
> often app specific
>
>
> --
> Jeff Jirsa
>
>
> > On Oct 18, 2018, at 6:47 PM, Jonathan Ellis  wrote:
> >
> > Isn't this what CDC was designed for?
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-8844
> >
> > On Thu, Oct 18, 2018 at 10:54 AM Carl Mueller
> >  wrote:
> >
> >> tl;dr: a generic trigger on TABLES that will mirror all writes to
> >> facilitate data migrations between clusters or systems. What is
> necessary
> >> to ensure full write mirroring/coherency?
> >>
> >> When cassandra clusters have several "apps" aka keyspaces serving
> >> applications colocated on them, but the app/keyspace bandwidth and size
> >> demands begin impacting other keyspaces/apps, then one strategy is to
> >> migrate the keyspace to its own dedicated cluster.
> >>
> >> With backups/sstableloading, this will entail a delay and therefore a
> >> "coherency" shortfall between the clusters. So typically one would
> employ a
> >> "double write, read once":
> >>
> >> - all updates are mirrored to both clusters
> >> - writes come from the current most coherent.
> >>
> >> Often two sstable loads are done:
> >>
> >> 1) first load
> >> 2) turn on double writes/write mirroring
> >> 3) a second load is done to finalize coherency
> >> 4) switch the app to point to the new cluster now that it is coherent
> >>
> >> The double writes and read is the sticking point. We could do it at the
> app
> >> layer, but if the app wasn't written with that, it is a lot of testing
> and
> >> customization specific to the framework.
> >>
> >> We could theoretically do some sort of proxying of the java-driver
> somehow,
> >> but all the async structures and complex interfaces/apis would be
> difficult
> >> to proxy. Maybe there is a lower level in the java-driver that is
> possible.
> >> This also would only apply to the java-driver, and not
> >> python/go/javascript/other drivers.
> >>
> >> Finally, I suppose we could do a trigger on the tables. It would be
> really
> >> nice if we could add to the cassandra toolbox the basics of a write
> >> mirroring trigger that could be activated "fairly easily"... now I know
> >> there are the complexities of inter-cluster access, and if we are even
> >> using cassandra as the target mirror system (for example there is an
> >> article on triggers write-mirroring to kafka:
> >> https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
> >>
> >> And this starts to get into the complexities of hinted handoff as well.
> But
> >> fundamentally this seems something that would be a very nice feature
> >> (especially when you NEED it) to have in the core of cassandra.
> >>
> >> Finally, is the mutation hook in triggers sufficient to track all
> incoming
> >> mutations (outside of "shudder" other triggers generating data)
> >>
> >
> >
> > --
> > Jonathan Ellis
> > co-founder, http://www.datastax.com
> > @spyced
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
> --


*Ben Slater*

*Chief Product Officer *

   


Read our latest technical blog posts here
.

This email has been sent on behalf of Instaclustr Pty. Limited (Australia)
and Instaclustr Inc (USA).

This email and any attachments may contain confidential and legally
privileged information.  If you are not the intended recipient, do not copy
or disclose its content, but please reply to this email immediately and
highlight the error to the sender and then immediately delete the message.

Re: Built in trigger: double-write for app migration

[Jeff Jirsa]

Could be done with CDC
Could be done with triggers
(Could be done with vtables — double writes or double reads — if they were 
extended to be user facing)

Would be very hard to generalize properly, especially handling failure cases 
(write succeeds in one cluster/table but not the other) which are often app 
specific


-- 
Jeff Jirsa


> On Oct 18, 2018, at 6:47 PM, Jonathan Ellis  wrote:
> 
> Isn't this what CDC was designed for?
> 
> https://issues.apache.org/jira/browse/CASSANDRA-8844
> 
> On Thu, Oct 18, 2018 at 10:54 AM Carl Mueller
>  wrote:
> 
>> tl;dr: a generic trigger on TABLES that will mirror all writes to
>> facilitate data migrations between clusters or systems. What is necessary
>> to ensure full write mirroring/coherency?
>> 
>> When cassandra clusters have several "apps" aka keyspaces serving
>> applications colocated on them, but the app/keyspace bandwidth and size
>> demands begin impacting other keyspaces/apps, then one strategy is to
>> migrate the keyspace to its own dedicated cluster.
>> 
>> With backups/sstableloading, this will entail a delay and therefore a
>> "coherency" shortfall between the clusters. So typically one would employ a
>> "double write, read once":
>> 
>> - all updates are mirrored to both clusters
>> - writes come from the current most coherent.
>> 
>> Often two sstable loads are done:
>> 
>> 1) first load
>> 2) turn on double writes/write mirroring
>> 3) a second load is done to finalize coherency
>> 4) switch the app to point to the new cluster now that it is coherent
>> 
>> The double writes and read is the sticking point. We could do it at the app
>> layer, but if the app wasn't written with that, it is a lot of testing and
>> customization specific to the framework.
>> 
>> We could theoretically do some sort of proxying of the java-driver somehow,
>> but all the async structures and complex interfaces/apis would be difficult
>> to proxy. Maybe there is a lower level in the java-driver that is possible.
>> This also would only apply to the java-driver, and not
>> python/go/javascript/other drivers.
>> 
>> Finally, I suppose we could do a trigger on the tables. It would be really
>> nice if we could add to the cassandra toolbox the basics of a write
>> mirroring trigger that could be activated "fairly easily"... now I know
>> there are the complexities of inter-cluster access, and if we are even
>> using cassandra as the target mirror system (for example there is an
>> article on triggers write-mirroring to kafka:
>> https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
>> 
>> And this starts to get into the complexities of hinted handoff as well. But
>> fundamentally this seems something that would be a very nice feature
>> (especially when you NEED it) to have in the core of cassandra.
>> 
>> Finally, is the mutation hook in triggers sufficient to track all incoming
>> mutations (outside of "shudder" other triggers generating data)
>> 
> 
> 
> -- 
> Jonathan Ellis
> co-founder, http://www.datastax.com
> @spyced

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

table that has secondary index used up a lot of space - how to free up disk space?

[Kevin Mo]

Hi,

We are using a Cassandra to develop our application and we use a secondary 
index in one of our table for faster performance. As of now in our production, 
we saw a growing disk space on the table that has secondary index on it. It 
becomes a problem on us since we have a lot of data need to store.  As a 
result, we would like to reduce the disk space on that table.

We are thinking following to recreate the table without secondary index and 
repopulate the data. However, this is a time consuming task.

Do you have any suggestion on how to reduce the disk space size on the table 
that has secondary index?

Thanks

Kevin

Re: CASSANDRA-13241 lower default chunk_length_in_kb

[Ariel Weisberg]

Hi,

For those who were asking about the performance impact of block size on 
compression I wrote a microbenchmark.

https://pastebin.com/RHDNLGdC

 [java] Benchmark   Mode  Cnt   
   Score  Error  Units
 [java] CompactIntegerSequenceBench.benchCompressLZ4Fast16kthrpt   15  
331190055.685 ±  8079758.044  ops/s
 [java] CompactIntegerSequenceBench.benchCompressLZ4Fast32kthrpt   15  
353024925.655 ±  7980400.003  ops/s
 [java] CompactIntegerSequenceBench.benchCompressLZ4Fast64kthrpt   15  
365664477.654 ± 10083336.038  ops/s
 [java] CompactIntegerSequenceBench.benchCompressLZ4Fast8k thrpt   15  
305518114.172 ± 11043705.883  ops/s
 [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast16k  thrpt   15  
688369529.911 ± 25620873.933  ops/s
 [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast32k  thrpt   15  
703635848.895 ±  5296941.704  ops/s
 [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast64k  thrpt   15  
695537044.676 ± 17400763.731  ops/s
 [java] CompactIntegerSequenceBench.benchDecompressLZ4Fast8k   thrpt   15  
727725713.128 ±  4252436.331  ops/s

To summarize, compression is 8.5% slower and decompression is 1% faster. This 
is measuring the impact on compression/decompression not the huge impact that 
would occur if we decompressed data we don't need less often.

I didn't test decompression of Snappy and LZ4 high, but I did test compression.

Snappy:
 [java] CompactIntegerSequenceBench.benchCompressSnappy16k   thrpt2  
196574766.116  ops/s
 [java] CompactIntegerSequenceBench.benchCompressSnappy32k   thrpt2  
198538643.844  ops/s
 [java] CompactIntegerSequenceBench.benchCompressSnappy64k   thrpt2  
194600497.613  ops/s
 [java] CompactIntegerSequenceBench.benchCompressSnappy8kthrpt2  
186040175.059  ops/s

LZ4 high compressor:
 [java] CompactIntegerSequenceBench.bench16k  thrpt2  20822947.578  
ops/s
 [java] CompactIntegerSequenceBench.bench32k  thrpt2  12037342.253  
ops/s
 [java] CompactIntegerSequenceBench.bench64k  thrpt2   6782534.469  
ops/s
 [java] CompactIntegerSequenceBench.bench8k   thrpt2  32254619.594  
ops/s

LZ4 high is the one instance where block size mattered a lot. It's a bit 
suspicious really when you look at the ratio of performance to block size being 
close to 1:1. I couldn't spot a bug in the benchmark though.

Compression ratios with LZ4 fast for the text of Alice in Wonderland was:

Chunk size 8192, ratio 0.709473
Chunk size 16384, ratio 0.667236
Chunk size 32768, ratio 0.634735
Chunk size 65536, ratio 0.607208

By way of comparison I also ran deflate with maximum compression:

Chunk size 8192, ratio 0.426434
Chunk size 16384, ratio 0.402423
Chunk size 32768, ratio 0.381627
Chunk size 65536, ratio 0.364865

Ariel
 
On Thu, Oct 18, 2018, at 5:32 AM, Benedict Elliott Smith wrote:
> FWIW, I’m not -0, just think that long after the freeze date a change 
> like this needs a strong mandate from the community.  I think the change 
> is a good one.
> 
> 
> 
> 
> 
> > On 17 Oct 2018, at 22:09, Ariel Weisberg  wrote:
> > 
> > Hi,
> > 
> > It's really not appreciably slower compared to the decompression we are 
> > going to do which is going to take several microseconds. Decompression is 
> > also going to be faster because we are going to do less unnecessary 
> > decompression and the decompression itself may be faster since it may fit 
> > in a higher level cache better. I ran a microbenchmark comparing them.
> > 
> > https://issues.apache.org/jira/browse/CASSANDRA-13241?focusedCommentId=16653988=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16653988
> > 
> > Fetching a long from memory:   56 nanoseconds
> > Compact integer sequence   :   80 nanoseconds
> > Summing integer sequence   :  165 nanoseconds
> > 
> > Currently we have one +1 from Kurt to change the representation and 
> > possibly a -0 from Benedict. That's not really enough to make an exception 
> > to the code freeze. If you want it to happen (or not) you need to speak up 
> > otherwise only the default will change.
> > 
> > Regards,
> > Ariel
> > 
> > On Wed, Oct 17, 2018, at 6:40 AM, kurt greaves wrote:
> >> I think if we're going to drop it to 16k, we should invest in the compact
> >> sequencing as well. Just lowering it to 16k will have potentially a painful
> >> impact on anyone running low memory nodes, but if we can do it without the
> >> memory impact I don't think there's any reason to wait another major
> >> version to implement it.
> >> 
> >> Having said that, we should probably benchmark the two representations
> >> Ariel has come up with.
> >> 
> >> On Wed, 17 Oct 2018 at 20:17, Alain RODRIGUEZ  wrote:
> >> 
> >>> +1
> >>> 
> >>> I would guess a lot of C* clusters/tables have this option set to the
> >>> default value, 

Re: Built in trigger: double-write for app migration

[Jonathan Ellis]

Isn't this what CDC was designed for?

https://issues.apache.org/jira/browse/CASSANDRA-8844

On Thu, Oct 18, 2018 at 10:54 AM Carl Mueller
 wrote:

> tl;dr: a generic trigger on TABLES that will mirror all writes to
> facilitate data migrations between clusters or systems. What is necessary
> to ensure full write mirroring/coherency?
>
> When cassandra clusters have several "apps" aka keyspaces serving
> applications colocated on them, but the app/keyspace bandwidth and size
> demands begin impacting other keyspaces/apps, then one strategy is to
> migrate the keyspace to its own dedicated cluster.
>
> With backups/sstableloading, this will entail a delay and therefore a
> "coherency" shortfall between the clusters. So typically one would employ a
> "double write, read once":
>
> - all updates are mirrored to both clusters
> - writes come from the current most coherent.
>
> Often two sstable loads are done:
>
> 1) first load
> 2) turn on double writes/write mirroring
> 3) a second load is done to finalize coherency
> 4) switch the app to point to the new cluster now that it is coherent
>
> The double writes and read is the sticking point. We could do it at the app
> layer, but if the app wasn't written with that, it is a lot of testing and
> customization specific to the framework.
>
> We could theoretically do some sort of proxying of the java-driver somehow,
> but all the async structures and complex interfaces/apis would be difficult
> to proxy. Maybe there is a lower level in the java-driver that is possible.
> This also would only apply to the java-driver, and not
> python/go/javascript/other drivers.
>
> Finally, I suppose we could do a trigger on the tables. It would be really
> nice if we could add to the cassandra toolbox the basics of a write
> mirroring trigger that could be activated "fairly easily"... now I know
> there are the complexities of inter-cluster access, and if we are even
> using cassandra as the target mirror system (for example there is an
> article on triggers write-mirroring to kafka:
> https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
>
> And this starts to get into the complexities of hinted handoff as well. But
> fundamentally this seems something that would be a very nice feature
> (especially when you NEED it) to have in the core of cassandra.
>
> Finally, is the mutation hook in triggers sufficient to track all incoming
> mutations (outside of "shudder" other triggers generating data)
>


-- 
Jonathan Ellis
co-founder, http://www.datastax.com
@spyced

Re: Built in trigger: double-write for app migration

[Carl Mueller]

Thanks. Well, at a minimum I'll probably start writing something soon for
trigger-based write mirroring, and we will probably support kafka and
another cassandra cluster, so if those seem to work I will contribute
those.

On Thu, Oct 18, 2018 at 11:27 AM Jeff Jirsa  wrote:

> The write sampling is adding an extra instance with the same schema to
> test things like yaml params or compaction without impacting reads or
> correctness - it’s different than what you describe
>
>
>
> --
> Jeff Jirsa
>
>
> > On Oct 18, 2018, at 5:57 PM, Carl Mueller 
> > 
> wrote:
> >
> > I guess there is also write-survey-mode from cass 1.1:
> >
> > https://issues.apache.org/jira/browse/CASSANDRA-3452
> >
> > Were triggers intended to supersede this capability? I can't find a lot
> of
> > "user level" info on it.
> >
> >
> > On Thu, Oct 18, 2018 at 10:53 AM Carl Mueller <
> carl.muel...@smartthings.com>
> > wrote:
> >
> >> tl;dr: a generic trigger on TABLES that will mirror all writes to
> >> facilitate data migrations between clusters or systems. What is
> necessary
> >> to ensure full write mirroring/coherency?
> >>
> >> When cassandra clusters have several "apps" aka keyspaces serving
> >> applications colocated on them, but the app/keyspace bandwidth and size
> >> demands begin impacting other keyspaces/apps, then one strategy is to
> >> migrate the keyspace to its own dedicated cluster.
> >>
> >> With backups/sstableloading, this will entail a delay and therefore a
> >> "coherency" shortfall between the clusters. So typically one would
> employ a
> >> "double write, read once":
> >>
> >> - all updates are mirrored to both clusters
> >> - writes come from the current most coherent.
> >>
> >> Often two sstable loads are done:
> >>
> >> 1) first load
> >> 2) turn on double writes/write mirroring
> >> 3) a second load is done to finalize coherency
> >> 4) switch the app to point to the new cluster now that it is coherent
> >>
> >> The double writes and read is the sticking point. We could do it at the
> >> app layer, but if the app wasn't written with that, it is a lot of
> testing
> >> and customization specific to the framework.
> >>
> >> We could theoretically do some sort of proxying of the java-driver
> >> somehow, but all the async structures and complex interfaces/apis would
> be
> >> difficult to proxy. Maybe there is a lower level in the java-driver
> that is
> >> possible. This also would only apply to the java-driver, and not
> >> python/go/javascript/other drivers.
> >>
> >> Finally, I suppose we could do a trigger on the tables. It would be
> really
> >> nice if we could add to the cassandra toolbox the basics of a write
> >> mirroring trigger that could be activated "fairly easily"... now I know
> >> there are the complexities of inter-cluster access, and if we are even
> >> using cassandra as the target mirror system (for example there is an
> >> article on triggers write-mirroring to kafka:
> >> https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
> >>
> >> And this starts to get into the complexities of hinted handoff as well.
> >> But fundamentally this seems something that would be a very nice feature
> >> (especially when you NEED it) to have in the core of cassandra.
> >>
> >> Finally, is the mutation hook in triggers sufficient to track all
> incoming
> >> mutations (outside of "shudder" other triggers generating data)
> >>
> >>
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
>
>

Re: Built in trigger: double-write for app migration

[Jeff Jirsa]

The write sampling is adding an extra instance with the same schema to test 
things like yaml params or compaction without impacting reads or correctness - 
it’s different than what you describe



-- 
Jeff Jirsa


> On Oct 18, 2018, at 5:57 PM, Carl Mueller 
>  wrote:
> 
> I guess there is also write-survey-mode from cass 1.1:
> 
> https://issues.apache.org/jira/browse/CASSANDRA-3452
> 
> Were triggers intended to supersede this capability? I can't find a lot of
> "user level" info on it.
> 
> 
> On Thu, Oct 18, 2018 at 10:53 AM Carl Mueller 
> wrote:
> 
>> tl;dr: a generic trigger on TABLES that will mirror all writes to
>> facilitate data migrations between clusters or systems. What is necessary
>> to ensure full write mirroring/coherency?
>> 
>> When cassandra clusters have several "apps" aka keyspaces serving
>> applications colocated on them, but the app/keyspace bandwidth and size
>> demands begin impacting other keyspaces/apps, then one strategy is to
>> migrate the keyspace to its own dedicated cluster.
>> 
>> With backups/sstableloading, this will entail a delay and therefore a
>> "coherency" shortfall between the clusters. So typically one would employ a
>> "double write, read once":
>> 
>> - all updates are mirrored to both clusters
>> - writes come from the current most coherent.
>> 
>> Often two sstable loads are done:
>> 
>> 1) first load
>> 2) turn on double writes/write mirroring
>> 3) a second load is done to finalize coherency
>> 4) switch the app to point to the new cluster now that it is coherent
>> 
>> The double writes and read is the sticking point. We could do it at the
>> app layer, but if the app wasn't written with that, it is a lot of testing
>> and customization specific to the framework.
>> 
>> We could theoretically do some sort of proxying of the java-driver
>> somehow, but all the async structures and complex interfaces/apis would be
>> difficult to proxy. Maybe there is a lower level in the java-driver that is
>> possible. This also would only apply to the java-driver, and not
>> python/go/javascript/other drivers.
>> 
>> Finally, I suppose we could do a trigger on the tables. It would be really
>> nice if we could add to the cassandra toolbox the basics of a write
>> mirroring trigger that could be activated "fairly easily"... now I know
>> there are the complexities of inter-cluster access, and if we are even
>> using cassandra as the target mirror system (for example there is an
>> article on triggers write-mirroring to kafka:
>> https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
>> 
>> And this starts to get into the complexities of hinted handoff as well.
>> But fundamentally this seems something that would be a very nice feature
>> (especially when you NEED it) to have in the core of cassandra.
>> 
>> Finally, is the mutation hook in triggers sufficient to track all incoming
>> mutations (outside of "shudder" other triggers generating data)
>> 
>> 
>> 
>> 

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Built in trigger: double-write for app migration

[Carl Mueller]

I guess there is also write-survey-mode from cass 1.1:

https://issues.apache.org/jira/browse/CASSANDRA-3452

Were triggers intended to supersede this capability? I can't find a lot of
"user level" info on it.


On Thu, Oct 18, 2018 at 10:53 AM Carl Mueller 
wrote:

> tl;dr: a generic trigger on TABLES that will mirror all writes to
> facilitate data migrations between clusters or systems. What is necessary
> to ensure full write mirroring/coherency?
>
> When cassandra clusters have several "apps" aka keyspaces serving
> applications colocated on them, but the app/keyspace bandwidth and size
> demands begin impacting other keyspaces/apps, then one strategy is to
> migrate the keyspace to its own dedicated cluster.
>
> With backups/sstableloading, this will entail a delay and therefore a
> "coherency" shortfall between the clusters. So typically one would employ a
> "double write, read once":
>
> - all updates are mirrored to both clusters
> - writes come from the current most coherent.
>
> Often two sstable loads are done:
>
> 1) first load
> 2) turn on double writes/write mirroring
> 3) a second load is done to finalize coherency
> 4) switch the app to point to the new cluster now that it is coherent
>
> The double writes and read is the sticking point. We could do it at the
> app layer, but if the app wasn't written with that, it is a lot of testing
> and customization specific to the framework.
>
> We could theoretically do some sort of proxying of the java-driver
> somehow, but all the async structures and complex interfaces/apis would be
> difficult to proxy. Maybe there is a lower level in the java-driver that is
> possible. This also would only apply to the java-driver, and not
> python/go/javascript/other drivers.
>
> Finally, I suppose we could do a trigger on the tables. It would be really
> nice if we could add to the cassandra toolbox the basics of a write
> mirroring trigger that could be activated "fairly easily"... now I know
> there are the complexities of inter-cluster access, and if we are even
> using cassandra as the target mirror system (for example there is an
> article on triggers write-mirroring to kafka:
> https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).
>
> And this starts to get into the complexities of hinted handoff as well.
> But fundamentally this seems something that would be a very nice feature
> (especially when you NEED it) to have in the core of cassandra.
>
> Finally, is the mutation hook in triggers sufficient to track all incoming
> mutations (outside of "shudder" other triggers generating data)
>
>
>
>

Built in trigger: double-write for app migration

[Carl Mueller]

tl;dr: a generic trigger on TABLES that will mirror all writes to
facilitate data migrations between clusters or systems. What is necessary
to ensure full write mirroring/coherency?

When cassandra clusters have several "apps" aka keyspaces serving
applications colocated on them, but the app/keyspace bandwidth and size
demands begin impacting other keyspaces/apps, then one strategy is to
migrate the keyspace to its own dedicated cluster.

With backups/sstableloading, this will entail a delay and therefore a
"coherency" shortfall between the clusters. So typically one would employ a
"double write, read once":

- all updates are mirrored to both clusters
- writes come from the current most coherent.

Often two sstable loads are done:

1) first load
2) turn on double writes/write mirroring
3) a second load is done to finalize coherency
4) switch the app to point to the new cluster now that it is coherent

The double writes and read is the sticking point. We could do it at the app
layer, but if the app wasn't written with that, it is a lot of testing and
customization specific to the framework.

We could theoretically do some sort of proxying of the java-driver somehow,
but all the async structures and complex interfaces/apis would be difficult
to proxy. Maybe there is a lower level in the java-driver that is possible.
This also would only apply to the java-driver, and not
python/go/javascript/other drivers.

Finally, I suppose we could do a trigger on the tables. It would be really
nice if we could add to the cassandra toolbox the basics of a write
mirroring trigger that could be activated "fairly easily"... now I know
there are the complexities of inter-cluster access, and if we are even
using cassandra as the target mirror system (for example there is an
article on triggers write-mirroring to kafka:
https://dzone.com/articles/cassandra-to-kafka-data-pipeline-part-1).

And this starts to get into the complexities of hinted handoff as well. But
fundamentally this seems something that would be a very nice feature
(especially when you NEED it) to have in the core of cassandra.

Finally, is the mutation hook in triggers sufficient to track all incoming
mutations (outside of "shudder" other triggers generating data)

Re: Using Cassandra as local db without cluster

[Aleksey Yeshchenko]

I agree with Jeff here.

Furthermore, Cassandra should generally be your solution of last resort - if 
nothing else works out.

In your case I’d try sqlite or leveldb (or rocksdb).

> On 18 Oct 2018, at 11:46, Jeff Jirsa  wrote:
> 
> I can’t think of a situation where I’d choose Cassandra as a database in a 
> single-host use case (if you’re sure it’ll never be more than one machine).
> 
> -- 
> Jeff Jirsa
> 
> 
>> On Oct 18, 2018, at 12:31 PM, Abdelkrim Fitouri  wrote:
>> 
>> Hello,
>> 
>> I am wondering if using cassandra as one local database without the cluster
>> capabilities has a sens, (i cannot do multi node cluster due to a technical
>> constraint)
>> 
>> I have an application with a purpose to store a dynamic number of colones
>> on each rows (thing that i cannot do with classical relational database),
>> and i don't want to use documents based nosql database to avoid using Json
>> marshal and unmarshal treatments...
>> 
>> Does cassandra with only one node and with a well designer model based on
>> queries and partition keys can lead to best performance than postgresql ?
>> 
>> Does cassandra have some limitation about the size of data ? about the
>> number of partition on a node ?
>> 
>> Thanks for any details or help.
>> 
>> --
>> 
>> Best Regards.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: dev-h...@cassandra.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Using Cassandra as local db without cluster

[Abdelkrim Fitouri]

>
> ---> Postgresql  allows you tu use array type or map type with dynamic
> number of records, provided of course that the cardinality of the
> collection is not "too" big
>

Thanks for these details, but what do you mean about the cardinality of the
collection is not too big ?

In my solution a collection can have between 5 elements and 500 elements
and an element is about 256 caracter.

Kind regards.

On Thu, Oct 18, 2018 at 12:31 PM Abdelkrim Fitouri 
> wrote:
>
> > Hello,
> >
> > I am wondering if using cassandra as one local database without the
> cluster
> > capabilities has a sens, (i cannot do multi node cluster due to a
> technical
> > constraint)
> >
> > I have an application with a purpose to store a dynamic number of colones
> > on each rows (thing that i cannot do with classical relational database),
> > and i don't want to use documents based nosql database to avoid using
> Json
> > marshal and unmarshal treatments...
> >
> > Does cassandra with only one node and with a well designer model based on
> > queries and partition keys can lead to best performance than postgresql ?
> >
> > Does cassandra have some limitation about the size of data ? about the
> > number of partition on a node ?
> >
> > Thanks for any details or help.
> >
> > --
> >
> > Best Regards.
> >
>

Re: Using Cassandra as local db without cluster

[Jeff Jirsa]

I can’t think of a situation where I’d choose Cassandra as a database in a 
single-host use case (if you’re sure it’ll never be more than one machine).

-- 
Jeff Jirsa


> On Oct 18, 2018, at 12:31 PM, Abdelkrim Fitouri  wrote:
> 
> Hello,
> 
> I am wondering if using cassandra as one local database without the cluster
> capabilities has a sens, (i cannot do multi node cluster due to a technical
> constraint)
> 
> I have an application with a purpose to store a dynamic number of colones
> on each rows (thing that i cannot do with classical relational database),
> and i don't want to use documents based nosql database to avoid using Json
> marshal and unmarshal treatments...
> 
> Does cassandra with only one node and with a well designer model based on
> queries and partition keys can lead to best performance than postgresql ?
> 
> Does cassandra have some limitation about the size of data ? about the
> number of partition on a node ?
> 
> Thanks for any details or help.
> 
> --
> 
> Best Regards.

-
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org

Re: Using Cassandra as local db without cluster

[DuyHai Doan]

I have an application with a purpose to store a dynamic number of colones
on each rows (thing that i cannot do with classical relational database),

---> Postgresql  allows you tu use array type or map type with dynamic
number of records, provided of course that the cardinality of the
collection is not "too" big

On Thu, Oct 18, 2018 at 12:31 PM Abdelkrim Fitouri 
wrote:

> Hello,
>
> I am wondering if using cassandra as one local database without the cluster
> capabilities has a sens, (i cannot do multi node cluster due to a technical
> constraint)
>
> I have an application with a purpose to store a dynamic number of colones
> on each rows (thing that i cannot do with classical relational database),
> and i don't want to use documents based nosql database to avoid using Json
> marshal and unmarshal treatments...
>
> Does cassandra with only one node and with a well designer model based on
> queries and partition keys can lead to best performance than postgresql ?
>
> Does cassandra have some limitation about the size of data ? about the
> number of partition on a node ?
>
> Thanks for any details or help.
>
> --
>
> Best Regards.
>

Using Cassandra as local db without cluster

[Abdelkrim Fitouri]

Hello,

I am wondering if using cassandra as one local database without the cluster
capabilities has a sens, (i cannot do multi node cluster due to a technical
constraint)

I have an application with a purpose to store a dynamic number of colones
on each rows (thing that i cannot do with classical relational database),
and i don't want to use documents based nosql database to avoid using Json
marshal and unmarshal treatments...

Does cassandra with only one node and with a well designer model based on
queries and partition keys can lead to best performance than postgresql ?

Does cassandra have some limitation about the size of data ? about the
number of partition on a node ?

Thanks for any details or help.

--

Best Regards.

Re: CASSANDRA-13241 lower default chunk_length_in_kb

[Benedict Elliott Smith]

FWIW, I’m not -0, just think that long after the freeze date a change like this 
needs a strong mandate from the community.  I think the change is a good one.





> On 17 Oct 2018, at 22:09, Ariel Weisberg  wrote:
> 
> Hi,
> 
> It's really not appreciably slower compared to the decompression we are going 
> to do which is going to take several microseconds. Decompression is also 
> going to be faster because we are going to do less unnecessary decompression 
> and the decompression itself may be faster since it may fit in a higher level 
> cache better. I ran a microbenchmark comparing them.
> 
> https://issues.apache.org/jira/browse/CASSANDRA-13241?focusedCommentId=16653988=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16653988
> 
> Fetching a long from memory:   56 nanoseconds
> Compact integer sequence   :   80 nanoseconds
> Summing integer sequence   :  165 nanoseconds
> 
> Currently we have one +1 from Kurt to change the representation and possibly 
> a -0 from Benedict. That's not really enough to make an exception to the code 
> freeze. If you want it to happen (or not) you need to speak up otherwise only 
> the default will change.
> 
> Regards,
> Ariel
> 
> On Wed, Oct 17, 2018, at 6:40 AM, kurt greaves wrote:
>> I think if we're going to drop it to 16k, we should invest in the compact
>> sequencing as well. Just lowering it to 16k will have potentially a painful
>> impact on anyone running low memory nodes, but if we can do it without the
>> memory impact I don't think there's any reason to wait another major
>> version to implement it.
>> 
>> Having said that, we should probably benchmark the two representations
>> Ariel has come up with.
>> 
>> On Wed, 17 Oct 2018 at 20:17, Alain RODRIGUEZ  wrote:
>> 
>>> +1
>>> 
>>> I would guess a lot of C* clusters/tables have this option set to the
>>> default value, and not many of them are having the need for reading so big
>>> chunks of data.
>>> I believe this will greatly limit disk overreads for a fair amount (a big
>>> majority?) of new users. It seems fair enough to change this default value,
>>> I also think 4.0 is a nice place to do this.
>>> 
>>> Thanks for taking care of this Ariel and for making sure there is a
>>> consensus here as well,
>>> 
>>> C*heers,
>>> ---
>>> Alain Rodriguez - al...@thelastpickle.com
>>> France / Spain
>>> 
>>> The Last Pickle - Apache Cassandra Consulting
>>> http://www.thelastpickle.com
>>> 
>>> Le sam. 13 oct. 2018 à 08:52, Ariel Weisberg  a écrit :
>>> 
 Hi,
 
 This would only impact new tables, existing tables would get their
 chunk_length_in_kb from the existing schema. It's something we record in
>>> a
 system table.
 
 I have an implementation of a compact integer sequence that only requires
 37% of the memory required today. So we could do this with only slightly
 more than doubling the memory used. I'll post that to the JIRA soon.
 
 Ariel
 
 On Fri, Oct 12, 2018, at 1:56 AM, Jeff Jirsa wrote:
> 
> 
> I think 16k is a better default, but it should only affect new tables.
> Whoever changes it, please make sure you think about the upgrade path.
> 
> 
>> On Oct 12, 2018, at 2:31 AM, Ben Bromhead 
>>> wrote:
>> 
>> This is something that's bugged me for ages, tbh the performance gain
 for
>> most use cases far outweighs the increase in memory usage and I would
 even
>> be in favor of changing the default now, optimizing the storage cost
 later
>> (if it's found to be worth it).
>> 
>> For some anecdotal evidence:
>> 4kb is usually what we end setting it to, 16kb feels more reasonable
 given
>> the memory impact, but what would be the point if practically, most
 folks
>> set it to 4kb anyway?
>> 
>> Note that chunk_length will largely be dependent on your read sizes,
 but 4k
>> is the floor for most physical devices in terms of ones block size.
>> 
>> +1 for making this change in 4.0 given the small size and the large
>> improvement to new users experience (as long as we are explicit in
>>> the
>> documentation about memory consumption).
>> 
>> 
>>> On Thu, Oct 11, 2018 at 7:11 PM Ariel Weisberg 
 wrote:
>>> 
>>> Hi,
>>> 
>>> This is regarding
 https://issues.apache.org/jira/browse/CASSANDRA-13241
>>> 
>>> This ticket has languished for a while. IMO it's too late in 4.0 to
>>> implement a more memory efficient representation for compressed
>>> chunk
>>> offsets. However I don't think we should put out another release
>>> with
 the
>>> current 64k default as it's pretty unreasonable.
>>> 
>>> I propose that we lower the value to 16kb. 4k might never be the
 correct
>>> default anyways as there is a cost to compression and 16k will still
 be a
>>> large improvement.
>>> 
>>> Benedict and Jon