‘大数据’ SQL 第二部分¶

https://blueprints.launchpad.net/ceilometer/+spec/bigger-data-sql

在 SQL 重构的第一步中，我们对数据进行了反规范化处理，以便尽可能接近原始形式地捕获和存储数据。这消除了所有由弃用的数据设计需求引起的所有开销。本蓝图进一步重构数据模型，以更接近 API 模型的方式组织数据。

问题描述¶

目前，计量数据模型完全反规范化。我们存储样本（Samples），它们是原始数据点，以及计量器（Meters），它们是所述数据点的定义。这种优化可以实现良好的写入性能，但由于 Sample 表的大小，可能会导致读取性能问题，尤其是在获取计量器和资源时。具体来说，连接可能会导致性能问题。

当前模式如下

* meter - meter definition
    * id: meter id
    * name: meter name
    * type: meter type
    * unit: meter unit
* sample - the raw incoming data
    * id: sample id
    * meter_id: meter id (->meter.id)
    * user_id: user uuid
    * project_id: project uuid
    * resource_id: resource uuid
    * source_id: source id
    * resource_metadata: metadata dictionaries
    * volume: sample volume
    * timestamp: datetime
    * message_signature: message signature
    * message_id: message uuid

提议的变更¶

提议的更改是重新实现一个规范化的模型，该模型针对当前的 API 要求进行了定制。这意味着将资源特定数据分组到资源表中，将计量器特定数据分组到计量器表中。

提议的模式如下

* resource - resource data
    * internal_id: resource id (to handle assumption resources may not be
                   unique ie. diff user/project/source/meta per resource)
    * resource_id: resource uuid
    * user_id: user uuid
    * project_id: project uuid
    * source_id: source id
    * resource_metadata: metadata dictionary
    * metadata_hash: hash of metadata to allow comparison
* meter - meter definition
    * id: meter id
    * name: meter name
    * type: meter type
    * unit: meter unit
* sample - the raw incoming data
    * id: sample id
    * meter_id: meter id (->meter.id)
    * resource_id: resource id(->resource.internal_id)
    * volume: sample volume
    * timestamp: datetime
    * message_signature: message signature
    * message_id: message uuid

替代方案¶

由于模式可以以多种方式定义，因此从这个意义上讲，有很多替代方案。

数据模型影响¶

API 模型将保持不变。 SQL 后端模型将更改为上述建议。

创建新的资源表
将适当的值从样本表移动到资源表

这些更改需要数据库迁移。

REST API 影响¶

我们需要调整现有的 API 模型以与新的后端模式进行交互，但从用户角度来看，不会有任何变化。

安全影响¶

无

Pipeline 影响¶

无

其他最终用户影响¶

没有，我们将继续为每个样本存储一个新的资源

性能/可扩展性影响¶

读取性能应该会提高，因为我们将不再拥有一个巨大的样本表，而是更小、更定制的资源表、计量器表和样本表。写入性能预计不会明显下降。

预计写入性能的任何下降都将被现有的 tempest 测试捕获。

将使用 Ilya 的性能工具来验证读取性能是否提高以及写入性能下降可以忽略不计。[1]

[1] https://github.com/ityaptin/ceilometer/blob/master/tools/sample-generator.py

其他部署影响¶

无

开发者影响¶

没有，只是一个新的模式需要学习

实现¶

负责人¶

主要负责人: chungg
其他贡献者: 无
持续维护者: chungg

工作项¶

迁移脚本，用于在计量器表和新的资源表中添加新属性
修改 impl_sqlalchemy get_meters、get_resource、record_metering_data、expirer 和任何其他受影响的方法以使用新的模式

未来生命周期¶

大多数贡献者在某种程度上了解 SQL 后端。社区将维护直到 v3 后端被逐步淘汰。

依赖项¶

无

测试¶

现有的测试用例应该涵盖更改
Tempest 测试用例应该涵盖性能下降
需要添加测试来处理数据过期

文档影响¶

无

参考资料¶

与 Mike Bayer 的讨论：https://etherpad.openstack.org/p/ceilometer-sqlalchemy-mike-bayer

‘大数据’ SQL 第二部分