和传统数据库进行比较

Hive在很多方面和传统数据库类似(例如支持SQL接口），但是它底层对HDFS和 MapReduce的依赖意味着它的体系结构有别于传统数据库，而这些区别又影响着Hive所支持的特性，进而影响着Hive的使用。

读时模式VS.写时模式

在传统数据库里，表的模式是在数据加载时强制确定的。如果在加载时发现数据不 符合模式，则拒绝加载数据。因为数据是在写入数据库时对照模式进行检査，因此 这一设计有时被称为“写时模式”（schemaonwrite)。

在另一方面，Hive对数据的验证并不在加载数据时进行，而在查询时进行。这称 为“读时模式”（schema on read)。

用户需要在这两种方法之间进行权衡。读时模式可以使数据加载非常迅速。这是因 为它不需要读取数据，然后进行“解析”（parse),再进行序列化以数据库内部 格式存入磁盘。此时，数据加载操作仅仅是文件复制或移动。这一方法也更为 灵活：想想看，针对不同的分析任务，同一个数据有两个模式时。

写时模式有利于提升查询性能。因为数据库可以对列进行索引，并对数据进行压 缩。但是作为权衡，此时加载数据会花更多时间。此外，在很多情况下，在加载 时，模式是未知的。因为査询尚未确定，因此也不能决定使用何种索引。这些情况 正是出^发挥其长处的地方。

更新、事务和索引

更新、事务和索引都是传统数据库最重要的特性。但是，直到最近，Hive也还没 有考虑支持这些特性。因为Hive被设计为用MapReduce操作HDFS数据。在这 样的环境下，“全表扫描”(full-table scan)是常态操作，而表更新则是通过把数据 变换后放入新表实现的。对于在大规模数据集上运行的数据仓库应用，这一方式很 见效。

但是，在有些负载中，我们仍然需要更新(至少是追加)，或需要利用索引来显著提 升性能。对于事务问题，Hive并没有对表的并发访问定义清楚的语义。因此，应 用程序需要自己实现应用层的并发或加锁机制。Hive的开发团队正在积极工作， 以增强对这些特性的支持。

改变也来自另一个方向：HBase集成。HBase（第13章)和HDFS相比，有着不同的 存储特性，如行更新和列索引。因此，我们可以希望Hive在后续的发布版本里利 用这些HBase的特性。HBase和Hive的集成仍处于早期的开发阶段。