最近，我开始研究HBase（面向列的数据库之一）。在浏览源代码时，一个问题不断涌现。想到这个想法。 我的问题是，面向行的数据库究竟是如何处理信息检索（比如选择查询）以及面向列的数据库时的不同之处。 这些数据库在底层平面文件中存储数据的方式有多么不同（在一天结束时，每个数据库都使用文件）。
如果我在这个问题的任何部分出错了，请纠正我。
此致 克里希纳
答案 0 :(得分：10)
答案 1 :(得分：8)
你的问题的一个问题是NOSQL社区已经挪用了长期存在的数据库术语“以列为导向”（有些人可能会说“被劫持”！）来描述与它原来的含义完全不同的东西。 “面向列”的两种含义仍然是最新的，但它们指的是非常不同的DBMS产品。因此，澄清你所谈论的内容往往是有帮助的。在这种情况下，它是该术语的NOSQL含义。
在面向列的数据库的原始含义中，您的问题的答案是您检索信息的方式没有区别。列存储不是一个不同的数据模型，它只是内部存储中的一种不同类型的表示。
然而，在NOSQL社区中，术语列存储是指不同类型的数据模型。
这里有很好的解释：
http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-of_29.html
答案 2 :(得分：2)
面向行的数据库，a.k.a。“传统的RDBMS”（如MySQL，Oracle，DB2）使用事务性二级索引更新，在大多数情况下使用类似B-Tree的结构用于二级索引
面向列的数据库，a.k.a。“NoSQL”（例如Google Big Table，HBase，Cassandra）使用主键索引的简化结构（不是B-Tree）
面向列的数据库不支持“传统”事务二级索引。用户有责任维护“倒排索引”。
Cassandra支持一行的B-Tree-like索引：一行中的每个单元格都有一个标题，单元格按标题进行物理排序。
另一个（可能是超级重要的）差异：对于Oracle中的zillions记录，你需要维护B-Tree作为主键，它的大小也将是千万只; “按主键查找”的表现并不好。
另一方面，你可以在Cassandra或HBase中拥有“宽行”，并将类似的“单元”组合成单行宽; “主键索引”的大小变小了数百万倍，“按主键查找”超快（并且它不是B-Tree;它是聚类搜索）