共计 5348 个字符，预计需要花费 14 分钟才能阅读完成。
在不那么边远的旧 IT 时代，有这样一个段子——如果把数据库们”聚在一起“散会”。
Oracle: 咱们须要企业级数据库。
MySQL: Oracle 不开源。
PostgreSQL: MySQL 的性能不够多。
SQLite: 你能够把我嵌入到任何中央。这样，4 种数据库够大家用了。
MongoDB: 为什么咱们要用 join 和模式 (schema)?
Bigtable: MongoDB 的对 web 的扩展性不好。
Hbase: Bigtable 不开源。….
（摘自：《外刊 IT 评论》）
这段“对话”显然有滑稽的成分，但也映射出一个无奈逃脱的事实——一个数据库包打天下的时代过来了。俗话说，“工欲善其事，必先利其器”，那么，咱们到底须要怎么的数据架构？又该如何抉择数据库？在亚马逊云科技首期 Build On《现代化数据架构思考与实际 -NoSQL 的前世今生解读及架构搭建》中，数据库产品专家吕琳、李君针对现代化数据架构这一话题开展分享并率领大家现场实现了非关系型数据库相干的两个入手试验。
01 繁多数据库无奈满足需要
在数据库技术的发展史上，1970 年是个微小的转折点，这一年，埃德加·科德发表了《大型共享数据库数据的关系模型》一文。由此，关系型数据库始终占据着数据库生态圈的顶尖位置。科德自己也凭借这项成就取得了图灵奖。值得一体的是，仅关系型数据库这一个门类就前后诞生了四个图灵奖得主。
随着现代化利用的倒退，开发者对性能、规模和可用性的要求更高。用户量动辄百万以上，数据量从 TB 增长至 PB，性能要求达到毫秒甚至奥妙级别的提早 …… 与此同时开发者心愿免去沉重、反复的运维和部署工作，将更多的精力投入到开发业务中去。繁多数据库的模式已无奈满足企业的需要。
2004 年，亚马逊电商产生过一次很重大的故障，以致用户间断几个小时无奈实现交易。过后，亚马逊电商采纳的是 Oracle 关系型数据库，但因为关系型数据库人造地在面对海量数据的高效率读写时，读写性性能较差，因而，只管领有上万套 Oracle 数据库，并对数据进行了分库分表处理，在业务量剧增的状况下，零碎还是解体了。这时的亚马逊未然遇到了关系型数据库的扩大瓶颈。
在那次重大的事变后，亚马逊开始从新考量、构建本人的利用，并从新抉择数据库。其实，过后作为 Oracle 寰球最大的客户之一，亚马逊享受到的 license 折扣是极低的，然而，面向未来的爆炸式倒退需要，让他们意识到以后数据架构的不欠缺。在审慎调研与设计之后，亚马逊决定不再采纳繁多数据库模式，而是将其进行拆分，同时采纳 Amazon Redshift、Amazon DynamoDB、Amazon Aurora、PostgreSQL 等多种类型的数据库。这样的做法防止了仅采纳关系型数据库产生的因数据集增大而带来的性能降落问题。在海量数据集下仍旧能够放弃高并发申请和继续低响应提早，且简直没有扩大下限。现在，亚马逊电商零碎在相似双 11 流动规模的 Prime Day 上，每秒可能会应答超过 8000 万次的调用，如果仅采纳关系型数据库，简直是不可能实现的。
不仅仅是在亚马逊，互联网行业、金融行业的很多巨头公司，都已同时采纳多种数据库。如为寰球旅行者和房东提供出租 / 租用的服务型网站 Airbnb，在关系型数据库上抉择 MySQL 和 RDS，在非关系型数据库上抉择 DynamoDB，同时采纳 Amazon ElastiCache、Redis 进行前端的数据缓存。金融行业公司 Capital One 大量应用非关系型数据库 DynamoDB，而须要数据分析时则会用到 Amazon Redshift。
每一款数据库都有其历史背景，是特定工夫、技术条件之下面向指定场景需要的产物，各有千秋的同时也各有局限性。因而，不同的业务类型、乃至同一业务链路下的不同场景个性能够按需拆分为不同的数据库需要。并且，随着微服务拆分地越来越细，数据库也人造得有了拆分的保障，越来越多企业更适宜、也更违心依据其需要场景来抉择专用数据库。
所以，明天咱们为大家带来的是现代化数据架构的第一个也是最重要的一个概念——“专门构建，专库专用”
02 如何抉择适合的数据库？
要说最目迷五色的，莫过于数据库服务的“大家族”了。在不同的数据库间如何依据本人的利用场景进行抉择，能力让每个场景都取得极致的性能、可用性和扩展性？吕琳在分享中介绍了不同类型专用数据库的利用场景。
他首先从开发者们最为相熟的关系型数据库讲起。比拟罕用的关系型数据库有 PostgreSQL、MySQL、MariaDB、Oracle Database、SQL Server 等，亚马逊云科技的 RDS 也同时提供五种罕用数据库引擎。为什么还要借鉴了 Amazon Aurora，吕琳说：“这其实源自客户的需要。”
客户反馈，Oracle、SQL Server 功能强大，提供企业级反对，但它们有刻薄的 License 许可机制和重大的绑定偏向，且费用低廉。反之，MySQL、PostgreSQL 这样的开源数据库，尽管收费，但又少了性能、性能、高可用性及企业级反对。
如何能力鱼与熊掌兼得？2014 年，亚马逊云科技推出首款专为云打造的关系型数据库 Amazon Aurora。Amazon Aurora 齐全兼容 MySQL 和 PostgreSQL，性能能够达到规范的 MySQL 的五倍，规范的 PostgreSQL 的三倍，且可依照使用量付费。在性能方面 Amazon Aurora 是一个高可用的典型案例。
但作为一款关系型数据库，Amazon Aurora 仍旧逃脱不了关系型数据库的设计问题，即随着数据量的增长，索引效力肯定会有所降落。当面对海量数据，又要保障索引效力，企业通常会采纳两种方法。
其一，是对关系型数据库进行分库分表。分库分表可能晋升性能，减少可用性，然而，这样的形式也会为开发者带来很多麻烦。比方，事务问题怎么解决？跨分辨查问怎么办？如何让冷热数据平均散落在各个分库分表内？这些都须要开发者花工夫去思考。
第二种办法，就不得不谈到非关系型数据库了。非关系型数据库存储格局灵便、速度快、扩展性高、且老本绝对较低。在很多特定场景下，体现强劲，比方海量写入，精准读取，高并发更新，对一致性要求不低等场景。亚马逊云科技最典型的非关系型数据库是 DynamoDB，它的扩大简直没有下限，且可能防止数据集增大导致性能降落，海量数据集下仍然能够放弃毫秒甚至微秒级的响应工夫。不仅如此，DynamoDB 还采纳了无服务器架构无需硬件配置、软件补丁或降级就能够自动化扩大或缩减、间断不间断地备份数据。
除常见的关系型数据库和非关系型数据库，还存在一些其余类型的数据库，如内存数据库，文档数据库、图数据库、时序数据库等，也都领有各自适宜的利用场景。吕琳一一为大家进行介绍。
内存数据库：如 Amazon ElastiCache 或者 Amazon MemoryDB 等。这类数据库能够保证数据不失落，通常来说，Redis 的复制技术是异步复制，可能会失落一部分数据，但采纳内存数据库 Amazon MemoryDB 则不存在数据失落的状况。
文档数据库：如 MongoDB、Amazon DocumentDB 等。MongoDB 在中国区的接受度很高，很适宜间接存储 JSON 数据，因而，游戏、直播等行业会人造地偏向采纳它。但 MongoDB 免费版很难做到高可用，而免费版费用又很高，相比来说，Amazon DocumentDB 提供更弱小的高可用和可扩大能力。
图数据库：如 Amazon Neptune，图数据库属于比拟新兴的数据库，次要用以记录不同事物间的互相关系。在社交网络、常识图谱、生命科学等场景比拟罕用，此外在欺诈检测、疫情防控的背地，图数据库也施展了重要的作用。
时序数据库：如 Amazon Timestream，时序数据库次要用于解决带有工夫标签的数据，次要使用于保险、电力、化工等行业，进行各类实时检测、监测与剖析。Amazon Timestream 提供疾速、可扩大、齐全托管的服务，与关系数据库相比速度快 1,000 倍，老本仅为 1/10。
所谓尺有所短，寸有所长。因而，各种各样的数据库，只有在本人适宜的场景，才可能施展最大的价值。
03 面向现代化利用的高可用、可扩大 NoSQL 数据库
尽管数据库的品种繁多，但大体个别可分为两类，一类是传统的 SQL，另一类是比拟新兴的 NoSQL。吕琳强调，这两种数据库并非相互代替的关系。如果须要大量 joins 或者灵便的即席查问，那么 SQL 肯定是不二的抉择。然而，如果须要海量扩大、低可预期的提早和灵便的 schema，那么 NoSQL 才是更优的抉择。
在非关系型数据库中，吕琳着重介绍了 DynamoDB 的根底及最佳实际，后续的入手试验也是围绕这款数据库开展。
2007 年，亚马逊 Dynamo 论文的发表，为起初一系列 NoSQL 实践与产品的倒退提供了启发，铺平了实践的路线，很多 NoSQL 产品都参考了 Dynamo 零碎。2012 年，DynamoDB 正式诞生。这是一款齐全托管的无服务器类型的 NoSQL 数据库。用以解决数据库治理、性能、可扩展性和可靠性等外围问题。具备很高的可扩展性、可用性和健壮性，适宜存储大量数据并且同时要求低提早的应用服务。DynamoDB 提供全托管服务且操作简略，以至于在开发者中流传着这样一句话“应用 DynamoDB 你什么也不必管，只须要记得付账单就能够了。”很多顶级企业都是 DynamoDB 的用户，国外有 Netflix，国内如华米、随锐。
DynamoDB 的外围组件是表、我的项目和属性。表是我的项目的合集，我的项目是属性的合集。DynamoDB 应用主键来示意表中的我的项目。分区键用来构建一个非排序的散列索引，使得表能够进行分区，从而满足扩展性的需要。在一个分区键决定的散列索引里，数据依照排序键进行排列，每个排序键所对应的数据行数没有下限，除非你有本地二级索引。
本地二级索引 (LSI) 能够抉择与表不同的排序键，每个表分区对应一个索引分区。每个分区键能够存储最多 10 GB 的数据，包含表分区和索引分区的数据量。
除本地二级索引，另外一种索引形式是全局二级索引 (GSI)。全局二级索引能够抉择与表不同的分区键以及排序键，且每个索引分区会对应所有的表分区。
GSI 和 LSI 该如何抉择呢？对于 GSI 来说，索引尺寸没有下限，读写容量和表是独立的，只反对最终的一致性。而对于 LSI 来说，索引保留在表的分区中，每个分区键值的存储下限是 10GB，应用的是表上的 RCU 和 WCU。
应用 DynamoDB 除了须要指定主键、分区键和排序键外，用户只需确定拜访次数，零碎会依据拜访次数预置容量。不仅如此，DynamoDB 还领有独特的 Token Bucket 算法，能够将残余的 RCU 存储下来，以应答从天而降的流量洪峰。
对于 NoSQL 来说，一个比拟常见的问题是拜访不平衡的问题，而 DynamoDB 特有自适应容量（Adaptive Capacity）性能，减少过热分区的吞吐量，对过热我的项目进行隔离。此外，DynamoDB 还提供预置容量主动伸缩和按需扩容等性能在保障容量的根底上，最大限度升高企业老本。
分享的最初，吕琳介绍了四个无关 DynamoDB 设计最佳实际，别离为：
● 谨慎抉择 Hash Key 以实现有限扩大
● 如何存储大我的项目
● 如何解决热点我的项目
● 应用 Time-Series 表格存储时序型数据
04 入手试验环节
“纸上得来终觉浅，绝知此事要躬行”吕琳老师的分享让现场的开发者对现代化数据架构有了初步的意识。随后，开发者们在李君老师的率领下，开始了入手试验环节。本次 Build On 共设置两个入手试验。
动 ⼿试验⼀ 使⽤ Amazon DynamoDB 为挪动应⽤程序设计数据库
入手试验一假如开发者正在构建一个用来上传照片的挪动应用程序。用户将通过开发者开发的应用程序上传照片，其好友能够查看他们的照片。这个应用程序是一个社交应用程序，因而用户可能会查找和关注好友。关注好友后，用户将收到好友公布新照片的告诉，并可能向好友发送音讯。开发者设计的应用程序要可能满足用户应用爱心、笑脸、竖起大拇指、戴墨镜四种表情符号对照片做出表态的需要。
通过这个试验，开发者学习了如何对 DynamoDB 表进行建模以解决应用程序的所有拜访模式，并理解了如何应用新的事务处理性能，从而疾速高效地应用 DynamoDB。
动 ⼿试验二 使⽤ Amazon DynamoDB 对游戏玩家数据建模
除利用于社交场景外，DynamoDB 也是游戏场景颇受欢迎的数据库服务。入手试验二假如开发者正在构建一个有 50 名玩家同时在线的大逃杀游戏。游戏工夫通常为 30 分钟左右，在游戏中，开发者必须更新某特定玩家的记录，以指明该玩家玩游戏的时长、创纪录的杀敌数量或者是否获胜。满足用户想查看他们玩过的游戏、游戏获胜者或者想观看每场游戏动作重播的需要。
通过该试验，开发者们进一步理解了一些外围数据建模的策略，以及如何在游戏及其相似场景中应用 DynamoDB 构建现代化数据架构。
你是不是也想试试呢？未能亲临现场参加本次流动，并对 DynamoDB 数据库感兴趣的开发者可扫描下方二维码注册账号并支付礼包，实操上述两个入手试验
点击 浏览原文 即可下载本期 Build On 上手实操手册，快来亲自动手学习 \ 温习课程内容吧~
扫描上方二维码即刻注册
