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 67BF7E1F1 for ; Sun, 6 Jan 2013 15:47:09 +0000 (UTC) Received: (qmail 32303 invoked by uid 500); 6 Jan 2013 15:47:06 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 32223 invoked by uid 500); 6 Jan 2013 15:47:06 -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 32211 invoked by uid 99); 6 Jan 2013 15:47:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Jan 2013 15:47:06 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of bra@fsn.hu designates 195.228.252.137 as permitted sender) Received: from [195.228.252.137] (HELO people.fsn.hu) (195.228.252.137) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 06 Jan 2013 15:46:56 +0000 Received: by people.fsn.hu (Postfix, from userid 1001) id 6E9ABF502BA; Sun, 6 Jan 2013 16:46:35 +0100 (CET) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.3 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 24.2322] X-CRM114-CacheID: sfid-20130106_16463_F28F0808 X-CRM114-Status: Good ( pR: 24.2322 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Sun Jan 6 16:46:35 2013 X-DSPAM-Confidence: 0.9928 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 50e99c5b357591998812662 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, cache, 0.00208, bytes, 0.00280, something+like, 0.00467, is+fine, 0.00559, Received*; Sun, 6 Jan 2013 16:46:34 +0100 (CET) Message-ID: <50E99C57.1000006@fsn.hu> Date: Sun, 06 Jan 2013 16:46:31 +0100 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Schema recommendation Content-Type: multipart/alternative; boundary="------------040302000101070601080309" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------040302000101070601080309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm new to Cassandra, so I wonder what would be the most efficient(*) schema for specific operations on the following dataset: - basically the task is to create a distributed file system with only few allowed operations - it should handle split brain conditions well (two or three DCs, it's possible to get user requests while the intra-DC connections are down) - each data file is blob (pretty often, but not always 8 bit text, sometimes without the encoding known), ranging from a few 100 bytes to around 20-30 MB. Average size is 350 kB. - it's well compressible (gzip -1 gives 1.63x compress ratio on plain files) - files are mostly immutable - for the few, which are not, they are append-only - each file has a unique file name (size in the range of 70-100 bytes) and it's preserved during its lifetime (if it changes, a rewrite is OK). - the files have metadata attached (various, 1.2's sets and maps are a good fit here, but even simple columns should do) - the files are organized into directories (multi level, and sometimes there can be up to some millions of files in a dir, but more likely are the range of 0-some hundred, thousands (up to 10k)) - directories also have metadata (most notably an mtime, which changes when directory contents are changed, that can be used to cache directory lists) - each directory (and the files therein) belongs to a user(name) - Cassandra 1.2 is fine Given that designing schema for Cassandra begins with listing the operations, here they are: 1. get the contents of a directory (input: directory (owner) name, output:file names) 2. get a file (in: file (dir) name, out:file metadata and contents) 3. put a file (in: file (dir, owner) name, metadata, data) 4. append to a file, chunk size maximum is 4-8 kB (in: file (dir, owner) name, data) 5. move a file to a different directory (in: file, dir (owner) name, target dir) 6. remove a file (in: file (dir, owner) name) 7. remove all stuff for a user (input: user name), but it's "rare" (compared to the above), so walking through the dirlist on the client side is OK, it's not performance critical All (minus the last) should be close to ACID. I've tried to do the homework (taken a look at Cassandra in the 0.6-7 times, so now I'm le-learning the new (1.2, CQL 3) way) and still couldn't find the best way. I thought the best would be to start with the docs, without any preliminary performance testing. This brought me the following schema: CREATE TABLE file ( name varchar PRIMARY KEY, owner varchar, dir varchar, flags set, fstat map, data list ); CREATE INDEX file_dir ON file (dir); CREATE INDEX file_owner ON file (owner); Which gives me for the operations: 1. something like SELECT name(,etc) FROM file WHERE dir="dirname"; Which can be LIMIT-ed. Problems: SLOOOW (and maybe despite the LIMIT, it materializes in the coordinator's memory, I don't know), also, doesn't scale, because all nodes must inspect their index CFs. 2. a simple SELECT data(,etc) FROM file WHERE name="filename"; Problems: Cassandra is said not to good at storing such amounts of data, it has to read all in memory (on the coordinator and the replica node), also the client will have to hold it in memory. But it seems to be acceptible to some levels, because all data is needed, so fetching it once is an optimization. The limiting factor here seems to be the network speed (nodes pass the data as a hot potato, the slower the network, the longer it has to be kept in memory), and CPU speed. 3. a simple INSERT INTO or UPDATE 4. 1.2's lists make appends easy 5. most important. It's a manner of UPDATE file SET dir VALUES("newdir") WHERE name="filename"; This either happens, or not, there is no situation where the file is in multiple directories, or nowhere. Even if a site (node) doesn't get it, it still sees the file on the old location, and if there is a move there, eventually everything will get into the right shape, without worrying needed on the client side. 6. a simple DELETE 7. SELECT and DELETEs For most operations, it seems fine (but your insightful recommendations are welcome :), the biggest pain seems to be listing directories. It takes seconds from minutes (or timeouts). I could add more CF(s) for example with composite columns (each directory being a row), but that would destroy the benefit of the above schema for moving files in one (atomic and idempotent) operation. Is there a schema, which can do best for all operations and still maintain ACID-like properties? Thanks, *: in terms of query efficiency, closeness to ACID --------------040302000101070601080309 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

I'm new to Cassandra, so I wonder what would be the most efficient(*) schema for specific operations on the following dataset:
- basically the task is to create a distributed file system with only few allowed operations
- it should handle split brain conditions well (two or three DCs, it's possible to get user requests while the intra-DC connections are down)
- each data file is blob (pretty often, but not always 8 bit text, sometimes without the encoding known), ranging from a few 100 bytes to around 20-30 MB. Average size is 350 kB.
- it's well compressible (gzip -1 gives 1.63x compress ratio on plain files)
- files are mostly immutable
- for the few, which are not, they are append-only
- each file has a unique file name (size in the range of 70-100 bytes) and it's preserved during its lifetime (if it changes, a rewrite is OK).
- the files have metadata attached (various, 1.2's sets and maps are a good fit here, but even simple columns should do)
- the files are organized into directories (multi level, and sometimes there can be up to some millions of files in a dir, but more likely are the range of 0-some hundred, thousands (up to 10k))
- directories also have metadata (most notably an mtime, which changes when directory contents are changed, that can be used to cache directory lists)
- each directory (and the files therein) belongs to a user(name)
- Cassandra 1.2 is fine

Given that designing schema for Cassandra begins with listing the operations, here they are:
1. get the contents of a directory (input: directory (owner) name, output:file names)
2. get a file (in: file (dir) name, out:file metadata and contents)
3. put a file (in: file (dir, owner) name, metadata, data)
4. append to a file, chunk size maximum is 4-8 kB (in: file (dir, owner) name, data)
5. move a file to a different directory (in: file, dir (owner) name, target dir)
6. remove a file (in: file (dir, owner) name)
7. remove all stuff for a user (input: user name), but it's "rare" (compared to the above), so walking through the dirlist on the client side is OK, it's not performance critical

All (minus the last) should be close to ACID.

I've tried to do the homework (taken a look at Cassandra in the 0.6-7 times, so now I'm le-learning the new (1.2, CQL 3) way) and still couldn't find the best way.

I thought the best would be to start with the docs, without any preliminary performance testing.

This brought me the following schema:
CREATE TABLE file (
  name varchar PRIMARY KEY,
  owner varchar,
  dir varchar,
  flags set<ascii>,
  fstat map<ascii, int>,
  data list<blob>
);
CREATE INDEX file_dir ON file (dir);
CREATE INDEX file_owner ON file (owner);

Which gives me for the operations:
1. something like SELECT name(,etc) FROM file WHERE dir="dirname"; Which can be LIMIT-ed. Problems: SLOOOW (and maybe despite the LIMIT, it materializes in the coordinator's memory, I don't know), also, doesn't scale, because all nodes must inspect their index CFs.
2. a simple SELECT data(,etc) FROM file WHERE name="filename"; Problems: Cassandra is said not to good at storing such amounts of data, it has to read all in memory (on the coordinator and the replica node), also the client will have to hold it in memory. But it seems to be acceptible to some levels, because all data is needed, so fetching it once is an optimization. The limiting factor here seems to be the network speed (nodes pass the data as a hot potato, the slower the network, the longer it has to be kept in memory), and CPU speed.
3. a simple INSERT INTO or UPDATE
4. 1.2's lists make appends easy
5. most important. It's a manner of UPDATE file SET dir VALUES("newdir") WHERE name="filename"; This either happens, or not, there is no situation where the file is in multiple directories, or nowhere. Even if a site (node) doesn't get it, it still sees the file on the old location, and if there is a move there, eventually everything will get into the right shape, without worrying needed on the client side.
6. a simple DELETE
7. SELECT and DELETEs

For most operations, it seems fine (but your insightful recommendations are welcome :), the biggest pain seems to be listing directories.
It takes seconds from minutes (or timeouts).
I could add more CF(s) for example with composite columns (each directory being a row), but that would destroy the benefit of the above schema for moving files in one (atomic and idempotent) operation.

Is there a schema, which can do best for all operations and still maintain ACID-like properties?

Thanks,

*: in terms of query efficiency, closeness to ACID
--------------040302000101070601080309--