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 <hkro...@gmail.com> 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 <doanduy...@gmail.com> 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 <dorian.ho...@gmail.com> > 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 <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 <doanduy...@gmail.com> >>> 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, boolean> >>>> text_map map<text, text> >>>> long_map map<text, long>, >>>> ... >>>> 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": xxxx, >>>> "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 <dorian.ho...@gmail.com> >>>> 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 <doanduy...@gmail.com> >>>>> 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 < >>>>>> 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 <dorian.ho...@gmail.com> >>>>>>> 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 <doanduy...@gmail.com> >>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >> > >
