最近，我开始研究 HBase（面向列的数据库之一）。在浏览源代码时，一个问题一直在我脑海中浮现。想问这个。 我的问题是，面向行的数据库究竟如何处理信息检索（比如选择查询），以及面向列的数据库有何不同。 以及这些数据库在底层平面文件中存储数据的不同之处（最终，每个数据库都使用文件）。
如果我在这个问题的任何部分出错，请纠正我。
问候， 克里希纳
【问题讨论】：
标签： java database database-design hadoop hbase
如果我理解正确的话，你对底层存储和检索问题更感兴趣，而不是 DDL 和定义问题，面向列的 dbs 的类别，对吧？
我假设您了解几乎所有存储，无论供应商如何，都是以下某种形式：
在此基础之上，每个供应商都有优化和专利专业化。例如。 Sybase（行）有：
下一个问题是所有供应商（除了 oracle）都有相当复杂的引擎，采用模块化设计，并且 I/O 在低级别异步处理以获得速度。 I/O 的单位是页。 OLTP 系统通常为 2 到 8KB，DSS 系统通常为 8 到 64KB。 （注意我避免了行与列的问题。）因此，无论行/列如何，DSS 引擎都是为大规模检索而构建的，因为在大块中获得更多的索引/数据行或列，而 I/O 请求更少。
“Large I/O”可以通过一个 I/O 请求将 Extents (8 Pages) 和更大的 AllocationUnits (256 Pages) 读入内存来执行。但基本单位是页面。
行与列
针对引擎执行的所有查询，都必须导航索引，从上述数据存储结构中检索数据行/列。
结果是上面的乘法；
小/大块大小，次
底层物理结构，时代
行/列方向
这就是你要找的吗？上面有一组 Sybase ASE 的技术（不是温暖和模糊的）图表，一个 OLTP/DSS 严格面向行的引擎，如果你有兴趣，我可以得到。
.
你的意思是说，无论数据库类型如何，我们最终都会归结为页面。
是的。
如果是这种情况，那么如何进行数据库集群。让我们看一个以行方式存储数据的数据库。如果我正在为这种类型的数据库进行集群，那么表结构将如何准确地传送到不同的节点（如果我有多个节点）。这个表结构会链接到一个页面还是通过不同的机制。
你知道，在我回答这个问题之前，我必须承认你。以你这样的知识水平，能深入到那个关键点，得到那个洞见，真是太好了。 Shiva ki Jai！
是的，这是集群 DBMS 的关键设计问题，关键的限制问题，尤其是与集群相关的各种设计问题；如果供应商很好地处理了这个问题，则集群运行良好；如果没有，集群就是狗早餐。
IT 中的一切都受物理定律的约束。没有什么是免费的，功能的每一个功能都有成本、处理或存储。没有魔法，除了 MS 营销手册。
良好的集群数据库架构
我不知道所有的集群 DBMS；我非常了解 Sybase CE 和 Oracle RAC。 Sybase IQ 的工作知识。
Sybase CE 才一岁。但该架构非常出色，它很好地处理了这个关键问题。 SAN 上只有一个页面版本。所有节点都连接到 SAN。任何节点都可以读取或写入 Page。节点通过专用 LAN 连接（除了网络上其他所有设备使用的普通客户端-服务器 LAN）。节点协调锁以及一些节点间通信以实现负载平衡等。
.
归根结底，为了获得最大的并发性，即使使用 Sybase CE，您也需要对数据库进行逻辑分区，以便每个节点上的工作负载是分开的，正在访问不同的文件路径，或者共享数据库的单独物理区域。
Sybase IQ 已经 100% 面向列。这是他们的 DW 产品。它已经完成了完全负载平衡。它可以用作集群，但不能用于上述 CE 意义上的集群。我应该把它包含在
糟糕的集群数据库架构
集群 dbms 的狗早餐类型会做一些愚蠢的事情。列举几个：
将页面存储在每个节点上[大量重复]，但随后必须在集群中移动更新的页面
使用 MVCC 来解决这个问题（但 MVCC 的开销要大得多，实际上会减慢并发速度，因此它会自行解决问题）
集群不适合专用数据库服务器
基本上集群对于某些应用程序来说非常有用，但对于专用数据库服务器来说这是一个愚蠢的想法（一个事实在一个地方；共享资源一起管理；锁争用在一个地方管理时最有效，因为数据是在一个地方）。我永远不会为数据库服务器推荐集群。
与 SAN 问题相同。当然，很多人的 db 存储都位于 SAN 中，但为了获得最高速度以及与连接到 SAN 的其他服务器的负载问题隔离，没有什么能比得上本地磁盘。
与 VMWare 问题相同。当然，很多人都将db server建立为VMWare主机单元，但是为了最高速度，去掉VMWare的开销；为了与机箱中其他主机单元的负载问题隔离，请将其从那里取出，放到专用的硬盒上。
数据库供应商为什么要为集群烦恼
哦，它是有价值的，但不是现在，而是未来。 AFAIC，随着时间的推移，Sybase 体系结构将占主导地位，而所有其他体系结构都将被淘汰。每个供应商都会照常复制。
Sybase CE 的真正强大之处在于：
真正的 100% 正常运行时间（能够将节点添加到集群并关闭旧节点进行维护）和
完全动态负载平衡（假设现有节点是 4 x 四核；添加一个临时 4 x 四核节点；取下旧节点；插入 2 x 四核；启动它；取下临时节点向下）然后在 60 秒内，没有手指在任何键盘上，整个野兽重新平衡。
一家可以错开几台单节点服务器的夜间数据库维护计划的商店，可以节省相当多的钱；他们只有几台额外的机器用于切换。
数据仓库略有不同。它们大多是只读的。因此，将它托管在集群上是没有问题的（许多读取器节点，只有一个写入器节点，没有争用，没有人关心页面正在被读取时被写入）。 Sybase IQ 就是这样的产品。
面向列的 Sybase CE
Sybase IQ 已经是面向列的，可以部署在集群中，但不是上述 CE 意义上的集群。列映射到页面。我应该将它包含在上面的 Good Clustered Db Architecture 中，现在更正了。
我不知道是否值得将面向列和面向行的混合体结合起来。
但该问题的完整答案是，使用纯 Db（而非 DW），例如 Sybase ASE 或 ASE/CE，并实现真正的第六范式数据库。这就是最终的归一化，即不可约的 NF，具有几个实质性优势，包括速度和易于旋转。它在页面上提供面向列的存储。由于 SQL 不完全支持 6NF，您需要提供视图以从（存储的）6NF 结构中提供 5NF 行。我为目录编写了一个扩展，以便生成供开发人员使用的 SQL 代码。
【讨论】：
您的问题的一个问题是，长期存在的数据库术语“面向列”已被 NOSQL 社区挪用（有些人可能会说“被劫持”！）来描述与最初含义完全不同的东西。 “面向列”的两种含义仍然适用，但它们指的是非常不同的 DBMS 产品。因此，澄清您在谈论的内容通常很有帮助。在这种情况下，它是该术语的 NOSQL 含义。
在面向列的数据库的原始含义中，您的问题的答案是检索信息的方式没有区别。列存储不是一种不同的数据模型，它只是内部存储中的一种不同类型的表示。
然而，在 NOSQL 社区中，术语列存储指的是不同类型的数据模型。
这里有很好的解释：
http://dbmsmusings.blogspot.com/2010/03/distinguishing-two-major-types-of_29.html
【讨论】：
面向行的数据库，又名“传统 RDBMS”（例如 MySQL、Oracle、DB2）使用事务二级索引更新，在大多数情况下使用 B-Tree 类结构作为二级索引
面向列的数据库，又名“NoSQL”（例如 Google Big Table、HBase、Cassandra）对主键索引（不是 B-Tree）使用简化的结构
面向列的数据库不支持“传统”事务二级索引。维护“倒排索引”是用户的责任。
Cassandra 支持类似 B-Tree 的行索引：一行中的每个单元格都有一个标题，并且单元格按标题进行物理排序。
另一个（可能是非常重要的）区别：对于 Oracle 中的无数条记录，您需要为主键维护 B-Tree，它的大小也将类似于无数条； “按主键查找”性能不好。
另一方面，您可以在 Cassandra 或 HBase 中拥有“宽行”，并将相似的“单元格”合并为单个宽行； “主键索引”的大小变小了数百万倍，并且“按主键查找”超级快（而且它不是B-Tree；它是聚集搜索）
【讨论】：