cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Cassandra Wiki] Update of "StorageConfiguration" by tuxracer69
Date Fri, 13 Nov 2009 11:09:24 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Cassandra Wiki" for change notification.

The "StorageConfiguration" page has been changed by tuxracer69.
The comment on this change is: creating the page from the conf/storage-conf.xml.


New page:
Cassandra storage configuration is described by the conf/storage-conf.xml file.

== Cluster Name ==
The name of this cluster.  This is mainly used to prevent machines in one logical cluster
from joining another.


<ClusterName>Test Cluster</ClusterName>

== Keyspaces and ColumnFamilies ==
Keyspaces and !ColumnFamilies: A !ColumnFamily is the Cassandra concept closest to a relational
table.  !Keyspaces are separate groups of !ColumnFamilies.  Except in very unusual circumstances
you will have one Keyspace per application.

There is an implicit keyspace named 'system' for Cassandra internals.

 <Keyspace Name="Keyspace1">

The !CompareWith attribute tells Cassandra how to sort the columns for slicing operations.
 The default is !BytesType, which is a straightforward lexical comparison of the bytes in
each column. Other options are !AsciiType, !UTF8Type, !LexicalUUIDType, !TimeUUIDType, and
!LongType.  You can also specify the fully-qualified class name to a class of your choice
extending org.apache.cassandra.db.marshal.AbstractType.

!SuperColumns have a similar !CompareSubcolumnsWith attribute.

BytesType: Simple sort by byte value.  No validation is performed. !AsciiType: Like !BytesType,
but validates that the input can be parsed as US-ASCII.

UTF8Type: A string encoded as UTF8 !LongType: A 64bit long !LexicalUUIDType: A 128bit UUID,
compared lexically (by byte value) T!imeUUIDType: a 128bit version 1 !UUID, compared by !timestamp

(To get the closest approximation to 0.3-style !supercolumns, you would use !CompareWith=UTF8Type

If !FlushPeriodInMinutes is configured and positive, it will be flushed to disk with that
period whether it is dirty or not.  This is intended for lightly-used !columnfamilies so that
they do not prevent !commitlog segments from being purged.

<ColumnFamily CompareWith="BytesType"
 <ColumnFamily CompareWith="UTF8Type" Name="Standard2"/> <ColumnFamily CompareWith="TimeUUIDType"
Name="StandardByUUID1"/> <ColumnFamily ColumnType="Super"
CompareWith="UTF8Type" CompareSubcolumnsWith="UTF8Type" Name="Super1"/>

== Partitioner ==
Partitioner: any !IPartitioner may be used, including your own as long as it is on the !classpath.
 Out of the box, Cassandra provides org.apache.cassandra.dht.RandomPartitioner, org.apache.cassandra.dht.OrderPreservingPartitioner,
and org.apache.cassandra.dht.CollatingOrderPreservingPartitioner. (CollatingOPP colates according
to EN,US rules, not naive byte ordering.  Use this as an example if you need locale-aware
collation.) Range queries require using an order-preserving partitioner.

Achtung!  Changing this parameter requires wiping your data directories, since the partitioner
can modify the !sstable on-disk format.



If you are using an order-preserving partitioner and you know your key distribution, you can
specify the token for this node to use. (Keys are sent to the node with the "closest" token,
so distributing your tokens equally along the key distribution space will spread keys evenly
across your cluster.)  This setting is only checked the first time a node is started.

This can also be useful with RandomPartitioner to force equal spacing of tokens around the
hash space, especially for clusters with a small number of nodes.


== EndPointSnitch ==
!EndPointSnitch: Setting this to the class that implements !IEndPointSnitch which will see
if two endpoints are in the same data center or on the same rack. Out of the box, Cassandra
provides org.apache.cassandra.locator.EndPointSnitch


== ReplicaPlacementStrategy ==
Strategy: Setting this to the class that implements IReplicaPlacementStrategy will change
the way the node picker works. Out of the box, Cassandra provides org.apache.cassandra.locator.RackUnawareStrategy
and org.apache.cassandra.locator.RackAwareStrategy (place one replica in a different datacenter,
and the others on different racks in the same one.)


Number of replicas of the data


== Directories ==
Directories: Specify where Cassandra should store different data on disk.  Keep the data disks
and the CommitLog disks separate for best performance

<CommitLogDirectory>/var/lib/cassandra/commitlog</CommitLogDirectory> <DataFileDirectories>
<CalloutLocation>/var/lib/cassandra/callouts</CalloutLocation> <BootstrapFileDirectory>/var/lib/cassandra/bootstrap</BootstrapFileDirectory>

== Hosts ==
Addresses of hosts that are deemed contact points. Cassandra nodes use this list of hosts
to find each other and learn the topology of the ring. You must change this if you are running
multiple nodes!


== Miscellaneous ==
Time to wait for a reply from other nodes before failing the command


Size to allow commitlog to grow to before creating a new segment


Local hosts and ports

Address to bind to and tell other nodes to connect to.  You _must_ change this if you want
multiple nodes to be able to communicate!

Leaving it blank leaves it up to InetAddress.getLocalHost(). This will always do the Right
Thing *if* the node is properly configured (hostname, name resolution, etc), and the Right
Thing is to use the address associated with the hostname (it might not be).

<!-- TCP port, for commands and data --> 
<!-- UDP port, for membership communications (gossip) --> 

The address to bind the Thrift RPC service to. Unlike ListenAddress above, you *can* specify here if you want Thrift to listen on all interfaces.

Leaving this blank has the same effect it does for ListenAddress, (i.e. it will be based on
the configured hostname of the node).

<!-- Thrift RPC port (the port clients connect to). --> 

Whether or not to use a framed transport for Thrift. If this option is set to true then you
must also use a framed transport on the  client-side, (framed and non-framed transports are
not compatible).


== Memory, Disk, and Performance ==
Buffer size to use when performing contiguous column slices. Increase this to the size of
the column slices you typically perform.  (Name-based queries are performed with a buffer
size of  !ColumnIndexSizeInKB.)


Buffer size to use when flushing !memtables to disk. (Only one  !memtable is ever flushed
at a time.) Increase (decrease) the index buffer size relative to the data buffer if you have
few (many)  columns per key.  Bigger is only better _if_ your !memtables get large enough
to use the space. (Check in your data directory after your app has been running long enough.)


Add column indexes to a row after its contents reach this size. Increase if your column values
are large, or if you have a very large number of columns.  The competing causes are, Cassandra
has to deserialize this much of the row to read a single column, so you want it to be small
- at least if you do many partial-row reads - but all the index data is read for each access,
so you don't want to generate that wastefully either.


The maximum amount of data to store in memory per !ColumnFamily before flushing to disk. 
Note: There is one memtable per column family, and  this threshold is based solely on the
amount of data stored, not actual heap memory usage (there is some overhead in indexing the


The maximum number of columns in millions to store in memory per ColumnFamily before flushing
to disk.  This is also a per-memtable setting.  Use with MemtableSizeInMB to tune memory usage.

Unlike most systems, in Cassandra writes are faster than reads, so you can afford more of
those in parallel.  A good rule of thumb is 2 concurrent reads per processor core.  Increase
ConcurrentWrites to the number of clients writing at once if you enable CommitLogSync + CommitLogSyncDelay.

<ConcurrentReads>8</ConcurrentReads> <ConcurrentWrites>32</ConcurrentWrites>

!CommitLogSync may be either "periodic" or "batch."  When in batch mode, Cassandra won't ack
writes until the commit log has been !fsynced to disk.  It will wait up to !CommitLogSyncBatchWindowInMS
milliseconds for other writes, before performing the sync.

This is less necessary in Cassandra than in traditional databases since replication reduces
the odds of losing data from a failure after writing the log entry but before it actually
reaches the disk. So the other option is "timed," where writes may be acked immediately and
the CommitLog is simply synced every CommitLogSyncPeriodInMS milliseconds.

Interval at which to perform syncs of the !CommitLog in periodic mode. Usually the default
of 1000ms is fine; increase it only if the CommitLog PendingTasks backlog in jmx shows that
you are frequently scheduling a second sync while the first has not yet been processed.

Delay (in milliseconds) during which additional commit log entries may be written before fsync
in batch mode.  This will increase latency slightly, but can vastly improve throughput where
there are many writers.  Set to zero to disable (each entry will be synced individually).
 Reasonable values range from a minimal 0.1 to 10 or even more if throughput matters more
than latency.

<!-- <CommitLogSyncBatchWindowInMS>1</CommitLogSyncBatchWindowInMS> -->
Time to wait before garbage-collection deletion markers.  Set this to a large enough value
that you are confident that the deletion marker will be propagated to all replicas by the
time this many seconds has elapsed, even in the face of hardware failures.  The default value
is ten days.

Number of threads to run when flushing memtables to disk.  Set this to the number of disks
you physically have in your machine allocated for DataDirectory * 2.  If you are planning
to use the Binary Memtable, its recommended to increase the max threads to maintain a higher
quality of service while under load when normal memtables are flushing to disk.

<FlushMinThreads>1</FlushMinThreads> <FlushMaxThreads>1</FlushMaxThreads>

The threshold size in megabytes the binary memtable must grow to, before it's submitted for
flushing to disk.


View raw message