Re: Why does Cassandra need to have 2B column limit? why can't we have unlimited ?

[Dorian Hoxha]

Also, I'm not sure, but I don't think it's "cool" to write to multiple
lists in the same message. (based on postgresql mailing lists rules).
Example I'm not subscribed to those, and now the messages are separated.

On Wed, Oct 12, 2016 at 10:37 AM, Dorian Hoxha 
wrote:

> There are some issues working on larger partitions.
> Hbase doesn't do what you say! You have also to be carefull on hbase not
> to create large rows! But since they are globally-sorted, you can easily
> sort between them and create small rows.
>
> In my opinion, cassandra people are wrong, in that they say "globally
> sorted is the devil!" while all fb/google/etc actually use globally-sorted
> most of the time! You have to be careful though (just like with random
> partition)
>
> Can you tell what rowkey1, page1, col(x) actually are ? Maybe there is a
> way.
> The most "recent", means there's a timestamp in there ?
>
> On Wed, Oct 12, 2016 at 9:58 AM, Kant Kodali  wrote:
>
>> Hi All,
>>
>> I understand Cassandra can have a maximum of 2B rows per partition but in
>> practice some people seem to suggest the magic number is 100K. why not
>> create another partition/rowkey automatically (whenever we reach a safe
>> limit that  we consider would be efficient)  with auto increment bigint  as
>> a suffix appended to the new rowkey? so that the driver can return the new
>> rowkey  indicating that there is a new partition and so on...Now I
>> understand this would involve allowing partial row key searches which
>> currently Cassandra wouldn't do (but I believe HBASE does) and thinking
>> about token ranges and potentially many other things..
>>
>> My current problem is this
>>
>> I have a row key followed by bunch of columns (this is not time series
>> data)
>> and these columns can grow to any number so since I have 100K limit (or
>> whatever the number is. say some limit) I want to break the partition into
>> level/pages
>>
>> rowkey1, page1->col1, col2, col3..
>> rowkey1, page2->col1, col2, col3..
>>
>> now say my Cassandra db is populated with data and say my application
>> just got booted up and I want to most recent value of a certain partition
>> but I don't know which page it belongs to since my application just got
>> booted up? how do I solve this in the most efficient that is possible in
>> Cassandra today? I understand I can create MV, other tables that can hold
>> some auxiliary data such as number of pages per partition and so on..but
>> that involves the maintenance cost of that other table which I cannot
>> afford really because I have MV's, secondary indexes for other good
>> reasons. so it would be great if someone can explain the best way possible
>> as of today with Cassandra? By best way I mean is it possible with one
>> request? If Yes, then how? If not, then what is the next best way to solve
>> this?
>>
>> Thanks,
>> kant
>>
>
>

Re: Why does Cassandra need to have 2B column limit? why can't we have unlimited ?

[Dorian Hoxha]

There are some issues working on larger partitions.
Hbase doesn't do what you say! You have also to be carefull on hbase not to
create large rows! But since they are globally-sorted, you can easily sort
between them and create small rows.

In my opinion, cassandra people are wrong, in that they say "globally
sorted is the devil!" while all fb/google/etc actually use globally-sorted
most of the time! You have to be careful though (just like with random
partition)

Can you tell what rowkey1, page1, col(x) actually are ? Maybe there is a
way.
The most "recent", means there's a timestamp in there ?

On Wed, Oct 12, 2016 at 9:58 AM, Kant Kodali  wrote:

> Hi All,
>
> I understand Cassandra can have a maximum of 2B rows per partition but in
> practice some people seem to suggest the magic number is 100K. why not
> create another partition/rowkey automatically (whenever we reach a safe
> limit that  we consider would be efficient)  with auto increment bigint  as
> a suffix appended to the new rowkey? so that the driver can return the new
> rowkey  indicating that there is a new partition and so on...Now I
> understand this would involve allowing partial row key searches which
> currently Cassandra wouldn't do (but I believe HBASE does) and thinking
> about token ranges and potentially many other things..
>
> My current problem is this
>
> I have a row key followed by bunch of columns (this is not time series
> data)
> and these columns can grow to any number so since I have 100K limit (or
> whatever the number is. say some limit) I want to break the partition into
> level/pages
>
> rowkey1, page1->col1, col2, col3..
> rowkey1, page2->col1, col2, col3..
>
> now say my Cassandra db is populated with data and say my application just
> got booted up and I want to most recent value of a certain partition but I
> don't know which page it belongs to since my application just got booted
> up? how do I solve this in the most efficient that is possible in Cassandra
> today? I understand I can create MV, other tables that can hold some
> auxiliary data such as number of pages per partition and so on..but that
> involves the maintenance cost of that other table which I cannot afford
> really because I have MV's, secondary indexes for other good reasons. so it
> would be great if someone can explain the best way possible as of today
> with Cassandra? By best way I mean is it possible with one request? If Yes,
> then how? If not, then what is the next best way to solve this?
>
> Thanks,
> kant
>

Does increment/decrement by 0 generate any commits ?

[Dorian Hoxha]

I just have a bunch of counters in 1 row, and I want to selectively update
them. And I want to keep prepared queries. But I don't want to keep 30
prepared queries (1 for each counter column, but keep only 1). So in most
cases, I will increment 1 column by positive integer and the others by 0.

Makes sense ?

Re: Rationale for using Hazelcast in front of Cassandra?

[Dorian Hoxha]

Primary-key select is pretty fast in rdbms too and they also have caches.
By "close to" you mean in latency ?
Have you thought why people don't use cassandra as a cache ? While it
doesn't have LRU, it has TTL,replicatio,sharding.

On Fri, Oct 7, 2016 at 12:00 AM, KARR, DAVID  wrote:

> Clearly, with “traditional” RDBMSs, you tend to put a cache “close to” the
> client.  However, I was under the impression that Cassandra nodes could be
> positioned “close to” their clients, and Cassandra has its own cache (I
> believe), so how effective would it be to put a cache in front of a cache?
>
>
>
> *From:* Dorian Hoxha [mailto:dorian.ho...@gmail.com]
> *Sent:* Thursday, October 06, 2016 2:52 PM
> *To:* user@cassandra.apache.org
> *Subject:* Re: Rationale for using Hazelcast in front of Cassandra?
>
>
>
> Maybe when you can have very hot keys that can give trouble to your
> 3(replication) cassandra nodes ?
>
> Example: why does facebook use memcache ? They certainly have things
> distributed on thousands of servers.
>
>
>
> On Thu, Oct 6, 2016 at 11:40 PM, KARR, DAVID  wrote:
>
> I've seen use cases that briefly describe using Hazelcast as a "front-end"
> for Cassandra, perhaps as a cache.  This seems counterintuitive to me.  Can
> someone describe to me when this kind of architecture might make sense?
>
>
>

Re: Rationale for using Hazelcast in front of Cassandra?

[Dorian Hoxha]

Maybe when you can have very hot keys that can give trouble to your
3(replication) cassandra nodes ?
Example: why does facebook use memcache ? They certainly have things
distributed on thousands of servers.

On Thu, Oct 6, 2016 at 11:40 PM, KARR, DAVID  wrote:

> I've seen use cases that briefly describe using Hazelcast as a "front-end"
> for Cassandra, perhaps as a cache.  This seems counterintuitive to me.  Can
> someone describe to me when this kind of architecture might make sense?
>

Re: Efficient model for a sorting

[Dorian Hoxha]

On lucene you can query+filter+sort on a single shard, so it should be
better than MV/sasi. The index building is a little async though.

On Tue, Oct 4, 2016 at 2:29 PM, Benjamin Roth 
wrote:

> Thanks guys!
>
> Good to know, that my approach is basically right, but I will check that
> lucene indices by time.
>
> 2016-10-04 14:22 GMT+02:00 DuyHai Doan :
>
>> "What scatter/gather? "
>>
>> http://www.slideshare.net/doanduyhai/sasi-cassandra-on-the-
>> full-text-search-ride-voxxed-daybelgrade-2016/23
>>
>> "If you partition your data by user_id then you query only 1 shard to
>> get sorted by time visitors for a user"
>>
>> Exact, but in this case, you're using a 2nd index only for sorting right
>> ? For SASI it's not even possible. Maybe it can work with Statrio Lucene
>> impl
>>
>> On Tue, Oct 4, 2016 at 2:15 PM, Dorian Hoxha 
>> wrote:
>>
>>> @DuyHai
>>>
>>> What scatter/gather? If you partition your data by user_id then you
>>> query only 1 shard to get sorted by time visitors for a user.
>>>
>>> On Tue, Oct 4, 2016 at 2:09 PM, DuyHai Doan 
>>> wrote:
>>>
>>>> MV is right now your best choice for this kind of sorting behavior.
>>>>
>>>> Secondary index (whatever the impl, SASI or Lucene) has a cost of
>>>> scatter-gather if your cluster scale out. With MV you're at least
>>>> guaranteed to hit a single node everytime
>>>>
>>>> On Tue, Oct 4, 2016 at 1:56 PM, Dorian Hoxha 
>>>> wrote:
>>>>
>>>>> Can you use the lucene index https://github.com/Stratio/cas
>>>>> sandra-lucene-index ?
>>>>>
>>>>> On Tue, Oct 4, 2016 at 1:27 PM, Benjamin Roth >>>> > wrote:
>>>>>
>>>>>> Hi!
>>>>>>
>>>>>> I have a frequently used pattern which seems to be quite costly in
>>>>>> CS. The pattern is always the same: I have a unique key and a sorting by 
>>>>>> a
>>>>>> different field.
>>>>>>
>>>>>> To give an example, here a real life example from our model:
>>>>>> CREATE TABLE visits.visits_in (
>>>>>> user_id int,
>>>>>> user_id_visitor int,
>>>>>> created timestamp,
>>>>>> PRIMARY KEY (user_id, user_id_visitor)
>>>>>> ) WITH CLUSTERING ORDER BY (user_id_visitor ASC)
>>>>>>
>>>>>> CREATE MATERIALIZED VIEW visits.visits_in_sorted_mv AS
>>>>>> SELECT user_id, created, user_id_visitor
>>>>>> FROM visits.visits_in
>>>>>> WHERE user_id IS NOT NULL AND created IS NOT NULL AND
>>>>>> user_id_visitor IS NOT NULL
>>>>>> PRIMARY KEY (user_id, created, user_id_visitor)
>>>>>> WITH CLUSTERING ORDER BY (created DESC, user_id_visitor DESC)
>>>>>>
>>>>>> This simply represents people, that visited my profile sorted by date
>>>>>> desc but only one entry per visitor.
>>>>>> Other examples with the same pattern could be a whats-app-like inbox
>>>>>> where the last message of each sender is shown by date desc. There are 
>>>>>> lots
>>>>>> of examples for that pattern.
>>>>>>
>>>>>> E.g. in redis I'd just use a sorted set, where the key could be like
>>>>>> "visits_${user_id}", set key would be user_id_visitor and score
>>>>>> the created timestamp.
>>>>>> In MySQL I'd create the table with PK on user_id + user_id_visitor
>>>>>> and create an index on user_id + created
>>>>>> In C* i use an MV.
>>>>>>
>>>>>> Is this the most efficient approach?
>>>>>> I also could have done this without an MV but then the situation in
>>>>>> our app would be far more complex.
>>>>>> I know that denormalization is a common pattern in C* and I don't
>>>>>> hesitate to use it but in this case, it is not as simple as it's not an
>>>>>> append-only case but updates have to be handled correctly.
>>>>>> If it is the first visit of a user, it's that simple, just 2 inserts
>>>>>> in base table + denormalized table. But on a 2nd or 3rd visit, the 1st or
>>>>>> 2nd visit has to be del

Re: Efficient model for a sorting

[Dorian Hoxha]

@DuyHai

What scatter/gather? If you partition your data by user_id then you query
only 1 shard to get sorted by time visitors for a user.

On Tue, Oct 4, 2016 at 2:09 PM, DuyHai Doan  wrote:

> MV is right now your best choice for this kind of sorting behavior.
>
> Secondary index (whatever the impl, SASI or Lucene) has a cost of
> scatter-gather if your cluster scale out. With MV you're at least
> guaranteed to hit a single node everytime
>
> On Tue, Oct 4, 2016 at 1:56 PM, Dorian Hoxha 
> wrote:
>
>> Can you use the lucene index https://github.com/Stratio/cas
>> sandra-lucene-index ?
>>
>> On Tue, Oct 4, 2016 at 1:27 PM, Benjamin Roth 
>> wrote:
>>
>>> Hi!
>>>
>>> I have a frequently used pattern which seems to be quite costly in CS.
>>> The pattern is always the same: I have a unique key and a sorting by a
>>> different field.
>>>
>>> To give an example, here a real life example from our model:
>>> CREATE TABLE visits.visits_in (
>>> user_id int,
>>> user_id_visitor int,
>>> created timestamp,
>>> PRIMARY KEY (user_id, user_id_visitor)
>>> ) WITH CLUSTERING ORDER BY (user_id_visitor ASC)
>>>
>>> CREATE MATERIALIZED VIEW visits.visits_in_sorted_mv AS
>>> SELECT user_id, created, user_id_visitor
>>> FROM visits.visits_in
>>> WHERE user_id IS NOT NULL AND created IS NOT NULL AND
>>> user_id_visitor IS NOT NULL
>>> PRIMARY KEY (user_id, created, user_id_visitor)
>>> WITH CLUSTERING ORDER BY (created DESC, user_id_visitor DESC)
>>>
>>> This simply represents people, that visited my profile sorted by date
>>> desc but only one entry per visitor.
>>> Other examples with the same pattern could be a whats-app-like inbox
>>> where the last message of each sender is shown by date desc. There are lots
>>> of examples for that pattern.
>>>
>>> E.g. in redis I'd just use a sorted set, where the key could be like
>>> "visits_${user_id}", set key would be user_id_visitor and score
>>> the created timestamp.
>>> In MySQL I'd create the table with PK on user_id + user_id_visitor and
>>> create an index on user_id + created
>>> In C* i use an MV.
>>>
>>> Is this the most efficient approach?
>>> I also could have done this without an MV but then the situation in our
>>> app would be far more complex.
>>> I know that denormalization is a common pattern in C* and I don't
>>> hesitate to use it but in this case, it is not as simple as it's not an
>>> append-only case but updates have to be handled correctly.
>>> If it is the first visit of a user, it's that simple, just 2 inserts in
>>> base table + denormalized table. But on a 2nd or 3rd visit, the 1st or 2nd
>>> visit has to be deleted from the denormalized table before. Otherwise the
>>> visit would not be unique any more.
>>> Handling this case without an MV requires a lot more effort, I guess
>>> even more effort than just using an MV.
>>> 1. You need kind of app-side locking to deal with race conditions
>>> 2. Read before write is required to determine if an old record has to be
>>> deleted
>>> 3. At least CL_QUORUM is required to make sure that read before write is
>>> always consistent
>>> 4. Old record has to be deleted on update
>>>
>>> I guess, using an MV here is more efficient as there is less roundtrip
>>> between C* and the app to do all that and the MV does not require strong
>>> consistency as MV updates are always local and are eventual consistent when
>>> the base table is. So there is also no need for distributed locks.
>>>
>>> I ask all this as we now use CS 3.x and have been advised that 3.x is
>>> still not considered really production ready.
>>>
>>> I guess in a perfect world, this wouldn't even require an MV if SASI
>>> indexes could be created over more than 1 column. E.g. in MySQL this case
>>> is nothing else than a BTree. AFAIK SASI indices are also BTrees, filtering
>>> by Partition Key (which should to be done anyway) and sorting by a field
>>> would perfectly do the trick. But from the docs, this is not possible right
>>> now.
>>>
>>> Does anyone see a better solution or are all my assumptions correct?
>>>
>>> --
>>> Benjamin Roth
>>> Prokurist
>>>
>>> Jaumo GmbH · www.jaumo.com
>>> Wehrstraße 46 · 73035 Göppingen · Germany
>>> Phone +49 7161 304880-6 · Fax +49 7161 304880-1
>>> AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
>>>
>>
>>
>

Re: Efficient model for a sorting

[Dorian Hoxha]

Can you use the lucene index
https://github.com/Stratio/cassandra-lucene-index ?

On Tue, Oct 4, 2016 at 1:27 PM, Benjamin Roth 
wrote:

> Hi!
>
> I have a frequently used pattern which seems to be quite costly in CS. The
> pattern is always the same: I have a unique key and a sorting by a
> different field.
>
> To give an example, here a real life example from our model:
> CREATE TABLE visits.visits_in (
> user_id int,
> user_id_visitor int,
> created timestamp,
> PRIMARY KEY (user_id, user_id_visitor)
> ) WITH CLUSTERING ORDER BY (user_id_visitor ASC)
>
> CREATE MATERIALIZED VIEW visits.visits_in_sorted_mv AS
> SELECT user_id, created, user_id_visitor
> FROM visits.visits_in
> WHERE user_id IS NOT NULL AND created IS NOT NULL AND user_id_visitor
> IS NOT NULL
> PRIMARY KEY (user_id, created, user_id_visitor)
> WITH CLUSTERING ORDER BY (created DESC, user_id_visitor DESC)
>
> This simply represents people, that visited my profile sorted by date desc
> but only one entry per visitor.
> Other examples with the same pattern could be a whats-app-like inbox where
> the last message of each sender is shown by date desc. There are lots of
> examples for that pattern.
>
> E.g. in redis I'd just use a sorted set, where the key could be like
> "visits_${user_id}", set key would be user_id_visitor and score
> the created timestamp.
> In MySQL I'd create the table with PK on user_id + user_id_visitor and
> create an index on user_id + created
> In C* i use an MV.
>
> Is this the most efficient approach?
> I also could have done this without an MV but then the situation in our
> app would be far more complex.
> I know that denormalization is a common pattern in C* and I don't hesitate
> to use it but in this case, it is not as simple as it's not an append-only
> case but updates have to be handled correctly.
> If it is the first visit of a user, it's that simple, just 2 inserts in
> base table + denormalized table. But on a 2nd or 3rd visit, the 1st or 2nd
> visit has to be deleted from the denormalized table before. Otherwise the
> visit would not be unique any more.
> Handling this case without an MV requires a lot more effort, I guess even
> more effort than just using an MV.
> 1. You need kind of app-side locking to deal with race conditions
> 2. Read before write is required to determine if an old record has to be
> deleted
> 3. At least CL_QUORUM is required to make sure that read before write is
> always consistent
> 4. Old record has to be deleted on update
>
> I guess, using an MV here is more efficient as there is less roundtrip
> between C* and the app to do all that and the MV does not require strong
> consistency as MV updates are always local and are eventual consistent when
> the base table is. So there is also no need for distributed locks.
>
> I ask all this as we now use CS 3.x and have been advised that 3.x is
> still not considered really production ready.
>
> I guess in a perfect world, this wouldn't even require an MV if SASI
> indexes could be created over more than 1 column. E.g. in MySQL this case
> is nothing else than a BTree. AFAIK SASI indices are also BTrees, filtering
> by Partition Key (which should to be done anyway) and sorting by a field
> would perfectly do the trick. But from the docs, this is not possible right
> now.
>
> Does anyone see a better solution or are all my assumptions correct?
>
> --
> Benjamin Roth
> Prokurist
>
> Jaumo GmbH · www.jaumo.com
> Wehrstraße 46 · 73035 Göppingen · Germany
> Phone +49 7161 304880-6 · Fax +49 7161 304880-1
> AG Ulm · HRB 731058 · Managing Director: Jens Kammerer
>

Re: Way to write to dc1 but keep data only in dc2

[Dorian Hoxha]

@INDRANIL
Please go find your own thread and don't hijack mine.

On Mon, Oct 3, 2016 at 6:19 PM, INDRANIL BASU  wrote:

> Hello All,
>
> I am getting the below error repeatedly in the system log of C* 2.1.0
>
> WARN  [SharedPool-Worker-64] 2016-09-27 00:43:35,835
> SliceQueryFilter.java:236 - Read 0 live and 1923 tombstoned cells in
> test_schema.test_cf.test_cf_col1_idx (see tombstone_warn_threshold). 5000
> columns was requested, slices=[-], delInfo={deletedAt=-9223372036854775808,
> localDeletion=2147483647}
>
> After that NullPointer Exception and finally OOM
>
> ERROR [CompactionExecutor:6287] 2016-09-29 22:09:13,546
> CassandraDaemon.java:166 - Exception in thread Thread[CompactionExecutor:
> 6287,1,main]
> java.lang.NullPointerException: null
> at org.apache.cassandra.service.CacheService$
> KeyCacheSerializer.serialize(CacheService.java:475)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at org.apache.cassandra.service.CacheService$
> KeyCacheSerializer.serialize(CacheService.java:463)
> ~[apache-cassandra-2.1.0.jar:2.1.0]
> at org.apache.cassandra.cache.AutoSavingCache$Writer.
> saveCache(AutoSavingCache.java:225) ~[apache-cassandra-2.1.0.jar:2.1.0]
> at org.apache.cassandra.db.compaction.CompactionManager$
> 11.run(CompactionManager.java:1061) ~[apache-cassandra-2.1.0.jar:2.1.0]
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown
> Source) ~[na:1.7.0_80]
> at java.util.concurrent.FutureTask.run(Unknown Source)
> ~[na:1.7.0_80]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) [na:1.7.0_80]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) [na:1.7.0_80]
> at java.lang.Thread.run(Unknown Source) [na:1.7.0_80]
> ERROR [CompactionExecutor:9712] 2016-10-01 10:09:13,871
> CassandraDaemon.java:166 - Exception in thread Thread[CompactionExecutor:
> 9712,1,main]
> java.lang.NullPointerException: null
> ERROR [CompactionExecutor:10070] 2016-10-01 14:09:14,154
> CassandraDaemon.java:166 - Exception in thread Thread[CompactionExecutor:
> 10070,1,main]
> java.lang.NullPointerException: null
> ERROR [CompactionExecutor:10413] 2016-10-01 18:09:14,265
> CassandraDaemon.java:166 - Exception in thread Thread[CompactionExecutor:
> 10413,1,main]
> java.lang.NullPointerException: null
> ERROR [MemtableFlushWriter:2396] 2016-10-01 20:28:27,425
> CassandraDaemon.java:166 - Exception in thread Thread[MemtableFlushWriter:
> 2396,5,main]
> java.lang.OutOfMemoryError: unable to create new native thread
> at java.lang.Thread.start0(Native Method) ~[na:1.7.0_80]
> at java.lang.Thread.start(Unknown Source) ~[na:1.7.0_80]
> at java.util.concurrent.ThreadPoolExecutor.addWorker(Unknown
> Source) ~[na:1.7.0_80]
> at java.util.concurrent.ThreadPoolExecutor.processWorkerExit(Unknown
> Source) ~[na:1.7.0_80]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown
> Source) ~[na:1.7.0_80]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
> Source) ~[na:1.7.0_80]
> at java.lang.Thread.run(Unknown Source) ~[na:1.7.0_80]
>
> -- IB
>
>
>

Re: Way to write to dc1 but keep data only in dc2

[Dorian Hoxha]

Thanks for the explanation Eric.

I would think it as something like:
The keyspace will be on dc1 + dc2, with the option that no long-term-data
is in dc1. So you write to dc1 (to the right nodes), they write to
commit-log/memtable and when they push for inter-dc-replication dc1 then
deletes local data. While dc2 doesn't push data to dc1 for replication.

On Mon, Oct 3, 2016 at 5:25 PM, Eric Stevens  wrote:

> It sounds like you're trying to avoid the latency of waiting for a write
> confirmation to a remote data center?
>
> App ==> DC1 ==high-latency==> DC2
>
> If you need the write to be confirmed before you consider the write
> successful in your application (definitely recommended unless you're ok
> with losing data and the app having no idea), you're not going to solve the
> fundamental physics problem of having to wait for a round-trip between
> _something_ and DC2.  DC1 can't acknowledge the write until it's in
> memtables and commitlog of a node that owns that data, so under the hoods
> it's doing basically the same thing your app would have to do.  In fact,
> putting DC1 in the middle just introduces a (possibly trivial but
> definitely not zero) amount of additional latency over:
>
> App ==high-latency==> DC2
>
> The only exception would be if you had an expectation that latency between
> DC1 and DC2 would be lower than latency between App and DC2, which I admit
> is not impossible.
>
> On Fri, Sep 30, 2016 at 1:49 PM Dorian Hoxha 
> wrote:
>
>> Thanks Edward. Looks like it's not possible what I really wanted (to use
>> some kind of a quorum write ex).
>>
>> Note that the queue is ordered, but I need just so they eventually
>> happen, but with more consistency than ANY (2 nodes or more).
>>
>> On Fri, Sep 30, 2016 at 12:25 AM, Edward Capriolo 
>> wrote:
>>
>>> You can do something like this, though your use of terminology like
>>> "queue" really do not apply.
>>>
>>> You can setup your keyspace with replication in only one data center.
>>>
>>> CREATE KEYSPACE NTSkeyspace WITH REPLICATION = { 'class' : 
>>> 'NetworkTopologyStrategy', 'dc2' : 3 };
>>>
>>> This will make the NTSkeyspace like only in one data center. You can
>>> always write to any Cassandra node, since they will transparently proxy the
>>> writes to the proper place. You can configure your client to ONLY bind to
>>> specific hosts or data centers/hosts DC1.
>>>
>>> You can use a write consistency level like ANY. IF you use a consistency
>>> level like ONE. It will cause the the write to block anyway waiting for
>>> completion on the other datacenter.
>>>
>>> Since you mentioned the words "like a queue" I would suggest an
>>> alternative is to writing the data do a distributed commit log like kafka.
>>> At that point you can decouple the write systems either through producer
>>> consumer or through a tool like Kafka's mirror maker.
>>>
>>>
>>> On Thu, Sep 29, 2016 at 5:24 PM, Dorian Hoxha 
>>> wrote:
>>>
>>>> I have dc1 and dc2.
>>>> I want to keep a keyspace only on dc2.
>>>> But I only have my app on dc1.
>>>> And I want to write to dc1 (lower latency) which will not keep data
>>>> locally but just push it to dc2.
>>>> While reading will only work for dc2.
>>>> Since my app is mostly write, my app ~will be faster while not having
>>>> to deploy to the app to dc2 or write directly to dc2 with higher latency.
>>>>
>>>> dc1 would act like a queue or something and just push data + delete
>>>> locally.
>>>>
>>>> Does this make sense ?
>>>>
>>>> Thank You
>>>>
>>>
>>>
>>

Re: Way to write to dc1 but keep data only in dc2

[Dorian Hoxha]

Thanks Edward. Looks like it's not possible what I really wanted (to use
some kind of a quorum write ex).

Note that the queue is ordered, but I need just so they eventually happen,
but with more consistency than ANY (2 nodes or more).

On Fri, Sep 30, 2016 at 12:25 AM, Edward Capriolo 
wrote:

> You can do something like this, though your use of terminology like
> "queue" really do not apply.
>
> You can setup your keyspace with replication in only one data center.
>
> CREATE KEYSPACE NTSkeyspace WITH REPLICATION = { 'class' : 
> 'NetworkTopologyStrategy', 'dc2' : 3 };
>
> This will make the NTSkeyspace like only in one data center. You can
> always write to any Cassandra node, since they will transparently proxy the
> writes to the proper place. You can configure your client to ONLY bind to
> specific hosts or data centers/hosts DC1.
>
> You can use a write consistency level like ANY. IF you use a consistency
> level like ONE. It will cause the the write to block anyway waiting for
> completion on the other datacenter.
>
> Since you mentioned the words "like a queue" I would suggest an
> alternative is to writing the data do a distributed commit log like kafka.
> At that point you can decouple the write systems either through producer
> consumer or through a tool like Kafka's mirror maker.
>
>
> On Thu, Sep 29, 2016 at 5:24 PM, Dorian Hoxha 
> wrote:
>
>> I have dc1 and dc2.
>> I want to keep a keyspace only on dc2.
>> But I only have my app on dc1.
>> And I want to write to dc1 (lower latency) which will not keep data
>> locally but just push it to dc2.
>> While reading will only work for dc2.
>> Since my app is mostly write, my app ~will be faster while not having to
>> deploy to the app to dc2 or write directly to dc2 with higher latency.
>>
>> dc1 would act like a queue or something and just push data + delete
>> locally.
>>
>> Does this make sense ?
>>
>> Thank You
>>
>
>

Way to write to dc1 but keep data only in dc2

[Dorian Hoxha]

I have dc1 and dc2.
I want to keep a keyspace only on dc2.
But I only have my app on dc1.
And I want to write to dc1 (lower latency) which will not keep data locally
but just push it to dc2.
While reading will only work for dc2.
Since my app is mostly write, my app ~will be faster while not having to
deploy to the app to dc2 or write directly to dc2 with higher latency.

dc1 would act like a queue or something and just push data + delete locally.

Does this make sense ?

Thank You

Re: [RELEASE] Apache Cassandra 3.9 released

[Dorian Hoxha]

So how does documentation work? Example: I'm interested in Change Data
Capture.

*I do appreciate the work done.

On Thu, Sep 29, 2016 at 11:02 PM, Michael Shuler 
wrote:

> The Cassandra team is pleased to announce the release of Apache
> Cassandra version 3.9.
>
> Apache Cassandra is a fully distributed database. It is the right choice
> when you need scalability and high availability without compromising
> performance.
>
>  http://cassandra.apache.org/
>
> Downloads of source and binary distributions are listed in our download
> section:
>
>  http://cassandra.apache.org/download/
>
> This version is a bug fix release[1] on the 3.9 series. As always,
> please pay attention to the release notes[2] and Let us know[3] if you
> were to encounter any problem.
>
> Enjoy!
>
> [1]: (CHANGES.txt) https://goo.gl/SCtmhc
> [2]: (NEWS.txt) https://goo.gl/brKot5
> [3]: https://issues.apache.org/jira/browse/CASSANDRA
>

Re: Using keyspaces for virtual clusters

[Dorian Hoxha]

@Alain
I wanted to do 2, but looks like that won't be possible because of too much
overhead.

@Eric
Yeah that's what I was afraid of. Though I know that the client connects to
every server, I just didn't want to do the extra code.

On Wed, Sep 21, 2016 at 4:56 PM, Eric Stevens  wrote:

> Using keyspaces to support multi tenancy is very close to an anti pattern
> unless there is a finite and reasonable upper bound to how many tenants
> you'll support overall. Large numbers of tables comes with cluster overhead
> and operational complexity you will come to regret eventually.
>
> >and because I don't like having multiple cql clients/connections on my
> app-code
>
> You should note that although Cassandra drivers present a single logical
> connection per cluster, under the hood it maintains connection pools per C*
> host. You might be able to do a slightly better job of managing those pools
> as a single cluster and logical connection, but I doubt it will be very
> significant. It would depend on what options you have available in your
> driver of choice.
>
> Application logic would complexity not be greatly improved because you
> still need to switch by tenant, whether it's keyspace name or connection
> name doesn't seem like it would make much difference.
>
> As Alain pointed out, upgrades will be painful and maybe even dangerous as
> a monolithic cluster.
>
> On Wed, Sep 21, 2016, 3:50 AM Alain RODRIGUEZ  wrote:
>
>> Hi Dorian,
>>
>> I'm thinking of creating many keyspaces and storing them into many
>>> virtual datacenters (the servers will be in 1 logical datacenter, but
>>> separated by keyspaces).
>>>
>>> Does that make sense (so growing up to 200 dcs of 3 servers each in best
>>> case scenario)?
>>
>>
>> There is 3 main things you can do here
>>
>> 1 - Use 1 DC, 200 keyspaces using the DC
>> 2 - Use 200 DC, 1 keyspace per DC.
>> 3 - Use 200 cluster, 1 DC, 1 keyspace per client (or many keyspaces, but
>> related to 1 client)
>>
>> I am not sure if you want to go with 1 or 2, my understanding is you
>> wanted to write "the servers will be in 1 -*logical- **physical*
>> datacenter" and you are willing to do as described in 2.
>>
>> This looks to be a good idea to me, but for other reasons (clients /
>> workload isolation, limited risk, independent growth for each client,
>> visibility on cost per client, ...)
>>
>> Does that make sense (so growing up to 200 dcs of 3 servers each in best
>>> case scenario)?
>>>
>>
>> Yet I would not go with distinct DC, but rather distinct C* clusters
>> (different cluster names, seeds, etc).
>>
>> I see no good reason to use virtual cluster instead of distinct cluster.
>> Keep keyspace in distinct isolated datacenter would work. Datacenter would
>> be quite isolated since no information or load would be shared, excepted
>> from gossip.
>>
>> Yet there are some issue with big clusters due to gossip, and I had some
>> issue in the past due to gossip, affecting all the DC within a cluster. In
>> this case you would face a major issue, that you could have avoided or
>> limited. Plus when upgrading Cassandra, you would have to upgrade 600 nodes
>> quite quickly when distinct clusters can be upgraded independently. I would
>> then go with either option 1 or 3.
>>
>> and because I don't like having multiple cql clients/connections on my
>>> app-code
>>
>>
>> In this case, wouldn't it make sense for you to have per customer app-code
>> or just a conditional connection creation depending on the client?
>>
>> I just try to give you some ideas.
>>
>> Are the keyspaces+tables of dc1 stored in a cassandra node of dc2 ?(since
>>> there is overhead with each keyspace + table which would probably break
>>> this design)
>>
>> Or is it just a simple map dcx--->ip1,ip2,ip3 ?
>>
>>
>> I just checked it. All the nodes would know about every keyspace and
>> table, if using the same Cassandra cluster, (in my testing version C*3.7,
>> this is stored under system_schema.tables - local strategy, no
>> replication). To avoid that, using distinct clusters is the way to go.
>>
>> https://gist.github.com/arodrime/2f4fb2133c5b242b9500860ac8c6d89c
>>
>> C*heers,
>> ---
>> Alain Rodriguez - @arodream - al...@thelastpickle.com
>> France
>>
>> The Last Pickle - Apache Cassandra Consulting
>> http://www.thelastpickle.com
>>
>> 2016-09-20 22:49 GMT+02:00 Dorian Hoxha :
>>

Using keyspaces for virtual clusters

[Dorian Hoxha]

Hi,

I need to separate clients data into multiple clusters and because I don't
like having multiple cql clients/connections on my app-code, I'm thinking
of creating many keyspaces and storing them into many virtual datacenters
(the servers will be in 1 logical datacenter, but separated by keyspaces).

Does that make sense (so growing up to 200 dcs of 3 servers each in best
case scenario)?

Does the cql-engine make a new connection (like "use keyspace") when
specifying "keyspace.table" on the query ?

Are the keyspaces+tables of dc1 stored in a cassandra node of dc2 ?(since
there is overhead with each keyspace + table which would probably break
this design)
Or is it just a simple map dcx--->ip1,ip2,ip3 ?

Thank you!

Re: Having secondary indices limited to analytics dc

[Dorian Hoxha]

Only way I know is in elassandra .
You spin nodes in dc1 as elassandra (having data + indexes) and in dc2 as
cassandra (having only data).

On Sun, Sep 18, 2016 at 5:43 PM, Bhuvan Rawal  wrote:

> Hi,
>
> Is it possible to have secondary indices (SASI or native ones) defined on
> a table restricted to a particular DC? For instance it is very much
> possible in mysql to have a parent server on which writes are being done
> without any indices (other than the required ones), and to have indices on
> replica db's, this helps the parent database to be lightweight and free
> from building secondary index on every write.
>
> For analytics & auditing purposes it is essential to serve different
> access patterns than that modeled from a partition key fetch perspective,
> although a limited reads are needed by users but if enabled cluster wide it
> will require index write for every row written on that table on every
> single node on every DC even the one which may be serving read operations.
>
> What could be the potential means to solve this problem inside of
> cassandra (Not having to ship off the data into elasticsearch etc).
>
> Best Regards,
> Bhuvan
>

Re: Maximum number of columns in a table

[Dorian Hoxha]

@DuyHai
I know they don't support.
I need key+value mapping, not just "values" or just "keys".

I'll use the lucene index.



On Thu, Sep 15, 2016 at 10:23 PM, DuyHai Doan  wrote:

> I'd advise anyone against using the old native secondary index ... You'll
> get poor performance (that's the main reason why some people developed
> SASI).
>
> On Thu, Sep 15, 2016 at 10:20 PM, Hannu Kröger  wrote:
>
>> Hi,
>>
>> The ‘old-fashioned’ secondary indexes do support index of collection
>> values:
>> https://docs.datastax.com/en/cql/3.1/cql/ddl/ddlIndexColl.html
>>
>> Br,
>> Hannu
>>
>> On 15 Sep 2016, at 15:59, DuyHai Doan  wrote:
>>
>> "But the problem is I can't use secondary indexing "where int25=5", while
>> with normal columns I can."
>>
>> You have many objectives that contradict themselves in term of impl.
>>
>> Right now you're unlucky, SASI does not support indexing collections yet
>> (it may come in future, when ?  ¯\_(ツ)_/¯ )
>>
>> If you're using DSE Search or Stratio Lucene Index, you can index map
>> values
>>
>> On Thu, Sep 15, 2016 at 9:53 PM, Dorian Hoxha 
>> wrote:
>>
>>> Yes that makes more sense. But the problem is I can't use secondary
>>> indexing "where int25=5", while with normal columns I can.
>>>
>>> On Thu, Sep 15, 2016 at 8:23 PM, sfesc...@gmail.com 
>>> wrote:
>>>
>>>> I agree a single blob would also work (I do that in some cases). The
>>>> reason for the map is if you need more flexible updating. I think your
>>>> solution of a map/data type works well.
>>>>
>>>> On Thu, Sep 15, 2016 at 11:10 AM DuyHai Doan 
>>>> wrote:
>>>>
>>>>> "But I need rows together to work with them (indexing etc)"
>>>>>
>>>>> What do you mean rows together ? You mean that you want to fetch a
>>>>> single row instead of 1 row per property right ?
>>>>>
>>>>> In this case, the map might be the solution:
>>>>>
>>>>> CREATE TABLE generic_with_maps(
>>>>>object_id uuid
>>>>>boolean_map map
>>>>>text_map map
>>>>>long_map map,
>>>>>...
>>>>>PRIMARY KEY(object_id)
>>>>> );
>>>>>
>>>>> The trick here is to store all the fields of the object in different
>>>>> map, depending on the type of the field.
>>>>>
>>>>> The map key is always text and it contains the name of the field.
>>>>>
>>>>> Example
>>>>>
>>>>> {
>>>>>"id": ,
>>>>> "name": "John DOE",
>>>>> "age":  32,
>>>>> "last_visited_date":  "2016-09-10 12:01:03",
>>>>> }
>>>>>
>>>>> INSERT INTO generic_with_maps(id, map_text, map_long, map_date)
>>>>> VALUES(xxx, {'name': 'John DOE'}, {'age': 32}, {'last_visited_date': 
>>>>> '2016-09-10
>>>>> 12:01:03'});
>>>>>
>>>>> When you do a select, you'll get a SINGLE row returned. But then you
>>>>> need to extract all the properties from different maps, not a big deal
>>>>>
>>>>> On Thu, Sep 15, 2016 at 7:54 PM, Dorian Hoxha 
>>>>> wrote:
>>>>>
>>>>>> @DuyHai
>>>>>> Yes, that's another case, the "entity" model used in rdbms. But I
>>>>>> need rows together to work with them (indexing etc).
>>>>>>
>>>>>> @sfespace
>>>>>> The map is needed when you have a dynamic schema. I don't have a
>>>>>> dynamic schema (may have, and will use the map if I do). I just have
>>>>>> thousands of schemas. One user needs 10 integers, while another user 
>>>>>> needs
>>>>>> 20 booleans, and another needs 30 integers, or a combination of them all.
>>>>>>
>>>>>> On Thu, Sep 15, 2016 at 7:46 PM, DuyHai Doan 
>>>>>> wrote:
>>>>>>
>>>>>>> "Another possible alternative is to use a single map column"
>>>>>>>
>>>>>>> --> how do y

Re: Maximum number of columns in a table

[Dorian Hoxha]

Yes that makes more sense. But the problem is I can't use secondary
indexing "where int25=5", while with normal columns I can.

On Thu, Sep 15, 2016 at 8:23 PM, sfesc...@gmail.com 
wrote:

> I agree a single blob would also work (I do that in some cases). The
> reason for the map is if you need more flexible updating. I think your
> solution of a map/data type works well.
>
> On Thu, Sep 15, 2016 at 11:10 AM DuyHai Doan  wrote:
>
>> "But I need rows together to work with them (indexing etc)"
>>
>> What do you mean rows together ? You mean that you want to fetch a single
>> row instead of 1 row per property right ?
>>
>> In this case, the map might be the solution:
>>
>> CREATE TABLE generic_with_maps(
>>object_id uuid
>>boolean_map map
>>text_map map
>>long_map map,
>>...
>>PRIMARY KEY(object_id)
>> );
>>
>> The trick here is to store all the fields of the object in different map,
>> depending on the type of the field.
>>
>> The map key is always text and it contains the name of the field.
>>
>> Example
>>
>> {
>>"id": ,
>> "name": "John DOE",
>> "age":  32,
>> "last_visited_date":  "2016-09-10 12:01:03",
>> }
>>
>> INSERT INTO generic_with_maps(id, map_text, map_long, map_date)
>> VALUES(xxx, {'name': 'John DOE'}, {'age': 32}, {'last_visited_date': 
>> '2016-09-10
>> 12:01:03'});
>>
>> When you do a select, you'll get a SINGLE row returned. But then you need
>> to extract all the properties from different maps, not a big deal
>>
>> On Thu, Sep 15, 2016 at 7:54 PM, Dorian Hoxha 
>> wrote:
>>
>>> @DuyHai
>>> Yes, that's another case, the "entity" model used in rdbms. But I need
>>> rows together to work with them (indexing etc).
>>>
>>> @sfespace
>>> The map is needed when you have a dynamic schema. I don't have a dynamic
>>> schema (may have, and will use the map if I do). I just have thousands of
>>> schemas. One user needs 10 integers, while another user needs 20 booleans,
>>> and another needs 30 integers, or a combination of them all.
>>>
>>> On Thu, Sep 15, 2016 at 7:46 PM, DuyHai Doan 
>>> wrote:
>>>
>>>> "Another possible alternative is to use a single map column"
>>>>
>>>> --> how do you manage the different types then ? Because maps in
>>>> Cassandra are strongly typed
>>>>
>>>> Unless you set the type of map value to blob, in this case you might as
>>>> well store all the object as a single blob column
>>>>
>>>> On Thu, Sep 15, 2016 at 6:13 PM, sfesc...@gmail.com >>> > wrote:
>>>>
>>>>> Another possible alternative is to use a single map column.
>>>>>
>>>>>
>>>>> On Thu, Sep 15, 2016 at 7:19 AM Dorian Hoxha 
>>>>> wrote:
>>>>>
>>>>>> Since I will only have 1 table with that many columns, and the other
>>>>>> tables will be "normal" tables with max 30 columns, and the memory of 2K
>>>>>> columns won't be that big, I'm gonna guess I'll be fine.
>>>>>>
>>>>>> The data model is too dynamic, the alternative would be to create a
>>>>>> table for each user which will have even more overhead since the number 
>>>>>> of
>>>>>> users is in the several thousands/millions.
>>>>>>
>>>>>>
>>>>>> On Thu, Sep 15, 2016 at 3:04 PM, DuyHai Doan 
>>>>>> wrote:
>>>>>>
>>>>>>> There is no real limit in term of number of columns in a table, I
>>>>>>> would say that the impact of having a lot of columns is the amount of 
>>>>>>> meta
>>>>>>> data C* needs to keep in memory for encoding/decoding each row.
>>>>>>>
>>>>>>> Now, if you have a table with 1000+ columns, the problem is probably
>>>>>>> your data model...
>>>>>>>
>>>>>>> On Thu, Sep 15, 2016 at 2:59 PM, Dorian Hoxha <
>>>>>>> dorian.ho...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Is there alot of overhead with having a big number of columns in a
>>>>>>>> table ? Not unbounded, but say, would 2000 be a problem(I think that's 
>>>>>>>> the
>>>>>>>> maximum I'll need) ?
>>>>>>>>
>>>>>>>> Thank You
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>

Re: Maximum number of columns in a table

[Dorian Hoxha]

@DuyHai
Yes, that's another case, the "entity" model used in rdbms. But I need rows
together to work with them (indexing etc).

@sfespace
The map is needed when you have a dynamic schema. I don't have a dynamic
schema (may have, and will use the map if I do). I just have thousands of
schemas. One user needs 10 integers, while another user needs 20 booleans,
and another needs 30 integers, or a combination of them all.

On Thu, Sep 15, 2016 at 7:46 PM, DuyHai Doan  wrote:

> "Another possible alternative is to use a single map column"
>
> --> how do you manage the different types then ? Because maps in Cassandra
> are strongly typed
>
> Unless you set the type of map value to blob, in this case you might as
> well store all the object as a single blob column
>
> On Thu, Sep 15, 2016 at 6:13 PM, sfesc...@gmail.com 
> wrote:
>
>> Another possible alternative is to use a single map column.
>>
>>
>> On Thu, Sep 15, 2016 at 7:19 AM Dorian Hoxha 
>> wrote:
>>
>>> Since I will only have 1 table with that many columns, and the other
>>> tables will be "normal" tables with max 30 columns, and the memory of 2K
>>> columns won't be that big, I'm gonna guess I'll be fine.
>>>
>>> The data model is too dynamic, the alternative would be to create a
>>> table for each user which will have even more overhead since the number of
>>> users is in the several thousands/millions.
>>>
>>>
>>> On Thu, Sep 15, 2016 at 3:04 PM, DuyHai Doan 
>>> wrote:
>>>
>>>> There is no real limit in term of number of columns in a table, I would
>>>> say that the impact of having a lot of columns is the amount of meta data
>>>> C* needs to keep in memory for encoding/decoding each row.
>>>>
>>>> Now, if you have a table with 1000+ columns, the problem is probably
>>>> your data model...
>>>>
>>>> On Thu, Sep 15, 2016 at 2:59 PM, Dorian Hoxha 
>>>> wrote:
>>>>
>>>>> Is there alot of overhead with having a big number of columns in a
>>>>> table ? Not unbounded, but say, would 2000 be a problem(I think that's the
>>>>> maximum I'll need) ?
>>>>>
>>>>> Thank You
>>>>>
>>>>
>>>>
>>>
>

Re: Maximum number of columns in a table

[Dorian Hoxha]

Since I will only have 1 table with that many columns, and the other tables
will be "normal" tables with max 30 columns, and the memory of 2K columns
won't be that big, I'm gonna guess I'll be fine.

The data model is too dynamic, the alternative would be to create a table
for each user which will have even more overhead since the number of users
is in the several thousands/millions.

On Thu, Sep 15, 2016 at 3:04 PM, DuyHai Doan  wrote:

> There is no real limit in term of number of columns in a table, I would
> say that the impact of having a lot of columns is the amount of meta data
> C* needs to keep in memory for encoding/decoding each row.
>
> Now, if you have a table with 1000+ columns, the problem is probably your
> data model...
>
> On Thu, Sep 15, 2016 at 2:59 PM, Dorian Hoxha 
> wrote:
>
>> Is there alot of overhead with having a big number of columns in a table
>> ? Not unbounded, but say, would 2000 be a problem(I think that's the
>> maximum I'll need) ?
>>
>> Thank You
>>
>
>

Maximum number of columns in a table

[Dorian Hoxha]

Is there alot of overhead with having a big number of columns in a table ?
Not unbounded, but say, would 2000 be a problem(I think that's the maximum
I'll need) ?

Thank You