事务型数据库针对运行生产系统(从网站到银行再到零售店)进行了优化。这些数据库擅长快速读取和写入单个数据行,同时保持数据完整性。
事务型数据库属于行存储,这意味着,数据以行(而非列)的形式存储在磁盘上。当您需要了解用户表中一个客户的所有相关数据时,行存储是不错的选择,因为您只能获取所需的数据。但是,当您尝试计算特定邮政编码中的客户数量时,行存储不是很好,因为您必须加载邮政编码列,还需要加载名称、地址和 user_id 列。
事务型数据库并非专为分析而构建,但实际上已成为分析环境,因为它们已作为生产数据库在使用。它们已有数十年历史,使用面很广并且易于使用。
如果您的组织没有预先存在的单独分析栈,则开始分析的最快方式之一是创建事务型数据库的副本。这样可确保分析查询不会意外妨碍关键业务生产查询,同时只需进行极少的额外设置。其缺点是这些数据库旨在用于处理事务而非分析。使用这些数据库进行分析是一个很好的切入点,但您可能会遇到局限性问题;与特定于分析的设置相比,您更早需要解决这些局限性问题。
事务型数据库非常适合:
确保数据完整性
事务型数据库采用与 ACID 兼容的架构,可确保写入数据库的操作成功或失败,从而在将数据写入数据库时保持高水平的数据完整性。因此,对于需要高数据完整性的业务事务,事务型数据库至关重要,典型的示例是银行业务,其中您希望整个事务(从一个账号取款并存入另一个账号)成功或失败。
延迟时间短
由于事务型数据库的设计是为了运行生产系统,因此非常适合必须在几毫秒内完成的操作。如果您正在对生产数据库的事务型副本执行分析,则该副本可能几乎与主数据库同步,即亚秒级延迟时间。
监控操作系统
使用事务型数据库中的数据来提供实时操作快照是事务型数据库的完美分析应用场景,因为副本带来的延迟时间很短。如果您要尝试监控支持工作负载或库存或其他操作系统,并且需要根据最新数据做出决策,则复制生产数据库可能是最佳选择。
ACID 是一组属性,描述了事务型数据库的架构设计方式以保持对数据库写入的完整性。以下是每个属性的定义:
原子性
即使事务的一部分失败,整个事务也会失败。这样,每个事务都必须 100% 成功才能成功提交到数据库。
一致性
系统要么将事务写入数据库(将数据库从一种有效状态更改为另一种状态),要么还原事务。
隔离
尚未完成的事务无法由其他事务处理或修改。
耐用性
事务写入数据库后,即使数据库发生故障,事务也会保留在数据库中。