数据库表设计的思路

[timzaak]

首先一个点，不同的数据库，是为了用其特定的索引和数据结构。选择时，这为最先思考的，其次是特定场景对性能、事务、稳定、横向扩展的需求。目前由于 Postgres 支持索引和数据结构的多样性，是我的第一优先级选择。Redis 里面的数据结构也支持广泛，但是我自身运营能力不太足，对其持久化没有太大的把握，所以只先用来做缓存了。

在对业务进行抽象时，主要是遵循DDD领域驱动设计。这本书很久以前看的，相关概念有些忘了，我尝试在这复述一下自己的理解，估计是有问题的。 数据按用途讲，总共分为五种：

• 当前状态，例如银行卡余额、可用现金
• 事件记录，例如账户转账流水
• 快照，例如某一时间节点，用户名称是怎样的
• 链接，将独立的数据源链接起来，例如朋友关系
• 快速索引，为了快速查询，而将上面四种进行有规则的聚合，可重建

在使用 Postgres 的时候，相比于传统的 table 使用方式， 我更倾向于将非索引的数据部分用 bson 存储，然后在代码层面进行序列化约束，尽量排除脏数据和数据歧义。另外对外键无感，目前没想到哪些场景必用外键。

[timzaak]

在对业务逻辑抽象的时候，最近的一次项目，是以流水为核心，然后在流水上分离出具体的信息。最后由于流的复杂，我就又引入的图数据库。

业务动态和静态的区分，目前感觉还不太熟练，尤其是对业务辨析度不够的时候。各种模型重构就要来了。 以前觉得应该以描述动态的过程为核心，也就是流水，现在则是应该先塑造静态的物体为核心，然后再考虑关联关系。

原因是：对于用户来讲，绝大部分的需求是静态状态的展示，只有小部分需求涉及链路，而且即使涉及，也多是将链路每个节点的静态信息拿出来展示。此时的链路更像一个额外的索引功能。

[timzaak]

88

随着数据的增长，除了考虑其特定的索引和数据结构，还要考虑资源利用问题， 资源利用主要是指内存和CPU核： 内存代表着数据库表缓存+ join 性能（不推荐用Join），CPU核指并行查找计算能力。 数据库在云厂商那里收费巨贵，PG 也没找到有支持Mutilple Master 的云服务商，所以会考虑 Ignite 等增强原有数据库内存、CPU资源或是 TiDB、ElasticSearch 可横向拓展的方案。

ElasticSearch 真的是独领风骚，在大规模全文索引的市场上除了有些跟不上的 Solr，完全没有开源的替代品可言。耐心找了不少，但都是单节点、小数据规模。

[timzaak]

34 Ignite 分布式内存计算 关于数据计算的考量

[timzaak]

时序数据库，是在特定场景下的产物，该场景具体描述如下： 历史数据可被聚合存储（压缩），例如一个小时内的某个设备 1000 条数据可被聚合成1条。 写性能要求贼高， 读性能要求反而没那么高。 对近期数据读需求高，远期数据读需求低，甚至无。 数据统计为主，面向报表。

[timzaak]

目前预判 100G 级别 PostgreSQL 完全OK，为了倒索引加个 ES。

100G 以上需要大量计算的可在 PG 以上 添加一层 Ignite， 用 PG 做 Ignite 的持久层，若是对写效率有很高的要求，就直接用 本地文件持久化 + Partition 来做容灾。 若对写效率没那么高的要求，就 PG 读写分离、Multiple Master 来处理即可。

PB 以上的 HDFS/S3 + Flink 等，看具体任务需求在 HDFS/S3 上补一层 data cache（Ignite）或 KV/Column DB/时序DB （HBase）。若只是数据查询+事务， 可找分布式 KV/SQL 的方案，例如 TiDB。

至于性能，除非最底层的 CPU 运算 转换成 GPU 或其它运算，那么性能就是买买买+调调调，买到单节点差不多最顶端，调到所有关于性能的参数都整过一遍，至此，再考虑多节点架构。

[timzaak]

现在数据库发展的方向：存算分离。细分下，存储分离的实现方式有两种方式：

1. 构建分布式存储引擎，例如：TiDB
2. 构建分布式文件系统，例如：PolarDB for PostgreSQL

第二种方法会是最终方案，但目前来讲，Ceph 等分布式文件系统还存在很多问题Bug。分布式存储引擎的方案比较成熟，但由于其架构限制，性能上限也低。

存算分离的架构特别适合云厂商去调配资源，对数据库资源进行超卖（要解决计算资源多租户调度问题）。虽然延迟可能会高一些，但对于 Restful API 之类的应用可忽略不计。

与之对比，虽然 Apache Ignite 这款产品我觉得没问题，但 Focus 在内存计算，有些跟不上数据大爆炸(缓存命中问题)，应用场景可能会越来越窄。

[timzaak]

111