云原生项目正确的数据库选择
项目痛点
本项目为和AWS Proserve 合作自研云原生开发的一期项目：网点价的自动计算，项目痛点：网点价受产品的多种参数影响：包含但不限于具体出轴类型、型号规格、传动比、安装形式、装配形式、电机类型、强度、速比、功率、品牌、零部件材质、运输成本距离等等，业务部门会随着新产品的落地，搭配不同的价格政策且随着市场的各项成本波动，周期性的调整产品的整体价格；
亚马逊AWS海外区域账户免费套餐_免费云服务-AWS云服务
数据库选型
1.不同的选择：从团队角度出发，作为一个甲方内部的团队我们更熟悉直接部署在服务器上的传统关系型数据库SQL SEVER，选择SQL SEVER 我们的数据库工程师无疑更得心应手，无论是性能上的优化，备份的设置都会更顺畅；出于成本上的考虑，考虑到这个项目上线后的使用频率和容量，我们必须选择做出取舍，我们更倾向于“以战代练”，毕竟我们邀请了 AWS Proserve 团队的数据库专家James老师，我们为什么不选择一个最适合这个项目，能满足我们自拓展字段需求的数据库呢 ；
2.运维及开发上的考虑：因项目痛点,PO明确指出：网点价参数是不断变化的，这就带来了第一个技术穿刺点：我们是选择传统关系型数据库SQL SERVER / ORACLE 等等，还是选择no sql等数据库都是可选范围之内；选择SQL SERVER 开发人员和数据库管理人员就要直面网点价参数是不断变化带来的字段增加，出于这一点DynamoDB 成为了我们做技术穿刺的首选；
3.技术上：Amazon DynamoDB是一个完全托管的NoSQL数据库服务，可以提供快速的、可预期的性能，并且可以实现无缝扩展。由于DynamoDB并可以根据实际需求对表进行扩展和收缩，这个过程既不需要停止对外服务，也不会降低服务性能；
4.成本上：按需容量模式的定价策略，无论从写入读写频次和存储空间上的预估结合我司的使用场景，前台大量的销售、财务、销售内勤的频繁调用，按需容量模式的定价策略让我们不会产生额外的成本上的浪费，而且这种模式也能直接通过内部审计的采购选型，相比于去购买云上SQL SERVER 的lisence，这无疑节省了巨额的预期成本；
DynamoDB 架构介绍
三个核心概念
Table（表），Item（项目/记录/行），Attribute（属性/字段/列），Table是数据的集合，包含零个或者多个Item，Item是一组属性，包含一个或者多个Attribute。一个Item必须通过主键和其他Item区分开来，主键在创建表的时候需要指定，其他非主键的Attribute无须提前指定。
举例：见下图，表名：People，有3个Item：
第1个Item有4个Attribute，分别是PersonID、LastName、FirstName、Phone。
第2个Item有4个Attribute，分别是PersonID、LastName、FirstName、Address。
第3个Item有5个Attribute，分别是PersonID、LastName、FirstName、Address、FavoriteColor。
以上Attribute中，PersonID、LastName、FirstName、FavoriteColor都是单值，Address是嵌套字段，里面分别还有4个字段，分别是Street、City、State、ZIPCode，DynamoDB 支持最高 32 级深度的嵌套属性，层数不要太多。
在这个People，PersonID为主键，通过此Attribute即可区分不同的Item。
在下面的Music中，Artist和SongTitle两个字段构成主键，是一个复合主键，用这两个字段区分不同的Item，其中Artist叫分区键，SongTitle是排序键。
1）只有一个属性的主键
2）包含2个属性的主键，第一个是分区键，第二个是排序键
二级索引
所谓“二级”，是相对于上面提到的主键而言的，通过二级索引，可以加快以其他属性（非主键属性）为条件的查询速度。包括两种二级索引，分别是：
- 全局二级索引 – 一种带有可能与表中不同的分区键和排序键的索引，不支持强一致性读取。
- 本地二级索引 – 分区键与表中的相同但排序键与表中的不同的索引。
DynamoDB 中的每个表具有 20 个全局二级索引（默认配额）和 5 个本地二级索引的配额。
下图显示了示例 Music 表，该表包含一个名为 GenreAlbumTitle 的新索引。在索引中，Genre 是分区键，AlbumTitle 是排序键。
- 每个索引属于一个表（称为索引的基表）。在上述示例中，Music 是 GenreAlbumTitle 索引的基表。
- DynamoDB 将自动维护索引。当您添加、更新或删除基表中的某个项目时，DynamoDB 会添加、更新或删除属于该表的任何索引中的对应项目。
- 当您创建索引时，可指定哪些属性将从基表复制或投影 到索引。DynamoDB 至少会将键属性从基表投影到索引中。对于 GenreAlbumTitle 也是如此，只不过此时只有 Music 表中的键属性会投影到索引中。
1）下面是创建本地二级索引，若将checkbox “以本地二级索引的形式创建”去掉，则是创建的全局二级索引。
2）下面是创建全局二级索引
读取一致性
当应用程序向 DynamoDB 表写入数据并收到 HTTP 200 响应 (OK) 时，AWS DynamoDB保证该写入已发生并且持久。该数据最终将在所有存储位置中保持一致，通常只需一秒或更短时间。
DynamoDB 支持最终一致性 和强一致性 读取：
- 最终一致性，当从 DynamoDB 表中读取数据时，响应反映的可能不是刚刚完成的写入操作的结果。响应可能包含某些陈旧数据。默认采用最终一致性读取，读取操作（例如 GetItem、 Query和 Scan）提供 ConsistentRead 参数，设置为true则采用强一致性读取。
- 强一致性读取，当请求强一致性读取时，DynamoDB 会返回具有最新数据的响应，从而反映来自所有已成功的之前写入操作的更新。
读/写容量模式
- 按需模式，按需 Amazon DynamoDB 是一个灵活的结算选项，可以每秒处理数千个请求而不需要进行容量规划。按需 DynamoDB 针对读写请求提供按需支付定价，以便您只需为您使用的资源付费。
- 预置模式，如果您选择预置模式，则指定您的应用程序需要的每秒读取和写入次数。您可以使用 Auto Scaling 根据流量变化自动调整表的预置容量。这可帮助您控制您对 DynamoDB 的使用，使之保持或低于定义的请求速率，以便获得成本可预测性。
读写容量单位的举例
假设您创建一个具有 6 个读取容量单位和 6 个写入容量单位的预置表。使用这些设置，您的应用程序可以执行以下操作：
- 执行高达每秒 24KB 的强一致性读取（4 KB × 6 个读取容量单位）。
- 执行高达每秒 48KB 的最终一致性读取（读取吞吐量的两倍）。
- 执行高达每秒 12 KB 的事务读取请求。
- 每秒写入高达 6KB（1 KB × 6 个写入容量单位）。
- 执行高达每秒 3KB 的事务写入请求。
使用场景
当至少需要以下一项时，DynamoDB 是最佳用例：
- 通过key查询数据，或者主键和排序键一起查询（如customer_id和order_date）。
- 希望数据轻松与其他 aws 服务集成，例如 Lambda 和 RedShift
- 每秒需要数百万次读取，可以添加 DAX 来缓存您的数据。
- 需要从联合用户访问数据库，可以按字段级别微调用户访问。
另一方面，如果以下任一情况属实，则不应使用DynamoDB：
- 需要高级查询和聚合。例如，不能使用连接、子查询、排序、批量选择、分组依据（平均、计数……等）、有子句、更改选择中的属性名称……
- 并不完全了解它的分区是如何工作的。Dynamo db 以数据库即服务的形式销售，无需担心其底层机制。但是你可以很容易地设计出简单地导致性能严重下降的索引策略。https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.html
- 需要在 1 条记录中存储超过 400 KB 的数据。检查其他DynamoDB 限制
优缺点
优点：
1. 宽松一致性和强一致性之间的权衡
这里的游戏规则是不需要在应用程序中对值的复制进行硬编码。在做出选择之后，一切都会正常运行。读写单位可根据实际应用使用情况随时调整。市场上没有任何东西可以与此相媲美。
2. 分析
将应用程序扩展到数据库并没有想象中那么容易。在一个完美的世界中，只需将一个 javascript 函数发送到数据库并让它在准备好时产生一个答案。迄今为止，每个 nosql 数据库在集成分析方面都确实下降了。在运行 map-reduce 作业时，Mongodb 有很大的限制。另一方面，Riak 将其 map-reduce 功能用于查询而不是生成新数据。我认为这很有趣，但不适合很多用例。
与 Elastic Map Reduce 的集成消除了分析存储数据的复杂性。只需几个命令即可开始执行 map reduce 作业，而无需 Hadoop 的凌乱“适配器”。
3.性能和管理
数据库基础设施性能和管理的整个复杂性在dynamoDB中消失了。在云中调整分布式数据库的噩梦已成为过去。我应该选择 EC2 临时存储还是 EBS？如果是 EBS，希望实例的性能可以接受并且已经正确地对磁盘进行了 RAID。还必须在主机出现故障时对其进行管理和恢复。在许多情况下，这不是一个可以轻松自动化的过程。一旦所有这些都完成了，调整过程就可以开始了。在寻找单个值时，临时磁盘和 EBS 磁盘都不能提供低延迟性能。在随机读取和更新方面，SSD 是真正的规则。这些都不意味着云托管数据库不可行，但DynamoDB易用性显然更胜一筹， DynamoDB比简单的无模式宽松一致性存储更好。该产品非常接近于实现 NoSQL 的承诺：易于使用结构化存储，无需管理 SQL 服务器的复杂性以及横向扩展的可靠性和性能优势。
缺点：
1.如果您真的需要强一致性和事务，那么您可能已经在使用 SQL 数据库，DynamoDB 是一个 NoSQL 数据库。这意味着您不能在 dynamoDB 上进行连接或复杂查询。也没有 ACID，因为它不是 RDBMS；
2.不能将大对象 (BLOBS) 写入 dynamo DB。您绝对可以将 BLOBS 的元数据存储在 dynamoDB 中，但您可以将实际对象存储在 S3 中。从 S3 调优中检索是为了获得更好的性能而需要考虑的另一件事，例如使用字典顺序、使用随机性和 GET 的并行化
-放入 Dynamo DB 表中的每个属性也有 400Kb 对象大小的限制；
安全检查
1.本地环境是通过aws_access_key_id,aws_secret_access_key来访问dynamodb的, 为了安全考虑，改成IAMrole和eks服务账号关联的方式
2.无RDS，dynamoDB暂未发现security issue
项目架构样例
基础架构：
- 生产环境EKS： master+2 workers(m5.xlarge, 4c16G)
- 开发环境EKS： master+2 workers(m5.large, 2c8G)
- UAT环境EKS： master+2 workers (m5.large, 2c8G)
CICD:
- CICD工具选择：
- 持续集成：jenkins on EKS
- 代码仓库：Codecommit
- 镜像仓库：ECR
- EKS： master+2 workers (m5.large, 2c8G)
数据库：
- Dynamodb
应用样例
SalePolicy
描述： 核心的销售政策表
分区键：salePolicyId (String)
排序键： modifyTime (String)
样例：
1{
2 "id": { "S": "1d6f1b67-5007-44fa-8025-43985cb8d393"},
3 "approveTime": { "S": "2021-04-23 14:03:14"},
4 "version": {"N": "13"},
5 "approvePersonCode": { "S": "2010038"},
6 "formula": { "S": "4.23测试-1-修改1-修改1-审核"},
7 "businessStatus": {"S": "APPROVED"},
8 "status": {"S": "INVALID" },
9 "priority": {"N": "30" },
10 "createTime": {"S": "2021-04-23 13:58:58"},
11 "name": {"S": "4.23测试-1-修改1-修改1-审核"},
12 "modifyPersonName": {"S": "于浩洋"},
13 "saleSeriesId": {"S": "1"},
14 "startTime": {"S": "2021-04-01 00:00:00"},
15 "modifyTime": {"S": "2021-04-23 14:05:15"},
16 "saleSeriesType": {"S": "STANDARD"},
17 "code": {"S": "4.23测试-1-修改1-修改1-审核"},
18 "approvePerson": {"S": "于浩洋"},
19 "endTime": { "S": "2021-05-31 00:00:00"},
20 "createPersonName": {"S": "于浩洋"},
21 "createPersonCode": {"S": "2010038"},
22 "modifyPersonCode": {"S": "2010038"},
23 "description": {"S": "4.23测试-1-修改1-修改1-审核"}
24}
索引信息：
总结
那么什么时候采用DynamoDB，什么时候采用关系型数据库呢？根据本次项目经验，DynamoDB好处如下：
- 对于海量数据，DynamoDB表现要好。由于DynamoDB是nosql，也就意味着没有传统数据库的诸多限制，在海量数据的方面无论是查询还是存储都比传统数据库要高。
- 数据库的schema方便调整。传统数据库的一个重大的问题就是调整表的结构，调整表结构会引起一些列的问题，甚至有重新设计数据库的可能，而对于nosql来说，因为其是通过文档进行存储的，所有没有严格意义上的schema，所以当后期进行扩展时，影响较小。
相对来说，DynamoDB缺点也十分明显，在没有传统数据库限制的同时，代价是其丧失了很多重要功能，比如说外键，表连接，数据有效性检查等等。总而言之，如果项目极度依赖表和表之间的关系，且关系及其复杂，那么建议用传统关系型数据库，否则可以尝试DynamoDB。
粉丝福利
亚马逊云科技专为开发者们打造了多种学习平台：
1. 入门资源中心：从0到1 轻松上手云服务，内容涵盖：成本管理，上手训练，开发资源。AWS入门_AWS入门使用教程_AWS云计算资源-AWS云服务
2. 架构中心：亚马逊云科技架构中心提供了云平台参考架构图表、经过审查的架构解决方案、Well-Architected 最佳实践、模式、图标等。AWS架构中心部署说明_AWS云架构白皮书-AWS云服务
3. 构建者库：了解亚马逊云科技如何构建和运营软件。Amazon Builders' Library*all&awsf.filter-content-type=*all&awsf.filter-content-level=*all&trk=835e6894-d909-4691-aee1-3831428c04bd&sc_channel=el
4. 用于在亚马逊云科技平台上开发和管理应用程序的工具包：aws工具下载_aws开发工具_资源下载-AWS云服务