I can iterate over JSON data stored in mongo and present it as a table with rows and columns. It does not make mongo a rowstore.
On Fri, Sep 30, 2016 at 9:16 PM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > The problem with calling it a row store: > > https://en.wikipedia.org/wiki/Row_(database) > > In the context of a relational database > <https://en.wikipedia.org/wiki/Relational_database>, a *row*—also called > a record <https://en.wikipedia.org/wiki/Record_(computer_science)> or > tuple <https://en.wikipedia.org/wiki/Tuple>—represents a single, > implicitly structured data <https://en.wikipedia.org/wiki/Data> item in a > table <https://en.wikipedia.org/wiki/Table_(database)>. In simple terms, > a database table can be thought of as consisting of *rows* andcolumns > <https://en.wikipedia.org/wiki/Column_(database)> or fields > <https://en.wikipedia.org/wiki/Field_(computer_science)>.[1] > <https://en.wikipedia.org/wiki/Row_(database)#cite_note-1> Each row in a > table represents a set of related data, and every row in the table has the > same structure. > > When you have static columns and rows with maps, and lists, it is hard to > argue that every row has the same structure. Physically at the storage > layer they do not have the same structure and logically when accessing the > data they barely have the same structure, as the static column is just > appearing inside each row it is actually not contained in. > > On Fri, Sep 30, 2016 at 4:47 PM, Jonathan Haddad <j...@jonhaddad.com> > 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 use. >> On Fri, Sep 30, 2016 at 1:53 PM DuyHai Doan <doanduy...@gmail.com> 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 < >>> bened...@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 >>>> this awful nomenclature ever existed. >>>> >>>> >>>> >>>> On 30 September 2016 at 18:09, Joaquin Casares < >>>> joaq...@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 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 >>>>> key. >>>>> >>>>> 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 >>>>> able to return all columns that 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 ( >>>>> 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 >>>>> 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 key is stored as a column, including clustering keys (this >>>>> is 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 of >>>>> 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 <i...@mrcalonso.com> >>>>> wrote: >>>>> >>>>>> Cassandra is a Wide Column Store http://db-engines.com/en >>>>>> /system/Cassandra >>>>>> >>>>>> Carlos Alonso | Software Engineer | @calonso >>>>>> <https://twitter.com/calonso> >>>>>> >>>>>> On 30 September 2016 at 18:24, Mehdi Bada < >>>>>> mehdi.b...@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 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émont >>>>>>> mehdi.b...@dbi-services.com >>>>>>> www.dbi-services.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *⇒ dbi services is recruiting Oracle & SQL Server experts ! – Join >>>>>>> the team >>>>>>> <http://www.dbi-services.com/fr/dbi-services-et-ses-collaborateurs/offres-emplois-opportunites-carrieres/>* >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >
