Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 4D102200B98 for ; Mon, 3 Oct 2016 18:45:56 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 4B97C160ADC; Mon, 3 Oct 2016 16:45:56 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id F2399160ACD for ; Mon, 3 Oct 2016 18:45:53 +0200 (CEST) Received: (qmail 5110 invoked by uid 500); 3 Oct 2016 16:45:52 -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 5100 invoked by uid 99); 3 Oct 2016 16:45:52 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 03 Oct 2016 16:45:52 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id B4F7FC0D64 for ; Mon, 3 Oct 2016 16:45:51 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.679 X-Spam-Level: * X-Spam-Status: No, score=1.679 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx2-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id VA9vUOX9uSI0 for ; Mon, 3 Oct 2016 16:45:47 +0000 (UTC) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by mx2-lw-eu.apache.org (ASF Mail Server at mx2-lw-eu.apache.org) with ESMTPS id 6A2425F4ED for ; Mon, 3 Oct 2016 16:45:46 +0000 (UTC) Received: by mail-it0-f53.google.com with SMTP id r192so120728375ita.0 for ; Mon, 03 Oct 2016 09:45:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=htENWD6Ntrnh1TlHU7np4kVgGLOy8pMDaQdTzG+as1w=; b=s2yqTkL7aXuwFzpHvPvkVj2fdcdAJ5rJBQX2mWs1ZmBFc8V/pooxBZmVfvgOxukHqJ DwVFr2oqTMDjC88YyZ2f/hA+IYjkNtt+AHyfCTMzXnbi2oZ7z49Jya2M7rMPJrGwJuOv yCGEfUvNmnZtzJfEUthRJqi9xLpx6poS8hneCxr0Q4v6Ogusj6dekYv433ou5RGwh1MJ /JouNMN2v7T6hyyu+Xoi1WzoOGtIroRTOpg1EbcxwKWXJaBHKKCyBcoBmKKoA/LSR+2m U9t1H31jLimEncG27hcKlNax52krQ91u6cehx6LRM/FLp5spkJwm+Jgm3PzTgQdQrKAp Yg9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=htENWD6Ntrnh1TlHU7np4kVgGLOy8pMDaQdTzG+as1w=; b=LMyiuGbOAU+R8futrZ6gmi96+DOaghJP87QwuVZiSgVGX5XkGUbhjlzlos9fM8hsTp K2jIdgApAY/tIy3hJYQYySoy3d2PWT9rX6OsX53j/WUnm+fn9am7X4MRp+f0CA7+QDrB F+86+91fq0vH0rTqDpF1ZkxnzQRznSlKc0ktxez+GfDaKHasn5P8Uz8mOOdcJJbbPKtd SPQazT2WN0+/q2L2UVVQPjJjs3tFhxv67hYihUK1/MydCZFnjrkyfPBG3mVKvmF4LqtA MX5dVcEepWZMyTA9+9b1qe5QmJF3SpIZa0RMGkyyHZ3QorKUO3rQyCQQkH1i5umHkbQM P35w== X-Gm-Message-State: AA6/9RmdSEfUsC7AExVawrfD1ZQiB+z7K8yNyPgR4LyNNf0MI4AEdCLusYaZTwI1pktd5GCRDv7OJFvmHbjIMg== X-Received: by 10.36.9.16 with SMTP id 16mr18700374itm.8.1475513138292; Mon, 03 Oct 2016 09:45:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.142.130 with HTTP; Mon, 3 Oct 2016 09:45:37 -0700 (PDT) In-Reply-To: References: <2045743758.13821426.1475252660560.JavaMail.zimbra@dbi-services.com> From: Peter Lin Date: Mon, 3 Oct 2016 12:45:37 -0400 Message-ID: Subject: Re: Cassandra data model right definition To: "user@cassandra.apache.org" Content-Type: multipart/related; boundary=001a1135043a787325053df8acc4 archived-at: Mon, 03 Oct 2016 16:45:56 -0000 --001a1135043a787325053df8acc4 Content-Type: multipart/alternative; boundary=001a1135043a787322053df8acc3 --001a1135043a787322053df8acc3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I've met clients that read the cassandra docs and then said in a big meeting "it's just like relational database, it has tables just like sqlserver/oracle." I'm not putting words in other people's mouth either, but I've heard that said enough times to want to puke. Does the docs claim cassandra is relational ? it absolutely doesn't make that claim, but the docs play loosey goosey with terminology. End result is it confuses new users that aren't experts, or technology managers that try to make a case for cassandra. we can make all the excuses we want, but that doesn't change the fact the docs aren't user friendly. writing great documentation is tough and most developers hate it. It's cuz we suck at it. There I said it, "we SUCK as writing user friendly documentation". As many people have pointed out, it's not unique to Cassandra. 80% of the tech docs out there suck, starting with IBM at the top. Saying the docs suck isn't an indictment of anyone, it's just the reality of writing good documentation. On Mon, Oct 3, 2016 at 12:33 PM, Jonathan Haddad wrote: > Nobody is claiming Cassandra is a relational I'm not sure why that keeps > coming up. > On Mon, Oct 3, 2016 at 10:53 AM Edward Capriolo > wrote: > >> My original point can be summed up as: >> >> Do not define cassandra in terms SMILES & METAPHORS. Such words include >> "like" and "close relative". >> >> For the specifics: >> >> >> Any relational db could (and I'm sure one does!) allow for sparse fields >> as well. MySQL can be backed by rocksdb now, does that make it not a row >> store? >> >> >> Lets draw some lines, a relational database is clearly defined. >> >> https://en.wikipedia.org/wiki/Edgar_F._Codd >> >> Codd's theorem , a >> result proven in his seminal work on the relational model, equates the >> expressive power of relational algebra >> and relational >> calculus (both of >> which, lacking recursion, are strictly less powerful thanfirst-order >> logic ).[*citation >> needed *] >> >> As the relational model started to become fashionable in the early 1980s= , >> Codd fought a sometimes bitter campaign to prevent the term being misuse= d >> by database vendors who had merely added a relational veneer to older >> technology. As part of this campaign, he published his 12 rules >> to define what >> constituted a relational database. This made his position in IBM >> increasingly difficult, so he left to form his own consulting company wi= th >> Chris Date and others. >> >> Cassandra is not a relational database. >> >> I am have attempted to illustrate that a "row store" is defined as well. >> I do not believe Cassandra is a "row store". >> >> >> >> "Just because it uses log structured storage, sparse fields, and >> semi-flexible collections doesn't disqualify it from calling it a "row >> store"" >> >> What is the definition of "row store". Is it a logical construct or a >> physical one? >> >> Why isn't mongo DB a "row store"? I can drop a schema on top of mongo an= d >> present it as rows and columns. It seems to pass the litmus test being >> presented. >> >> https://github.com/mongodb/mongo-hadoop/wiki/Hive-Usage >> >> >> >> >> >> On Mon, Oct 3, 2016 at 10:02 AM, Jonathan Haddad >> wrote: >> >> Sorry Ed, but you're really stretching here. A table in Cassandra is >> structured by a schema with the data for each row stored together in eac= h >> data file. Just because it uses log structured storage, sparse fields, a= nd >> semi-flexible collections doesn't disqualify it from calling it a "row >> store" >> >> Postgres added flexible storage through hstore, I don't hear anyone >> arguing that it needs to be renamed. >> >> Any relational db could (and I'm sure one does!) allow for sparse fields >> as well. MySQL can be backed by rocksdb now, does that make it not a row >> store? >> >> You're arguing that everything is wrong but you're not proposing an >> alternative, which is not productive. >> On Mon, Oct 3, 2016 at 9:40 AM Edward Capriolo >> wrote: >> >> Also every piece of techincal information that describes a rowstore >> >> http://cs-www.cs.yale.edu/homes/dna/talks/abadi-sigmod08-slides.pdf >> https://en.wikipedia.org/wiki/Column-oriented_DBMS#Row-oriented_systems >> >> Does it like this: >> >> 001:10,Smith,Joe,40000; >> 002:12,Jones,Mary,50000; >> 003:11,Johnson,Cathy,44000; >> 004:22,Jones,Bob,55000; >> >> >> >> The never depict a scenario where a the data looks like this on disk: >> >> 001:10,Smith >> >> 001:10,40000; >> >> Which is much closer to how Cassandra *stores* it's data. >> >> >> >> On Fri, Sep 30, 2016 at 5:12 PM, Benedict Elliott Smith < >> benedict@apache.org> wrote: >> >> Absolutely. A "partitioned row store" is exactly what I would call it. >> As it happens, our README thinks the same, which is fantastic. >> >> I thought I'd take a look at the rest of our cohort, and didn't get far >> before disappointment. HBase literally calls itself a "*column-oriented= * store" >> - which is so totally wrong it's simultaneously hilarious and tragic. >> >> I guess we can't blame the wider internet for misunderstanding/misnaming >> us poor "wide column stores" if even one of the major examples doesn't k= now >> what it, itself, is! >> >> >> >> >> On 30 September 2016 at 21:47, Jonathan Haddad wrote= : >> >> +1000 to what Benedict says. I usually call it a "partitioned row store" >> which usually needs some extra explanation but is more accurate than >> "column family" or whatever other thrift era terminology people still us= e. >> On Fri, Sep 30, 2016 at 1:53 PM DuyHai Doan wrote= : >> >> I used to present Cassandra as a NoSQL datastore with "distributed" >> table. This definition is closer to CQL and has some academic background >> (distributed hash table). >> >> >> On Fri, Sep 30, 2016 at 7:43 PM, Benedict Elliott Smith < >> benedict@apache.org> wrote: >> >> Cassandra is not a "wide column store" anymore. It has a schema. Only >> thrift users no longer think they have a schema (though they do), and >> thrift is being deprecated. >> >> I really wish everyone would kill the term "wide column store" with >> fire. It seems to have never meant anything beyond "schema-less, >> row-oriented", and a "column store" means literally the opposite of this= . >> >> Not only that, but people don't even seem to realise the term "column >> store" existed long before "wide column store" and the latter is often >> abbreviated to the former, as here: http://www.planetcassandra. >> org/what-is-nosql/ >> >> Since it no longer applies, let's all agree as a community to forget thi= s >> awful nomenclature ever existed. >> >> >> >> On 30 September 2016 at 18:09, Joaquin Casares > > wrote: >> >> Hi Mehdi, >> >> I can help clarify a few things. >> >> As Carlos said, Cassandra is a Wide Column Store. Theoretically a row ca= n >> have 2 billion columns, but in practice it shouldn't have more than 100 >> million columns. >> >> Cassandra partitions data to certain nodes based on the partition key(s)= , >> but does provide the option of setting zero or more clustering keys. >> Together, the partition key(s) and clustering key(s) form the primary ke= y. >> >> When writing to Cassandra, you will need to provide the full primary key= , >> however, when reading from Cassandra, you only need to provide the full >> partition key. >> >> When you only provide the partition key for a read operation, you're abl= e >> to return all columns that exist on that partition with low latency. The= se >> columns are displayed as "CQL rows" to make it easier to reason about. >> >> Consider the schema: >> >> CREATE TABLE foo ( >> bar uuid, >> >> boz uuid, >> >> baz timeuuid, >> data1 text, >> >> data2 text, >> >> PRIMARY KEY ((bar, boz), baz) >> >> ); >> >> >> When you write to Cassandra you will need to send bar, boz, and baz and >> optionally data*, if it's relevant for that CQL row. If you chose not to >> define a data* field for a particular CQL row, then nothing is stored no= r >> allocated on disk. But I wouldn't consider that caveat to be "schema-les= s". >> >> However, all writes to the same bar/boz will end up on the same Cassandr= a >> replica set (a configurable number of nodes) and be stored on the same >> place(s) on disk within the SSTable(s). And on disk, each field that's n= ot >> a partition key is stored as a column, including clustering keys (this i= s >> optimized in Cassandra 3+, but now we're getting deep into internals). >> >> In this way you can get fast responses for all activity for bar/boz >> either over time, or for a specific time, with roughly the same number o= f >> disk seeks, with varying lengths on the disk scans. >> >> Hope that helps! >> >> Joaquin Casares >> Consultant >> Austin, TX >> >> Apache Cassandra Consulting >> http://www.thelastpickle.com >> >> On Fri, Sep 30, 2016 at 11:40 AM, Carlos Alonso >> wrote: >> >> Cassandra is a Wide Column Store http://db-engines.com/ >> en/system/Cassandra >> >> Carlos Alonso | Software Engineer | @calonso >> >> >> On 30 September 2016 at 18:24, Mehdi Bada >> wrote: >> >> Hi all, >> >> I have a theoritical question: >> - Is Apache Cassandra really a column store? >> Column store mean storing the data as column rather than as a rows. >> >> In fact C* store the data as row, and data is partionned with row key. >> >> Finally, for me, Cassandra is a row oriented schema less DBMS.... Is it >> true for you also??? >> >> Many thanks in advance for your reply >> >> Best Regards >> Mehdi Bada >> ---- >> >> *Mehdi Bada* | Consultant >> Phone: +41 32 422 96 00 | Mobile: +41 79 928 75 48 | Fax: +41 32 422 96 >> 15 >> dbi services, Rue de la Jeunesse 2, CH-2800 Del=C3=A9mont >> mehdi.bada@dbi-services.com >> www.dbi-services.com >> >> >> >> >> *=E2=87=92 dbi services is recruiting Oracle & SQL Server experts ! =E2= =80=93 Join the >> team >> * >> >> >> >> >> >> >> >> --001a1135043a787322053df8acc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've met clients that read the cassandr= a docs and then said in a big meeting "it's just like relational d= atabase, it has tables just like sqlserver/oracle."

I'= ;m not putting words in other people's mouth either, but I've heard= that said enough times to want to puke. Does the docs claim cassandra is r= elational ? it absolutely doesn't make that claim, but the docs play lo= osey goosey with terminology. End result is it confuses new users that aren= 't experts, or technology managers that try to make a case for cassandr= a.

we can make all the excuses we want, but that doesn't c= hange the fact the docs aren't user friendly. writing great documentati= on is tough and most developers hate it. It's cuz we suck at it. There = I said it, "we SUCK as writing user friendly documentation". As m= any people have pointed out, it's not unique to Cassandra. 80% of the t= ech docs out there suck, starting with IBM at the top.

Saying = the docs suck isn't an indictment of anyone, it's just the reality = of writing good documentation.

On Mon, Oct 3, 2016 at 12:33 PM, Jonathan Haddad <j= on@jonhaddad.com> wrote:
No= body is claiming Cassandra is a relational I'm not sure why that keeps = coming up.
On Mon, Oct 3, 2016 at 10:53 AM Edward Capriolo <= ;edlinuxguru@gma= il.com> wrote:
My original point can be summe= d up as:

Do not define cassandra in terms SMILES & METAPH= ORS. Such words include "like" and "close relative".=C2= =A0

For the specifics:


Any re= lational db could (and I'm sure one does!) allow for sparse fields as w= ell. MySQL can be backed by rocksdb now, does that make it not a row store?=


= Lets draw some lines, a relational database is clearly defined.

https://en.wikipedia.= org/wiki/Edgar_F._Codd

Codd's theorem, a result proven in his seminal work= on the relational model, equates the expressive power of=C2=A0relational a= lgebra=C2=A0and=C2=A0relational calculus=C2=A0(both of which, lac= king recursion, are strictly less powerful thanfirst-order logic).[citation needed]

As the relational model started to become fashionable= in the early 1980s, Codd fought a sometimes bitter campaign to prevent the= term being misused by database vendors who had merely added a relational v= eneer to older technology. As part of this campaign, he published his=C2=A0= 12 rules=C2=A0to define w= hat constituted a relational database. This made his position in IBM increa= singly difficult, so he left to form his own consulting company with Chris = Date and others.
=
Cassandra is not a relational = database.

I am have attempted to illustrate that a "row = store" is defined as well. I do not believe Cassandra is a "row s= tore".=C2=A0



&q= uot;Just because it uses log structured storage, sparse fields, = and semi-flexible collections doesn't disqualify it from calling it a &= quot;row store""

What is the definition of "row store". Is it a logi= cal construct or a physical one?

Why isn't mongo DB a &q= uot;row store"? I can drop a schema on top of mongo and present it as = rows and columns. It seems to pass the litmus test being presented.

https://github.c= om/mongodb/mongo-hadoop/wiki/Hive-Usage





On Mon, Oct 3, 2016 at 10:02 AM, Jonathan Haddad <= jon@jonhaddad.com> wrote:
Sorry Ed, but you're r= eally stretching here. A table in Cassandra is structured by a schema with = the data for each row stored together in each data file. Just because it us= es log structured storage, sparse fields, and semi-flexible collections doe= sn't disqualify it from calling it a "row store"

Postgres added flexible storage through hstore, I don't hear anyone a= rguing that it needs to be renamed.

Any relational db could = (and I'm sure one does!) allow for sparse fields as well. MySQL can be = backed by rocksdb now, does that make it not a row store?

You= 're arguing that everything is wrong but you're not proposing an al= ternative, which is not productive.
On Mon, Oct 3, 2016 at 9:40 A= M Edward Capriolo <edlinuxguru@gmail.com>= ; wrote:
Also every piece of techincal information that = describes a rowstore

http://cs-www.cs.yale.edu/homes/dna/talks/abadi= -sigmod08-slides.pdf
https://en= .wikipedia.org/wiki/Column-oriented_DBMS#Row-oriented_systems=

Does it like this:=C2=A0
001:10,Smith,Joe,40000;
002:12,Jones,Mary,50000;
003:11,Johnson,Cathy,44000;
004:22,Jones,Bob,55000;

The never depict a scenario where= a the data looks like this on disk:

001:10,Smith
001:10,40000;
Which is much closer to how Cassandra stores it's data.



On Fri, Sep 3= 0, 2016 at 5:12 PM, Benedict Elliott Smith <benedict@apache.org> wrote:
Absolutely.=C2=A0 A "partitioned row st= ore" is exactly what I would call it.=C2=A0 As it happens, our README = thinks the same, which is fantastic. =C2=A0

I thought I'd take a look at the res= t of our cohort, and didn't get far before disappointment.=C2=A0 HBase = literally calls itself a "c= olumn-oriented=C2=A0store" - which is so totally wrong it's si= multaneously hilarious and tragic. =C2=A0

I guess we can't blame the wider interne= t for misunderstanding/misnaming us poor "wide column stores" if = even one of the major examples doesn't know what it, itself, is!
<= div class=3D"m_1061060901321611475m_-940935237497870652m_-18260983274657888= 64gmail_msg m_1061060901321611475gmail_msg">



=
On 30 September 20= 16 at 21:47, Jonathan Haddad <jon@jonhaddad.com> wrote:=
+1000 to what Benedict says. I usually call i= t a "partitioned row store" which usually needs some extra explan= ation but is more accurate than "column family" or whatever other= thrift era terminology people still use.
On Fri, Sep= 30, 2016 at 1:53 PM DuyHai Doan <doanduyhai@gmai= l.com> wrote:
I used to present Cassandra as a NoSQ= L datastore with "distributed" table. This definition is closer t= o CQL and has some academic background (distributed hash table).

On Fri, Sep 30, 2016 at 7:43 PM, Benedict Elliott S= mith <benedict@apache.org> wrote:
Cassandra is not a "wide column store" anymore.=C2=A0 It = has a schema.=C2=A0 Only thrift users no longer think they have a schema (t= hough they do), and thrift is being deprecated.
I really wish everyone would kill the term "wide col= umn store" with fire.=C2=A0 It seems to have never meant anything beyo= nd "schema-less, row-oriented", and a "column store" me= ans literally the opposite of this.

= Not only that, but people don't even seem to realise the term "col= umn store" existed long before "wide column store" and the l= atter is often abbreviated to the former, as here: http://www.planetcassandra.org/what-is-nosql/=C2= =A0

S= ince it no longer applies, let's all agree as a community to forget thi= s awful nomenclature ever existed.


<= /div>

On 30 September 2016 at 18:09, Joaquin Ca= sares <joaquin@thelastpickle.com> wrote:
Hi Mehdi,

I can help clarify a few things.

As Carlos said, Cassandra is a Wide Column = Store. Theoretically a row can have 2 billion columns, but in practice it s= houldn't have more than 100 million columns.

<= div class=3D"m_1061060901321611475m_-940935237497870652m_-18260983274657888= 64gmail_msg m_1061060901321611475gmail_msg">Cassandra partitions data to ce= rtain nodes based on the partition key(s), but does provide the option of s= etting zero or more clustering keys. Together, the=C2=A0partition=C2=A0key(= s) and clustering key(s) form the primary key.

When writing to Cassandra, you wi= ll need to provide the full primary key, however, when reading from Cassand= ra, you only need to provide the full partition key.

When you only provide the p= artition key for a read operation, you're able to return all columns th= at exist on that partition with low latency. These columns are displayed as= "CQL rows" to make it easier to reason about.

Consider the schema:

CREATE TABLE foo (
=C2=A0 bar uuid,
=C2=A0 boz u= uid,
=C2=A0 baz timeuuid,
=C2=A0 data1 text,
=C2=A0 da= ta2 text,
=C2=A0 PRIMARY KEY ((bar, boz), baz)
);

When you write to Ca= ssandra you will need to send bar, boz, and baz and optionally data*, if it= 's relevant for that CQL row. If you chose not to define a data* field = for a particular CQL row, then nothing is stored nor allocated on disk. But= I wouldn't consider that caveat to be "schema-less".

However, all= writes to the same bar/boz will end up on the same Cassandra replica set (= a configurable number of nodes) and be stored on the same place(s) on disk = within the SSTable(s). And on disk, each field that's not a partition k= ey is stored as a column, including clustering keys (this is optimized in C= assandra 3+, but now we're getting deep into internals).

In this way you can= get fast responses for all activity for bar/boz either over time, or for a= specific time, with roughly the same number of disk seeks, with varying le= ngths on the disk scans.
=
Hope that helps!

Joaquin Casares
C= onsultant

Apache Cassandra Consulting
http://www.thelastpickle.com

On Fri, Sep 30, 2016 at 11:40 AM, Carlos Alonso <= span dir=3D"ltr" class=3D"m_1061060901321611475m_-940935237497870652m_-1826= 098327465788864gmail_msg m_1061060901321611475gmail_msg"><info@mrcalonso.com> wrote:
Cassandra is a W= ide Column Store=C2=A0http://db-engine= s.com/en/system/Cassandra

Carlos Alonso | Software Engineer |=C2=A0@calonso

On 30 September 2016 at 18:24, Mehdi Bada <mehdi.bada@dbi-services.com> wrote:
Hi all,

I have a theoritical= question:
- Is Apache Cassandra really a column store?=
Column store mean storing the data as column rather tha= n as a rows.

In fact C* store the= data as row, and data is partionned with row key.

Finally, for me, Cassandra is a row oriented schema less DBM= S.... Is it true for you also???

Man= y thanks in advance for your reply

B= est Regards
Mehdi Bada
----

Mehdi Bada | Consultant
Phone: +41 32 422 96 00 | Mobile: = +41 79 928 75 48 | Fax= :=C2=A0+41 32 422 96 15
dbi services, Rue de la = Jeunesse 2, CH-2800 Del=C3=A9mont
mehdi.bada@dbi-services.com=
www.dbi-services.com



=E2=87=92 dbi services is recruiting O= racle & SQL Server experts ! =E2=80=93 Join the team


=


=
=

--001a1135043a787322053df8acc3-- --001a1135043a787325053df8acc4 Content-Type: image/png; name="logo signature.png" Content-Disposition: inline; filename="logo signature.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: db6081752cd6482e_0.1.1 iVBORw0KGgoAAAANSUhEUgAAAXUAAAAnCAIAAAB/rk/XAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAA6pSURBVHhe7Z1pUFvXFcdfO0mbdPqhM51m2mZt J9tMJh/6oUmnbToTO15xnMXjJplJtyzTOHXjJI0TGxvjQHBiiBOCzWLA2MYLYjE2ZhU2GBsj9n0n FhL7asxiBJJA9C+dx/Xzk54kZEiUzP3NG807955777nb/90nwBbmOBwOZ2ng+sLhcJaKm/RldHS0 u7tbq9W2cxaCXq8fGhoym83iOHI4HBuivlgsloGBgf7+foPBMD09beS4DYZramoK0tzV1WUymWg8 ORwOEPVlYmKir6+Pbw+PgUCPjY319vaKNofDYfqC1yI8hOme4xlQZ51OJxocDofpi1ar5fpy63R2 dop3HA6H6Ut7e7tX68us2Xp5PVxfOBwpi6kvNbrhFf5ZT+/IrNOPwJw0mn3PVLwUm59e5/mus5gM k+d3jnz1yEjoI9fzA+YsM2KGV8L1hcORspj6kl/fIzwbLayOutjYB3N8yrQyLOeurScjLjaTgwcY CvcOfigM+Vov3BiK9okZXgnXFw5HymLqS0FD720vHhKejSls6ocJffEJz71nu+pgYQs5LBjLzLWo J4a2C0N+1mtwuzAa+xcxyyvh+sLhSPFyfZkdPbx8cNu8vmwTxuLXilleCdcXDkeKd+vL3Jyx5eyQ 34+hLFaV+finxq/VYoZXwvWFw5Hi7foCTB2XJzK24DL3VIhJ3grXFw5HygL0ZXbW4vASs93Tl1mL xeFluVHNzcyajV9nT1UdxmVsTrOYp8V0r2Sh+lJWVuZvQ7RdUV9fHxISAv+IiAgxifP9QqvVxsfH BwUF0cLARF+6dEnMW1QWuvY8w7W+VFwZCjld9+Kn5x55O9nBtSnpya1pAaqqK71jmpYBh/oSp2mb mDYllGtfP1a4er967YFc2bXmgPqFqPPBuXUFbX0ypTFoQunlyHp9JEzmL+1w3CJLrS8kLmAp9OUb WHBUPxoS7W8VrwqGgLgwZZGyFEF+A9MNnOkLjhV+Jyru3BAnrIgUnomwfq7Ap6NrWfg9ryXA+Y6N h2X6cv+OxN0ZVa8cunD3dhWue32VrkR8Puyf8m5yycjk/CHFYhmNe3pw/udHQ77CtYNPzFlmxVzv Y6n1hZy/uw80qt9LtrRXBUOoVCqEBImB0MDEZ2pq6rlz5yj3u4gzfYnKaRbWRAk+0T97JR7nl6P5 bWdKO+yv0PSGZ3Zl3fZCnLA+5ofPx+JTqi8P+ac8FpD64K7kjTF5hzSteS299lduUzc0aNmXWXC7 b0filqSSGXrtssyOxv5p0FeiL9F/WPRfsTOaZ+v0V5Xf0BbALeoLM3FCppvY2Njh4WHKpRSCzi/M H+uSnnvkj3TcUBbSURurBECeQkNDKRc3WMFUhFIIJMITn7iHD9WGqtAQSycfZkqPVHiPYwHgBiYS ySSk8bOCLAaZKesdsvDJhgjhKQmuk3GgREJ2GGTtMmdqC59kwoENIOonLaB0pHjQHQbKIp015BCM NhXHYZZNAaBZkE0WVUizBjARMAFiloUHHM4aodSoSxT15er49N2vnRTWHrzrb8dLWgfEVGVOaXR3 4OVofYy9vkA19qrrps0udKH72vUN0Xnwf3R3ikZra9GqL39ean0xGM0Jl65Iv0jymMXSFylsvYq2 DUq096eliZXBNgAB01aHVVzEpHno8SiritYQLVkp5EzpbJ2RyeJE67QWGRSVaNiQxs8KuhwNtvFk vQNwpiwpTsZBtG2wABj0HsoODtQdUjHUaSt0AziTTHjcHQZSkI7m0BaTLSlQCirLkM2CFMQPcIMI yScjIwMmDYIsPKVZA04adYmivpwu0Vt/GdfnIN56xCRX/CvsovW8c7O+/GZn0poDatOMWy81FR1D OOzglSo4t85qu9IXvMGpCrVfnamPyGral1qbU9mFxLzann2n6yKzm5GCexyFkora92c0hmc07kur 1w2MJ1zSssMKulnfMVLQ0IuUzIpOFAnPavosuabI1oXUYj0qR1XBqbUVV4aQgrJfpdXDx9pcVZdM kxZLX2hlsxVDuYBMuJEp83f4GKcVBmi90gPKfmUDWTCAAsCyw+LDFmLtUjpbZGSyfUWbBIsYRQBz A0gHsvhdbkhZ76hH7OFPrTPhUEI2DoBMFowUqhNN4J4UmW1RGkDEjNbZnqQIPeuOFPtNjtqYJyJH CiKhLrAKpeMgmyzckA8SYZLaSqMFuAdKs+a8UZco6sunKTXCqijhudgqrVsVAbxACWsOyr5/uddX 5Z9eSQ4umZg2rYvIfWBn4sux+dYXFlf60n118nfvpV5u6m/oGMmr7fY7UTkyMb3645zUYl1xy0Ba id4nIKele/SPH509Xay/0jcGhz0pNR8cLs0o70Bx/cDEuk/UrT2j78RomjqvLffLLGsb1PaNQZV8 j5Wj4yt2ZamrulAVurY2IAc+PoHqwsY+W3M9b0cVyXRzsfSFTEyh1ARk0tIBMn8lyIdK0TLCcsEN 1hCWGlso9rXRkmUbhkHpbAnK3GiHONw/SAey+F1uSDIZ1AV7xGxlyI21LjOl0KYCuKHm2CuGdIsC khsaCs+6IwNCgBYxQeRMUJBoVLRvhnKVJovFzzpFMy6LR2nWnDfqEkV9+fBoGfTlJ3890tw1Kia5 4mJjn8OfH8VcbiUHd3jz+OX7diSuC8+1fgXjSl/warPjeEXwqZrPUmp2HivfnVBV3T68zC8zQFXl f7IyUFX1flxJ5ZWhd2OLzbbXn/5rhraeUQjNxr3nJ6fN7x8qwfFn3GCC4mia+987VELVAiTiaLNi VzZVFZBgrQp6tOtEZXBKLURqR3zZblWl+D3RPIurL8ChyabW3p/AGqVtIIVK2T8h6ZGFLPvalJYs pdOmYiZzs1ahsP5kWdTiQjck/Cldhpgtwck4AJkpgwrihYKGi57ewFboRinpUFDAC+2OExA/CQ00 Aia1ZQ8FI5sFBjt/0csRHcqALB66p6qkOG/UJYr68t9ojbAy8pf/PNk5dF1MckWd/ir0SFgXLdWX u7erTpReIQd3IH1ZtV/tjr5gw0MUOgYncNW2D6/enV3SOvDy5/mNHSO9I5O6/vE9ydW1uqvQEZkQ hGU0vBySvymyCG9YQ2NTm6Ot55dV/tlNnSNdw9ertcNQHJxlXgrJw3Gm79pkW/doYGJ1advgx4lV nYMT+sEJyNb6oFyIlFijDS/RF5mCEKwU1AT3WDeAPB0emAGtLfslS+nskS5zoy3BnvBSkA5k8WMn S03g0GRIjwzOcT4OMlOG9LnNIgSkbqx39ueXhXbHOdKxJYGwnw5CNgtSaBzok51QZPEozZrzRl2i qC9bYopt+nLCfX2pV9CX40umL0bz7OG8tv3pDQGJVeEZDSkaHd6q8up6IjMbPz1Vs/9sA44nkID8 OuvXK1Impkyfn6nDQQb3OASdq+mGQ0Z5Jyr5JKl63+laFEFWWqkeVe1Jrgk7W59e3oHmjuS1HUBz KltzRe1L9P0LmcChCTcyHS5ZPPQokR65zGSlGHCQripWG3tjUlqylI6yqAHO9KhnbnQgRyKyAO09 AunAfolTbFQQyHLJZNCKx25B18QkR7gcBzIdvscBRE4OQLrrHH7/gpCQ5Vl3pKBC1CwdH5ogknLW BXsVAE70hX1Bi2jFJLt4lGbNnUaBaNuhqC/b48uF1VG3b4hr6LD+Yy7uoPT7u9EL+fuAN45Z9QUF 3dEXb8NLzi+0KGVQKawS2hIMmFhPyMI+FJPmH8hKS5a1K4W5oR5ZE3S8Bywwcka7Mk+CnJV6h1Ky DsJkYyLFyThIcx3uScAEgsaHYPuNgXrIwbPuMOz7RaBOkkhA6sZAFkkbcKIvLGY2EUAWj5NZc9ko INMeRX0JTq21fb8bQz9JcYdodQskSfbzo/t8E7efKScHl4wajCvDch7YmfRqXIE73+96G174/Qvb JHDGCsbKYFkASwfOYjGJ+jjXFwBP2gz4hIPMDXWyRSltAjdUijmzUNEuK0JZSr0D2AzoF4VKBaW9 YLDKgXQcWK4sGBn02JfuSQI1sGrRNNv8wLPuMFAVGmWVIzy0LlU33GNSKGyAyNlhx8lkASrC+g7s 40HwLGbpkLpsFJBpj6K+ZFd2/uDZGGHtwTfDC8UkV6zanQ1/+c+n/ZKWfZk1NmUkH+dcaOt9dHfK /TsSQ/MbrPb3XV84Xgs7TSi9QHHcQVFfxg2mhzYlQS/u3BAXkdk0ZnD2X5cMj09/dLRMWBctrHfw +7u/9UvanKjRDY+TsxIa7cCqMPWDu5IfC0it7rpqTeL6wvk2YI9lSIyYxPEIRX0ByUXttz8Xa/2V Fp/oxzanrAtUbz1SGny6LjyrKTK7+Yu0+j3JNe/EaNYGqh/8d5KwMvIXfz/+ow1xsu9foBdPf5kJ iXlyb/rrxwr90yvDC5qOFrepKtpxJVS0x2naArOq/3Hk4uOBqXDD4WWvum6Wvo+1WEZjn7rp74+i fg/RsWZ5JVxfvh+QvkBc2DsCxzOc6QtIKdI9vjkFkiEsjxCWh1v/ylF2IXFZuLA6Ci9Hh/Narb/y uyKyoMH67++OTZmWh2b//IMTYRcaP8upfdg/5VfbEn69LYH+0PEe20X3uJAOcXlqX2Z0YYsoLjau n9858MH8309vFcbPviVmeCVcXzgcKS70BRiMM+llHZ+n1m6JKX71iwvP7znnE6he5pe5Pih34968 tyIvByVWn9LozDOzPVcng5KrAxOr6EfaRvNMQoU2NL+husv6BVWpbjDmcusnWdX/Syn9j0qDs8wb xws3qzTvJpfsSq88UNB0pqbjxl9Oz2Mxjk8Whkyc3TSRtmmyIGjWYHtv8la4vnA4UlzrC8d9uL5w OFK4viwmXF84HCmivnR1dXF9uUVMJpNerxcNDofD9GVsbGxgYMBs/g78H6xeC8awu7tbNDgcDtMX i8XS29s7PDxsMBiMRiMexRz3mZ6ehrjg5QhDR+PJ4XCAqC8AEjMyMoJNgkN+O8dtdDodPnH64+LC 4ci4oS8cDoezuHB94XA4S8Pc3P8BAs+M9iABHg0AAAAASUVORK5CYII= --001a1135043a787325053df8acc4--