真实的业务场景--数据库设计探讨

white182517

可能我对业务的描述还不够清楚，在对业务的理解有出入的情况下，讨论可能会偏离轨道。

有兴趣的朋友可以参考如下一个网站，这和我们正在做的产品，是要解决同样的问题，在这个基础上考虑可能会更有针对性。

http://www.mochabsm.com/index.php?option=com_content&view=article&id=302&Itemid=288

white182517

原帖由 kissmoon 于 2010-8-24 12:03 发表
如果业务是需要时记录，不需要时不记录，
还可以把业务表分成两个，一个时当前指标，一个是历史指标

所有的指标数据就是客户关心的数据，既有需要实时关注的，也有需要事后做统计的。所以我们同时有当前表，以及小时表，天表，周表，月表。。。。。通过定时任务做压缩，以支持统计。


我们现在的主要设计思路基于如下目标：
1.能够在添加新的设备，新的监控指标时，对系统的改动最小，甚至不需要开发人员的介入。

鉴于此，一个指标一张表，维护和实施的代价都太大了。


我们目前的作法是这样的：
1.建立了一个通用的模型，描述我们需要监控的设备，指标，这是通过配置文件实现的
2.指标数据统一存储在键值表中，包含的字段类似如下：device_id,indiator_id,key,value。
3.当增加新的设备时，只需要在配置库文件中添加相应的信息，解析，存储，包括前台展现的逻辑都是一样的，因为都来自于一张表。
这样做虽然有一定的扩展性，对现场实施有很好的帮助，但是最显著的问题是查询的速度是非常慢的，这是键值表固有的特性:
# Drawback no. 1: No real use of database data types
# Drawback no. 2: Awkward use of database constraints
# Drawback no. 3: Problematic use of AND operator when relating to more than one attribute in the query criteria


楼上有建议，用键值表存数据，基于此再建数据抽取，类似数据挖掘的作法，虽然可以解决性能方面的问题，但是遇到的问题正是我们上述能提供的。
1.新增设备和指标时，必须建相应的表，实现相应的存储逻辑，展示逻辑，这在产品实施和推广时成本会非常高，开发量也会很大。


实际上，应该有很多业务类似的基于时序的数据面临同样的问题，这也是为什么现在基于KEY_VALUE数据库开始引人关注的原因吧。


不知道上述解释是否让大家更清楚我们面临的问题？

lodge

NEC 有个著名的监控系统叫JP1, 似乎可以借鉴一哈.

kissmoon

原帖由 white182517 于 2010-8-25 13:27 发表


我们目前的作法是这样的：
1.建立了一个通用的模型，描述我们需要监控的设备，指标，这是通过配置文件实现的
2.指标数据统一存储在键值表中，包含的字段类似如下：device_id,indiator_id,key,value。
3.当增加新的设备时，只需要在配置库文件中添加相应的信息，解析，存储，包括前台展现的逻辑都是一样的，因为都来自于一张表。

我的思路是

每个设备建立一个键值表，包含的字段类似如下：indiator_id,key,value

有一个相当于“配置库文件”的 设备配置表，添加相应的设备信息如设备ID，设备对应的 键值表 的表名，
存储时，通过设备ID从  设备配置表 获取 其指标表名，把数据写入，查询时，也是一样
因为存储、分析或是查询都是对某个设备的，所通过设备ID来查设备配置表取得其对应的表名是可取的。
如此 解析，存储，包括前台展现的逻辑都是一样的，只是表名是一个变量。

kissmoon

在新增一个设备时，就新增一个 键值表 这个表名可以随意，只要不重复，即可，在系统中用的都是 变量，根据变量来访问相应的表名，

监控软件的实现应该也没有问题，在监控时，总需要区分这个数据是来源于什么设备的 即可以取到 设备ID

lewter

刚刚到ITpub论坛   蛮好的顶一下