PropScale与多维数据索引结构的技术解析

### PropScale与多维数据索引结构的技术解析 #### 1. PropScale的更新传播与应用优势 PropScale是一种用于联合可扩展存储的更新传播器，它在数据库存储和数据处理方面具有显著优势。 ##### 1.1 更新操作处理 对于 `Find(U, Π)` 中的每个 `(valueΠ.id, p)` 元组，处理方式如下： - 如果强路径 `p` 包含3个顶点，则根据更新值直接对驱动程序执行请求的添加、删除或修改操作。 - 否则，根据选择类型更新现有值。 ##### 1.2 应用场景及优势 ###### 1.2.1 引入的开销测试 以书店数据库为例，包含书籍、用户、书籍销售和书籍评论等关系。在基准测试中，假设存在100万本书籍和用户、500万条销售记录和1000万条评论。测试环境为单台英特尔i5 - 2400机器，CPU为3.10GHz，内存4GB。 - 首次测试将整个书籍关系仅存储在PostgreSQL中，添加新元组并测试传播器Web服务层引入的开销。结果显示，传播器的开销似乎与工作负载无关，且保持在可接受水平。 - 接着评估多个存储中实际更新操作之间的偏移。当对多个存储进行更改时，PropScale首先更新指定的投影（即关系的主投影，在模式中预定义）。以书籍数据分布在不同数据库（PostgreSQL存储财务数据、Mongo存储书籍信息、Redis存储简单书籍统计信息）为例，将PostgreSQL中的投影定义为主投影，先对其进行更改，然后测量在Mongo和Redis中应用更改之前的偏移。结果表明，随着工作负载增加，测试的偏移并未增长，且系统每秒能执行超过12000次操作，比仅使用PostgreSQL数据库时更多。 以下是开销测试的流程说明： 1. 准备测试环境，包括数据库和相关机器。 2. 将书籍关系存储在PostgreSQL中。 3. 添加新元组到关系中。 4. 记录客户端请求传播器的总时间和PostgreSQL消耗的时间。 5. 分析结果，评估传播器的开销。 ```mermaid graph LR A[准备测试环境] --> B[存储书籍关系到PostgreSQL] B --> C[添加新元组] C --> D[记录时间] D --> E[分析结果] ``` ###### 1.2.2 云集成应用 近年来，云数据库成为热门话题，一些公司将数据库外包给外部服务，如亚马逊SimpleDB等。在书店场景中，将书籍评论存储在云端可避免过多考虑可扩展性问题，且服务层协议明确。但公司可能不愿将财务或客户数据存储在公司系统之外，因此将关键业务数据保留在本地存储，将不太关键的数据外包给云数据库供应商。PropScale可以解决存储集成问题，它跟踪不同位置存储的数据，确保存储构成一致的存储系统。 具体操作步骤如下： 1. 确定关键业务数据和非关键数据。 2. 将关键业务数据存储在本地存储。 3. 将非关键数据外包给云数据库供应商。 4. 使用PropScale跟踪和管理数据。 ```mermaid graph LR A[确定数据类型] --> B[存储关键数据到本地] B --> C[外包非关键数据到云端] C --> D[使用PropScale管理数据] ``` ###### 1.2.3 自定义统计 PropScale的真正优势在于能够定义频繁访问的统计信息，并将其存储在具有快速数据访问能力的存储中，如键值存储。以简单社区论坛为例，系统包含论坛、线程和帖子三个关系，假设存在100个论坛、10000个线程，每个线程有100个帖子，共1000万个帖子。 - 测试常见的数据访问模式，包括添加单个帖子、检索论坛列表、检索论坛内的线程列表和检索线程内的帖子列表。在检索论坛和线程列表时，需要读取线程/论坛中最后一个帖子的信息、作者和添加日期，以及包含的线程/帖子数量。 - 对比两种架构选择： - 简单架构选择将数据以第三范式存储在MySQL中，无冗余列。添加或检索帖子的查询性能良好，但检索包含所有所需数据的线程速度明显低于可接受水平，单线程工作负载下吞吐量为每秒5次操作，检索线程的平均时间为376毫秒，添加和检索帖子分别需要4毫秒和49毫秒。 - 使用PropScale将冗余数据存储在Redis中，这种选择具有良好的可扩展性。测试结果显示，仅在MySQL中存储数据时，请