对象存储能存储结构化数据吗为什么不能存储，对象存储能存储结构化数据吗为什么

***：本文围绕对象存储能否存储结构化数据展开疑问探讨。对象存储主要以对象的形式管理数据，虽然其设计初衷更多是面向非结构化数据，如图片、视频等，但在一定程度上通过一些手段也可存储结构化数据。不过它在处理结构化数据时存在局限性，例如缺乏对复杂关系型数据高效处理的特性等，但随着技术发展这种情况也在逐渐改变。

本文目录导读：

1. 对象存储概述
2. 结构化数据的特点
3. 对象存储存储结构化数据的可行性
4. 对象存储存储结构化数据的局限性

《对象存储与结构化数据：存储的可能性与限制剖析》

对象存储概述

对象存储是一种基于对象的存储架构，旨在以扁平的结构来存储和管理数据，在对象存储中，数据被封装为对象，每个对象包含数据本身、元数据（描述对象的属性，如创建时间、所有者、访问权限等）以及一个全局唯一的标识符（Object ID），这种架构与传统的文件存储（基于文件系统的树形结构）和块存储（主要用于为服务器提供裸磁盘级别的存储）有所不同。

（一）对象存储的优势

1、可扩展性

- 对象存储能够轻松地扩展到海量数据规模，云服务提供商的对象存储系统可以存储数十亿甚至数万亿个对象，这对于处理诸如大数据分析、物联网（IoT）数据存储等场景下产生的大量数据非常有利。

- 它可以通过简单地添加存储节点来增加存储容量，而不需要像传统存储系统那样进行复杂的文件系统扩展或块存储卷管理操作。

2、数据持久性和可用性

- 对象存储通常设计为具有高度的数据持久性，一些云对象存储服务声称提供99.999999999%的数据持久性，这意味着数据丢失的概率极低。

- 多副本存储和分布式架构确保了在个别存储节点出现故障时，数据仍然可以被访问，数据会被复制到多个地理位置不同的存储设施中，以防止因自然灾害或局部故障导致的数据不可用。

3、成本效益

- 对于大量的非结构化数据（如图片、视频、日志文件等）存储，对象存储的成本相对较低，云对象存储服务通常采用按使用量付费的模式，用户只需为实际存储的数据量和数据访问操作付费。

- 相比之下，传统的存储系统可能需要购买昂贵的硬件设备，并且在存储容量扩展时可能面临高额的升级成本。

结构化数据的特点

结构化数据是指具有明确的数据结构和格式的数据类型，通常以表格（如关系型数据库中的表）的形式存在。

（一）数据模型

1、关系型模型

- 在关系型数据库中，结构化数据遵循严格的关系模型，数据被组织成多个表，每个表包含若干列（表示不同的属性）和行（表示不同的记录），在一个企业的客户关系管理（CRM）系统中，可能有“客户表”包含客户的基本信息（如姓名、年龄、联系方式等），“订单表”包含订单的详细信息（如订单号、产品名称、数量、价格等），这些表之间通过特定的关系（如外键关系）相互关联。

- 关系型模型的优势在于能够通过结构化查询语言（SQL）进行高效的查询、数据完整性维护（通过约束条件，如主键约束、外键约束等）和事务处理（确保数据操作的原子性、一致性、隔离性和持久性）。

2、数据的一致性和完整性要求

- 结构化数据对一致性和完整性有严格要求，在一个银行的核心业务系统中，当进行转账操作时，必须保证账户余额的一致性，如果从一个账户转出一笔资金，同时必须准确无误地将这笔资金添加到另一个账户中，并且整个操作必须符合预先定义的业务规则，如账户余额不能为负数等。

- 这种一致性和完整性的维护是通过数据库管理系统（DBMS）的各种机制来实现的，包括并发控制（防止多个事务同时操作同一数据时产生冲突）和数据验证（确保输入的数据符合定义的格式和约束条件）。

对象存储存储结构化数据的可行性

（一）以对象形式存储结构化数据

1、将结构化数据封装为对象

- 在理论上，可以将结构化数据封装成对象存储在对象存储系统中，可以将一个关系型数据库中的表数据转换为JSON或XML格式，然后将其作为对象的数据部分，同时在元数据中添加关于该结构化数据的描述信息，如数据结构定义、表名、字段名称等。

- 以一个简单的员工信息表为例，原本在关系型数据库中的数据（包含员工ID、姓名、部门等字段）可以被序列化为JSON格式，如{"employee_id": 1,"name": "John","department": "Sales"}，然后将这个JSON字符串作为对象存储在对象存储中，元数据中可以注明这是员工信息表的数据。

2、数据查询和检索的挑战与解决方案

挑战

- 当将结构化数据存储在对象存储中时，传统的关系型数据库查询方式（如SQL查询）不再直接适用，对象存储没有像关系型数据库那样内置的索引结构和查询优化器来高效地处理复杂的关系型查询，如果要查询所有在“Sales”部门的员工，在关系型数据库中可以通过简单的SQL语句（如SELECT * FROM employees WHERE department = 'Sales'）来实现，但在对象存储中，需要遍历所有的员工对象，解析对象中的数据，然后筛选出符合条件的对象，这在数据量较大时效率极低。

解决方案

- 一种解决方案是构建外部索引系统，可以使用搜索引擎技术（如Elasticsearch）来为存储在对象存储中的结构化数据构建索引，将对象存储中的数据抽取出来，按照一定的规则构建索引，然后通过这个外部索引系统进行查询，对于员工信息对象，可以将员工的部门信息作为索引项，当查询在“Sales”部门的员工时，首先在Elasticsearch索引中查找部门为“Sales”的员工的Object ID，然后根据这些Object ID从对象存储中获取对应的员工对象。

- 另一种方法是采用对象存储系统自身提供的元数据查询功能，虽然这种查询功能相对简单，但可以通过合理设计元数据结构来进行一些基本的查询操作，在元数据中设置专门的标签字段，用于标记数据的类别或属性，然后通过查询元数据中的标签来筛选对象。

（二）对象存储对结构化数据操作的支持

1、写入操作

- 在写入结构化数据到对象存储时，除了将数据封装为对象外，还需要考虑数据的完整性保护，可以采用数据校验和（Checksum）技术，在写入对象时计算数据的校验和，并将其存储在元数据中，当数据被读取时，可以再次计算校验和并与元数据中的校验和进行比较，以确保数据在存储过程中没有被损坏。

- 为了提高写入效率，可以采用批量写入的方式，将多个结构化数据对象组成一个批次，一次性写入对象存储系统，减少网络传输和存储系统的交互次数。

2、更新操作

- 更新存储在对象存储中的结构化数据相对复杂，由于对象存储的不可变性原则（对象一旦写入，通常不能直接修改，而是通过创建新版本来实现更新），对于结构化数据的更新需要特殊处理。

- 一种方法是读取原始对象，修改其中的结构化数据内容，然后将修改后的对象重新写入对象存储，并更新相关的索引（如果有外部索引系统），如果要更新员工的部门信息，需要先获取员工对象，修改JSON数据中的部门字段，然后将新的对象写回对象存储，并确保外部索引（如Elasticsearch中的索引）也得到更新。

3、删除操作

- 删除操作在对象存储中相对简单，可以根据对象的唯一标识符（Object ID）直接删除对象，对于结构化数据存储，需要考虑数据的关联性，如果一个结构化数据对象与其他对象存在关系（如在关系型数据模拟存储中，一个订单对象与客户对象相关联），在删除订单对象时，可能需要根据业务规则采取相应的措施，如在元数据中标记订单对象为已删除状态，而不是直接物理删除，以避免破坏数据的关联性。

对象存储存储结构化数据的局限性

（一）缺乏原生的关系型操作支持

1、事务处理能力

- 对象存储系统缺乏像关系型数据库那样原生的事务处理能力，在关系型数据库中，事务可以确保一系列操作（如多个SQL语句组成的操作序列）的原子性、一致性、隔离性和持久性（ACID特性），在一个电子商务系统中，当用户下单购买商品时，涉及到库存减少、订单生成、支付处理等多个操作，关系型数据库可以通过事务机制确保这些操作要么全部成功，要么全部失败。

- 而在对象存储中，要实现类似的事务处理功能非常困难，虽然可以通过应用层的逻辑来模拟事务操作，但这增加了开发的复杂性和出错的风险，如果要在对象存储中模拟上述电子商务系统的下单操作，需要在应用程序中编写大量的代码来确保各个操作的一致性，并且在出现故障时进行回滚操作，这比在关系型数据库中使用事务机制要复杂得多。

2、复杂关系型查询的效率

- 如前面所述，对象存储在处理复杂的关系型查询时效率低下，关系型数据库经过多年的优化，其查询优化器能够根据查询语句的结构和数据分布情况，选择最优的查询执行计划，对于一个涉及多个表连接（JOIN）的查询，关系型数据库可以通过索引优化、数据缓存等技术快速地返回查询结果。

- 在对象存储中，由于没有内置的关系型查询处理机制，对于类似的多对象关联查询（模拟关系型数据库中的表连接操作），需要在应用层进行大量的数据处理工作，这在数据量较大和查询复杂度较高时会导致性能严重下降。

（二）数据一致性和完整性维护的困难

1、并发访问控制

- 在多用户并发访问结构化数据时，对象存储难以提供像关系型数据库那样精细的并发访问控制，关系型数据库通过锁机制（如行级锁、表级锁等）来控制多个事务对同一数据的并发访问，当两个用户同时尝试修改同一个客户的信息时，关系型数据库可以通过行级锁确保只有一个用户能够成功修改，另一个用户需要等待锁释放后才能进行操作。

- 在对象存储中，虽然可以通过对象级别的锁定来实现一定程度的并发控制，但这种控制相对粗糙，并且在处理复杂的结构化数据操作（如多个对象之间存在关联关系的并发操作）时，容易导致数据不一致性，如果两个用户同时对关联的订单对象和客户对象进行操作，对象存储很难保证数据的一致性。

2、数据验证和约束执行

- 关系型数据库可以在数据库层面定义各种约束条件（如数据类型约束、唯一性约束等）来确保数据的完整性，在一个用户注册系统中，数据库可以定义用户名字段为唯一约束，当用户输入重复的用户名时，数据库会直接拒绝插入操作。

- 在对象存储中，数据验证和约束执行主要依赖于应用层，虽然可以在将结构化数据封装为对象时进行一定的验证，但这种验证缺乏数据库层面的强制力，如果应用程序存在漏洞或者没有正确执行验证逻辑，可能会导致不符合要求的数据被存储到对象存储中。

对象存储在一定程度上可以存储结构化数据，但与专门的关系型数据库相比，存在诸多局限性，特别是在处理复杂的关系型操作、事务处理、数据一致性和完整性维护等方面，随着技术的发展，对象存储和结构化数据存储之间的融合也在不断探索和推进，例如一些新型的数据库系统开始借鉴对象存储的可扩展性和成本效益优势，而对象存储也在不断增强对结构化数据操作的支持能力。