Yes. The term "family" is from BigTable. Cassandra applications don't model data like BigTable. Keeping the term suggests that they do.
Evan PS. See the section "storage layout and api comparison" from my blog post: http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra/ On Fri, Aug 21, 2009 at 3:22 PM, Sandeep Tata<[email protected]> wrote: > Ah, so you're arguing that common cassandra designs don't typically > use business objects that span multiple column families, and therefore > the term "column family" shouldn't be used? > > I understand columns in Cassandra, I'm just not familiar with > "row-oriented modeling" and "column oriented modeling":-) > Even with relational column stores, column groups (or column families) > are a storage optimization based on access patterns you expect in > queries. They don't affect the primary goals of ER modeling like > normalization and capturing RI constraints. > > On Fri, Aug 21, 2009 at 3:04 PM, Evan Weaver<[email protected]> wrote: >> No...I'm talking about column-oriented schemas in the BigTable sense. >> It's unrelated to Cassandra's "columns". >> >> When a business object spans multiple column families, it can be >> considered "column-oriented" because same fields are stored physically >> close on disk despite being from different keys. It's similar to a >> projection in a relational column store. >> >> Evan >> >> On Fri, Aug 21, 2009 at 2:49 PM, Sandeep Tata<[email protected]> wrote: >>> Evan, >>> >>>> PS. The implementation of column families hasn't changed from >>>> BigTable, but the use in modeling has. Common Cassandra designs are >>>> more row-oriented than column-oriented. >>> >>> I'm not sure I understand the distinction you're drawing between >>> row-oriented modeling and column-oriented modeling. >>> Are you talking about row-oriented modeling as placing entire objects >>> in a column (today's nomenclature) and treating a cassandra column >>> like a database row? >>> >>> Sandeep >>> >> >> >> >> -- >> Evan Weaver >> > -- Evan Weaver
