Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 571F76250 for ; Thu, 21 Jul 2011 11:27:32 +0000 (UTC) Received: (qmail 82812 invoked by uid 500); 21 Jul 2011 11:27:30 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 81692 invoked by uid 500); 21 Jul 2011 11:27:23 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 81660 invoked by uid 99); 21 Jul 2011 11:27:22 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jul 2011 11:27:22 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of nilabja.banerjee@gmail.com designates 209.85.212.44 as permitted sender) Received: from [209.85.212.44] (HELO mail-vw0-f44.google.com) (209.85.212.44) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Jul 2011 11:27:15 +0000 Received: by vws12 with SMTP id 12so1017007vws.31 for ; Thu, 21 Jul 2011 04:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=CYUKvoA2thwpkkVZp8JojkfBNe1ABEByydUlXdqDofI=; b=bUWByGC5phx7pq+BRIsGh8BT6cjDYBlSlNsYV1rKK1KUcRU0scjU8aC0xdfG8PCeB/ qSGcKvWj6KFn+ae3OVdLyW1L++q9+2NTtD6NphffOOTnAN8MjFhON2rbtsUNU/B9G9Qq 3zD6y6u4vZ+ft64djFoChG/Qr54SyrdL57k3o= MIME-Version: 1.0 Received: by 10.220.148.73 with SMTP id o9mr35395vcv.9.1311247614473; Thu, 21 Jul 2011 04:26:54 -0700 (PDT) Received: by 10.220.74.145 with HTTP; Thu, 21 Jul 2011 04:26:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 21 Jul 2011 16:56:54 +0530 Message-ID: Subject: Re: Memtables stored in which location From: Nilabja Banerjee To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec54ee8ea45f6a204a892a0bf X-Virus-Checked: Checked by ClamAV on apache.org --bcaec54ee8ea45f6a204a892a0bf Content-Type: text/plain; charset=ISO-8859-1 *One more thing I want to ask here* ...in the data folder of cassandra, for each columnfamily four type of .db files are generated. for example: CFname-f-1-*Data*.db, CFname-f-1-*Filter*.db, CFname-f-1-*Index*.db, CFname-f-1-*Statistic*.db, *What are these extensions are? *Thank you On 21 July 2011 16:11, samal wrote: > > Any ways , some where memtable has to be stored right, like we say memtable > data is flushed to create sstable on disk. > >> Exactly from which location or memory it will be getting from. is it like >> an objects streams or like it is storing the values in commitlog. >> > > A Memtable is Cassandra's in-memory representation of key/value pairs. > > >> my next question is , data is written to commit log. all the data is >> available here, and the sstable are getting created on disk, then where and >> when these memtables are coming into picture > > > Commitlog is append only file which record write sequentially, more[2], can > be thought as check sum file, which to used to recalculate data for > memtables in case of crash. > A write first hits the *CommitLog*, then Cassandra stores/writes values to > in-memory data structures called Memtables. The Memtables are flushed to > disk whenever one of the configurable thresholds is met.[3] > For each column family there is corresponding memtable. > There is generally one commitlog file for all CF. > > SSTables are immutable once written to disk cannot be modified. It will > only be replaced by new SSTable after compaction > > > [1]http://wiki.apache.org/cassandra/ArchitectureOverview > [2]http://wiki.apache.org/cassandra/ArchitectureCommitLog > [3]http://wiki.apache.org/cassandra/MemtableThresholds > > --bcaec54ee8ea45f6a204a892a0bf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One more thing I want to ask here ...in the data folder of cassandra= , for each columnfamily four type of .db files are generated. for example:= =A0 CFname-f-1-Data.db, CFname-f-1-Filter.db, CFname-f-1-I= ndex.db, CFname-f-1-Statistic.db,

What are these extensions are?

Thank you



=
On 21 July 2011 16:11, samal &= lt;samal@wakya.in> wrote:

Any ways , some where memtable has to b= e stored right, like we say memtable data is flushed to create sstable on d= isk.
Exactly from which location or memory it will be getting from. is it like a= n objects streams or like it is storing the values in commitlog.

A Memtable is Cassandra's in-memory represent= ation of key/value pairs.
=A0
my next question is , data is = written to commit log. all the data is available here, and the sstable are = getting created on disk, then where and when these memtables are coming int= o picture

Commitlog is append only file which record write=A0sequ= entially, more[2], can be thought as check sum file, which to used to=A0rec= alculate=A0data for memtables in case of crash.
A write first hit= s the CommitLog, then Cassandra stores/writes values to in-memory da= ta structures called Memtables. The Memtables are flushed to disk whenever one of the configurable thresholds is met.[3]=A0<= /div>
For each column family there is corresponding memtable.
There is=A0generally=A0one commitlog file for all CF.

SSTables are immutable once written to disk cannot be= =A0modified. It will only be replaced by new SSTable after compaction
=




--bcaec54ee8ea45f6a204a892a0bf--