tag:blogger.com,1999:blog-8899645800948009496.post470842105003385247..comments2024-03-18T21:59:02.831-07:00Comments on DBMS Musings: Distinguishing Two Major Types of Column-StoresDaniel Abadihttp://www.blogger.com/profile/16753133043157018521noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-8899645800948009496.post-25905016087725611732021-11-29T01:27:52.185-08:002021-11-29T01:27:52.185-08:00I noticed that the term "modern analytical sy...I noticed that the term "modern analytical systems" is recently popularly used to include Group B?Marchhttps://www.blogger.com/profile/05347071006579493264noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-26322243134800116622021-11-29T01:23:36.005-08:002021-11-29T01:23:36.005-08:00Cannot agree more.Cannot agree more.Marchhttps://www.blogger.com/profile/05347071006579493264noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-79658403978705585112019-07-15T17:54:07.122-07:002019-07-15T17:54:07.122-07:00Perhaps another difference is group B has B-Tree-v...Perhaps another difference is group B has B-Tree-variant storage and group A has LSM-tree/SSTable-variant?Anonymoushttps://www.blogger.com/profile/05187464857142575676noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-36145631073482685332019-01-04T03:00:01.900-08:002019-01-04T03:00:01.900-08:00Still a great explaination in 2019 ! Very clear an...Still a great explaination in 2019 ! Very clear and maybe the only post that deal correctly with this two very different type of database : Relational column-oriented DB and NoSQL family-column DB. May the hype don't borrow anymore an existing term to name a completly different new thing...Anonymoushttps://www.blogger.com/profile/09487941161435598265noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-13164402597199033672017-04-08T07:10:31.575-07:002017-04-08T07:10:31.575-07:00Hats off . Was tearing my hair and then got this. ...Hats off . Was tearing my hair and then got this. Thank you.Anonymoushttps://www.blogger.com/profile/08972040565691533240noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-46203305738796473042017-01-04T10:17:16.232-08:002017-01-04T10:17:16.232-08:00Excellent Article and good explanations in the com...Excellent Article and good explanations in the comments to. +1 to @edward for the comment.Kishore Bandi Shttps://www.blogger.com/profile/15336726556753930135noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-21418446005942329972016-09-02T06:43:36.704-07:002016-09-02T06:43:36.704-07:00Very helpful comparison, thanks.Very helpful comparison, thanks.Anonymoushttps://www.blogger.com/profile/10473101381793442268noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-16171780417470091682016-07-16T03:42:51.215-07:002016-07-16T03:42:51.215-07:00I agree with Edward, but a small wrinkle
Group A i...I agree with Edward, but a small wrinkle<br />Group A is a "Distributed map of maps" or "Distributed Map of sorted maps". Prithiviraj Damodaranhttps://www.blogger.com/profile/09121396085476250785noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-27928679239500197942014-08-04T16:36:28.155-07:002014-08-04T16:36:28.155-07:00+1+1Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-84943611752060931692014-04-18T12:35:33.844-07:002014-04-18T12:35:33.844-07:00Great article! Differences among the "column ...Great article! Differences among the "column stores" can be hard to put your finger on at first. The taxonomy you proposed makes perfect sense.DaveMoorehttps://www.blogger.com/profile/18164006455807907551noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-2684727224680179472013-09-24T11:23:32.785-07:002013-09-24T11:23:32.785-07:00I totally agree with you.
I think group A databas...I totally agree with you.<br /><br />I think group A databases should avoid the use of columns, in fact they are to blame for all the confusion. They could have used any other word, like key-value, dictionary, or hash-map.<br /><br />The fact that the keys are part of the data and not part of the schema is the main difference, that's where the sparseness comes from.<br /><br />I think having a standard naming convention for group A is the most important thing right now.Jenshttps://www.blogger.com/profile/14827264523408241153noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-87436926381043234262013-08-02T01:34:21.668-07:002013-08-02T01:34:21.668-07:00I'm not sure that this is relevant, but...
Ora...I'm not sure that this is relevant, but...<br />Oracle attacks this problem in a different way.<br />The Oracle optimizer will chose to scan an index (never reading the subject table) if that index contains all the columns required by the query. This makes the index a kind of row-by-row (Group A) extract of the table, arranged as a B-tree for fast searching. An obvious disadvantage is that the data is duplicated, but an upside is that one is not restricted to a given partitioning, but can have as many indexes as are useful. I should add that duplicate values in the index (particularly common in reference/dimension-type values) can be compressed, and nulls are, of course, absent.KrazyKathttps://www.blogger.com/profile/13498899870632397675noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-27873113342770537182013-07-30T12:42:06.255-07:002013-07-30T12:42:06.255-07:00Fantastic disposition!!!!!Fantastic disposition!!!!!Anonymoushttps://www.blogger.com/profile/07764610749492661683noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-26599814041674034402013-03-20T07:23:48.503-07:002013-03-20T07:23:48.503-07:00A bunch of thoughts:
- Groups A and B are really s...A bunch of thoughts:<br />- Groups A and B are really storage mechanisms that could be independent and used in parallel (e.g., B storage is wasteful if most values are null, so adopt sparse techniques ala A)<br />- Group A is problematic because of the composite values. Is it a value store or an index? Search on trailing column values requires scans.<br />- I don't see A as MVs, because there is no base table. This is a standard horizontal partition of an entity.<br />- Group A exists because the datastore designers opted for a lot of (storage expensive) strategies to keep the shards independent and reduce interaction. A lot of concurrency work can be done blind to other parts. Storing metadata with data distributes dictionary, allowing schema evolution without updates (which is possible in Group B, but would require versioning both in metadata and data.)<br />- Both groups rely on ordering for non-scan searches. Indexing is an interesting topic around both groups<br />- Group A closely matches what all of us thought DBMS would evolve to internally over time. A conceptual schema is defined, and automatically digested by an automated process analyzing use characteristics and creating the physical schema. It is just sad that trained professionals are used as compilers in this context.aaronwhttps://www.blogger.com/profile/08662527600866196364noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-8899701397277411912012-08-06T11:12:09.118-07:002012-08-06T11:12:09.118-07:00This post is really good .. its very much useful ....This post is really good .. its very much useful ... thanks for ur infoSyed Abdul Katherhttps://www.blogger.com/profile/00914166363600159534noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-71543019896865211332011-07-19T15:25:27.118-07:002011-07-19T15:25:27.118-07:00I would at this point characterize Group A as a ro...I would at this point characterize Group A as a row-oriented tuple store since each row consists of a set of name/value tuples with the constraint that the names are unique. Column families do throw a bit of a wrench into this definition, but since the lowest-level pattern of data is simply a set of tuples, I think it still makes sense.Kris Nuttycombehttps://www.blogger.com/profile/06347383351250086727noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-35224044436773554122011-04-24T09:25:43.035-07:002011-04-24T09:25:43.035-07:00Thanks , Good Explanation. I have a little confusi...Thanks , Good Explanation. I have a little confusion regarding storage difference between the group A and group B.<br />In group A , column family , store values row-wise but the column family is column wise, eg. in above case group A will store,<br /> row 1, first name : joe, last name :smith<br /> row 2, fist name : jack last name williams<br /> ...<br />and for Group B, you already mentioned. So<br />just want to confirm, is this the case, that I mentioned ?Noman Khanhttps://www.blogger.com/profile/04163750833132383324noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-28866591789327107812010-04-27T13:01:35.134-07:002010-04-27T13:01:35.134-07:00This comment has been removed by the author.Arto Bendikenhttps://www.blogger.com/profile/12670756684434923124noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-27014155045491173832010-04-07T02:17:31.642-07:002010-04-07T02:17:31.642-07:00Thanks! this is very clear explanation.
I want to ...Thanks! this is very clear explanation.<br />I want to add SADAS (sadasdb.com) in Column Store DBMS family.Unknownhttps://www.blogger.com/profile/12359912095510849108noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-12815555688591058212010-04-01T08:44:12.869-07:002010-04-01T08:44:12.869-07:00The outstanding definition of Group A systems is g...The outstanding definition of Group A systems is given by the post. Systems like Cassandra and Bigtable are "sparse, distributed, persistent multi-dimensional sorted maps". Therefore, the following names suits best:<br /><br />Group A: persistent (distributed) map<br />Group B: column store<br /><br />This name change is a big win for Group A, as it avoids the analogies with relational systems. In addition, modern programming languages have a map/dictionary data structure built in, and developers are used to it, so it will easy the path of adoption of Group A systems.<br /><br />Early adopters have a hard time understanding the concepts of NoSQL systems because of the use of words like table, column, and row that are not well suited for its particular context. Therefore, these names need to change too. I propose the following name change for systems in Group A:<br /><br />row -> key entry<br />table -> keyspace<br />column -> Attribute<br />column family -> Attribute Set<br /><br />Well, Cassandra seems to be half-way through this name change, but I think other systems in Group A should follow its example.eribeirohttps://www.blogger.com/profile/03798341926580142439noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-83237294937442676552010-03-31T20:26:51.068-07:002010-03-31T20:26:51.068-07:00Wow --- what a great comment thread! I definitely ...Wow --- what a great comment thread! I definitely recommend anybody who reads the post also reads the comment thread. I will add another addendum to the blog post to this effect.Daniel Abadihttps://www.blogger.com/profile/16753133043157018521noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-3601342452507580122010-03-30T15:33:27.361-07:002010-03-30T15:33:27.361-07:00It makes you wonder why are column stores part of ...It makes you wonder why are column stores part of NoSQL. <br /><br />The way I see it things like document stores, graph databases, etc that are horizontally scalable and have feature of high availability are NoSQL systems. Column stores look like reinventing the (relational) wheel and should be disregarded as such. This doesn't mean the technology isn't useful, and the advances should be disregarded. Just that it shouldn't be branded as NoSQL.<br /><br />What I think is interesting is the idea of storing our business objects in a natural form and be able to access them using sophisticated information retrieval techniques. And databases like CouchDB are much more exciting if you are thinking like this.Nuno Jobhttps://www.blogger.com/profile/02534312528961373590noreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-68239973588125224062010-03-30T04:23:07.138-07:002010-03-30T04:23:07.138-07:00There's a lot of confusion in the database ind...There's a lot of confusion in the database industry between the backend storage model, and the frontend API model.<br /><br />The backend model tends to be designed for performance, given an expected usage pattern; and the frontend designed for programmer convenience, given an expected usage pattern. So they both derive from the same usage pattern - but from different bits of it. The designer of the backend model might be interested in how common different operations are. The designer of the frontend model might not be so interested...<br /><br />We're feeling this keenly in the "SQL vs. NoSQL" debate. SQL vs. NoSQL is more an issue of API than of storage model, although there is some variation in the "logical" storage model (SQL makes dense tables, where all the columns are declared up front and generally widely used, easier; NoSQL systems often make it easier to be ad-hoc about what fields are in which records). However, there are widespread cries of "NoSQL is faster! SQL can't scale!", which is far from true, and confusing interface with implementation.<br /><br />I've been recorded talking briefly about these ideas at http://www.cloudbook.net/alaric-snell-pym<br /><br />My company (GenieDB) has written a replicated fault-tolerant key-value store, with various nifty properties - but, recognising that many people like to use SELECT statements, we've written a MySQL storage engine that backs onto our store. So the same data can be accessed via "NoSQL" or SQL interfaces, depending on needs. This makes it easier to migrate existing applications, and makes it easier for existing developers to use our stuff without having to learn everything from scratch.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-76426779233453020772010-03-30T02:33:47.279-07:002010-03-30T02:33:47.279-07:00I think #2 distinction is not that important, as i...I think #2 distinction is not that important, as in Group A you can setup one column per column family and effectively get column storage.<br /><br />I think the main difference is having firm schema and relational model vs not having them. Also Group A basically supports only one read operation - get document by key, (and map-reduce on top of that), so I'd call them Document Store vs Relational Column Store for Group B. Or does "document store" imply something very different?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8899645800948009496.post-24497619217391521072010-03-30T02:03:27.920-07:002010-03-30T02:03:27.920-07:00Part of the confusion seems to come from the use o...Part of the confusion seems to come from the use of the word "store".<br /><br />A: Datastore that is accessed by columns<br />B: Data is stored per column.<br /><br />Perhaps both should just be called database, and be prefixed with something prescriptive:<br /><br />A: Column-access database<br />B: Column-store databaseMarohttps://www.blogger.com/profile/13510024368951870757noreply@blogger.com