flyer

正文共： 2251字 3图 预计阅读时间： 6分钟 前言 在日常业务研发过程中，我们常常需要与数据库表打交道。设计范式是数据表设计的基本原则，对于数据表的设计范式，我们特别容易忽略它的存在。很多时候，当数据库运行了一段时间之后，我们才发现数据表设计上有问题。然后重新调整数据表的结构，需要做数据迁移，还有可能影响程序处理的业务逻辑，甚至系统的正常服务运行。 其实在数据库表结构设计的初期时候，我们就需要重视数据表的设计。 1、数据库的设计范式 1.1 数据库的设计范式包括哪些呢？ 我们在设计关系型数据库模型的时候，需要对关系内部各个属性之间联系的合理化程度进行定义，这就有了不同等级的规范要求，这些规范要求被称为范式（NF）。 范式简单理解即为：一张数据表的设计结构需要满足的某种设计标准的级别。 目前关系型数据库一共有 6 种范式，按照范式级别，从低到高分别是：1NF（第一范式）、2NF（第二范式）、3NF（第三范式）、BCNF（巴斯 - 科德范式）、4NF（第四范式）和 5NF（第五范式，又叫做完美范式）。 数据库的范式设计越高阶，冗余度就越低，同时高阶的范式一定符合低阶范式的要求，比如满足 2NF 的一定满足 1NF，满足 3NF 的一定满足 2NF，依次类推。 这么多的范式级别，那是不是都要符合呢？ 一般来说数据表的设计应尽量满足 3NF 。但也不绝对，有时候为了提高某些查询性能

作者 | 悟鹏 引子 性能测试在日常的开发工作中是常规需求，用来摸底服务的性能。 那么如何做性能测试？要么是通过编码的方式完成，写一堆脚本，用完即弃；要么是基于平台，在平台定义的流程中进行。对于后者，通常由于目标场景的复杂性，如部署特定的 workload、观测特定的性能项、网络访问问题等，往往导致性能测试平台要以高成本才能满足不断变化的开发场景的需求。 在云原生的背景下，是否可以更好解决这种问题？ 先看两个 yaml 文件： performance-test.yaml 描述了在 K8s 中的操作流程： 创建测试用的 Namespace 启动针对 Deployment 创建效率和创建成功率的监控 下述动作重复 N 次：① 使用 workload 模板创建 Deployment；② 等待 Deployment 变为 Ready 删除测试用的 Namespace basic-1-pod-deployment.yaml 描述使用的 workload 模板 performance-test.yaml ： apiVersion: aliyun.com/v1alpha1 kind: Beidou metadata: name: performance namespace: beidou spec: steps: - name: "Create Namespace If Not Exits"

　　美国小型飞行器初创公司 Kitty Hawk（小鹰）近日宣布，由于缺乏商业前景，5 年前开始的单人飞行器研发项目 “Flyer” 将被终止，解散 70 人组成的项目团队，其中绝大多数员工将离职，剩下的人将被转移到另一个名为 Heaviside 的项目团队中。 　　“在 Flyer 项目上，我们找不到通往可行商业计划的道路。但我们将把学到的经验、技术和知识用在 Heaviside 项目上，并将其作为未来的主要平台，翻开下一篇章，”小鹰公司 CEO 塞巴斯蒂安 · 特伦（Sebastian Thrun）表示。 　　自 2010 年成立以来，小鹰公司都是十分低调的存在，很少公布项目进展。但其背后站着一众硅谷大佬，有谷歌联合创始人拉里 · 佩奇担任投资人，谷歌 X 实验室创始人塞巴斯蒂安 · 特伦担任 CEO，推特工程部门前 SVP 亚历克斯 · 罗伊特（Alex Roetter）担任 Flyer 项目主管，因此一举一动都备受外界关注。 　　这次被画上句号的 Flyer 项目在 2017 年首次公之于众，但早在 2015 年就开始在内部孵化。项目愿景是开发一种能够垂直起降的纯电动单人小型飞行器（eVTOL）。最早人们猜测其样式可能类似于科幻电影中的飞行汽车，因此在早期报道中，该项目又被称为是“拉里 · 佩奇的飞行汽车”。 　　 　　图 | 2017 年展示的 Flyer 原型机