sql_nosql、systemDesign浅读

summary_2018/07 database se(软工)

1、日常工作

1.1、 system design 学习

1.2、 关系型数据库和非关系型数据库重新定义

2、技术学习

2.1、 system design 学习：系统设计的步骤

2.1.1、约束和用例

# 用例：用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，即系统的功能
# 约束：一些约束，如系统容量等性能指标，或者操作系统及环境、兼容性需求等
Example:URL服务简化为例
## 用例：
缩短URL：将一个长URL转换为一个短URL
重定向：接收到一个短URL后，重定向到长URL，即定向到真实地址
自定义URL功能
统计分析功能
链接自动过期（为短URL设置expiration time）
手动删除链接
## 约束
10%的流量流向缩短URL服务，90%流量流向重定向
每秒request数：400+（40：缩短；360：重定向）
5年内6billion urls
每个URL大小为500字节
每个URL的hash值为6字节
五年时间，url总大小为3TB，hash总大小为36GB
每秒写入的新数据约为20KB

2.1.2、抽象设计

一旦你确定了即将设计的系统范围，你应该继续概述一个高级抽象设计。这样做的目的是概述您的架构所需的所有重要组件。可以画一个简单的草图来描述你的整个系统设计。
Example:
1、应用服务层
缩短URL服务
重定向服务
2、数据存储层
存储映射关系
根据key恢复出实际URL值

2.1.3、了解瓶颈

当抽象设计完成后，考虑到实际问题需要，考虑系统可能会遇到哪些瓶颈，也许您的系统需要一个负载均衡器，并且它背后有许多机器来处理用户请求。或者数据可能非常庞大，您需要在多台计算机上分发数据库。这样做有哪些缺点？数据库是否太慢，是否需要一些内存缓存？
Tips：请记住，通常每个解决方案都是某种权衡。改变一些东西会使其他东西恶化。然而，重要的是能够根据实际情况权衡，并在给定约束和用例的情况下衡量它们对系统的影响。
Example：
分析第一阶段提出的约束，需要注意的地方是并发的处理和数据的存储，但每秒400+并不会造成并发处理的瓶颈，那么需要考虑的地方就在于数据量的处理上，采取哪种方案解决。（当然，有时也需要考虑到业务的发展，提前做好考虑，提高系统的可拓展性）

2.1.3、扩展抽象设计：可拓展性

当分析完瓶颈的时候，就需要考虑实际解决方案，来提高系统的可拓展性。
在拓展性中，我们需要知道一些概念，及之间的区别和取舍，如：
1、垂直缩放：通过增加机器的性能，如cpu、内存
2、水平缩放：通过增加多台机器
3、高速缓存
4、负载均衡
5、数据库复制
6、数据库分区
7、异步
。。。。
Example:
在本例中，我们可能就需要考虑数据存储相关的东西，如数据库的选择。。。，在本例中，可能mongo的表现效果不错，也可以很好的进行水平拓展。
当做完这些步骤后，我们就可以开始系统的详细设计了。。。
Tips：可拓展性是一个十分重要的东西，包涵的东西十分多，值得我们学习，比如还有系统的高可用性等等。。。

2.2、 关系型数据库和非关系型数据库重新定义

• 关系型数据库：基于关系模型来组织的数据库，可以简单理解为一张二维表，比如常见的MYSQL
• 非关系型数据库：指那些非关系型的，分布式的，且一般不保证遵循ACID原则的数据存储系统。
  
  • 面向高性能并发读写的key-value数据库：key-value数据库的主要特点即使具有极高的并发读写性能，Redis,Tokyo Cabinet,Flare就是这类的代表
  • 面向海量数据访问的面向文档数据库：可以在海量的数据中快速的查询数据，典型代表为MongoDB以及CouchDB
  • 面向可扩展性的分布式数据库：解决的问题就是传统数据库存在可扩展性上的缺陷