date:20200716

Re: Cqlsh copy command on a larger data set

2020-07-16 Thread Jai Bheemsen Rao Dhanwada

thank you

On Thu, Jul 16, 2020 at 12:29 PM Alex Ott  wrote:

> look into a series of the blog posts that I sent, I think that it should
> be in the 4th post
>
> On Thu, Jul 16, 2020 at 8:27 PM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
>> okay, is there a way to export the TTL using CQLsh or DSBulk?
>>
>> On Thu, Jul 16, 2020 at 11:20 AM Alex Ott  wrote:
>>
>>> if you didn't export TTL explicitly, and didn't load it back, then
>>> you'll get not expirable data.
>>>
>>> On Thu, Jul 16, 2020 at 7:48 PM Jai Bheemsen Rao Dhanwada <
>>> jaibheem...@gmail.com> wrote:
>>>
 In tried verify metadata, In case of writetime it is setting it as
 insert time but the TTL value is showing as null. Is this expected? Does
 this mean this record will never expire after the insert?
 Is there any alternative to preserve the TTL ?

 In the new Table inserted with Cqlsh and Dsbulk
 cqlsh > SELECT ttl(secret) from ks_blah.cf_blah ;

  ttl(secret)
 --
  null
  null

 (2 rows)

 In the old table where the data was written from application

 cqlsh > SELECT ttl(secret) from ks_old.cf_old ;

  ttl(secret)
 
  4517461
  4525958

 (2 rows)

 On Wed, Jul 15, 2020 at 1:17 PM Jai Bheemsen Rao Dhanwada <
 jaibheem...@gmail.com> wrote:

> thank you
>
> On Wed, Jul 15, 2020 at 1:11 PM Russell Spitzer <
> russell.spit...@gmail.com> wrote:
>
>> Alex is referring to the "writetime" and "tttl" values for each cell.
>> Most tools copy via CQL writes and don't by default copy those previous
>> writetime and ttl values and instead just give a new writetime value 
>> which
>> matches the copy time rather than initial insert time.
>>
>> On Wed, Jul 15, 2020 at 3:01 PM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> Hello Alex,
>>>
>>>
>>>- use DSBulk - it's a very effective tool for unloading &
>>>loading data from/to Cassandra/DSE. Use zstd compression for 
>>> offloaded data
>>>to save disk space (see blog links below for more details).  But the 
>>> *preserving
>>>metadata* could be a problem.
>>>
>>> Here what exactly do you mean by "preserving metadata" ? would you
>>> mind explaining?
>>>
>>> On Tue, Jul 14, 2020 at 8:50 AM Jai Bheemsen Rao Dhanwada <
>>> jaibheem...@gmail.com> wrote:
>>>
 Thank you for the suggestions

 On Tue, Jul 14, 2020 at 1:42 AM Alex Ott  wrote:

> CQLSH definitely won't work for that amount of data, so you need
> to use other tools.
>
> But before selecting them, you need to define requirements. For
> example:
>
>1. Are you copying the data into tables with exactly the same
>structure?
>2. Do you need to preserve metadata, like, writetime & TTL?
>
> Depending on that, you may have following choices:
>
>- use sstableloader - it will preserve all metadata, like, ttl
>and writetime. You just need to copy SSTable files, or stream 
> directly from
>the source cluster.  But this will require copying of data into 
> tables with
>exactly same structure (and in case of UDTs, the keyspace names 
> should be
>the same)
>- use DSBulk - it's a very effective tool for unloading &
>loading data from/to Cassandra/DSE. Use zstd compression for 
> offloaded data
>to save disk space (see blog links below for more details).  But 
> the
>preserving metadata could be a problem.
>- use Spark + Spark Cassandra Connector. But also, preserving
>the metadata is not an easy task, and requires programming to 
> handle all
>edge cases (see
>https://datastax-oss.atlassian.net/browse/SPARKC-596 for
>details)
>
>
> blog series on DSBulk:
>
>-
>
> https://www.datastax.com/blog/2019/03/datastax-bulk-loader-introduction-and-loading
>-
>
> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-more-loading
>-
>
> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-common-settings
>-
>
> https://www.datastax.com/blog/2019/06/datastax-bulk-loader-unloading
>-
>https://www.datastax.com/blog/2019/07/datastax-bulk-loader-counting
>-
>
> https://www.datastax.com/blog/2019/12/datastax-bulk-loader-examples-loading-other-locations
>
>
> On Tue, Jul 14, 2020 at 1:47 AM Jai Bheemsen Rao Dhanwada <
>

Re: Cqlsh copy command on a larger data set

2020-07-16 Thread Alex Ott

look into a series of the blog posts that I sent, I think that it should be
in the 4th post

On Thu, Jul 16, 2020 at 8:27 PM Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:

> okay, is there a way to export the TTL using CQLsh or DSBulk?
>
> On Thu, Jul 16, 2020 at 11:20 AM Alex Ott  wrote:
>
>> if you didn't export TTL explicitly, and didn't load it back, then you'll
>> get not expirable data.
>>
>> On Thu, Jul 16, 2020 at 7:48 PM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> In tried verify metadata, In case of writetime it is setting it as
>>> insert time but the TTL value is showing as null. Is this expected? Does
>>> this mean this record will never expire after the insert?
>>> Is there any alternative to preserve the TTL ?
>>>
>>> In the new Table inserted with Cqlsh and Dsbulk
>>> cqlsh > SELECT ttl(secret) from ks_blah.cf_blah ;
>>>
>>>  ttl(secret)
>>> --
>>>  null
>>>  null
>>>
>>> (2 rows)
>>>
>>> In the old table where the data was written from application
>>>
>>> cqlsh > SELECT ttl(secret) from ks_old.cf_old ;
>>>
>>>  ttl(secret)
>>> 
>>>  4517461
>>>  4525958
>>>
>>> (2 rows)
>>>
>>> On Wed, Jul 15, 2020 at 1:17 PM Jai Bheemsen Rao Dhanwada <
>>> jaibheem...@gmail.com> wrote:
>>>
 thank you

 On Wed, Jul 15, 2020 at 1:11 PM Russell Spitzer <
 russell.spit...@gmail.com> wrote:

> Alex is referring to the "writetime" and "tttl" values for each cell.
> Most tools copy via CQL writes and don't by default copy those previous
> writetime and ttl values and instead just give a new writetime value which
> matches the copy time rather than initial insert time.
>
> On Wed, Jul 15, 2020 at 3:01 PM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
>> Hello Alex,
>>
>>
>>- use DSBulk - it's a very effective tool for unloading & loading
>>data from/to Cassandra/DSE. Use zstd compression for offloaded data 
>> to save
>>disk space (see blog links below for more details).  But the 
>> *preserving
>>metadata* could be a problem.
>>
>> Here what exactly do you mean by "preserving metadata" ? would you
>> mind explaining?
>>
>> On Tue, Jul 14, 2020 at 8:50 AM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> Thank you for the suggestions
>>>
>>> On Tue, Jul 14, 2020 at 1:42 AM Alex Ott  wrote:
>>>
 CQLSH definitely won't work for that amount of data, so you need to
 use other tools.

 But before selecting them, you need to define requirements. For
 example:

1. Are you copying the data into tables with exactly the same
structure?
2. Do you need to preserve metadata, like, writetime & TTL?

 Depending on that, you may have following choices:

- use sstableloader - it will preserve all metadata, like, ttl
and writetime. You just need to copy SSTable files, or stream 
 directly from
the source cluster.  But this will require copying of data into 
 tables with
exactly same structure (and in case of UDTs, the keyspace names 
 should be
the same)
- use DSBulk - it's a very effective tool for unloading &
loading data from/to Cassandra/DSE. Use zstd compression for 
 offloaded data
to save disk space (see blog links below for more details).  But the
preserving metadata could be a problem.
- use Spark + Spark Cassandra Connector. But also, preserving
the metadata is not an easy task, and requires programming to 
 handle all
edge cases (see
https://datastax-oss.atlassian.net/browse/SPARKC-596 for
details)


 blog series on DSBulk:

-

 https://www.datastax.com/blog/2019/03/datastax-bulk-loader-introduction-and-loading
-

 https://www.datastax.com/blog/2019/04/datastax-bulk-loader-more-loading
-

 https://www.datastax.com/blog/2019/04/datastax-bulk-loader-common-settings
-
https://www.datastax.com/blog/2019/06/datastax-bulk-loader-unloading
-
https://www.datastax.com/blog/2019/07/datastax-bulk-loader-counting
-

 https://www.datastax.com/blog/2019/12/datastax-bulk-loader-examples-loading-other-locations


 On Tue, Jul 14, 2020 at 1:47 AM Jai Bheemsen Rao Dhanwada <
 jaibheem...@gmail.com> wrote:

> Hello,
>
> I would like to copy some data from one cassandra cluster to
> another cassandra cluster using the CQLSH copy command. Is this the 
> good
>

Re: Cqlsh copy command on a larger data set

2020-07-16 Thread Jai Bheemsen Rao Dhanwada

okay, is there a way to export the TTL using CQLsh or DSBulk?

On Thu, Jul 16, 2020 at 11:20 AM Alex Ott  wrote:

> if you didn't export TTL explicitly, and didn't load it back, then you'll
> get not expirable data.
>
> On Thu, Jul 16, 2020 at 7:48 PM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
>> In tried verify metadata, In case of writetime it is setting it as insert
>> time but the TTL value is showing as null. Is this expected? Does this mean
>> this record will never expire after the insert?
>> Is there any alternative to preserve the TTL ?
>>
>> In the new Table inserted with Cqlsh and Dsbulk
>> cqlsh > SELECT ttl(secret) from ks_blah.cf_blah ;
>>
>>  ttl(secret)
>> --
>>  null
>>  null
>>
>> (2 rows)
>>
>> In the old table where the data was written from application
>>
>> cqlsh > SELECT ttl(secret) from ks_old.cf_old ;
>>
>>  ttl(secret)
>> 
>>  4517461
>>  4525958
>>
>> (2 rows)
>>
>> On Wed, Jul 15, 2020 at 1:17 PM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> thank you
>>>
>>> On Wed, Jul 15, 2020 at 1:11 PM Russell Spitzer <
>>> russell.spit...@gmail.com> wrote:
>>>
 Alex is referring to the "writetime" and "tttl" values for each cell.
 Most tools copy via CQL writes and don't by default copy those previous
 writetime and ttl values and instead just give a new writetime value which
 matches the copy time rather than initial insert time.

 On Wed, Jul 15, 2020 at 3:01 PM Jai Bheemsen Rao Dhanwada <
 jaibheem...@gmail.com> wrote:

> Hello Alex,
>
>
>- use DSBulk - it's a very effective tool for unloading & loading
>data from/to Cassandra/DSE. Use zstd compression for offloaded data to 
> save
>disk space (see blog links below for more details).  But the 
> *preserving
>metadata* could be a problem.
>
> Here what exactly do you mean by "preserving metadata" ? would you
> mind explaining?
>
> On Tue, Jul 14, 2020 at 8:50 AM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
>> Thank you for the suggestions
>>
>> On Tue, Jul 14, 2020 at 1:42 AM Alex Ott  wrote:
>>
>>> CQLSH definitely won't work for that amount of data, so you need to
>>> use other tools.
>>>
>>> But before selecting them, you need to define requirements. For
>>> example:
>>>
>>>1. Are you copying the data into tables with exactly the same
>>>structure?
>>>2. Do you need to preserve metadata, like, writetime & TTL?
>>>
>>> Depending on that, you may have following choices:
>>>
>>>- use sstableloader - it will preserve all metadata, like, ttl
>>>and writetime. You just need to copy SSTable files, or stream 
>>> directly from
>>>the source cluster.  But this will require copying of data into 
>>> tables with
>>>exactly same structure (and in case of UDTs, the keyspace names 
>>> should be
>>>the same)
>>>- use DSBulk - it's a very effective tool for unloading &
>>>loading data from/to Cassandra/DSE. Use zstd compression for 
>>> offloaded data
>>>to save disk space (see blog links below for more details).  But the
>>>preserving metadata could be a problem.
>>>- use Spark + Spark Cassandra Connector. But also, preserving
>>>the metadata is not an easy task, and requires programming to handle 
>>> all
>>>edge cases (see
>>>https://datastax-oss.atlassian.net/browse/SPARKC-596 for details)
>>>
>>>
>>> blog series on DSBulk:
>>>
>>>-
>>>
>>> https://www.datastax.com/blog/2019/03/datastax-bulk-loader-introduction-and-loading
>>>-
>>>
>>> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-more-loading
>>>-
>>>
>>> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-common-settings
>>>-
>>>https://www.datastax.com/blog/2019/06/datastax-bulk-loader-unloading
>>>-
>>>https://www.datastax.com/blog/2019/07/datastax-bulk-loader-counting
>>>-
>>>
>>> https://www.datastax.com/blog/2019/12/datastax-bulk-loader-examples-loading-other-locations
>>>
>>>
>>> On Tue, Jul 14, 2020 at 1:47 AM Jai Bheemsen Rao Dhanwada <
>>> jaibheem...@gmail.com> wrote:
>>>
 Hello,

 I would like to copy some data from one cassandra cluster to
 another cassandra cluster using the CQLSH copy command. Is this the 
 good
 approach if the dataset size on the source cluster is very high(500G -
 1TB)? If not what is the safe approach? and are there any 
 limitations/known
 issues to keep in mind before attempting this?

>>>
>>>
>>> --
>>> With best wishes,Alex Ott
>>>

Re: Cqlsh copy command on a larger data set

2020-07-16 Thread Alex Ott

if you didn't export TTL explicitly, and didn't load it back, then you'll
get not expirable data.

On Thu, Jul 16, 2020 at 7:48 PM Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:

> In tried verify metadata, In case of writetime it is setting it as insert
> time but the TTL value is showing as null. Is this expected? Does this mean
> this record will never expire after the insert?
> Is there any alternative to preserve the TTL ?
>
> In the new Table inserted with Cqlsh and Dsbulk
> cqlsh > SELECT ttl(secret) from ks_blah.cf_blah ;
>
>  ttl(secret)
> --
>  null
>  null
>
> (2 rows)
>
> In the old table where the data was written from application
>
> cqlsh > SELECT ttl(secret) from ks_old.cf_old ;
>
>  ttl(secret)
> 
>  4517461
>  4525958
>
> (2 rows)
>
> On Wed, Jul 15, 2020 at 1:17 PM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
>> thank you
>>
>> On Wed, Jul 15, 2020 at 1:11 PM Russell Spitzer <
>> russell.spit...@gmail.com> wrote:
>>
>>> Alex is referring to the "writetime" and "tttl" values for each cell.
>>> Most tools copy via CQL writes and don't by default copy those previous
>>> writetime and ttl values and instead just give a new writetime value which
>>> matches the copy time rather than initial insert time.
>>>
>>> On Wed, Jul 15, 2020 at 3:01 PM Jai Bheemsen Rao Dhanwada <
>>> jaibheem...@gmail.com> wrote:
>>>
 Hello Alex,


- use DSBulk - it's a very effective tool for unloading & loading
data from/to Cassandra/DSE. Use zstd compression for offloaded data to 
 save
disk space (see blog links below for more details).  But the *preserving
metadata* could be a problem.

 Here what exactly do you mean by "preserving metadata" ? would you
 mind explaining?

 On Tue, Jul 14, 2020 at 8:50 AM Jai Bheemsen Rao Dhanwada <
 jaibheem...@gmail.com> wrote:

> Thank you for the suggestions
>
> On Tue, Jul 14, 2020 at 1:42 AM Alex Ott  wrote:
>
>> CQLSH definitely won't work for that amount of data, so you need to
>> use other tools.
>>
>> But before selecting them, you need to define requirements. For
>> example:
>>
>>1. Are you copying the data into tables with exactly the same
>>structure?
>>2. Do you need to preserve metadata, like, writetime & TTL?
>>
>> Depending on that, you may have following choices:
>>
>>- use sstableloader - it will preserve all metadata, like, ttl
>>and writetime. You just need to copy SSTable files, or stream 
>> directly from
>>the source cluster.  But this will require copying of data into 
>> tables with
>>exactly same structure (and in case of UDTs, the keyspace names 
>> should be
>>the same)
>>- use DSBulk - it's a very effective tool for unloading & loading
>>data from/to Cassandra/DSE. Use zstd compression for offloaded data 
>> to save
>>disk space (see blog links below for more details).  But the 
>> preserving
>>metadata could be a problem.
>>- use Spark + Spark Cassandra Connector. But also, preserving the
>>metadata is not an easy task, and requires programming to handle all 
>> edge
>>cases (see https://datastax-oss.atlassian.net/browse/SPARKC-596
>>for details)
>>
>>
>> blog series on DSBulk:
>>
>>-
>>
>> https://www.datastax.com/blog/2019/03/datastax-bulk-loader-introduction-and-loading
>>-
>>
>> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-more-loading
>>-
>>
>> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-common-settings
>>-
>>https://www.datastax.com/blog/2019/06/datastax-bulk-loader-unloading
>>-
>>https://www.datastax.com/blog/2019/07/datastax-bulk-loader-counting
>>-
>>
>> https://www.datastax.com/blog/2019/12/datastax-bulk-loader-examples-loading-other-locations
>>
>>
>> On Tue, Jul 14, 2020 at 1:47 AM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I would like to copy some data from one cassandra cluster to another
>>> cassandra cluster using the CQLSH copy command. Is this the good 
>>> approach
>>> if the dataset size on the source cluster is very high(500G - 1TB)? If 
>>> not
>>> what is the safe approach? and are there any limitations/known issues to
>>> keep in mind before attempting this?
>>>
>>
>>
>> --
>> With best wishes,Alex Ott
>> http://alexott.net/
>> Twitter: alexott_en (English), alexott (Russian)
>>
>

-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)

Re: Cqlsh copy command on a larger data set

2020-07-16 Thread Jai Bheemsen Rao Dhanwada

In tried verify metadata, In case of writetime it is setting it as insert
time but the TTL value is showing as null. Is this expected? Does this mean
this record will never expire after the insert?
Is there any alternative to preserve the TTL ?

In the new Table inserted with Cqlsh and Dsbulk
cqlsh > SELECT ttl(secret) from ks_blah.cf_blah ;

 ttl(secret)
--
 null
 null

(2 rows)

In the old table where the data was written from application

cqlsh > SELECT ttl(secret) from ks_old.cf_old ;

 ttl(secret)

 4517461
 4525958

(2 rows)

On Wed, Jul 15, 2020 at 1:17 PM Jai Bheemsen Rao Dhanwada <
jaibheem...@gmail.com> wrote:

> thank you
>
> On Wed, Jul 15, 2020 at 1:11 PM Russell Spitzer 
> wrote:
>
>> Alex is referring to the "writetime" and "tttl" values for each cell.
>> Most tools copy via CQL writes and don't by default copy those previous
>> writetime and ttl values and instead just give a new writetime value which
>> matches the copy time rather than initial insert time.
>>
>> On Wed, Jul 15, 2020 at 3:01 PM Jai Bheemsen Rao Dhanwada <
>> jaibheem...@gmail.com> wrote:
>>
>>> Hello Alex,
>>>
>>>
>>>- use DSBulk - it's a very effective tool for unloading & loading
>>>data from/to Cassandra/DSE. Use zstd compression for offloaded data to 
>>> save
>>>disk space (see blog links below for more details).  But the *preserving
>>>metadata* could be a problem.
>>>
>>> Here what exactly do you mean by "preserving metadata" ? would you mind
>>> explaining?
>>>
>>> On Tue, Jul 14, 2020 at 8:50 AM Jai Bheemsen Rao Dhanwada <
>>> jaibheem...@gmail.com> wrote:
>>>
 Thank you for the suggestions

 On Tue, Jul 14, 2020 at 1:42 AM Alex Ott  wrote:

> CQLSH definitely won't work for that amount of data, so you need to
> use other tools.
>
> But before selecting them, you need to define requirements. For
> example:
>
>1. Are you copying the data into tables with exactly the same
>structure?
>2. Do you need to preserve metadata, like, writetime & TTL?
>
> Depending on that, you may have following choices:
>
>- use sstableloader - it will preserve all metadata, like, ttl and
>writetime. You just need to copy SSTable files, or stream directly 
> from the
>source cluster.  But this will require copying of data into tables with
>exactly same structure (and in case of UDTs, the keyspace names should 
> be
>the same)
>- use DSBulk - it's a very effective tool for unloading & loading
>data from/to Cassandra/DSE. Use zstd compression for offloaded data to 
> save
>disk space (see blog links below for more details).  But the preserving
>metadata could be a problem.
>- use Spark + Spark Cassandra Connector. But also, preserving the
>metadata is not an easy task, and requires programming to handle all 
> edge
>cases (see https://datastax-oss.atlassian.net/browse/SPARKC-596
>for details)
>
>
> blog series on DSBulk:
>
>-
>
> https://www.datastax.com/blog/2019/03/datastax-bulk-loader-introduction-and-loading
>-
>https://www.datastax.com/blog/2019/04/datastax-bulk-loader-more-loading
>-
>
> https://www.datastax.com/blog/2019/04/datastax-bulk-loader-common-settings
>-
>https://www.datastax.com/blog/2019/06/datastax-bulk-loader-unloading
>-
>https://www.datastax.com/blog/2019/07/datastax-bulk-loader-counting
>-
>
> https://www.datastax.com/blog/2019/12/datastax-bulk-loader-examples-loading-other-locations
>
>
> On Tue, Jul 14, 2020 at 1:47 AM Jai Bheemsen Rao Dhanwada <
> jaibheem...@gmail.com> wrote:
>
>> Hello,
>>
>> I would like to copy some data from one cassandra cluster to another
>> cassandra cluster using the CQLSH copy command. Is this the good approach
>> if the dataset size on the source cluster is very high(500G - 1TB)? If 
>> not
>> what is the safe approach? and are there any limitations/known issues to
>> keep in mind before attempting this?
>>
>
>
> --
> With best wishes,Alex Ott
> http://alexott.net/
> Twitter: alexott_en (English), alexott (Russian)
>

Re: what is allowed and not allowed w.r.t altering cassandra table schema

2020-07-16 Thread Alex Ott

Hi

This is a quite big topic, maybe it should be a topic for a blog post, etc.
I've spent some time working with customers on that, so here is my TLDR:


   - You can add regular columns (not part of the primary key) to a table.
   You must not to add the column with the same name as another dropped column
   - this will lead to errors in commit log replay, and lead to problems with
   data in existing SSTables.
   - You can drop regular columns with some limitations:
   - we can't drop columns that are part of the primary key (if you need to
  do this, see the next section);
  - It's not possible to drop columns on tables that have materialized
  views, secondary or search indexes - if you still need to rename it, you
  need to drop view or index, and re-create it after renaming;
  - if you drop a column then re-add it, DSE does not restore the
  values written before the column was dropped;
   - It's not possible to change column type - this functionality did exist
   in some versions, but only for "compatible" data types, but it was removed
   from Cassandra as part of the CASSANDRA-12443, due the scalability
   problems. Don't try to drop the column & re-add it again with a new type -
   you'll get corrupt data. Actual changes in the column type should be done
   by:
  - adding a new column with desired type
  - running migration code that will copy data from existing columns
  - dropping the old column
  - To support process continuity, applications may work with both
  columns (read & write) during migration, and use only one after migration
  happened.
   - You can rename column that is the part of the primary key, but not the
   regular column
   - You can't change the primary key - you need to create a new table with
   desired primary key, and migrate data into it.
   - You can add new field to the UDT, and you can rename field in UDT, but
   not drop it


there are some tools to support schema evolution, for example:
https://github.com/hhandoko/cassandra-migration


On Wed, Jul 15, 2020 at 8:39 PM Manu Chadha  wrote:

> Hi
>
>
>
> What is allowed and not allowed w.r.t altering Cassandra table schema?
>
>
>
> Creating the right schema seems like the most step w.r.t using Cassandra.
> Coming from relational background, I still struggle to create schema which
> leverages duplication and per-query table (I end up creating relationships
> between tables).
>
>
>
> Even if I am able to create a schema which doesn’t have relationship
> between tables for now, my application will evolve in future and I might
> then have to change the schema to avoid creating relationships.
>
>
>
> In that respect, what would I be able to change and not change in a
> schema? If I add a new field (non-key), then for existing values I suppose
> the value of that new field will be null/empty. But if I am allowed to make
> the new field an additional key then what will be the value of this key for
> existing data?
>
>
>
> Thanks
>
> Manu
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>


-- 
With best wishes,Alex Ott
http://alexott.net/
Twitter: alexott_en (English), alexott (Russian)

Re: Cqlsh copy command on a larger data set

Re: Cqlsh copy command on a larger data set

Re: Cqlsh copy command on a larger data set

Re: Cqlsh copy command on a larger data set

Re: Cqlsh copy command on a larger data set

Re: what is allowed and not allowed w.r.t altering cassandra table schema

6 matches

Site Navigation

Mail list logo

Footer information