cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward Capriolo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-4175) Reduce memory (and disk) space requirements with a column name/id map
Date Fri, 07 Jun 2013 17:46:22 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678198#comment-13678198
] 

Edward Capriolo commented on CASSANDRA-4175:
--------------------------------------------

{quote} Schema has never really been eventually consistent since you can't do anything useful
until the schema has propagated. Fortunately, since schema changes are rare, this isn't a
problem in practice.
{quote}
I do not see how it will not be a problem in practice. In a single datacenter deployment it
means you will not be able to add schema is zookeeper is not up. 

In a multi-data center deployment I do not know what it means. Based on how you want to interpret
multi-datacenter zookeeper. Do all datacenters need to be reachable for schema changes? Then
it is not AP.
http://zookeeper-user.578899.n2.nabble.com/Managing-multi-site-clusters-with-Zookeeper-td4685686.html

{quote}
Nope, since it's 2 bytes for name length, then 2 for the name. To win vs 32bit int you'd have
to have a single-letter name. (And of course any use of CompositeType blows this right out.
{quote}

Seriously. Why aren't people using 1 or 2 character column names? That would give you something
like 676 and then in the schema we could just store a comment like 'pw means password'. Problem
solved.



                
> Reduce memory (and disk) space requirements with a column name/id map
> ---------------------------------------------------------------------
>
>                 Key: CASSANDRA-4175
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-4175
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Jonathan Ellis
>             Fix For: 2.1
>
>
> We spend a lot of memory on column names, both transiently (during reads) and more permanently
(in the row cache).  Compression mitigates this on disk but not on the heap.
> The overhead is significant for typical small column values, e.g., ints.
> Even though we intern once we get to the memtable, this affects writes too via very high
allocation rates in the young generation, hence more GC activity.
> Now that CQL3 provides us some guarantees that column names must be defined before they
are inserted, we could create a map of (say) 32-bit int column id, to names, and use that
internally right up until we return a resultset to the client.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message