Just a minor observation: those field names are extremely long. You store a copy of every field name with every value with only a couple of exceptions: http://www.datastax.com/documentation/cassandra/1.2/cassandra/architecture/architecturePlanningUserData_t.html
Your partition key column name (logentrytimestamputcguid) is just kept in the schema, so the length of that name doesn't impact your storage costs. Also clustering keys (you have none) you pay to store the *value* (not the name) before all other non clustering columns. Generally it's a good idea to prefer short column names over long ones. It increases application and diagnostic complexity, but we try to keep our column names under 4 bytes. This storage overhead for column names is reduced if you use sstable compression, but at the cost of an increase in CPU time. On Mon, Feb 2, 2015 at 8:33 AM, Asit KAUSHIK <asitkaushikno...@gmail.com> wrote: > HI All > > We are working on a application logging project and this is one of the > search tables as below : > > > CREATE TABLE logentries ( > logentrytimestamputcguid timeuuid PRIMARY KEY, > context text, > date_to_hour bigint, > durationinseconds float, > eventtimestamputc timestamp, > ipaddress inet, > logentrytimestamputc timestamp, > loglevel int, > logmessagestring text, > logsequence int, > message text, > modulename text, > productname text, > searchitems map<text, text>, > servername text, > sessionname text, > stacktrace text, > threadname text, > timefinishutc timestamp, > timestartutc timestamp, > urihostname text, > uripathvalue text, > uriquerystring text, > useragentstring text, > username text > ); > > I have some queries on the design of this table : > > 1) Does a timeuuid is a good candidate for partition key as we would be > querying other fields with stargate-core full text project > > This table is actually be used for search like username like '*john' > likewise and uing this present model the performance is very slow . > > Please advise > > Regards > Asit > > > > > >
