数据库设计

家喻户晓，MySQL 的 InnoDB 存储引擎应用了 B+ 树作为索引实现，那么为什么不应用其余的数据结构呢？数组、链表或者哈希表。实现存储引擎到底须要什么条件呢？ 咱们当初先以存储最简略的数据为例，这里的数据相似于 json 对象。有 key 和 value。 { "0": "value1", "1": "value2" }最简略的存储引擎必须实现以下三个办法： read: (key: number) => value 查找 key 并返回 valuewrite: (key: number, value) => void 查找并插入 key 以及 valuescan: (begin: number, end: number) => value[] 查找返回 key 范畴内数据简略数据结构对于开发我的项目来说，能应用最简略的数据结构实现我的项目是十分棒的，这意味着更少的 bug 和更少的工夫。 有序数组如果以后有序数组的地位和存储的 key 能够一一对应的话，也就是数组 index 对应 key（没有对应也就是稠密数组），咱们的 read 和 write 办法的工夫复杂度会是 O(1)，scan 办法也是 O(1)。但数据量稍大就扛不住了。 退而求其次，不存在地位对应主键的状况下，有序数组严密存储，这样能够通过二分查找，read 和 scan 办法的工夫复杂度为 O(log2n)。但 write 办法老本会高到离谱。 综上所属，有序数组是在数据量少的状况下能够用来做存储引擎的。 哈希表不思考空间是不可能的，那么间接舍弃 scan 办法呢？在某些业务场景下是能够不应用 scan 办法的。 ...

1. 简介 对于从事数据库结构设计相干人员而言，咱们通常会在设计的不同阶段用到ER图和数据库模型图，用来形容数据之间的组成构造和数据间的关系，然而很多画图人员会把它们两者给搞混了，上面就来聊聊它们之间的区别。 1、ER图全称为实体分割模型、实体关系模型或实体分割模式图 个别用在概念构造设计阶段用来形容数据需要，比方存储在数据库中的数据范畴、数据类型、数据间的关系等等提供了示意实体型、属性和分割的办法，用来形容事实世界的概念模型侧重于概念设计，用于剖析数据间的关系，满足第几范式要求2、数据库模型图个别在数据库建模时应用，也能够从数据库逆向生成数据库模型图 用在数据库建模阶段，个别用于关系型数据库建模，这个过程蕴含了概念设计阶段跟具体的数据库实现有肯定关系侧重点是生成具体的数据库构造，表、字段、索引、主键、外键等等罕用的数据库模型图/ER图绘制工具很多是商用的，价格不菲；而往往很多收费的画图工具，功能完善没有那么欠缺，而且基本上没有将ER图和数据库模型图辨别分明，对于从事数据库设计相干工作的使用者，这无疑是非常不不便的。在应用过这么多画图软件之后，和听取了不少从事数据库设计相干工作的使用者的倡议之后，PDDON收费在线画图同时提供了绘制ER图和数据库模型图的能力，不便使用者在数据库设计的不同阶段绘制指标类型绘图。本文将带大家学习如何绘制ER图和数据库模型图。 2. ER图绘制教程 2.1 ER图的三个因素 实体 实体是具备公共性质、并能够互相辨别的事实世界的对象的汇合或者是具备雷同构造对象的汇合。在ER图中用矩形示意，将实体名写在矩形内。 属性/字段 每个实体都具备肯定的特色和性质，咱们能力依据实体的特色来辨别一个个实例。属性就是形容实体或分割的性质或特色的数据项，属于一个实体的所有实例都有雷同的属性。在ER图中属性用椭圆示意，属性名写在椭圆内，并用不带箭头的连线将属性和实体连接起来。 分割 在事实世界中，事物的外部或事物之间都有着某种分割，这种分割在信息世界中反馈为实体外部的分割和实体之间的分割。在ER图中用菱形示意，菱形框内写明分割名，并用连线别离与无关实体连接起来，同时在连线上表明分割的类型，常见的分割类型有: 1：11：nm：n 2.2 两个实体之间的分割这里咱们具体解说一下实体间的分割类型，并配上图例 一对一分割（1：1） 实体A中的每个实例在实体B中至少有有一个（或没有）实例与其关联，反之亦然，则称实体A和实体B为一对一关系。 一对多分割（1：n） 实体A中的每个实例在实体B中有n个实例（n>1）与之相关联，而实体B中的每个实例在实体A中最多只有一个实例与之关联，则称实体A和实体B为一对多关系 多为多分割（m:n） 实体A中的每个实例在实体B中有n(m>1)个实例与之关联，实体b中的每个实例在实体A中有m（m>1）个实例与之关联，则成为实体A与实体B为多对多关系。 2.3 实例演示咱们以学生选课为例，一个学生能够抉择多门课程，一门课程能够被多个学生抉择，一门课程能够被多名老师授课，一名老师同样能够传授多门课程，如下所示： 3. 数据库模型图绘制教程 3.1 数据库模型图阐明PDDON 提供的数据建模工具套件能除了能够绘制简洁好看的数据库模型图，还反对实时生成和预览代码/SQL脚本，而且反对多种编程语言和SQL方言、打包下载代码/SQL等性能。数据库模型图蕴含以下因素和性能： 表构造 TableFieldKey主键外键索引 类型索引字段规定等SQL预览和下载PDDON提供了实时生成和预览SQL，也能够打包下载SQL脚本。 右键菜单预览某个类生成的SQL 主菜单能够整体预览/下载SQL 代码预览和下载 PDDON会主动将表转换为实体类构造，主动转换为代码驼峰格调的类名、字段名，主动转换字段类型。反对实时生成、预览、下载代码。 下载ER图图片 您能够应用下载性能，下载图片到本地 导出导入绘图数据 当然PDDON不仅仅保留了绘图信息，而且会保留您的所有建模相干的数据，您能够应用导出设计稿性能对设计信息进行备份，也能够联合一些代码版本工具对齐进行版本跟踪和管控。 当您须要再次应用该建模设计稿时，从新导入到PDDON工作空间即可。快捷转换 PDDON还反对UML类图和ER图之间的疾速互转，节俭设计工夫。3.2 残缺示例 创立数据库模型图 数据库模型图模板 ER图应用示例 4. PDDON与其余画图工具不同的中央 ...

导读：腾讯音乐内容库数据平台旨在为应用层提供库存盘点、分群画像、指标剖析、标签圈选等内容分析服务，高效为业务赋能。目前，内容库数据平台的数据架构曾经从 1.0 演进到了 4.0 ，经验了剖析引擎从 ClickHouse 到 Apache Doris 的替换、经验了数据架构语义层的初步引入到深度利用，无效进步了数据时效性、升高了运维老本、解决了数据管理割裂等问题，收益显著。本文将为大家分享腾讯音乐内容库数据平台的数据架构演进历程与实际思考，心愿所有读者从文章中有所启发。 作者：腾讯音乐内容库数据平台 张俊、代凯 腾讯音乐娱乐团体（简称“腾讯音乐娱乐”）是中国在线音乐娱乐服务开拓者，提供在线音乐和以音乐为外围的社交娱乐两大服务。腾讯音乐娱乐在中国有着宽泛的用户根底，领有目前国内市场出名的四大挪动音乐产品：QQ音乐、酷狗音乐、酷我音乐和全民K歌，总月活用户数超过8亿。 业务需要腾讯音乐娱乐领有海量的内容曲库，包含录制音乐、现场音乐、音频和视频等多种形式。通过技术和数据的赋能，腾讯音乐娱乐继续翻新产品，为用户带来更好的产品体验，进步用户参与度，也为音乐人和合作伙伴在音乐的制作、发行和销售方面提供更大的反对。 在业务经营过程中咱们须要对包含歌曲、词曲、专辑、艺人在内的内容对象进行全方位剖析，高效为业务赋能，内容库数据平台旨在集成各数据源的数据，整合造成内容数据资产（以指标和标签体系为载体），为应用层提供库存盘点、分群画像、指标剖析、标签圈选等内容分析服务。 数据架构演进TDW 是腾讯最大的离线数据处理平台，公司内大多数业务的产品报表、经营剖析、数据挖掘等的存储和计算都是在TDW中进行，内容库数据平台的数据加工链路同样是在腾讯数据仓库 TDW 上构建的。截止目前，内容库数据平台的数据架构曾经从 1.0 演进到了 4.0 ，经验了剖析引擎从 ClickHouse 到 Apache Doris 的替换、经验了数据架构语义层的初步引入到深度利用，无效进步了数据时效性、升高了运维老本、解决了数据管理割裂等问题，收益显著。接下来将为大家分享腾讯音乐内容库数据平台的数据架构演进历程与实际思考。 数据架构 1.0 如图所示为数据架构 1.0 架构图，分为数仓层、减速层、应用层三局部，数据架构 1.0 是一个绝对支流的架构，简略介绍一下各层的作用及工作原理： 数仓层：通过 ODS-DWD-DWS 三层将数据整合为不同主题的标签和指标体系， DWM 集市层围绕内容对象构建大宽表，从不同主题域 DWS 表中抽取字段。减速层：在数仓中构建的大宽表导入到减速层中，Clickhouse 作为剖析引擎，Elasticsearch 作为搜寻/圈选引擎。应用层：依据场景创立 DataSet，作为逻辑视图从大宽表选取所需的标签与指标，同时能够二次定义衍生的标签与指标。存在的问题： 数仓层：不反对局部列更新，当上游任一起源表产生提早，均会造成大宽表提早，进而导致数据时效性降落。减速层：不同的标签跟指标个性不同、更新频率也各不相同。因为 ClickHouse 目前更善于解决宽表场景，无区别将所有数据导入大宽表生成天的分区将造成存储资源的节约，保护老本也将随之升高。应用层：ClickHouse 采纳的是计算和存储节点强耦合的架构，架构简单，组件依赖重大，牵一发而动全身，容易呈现集群稳定性问题，对于咱们来说，同时保护 ClickHouse 和 Elasticsearch 两套引擎的连贯与查问，老本和难度都比拟高。除此之外，ClickHouse 由国外开源，交换具备肯定的语言学习老本，遇到问题无奈精确反馈、无奈疾速取得解决，与社区沟通上的阻塞也是促成咱们进行架构降级的因素之一。 数据架构 2.0基于架构 1.0 存在的问题和 ClickHouse 的局限性，咱们尝试对架构进行优化降级，将剖析引擎 ClickHouse 切换为 Doris，Doris 具备以下的劣势： Apache Doris 的劣势： Doris 架构极繁难用，部署只需两个过程，不依赖其余零碎，运维简略；兼容 MySQL 协定，并且应用规范 SQL。反对丰盛的数据模型，可满足多种数据更新形式，反对局部列更新。反对对 Hive、Iceberg、Hudi 等数据湖和 MySQL、Elasticsearch 等数据库的联邦查问剖析。导入形式多样，反对从 HDFS/S3 等远端存储批量导入，也反对读取 MySQL Binlog 以及订阅音讯队列 Kafka 中的数据，还能够通过 Flink Connector 实时/批次同步数据源（MySQL,Oracle,PostgreSQL 等）到 Doris。**社区目前 Apache Doris 社区沉闷、技术交换更多，SelectDB 针对社区有专职的技术支持团队，在应用过程中遇到问题均能疾速失去响应解决。同时咱们也利用 Doris 的个性，解决了架构 1.0 中较为突出的问题。 ...

作者： 360数科中间件团队 编辑整理： SelectDB 作为以人工智能驱动的金融科技平台，360数科携手金融合作伙伴，为尚未享受到普惠金融服务的优质用户提供个性化的互联网生产金融产品，致力于成为连贯用户与金融合作伙伴的科技平台。360数科旗下产品次要有 360借条、360小微贷、360分期等，截止目前，已累计帮忙 141 家金融机构为 4300 万用户提供授信服务、为2630万用户提供借款服务、单季促成交易金额1106.75亿元。同时作为国内当先的信贷科技服务品牌，360数科在三季度累计注册用户数首次冲破 2 亿。 业务需要随着金融科技业务的一直倒退，对数据的安全性、准确性、实时性提出了更严格的要求，晚期 Clickhouse 集群用于剖析、标签业务场景，然而存在稳定性较低、运维简单和表关联查问较慢等问题，除此之外，咱们业务中有局部报表数据扩散存储在各类 DB 中，这也导致保护治理复杂度较高，亟需做出优化和重构。 零碎选型及比照基于以上需要及痛点，咱们对实时数仓的选型指标提出了明确的需要，咱们心愿新的 MPP 数据库具备以下几个特点： 数据写入性能高，查问秒级兼容规范的 SQL 协定表关联查问性能优良丰盛的数据模型运维复杂度低社区沉闷对商业敌对，无法律危险2022年3月开始，咱们对合乎以上特点的数据库 Apache Doris 开展了为期两个月的调研测试。以下是 Apache Doris 1.1.2 在各个方面的满足状况。 基于上述情况，咱们决定采纳 Apache Doris，除了能够满足上文提到的几个特点，咱们还思考以下几个方面： Clickhouse 因为 Join 查问限度、函数局限性、数据模型局限性（只插入，不更新）、以及可维护性较差等起因，更适宜日志存储以及保留以后存量业务，不满足咱们以后的业务需要。目前Apache Doris 社区沉闷、技术交换更多，SelectDB 针对社区有专职的技术支持团队，在应用过程中遇到问题均能疾速失去响应解决。Apache Doris 危险更小，对商业敌对，无法律危险。大数据畛域 Apache 基金会我的项目形成了事实标准，在 360数科外部已有广泛应用，且Apache 开源协定对商业敌对、无法律危险，不会有协定上的顾虑。平台架构360数科大数据平台（毓数）提供一站式大数据管理、开发、剖析服务，笼罩大数据资产治理、数据开发及任务调度、自助剖析及可视化、对立指标治理等多个数据生命周期流程。在整个 OLAP 中，目前 Apache Doris 次要使用离线数仓剖析减速、自助 BI 报表等业务场景。 在引入 Doris 后，思考已有数据分析业务以及数据规模，Doris 集群将先同步局部业务上优先级更高的数据。通过上述架构图能够看到，依靠 Doris 弱小的查问性能，咱们将把 Doris 架设在 Hive 数仓的下层，为特定场景进行查问减速，这样的架构建设起来老本很低，只须要实现数据从 Hive 数仓到 Doris 集群的导入适配，因为 Doris 集群并没有产生任何新表，能够间接复用曾经建设好的数据血缘关系。 ...

你好，我是程序员Alan。 这篇文章我会具体讲一下设计表构造时我会重点关注的中央，助你少走弯路。 数字类型 这里须要重点关注一下范畴，不须要记得十分分明，然而要有一个大略的印象，对边界问题要敏感。 另外不举荐应用数据库的浮点类型，否则在计算时，因为精度类型问题，会导致最终的计算结果出错，这是因为MySQL 之前的版本中的浮点类型 Float 和 Double，不是高精度。 更重要的是，从 MySQL 8.0.17 版本开始，当创立表用到类型 Float 或 Double 时，会抛出上面的正告：MySQL 揭示用户不该用上述浮点类型，甚至揭示将在之后版本中废除浮点类型。 在理论的开发中，咱们经常会应用整型类型来作为表的主键，即用来惟一标识一行数据。整型联合属性 auto_increment，能够实现自增性能，但在表结构设计时用自增做主键，心愿你特地要留神以下两点，若不留神，可能会对业务造成灾难性的打击： 用 BIGINT 做主键，而不是 INT；自增值并不长久化，可能会有回溯景象（MySQL 8.0 版本前）。INT 的范畴最大在 42 亿的级别，在实在的互联网业务场景的利用中，一些流水表、日志表，很容易达到最大值。 因而，用自增整型做主键，一律应用 BIGINT，而不是 INT。不要为了节俭 4 个字节应用 INT，当达到下限时，再进行表构造的变更，将是微小的累赘与苦楚。 我所在的公司就遇到过线上环境呈现INT类型达到上线导致服务异样的问题，过后运维同学的做法是批改数据库表构造（字段类型 INT -> BIGINT）,你猜这个简略的操作会造成什么问题？表锁死！表锁死又导致了一系列相干申请全副卡死！举个和我的项目无关的例子，助你感受一下问题的严重性，设想一下当初是春运期间，检票进站的时候，检票服务出现异常，大量旅客滞留在候车室的场景 字符串类型MySQL 数据库的字符串类型我最常应用的是 CHAR、VARCHAR。 CHAR 和 VARCHAR 的定义 CHAR(N) 用来保留固定长度的字符，N 的范畴是 0 ~ 255，请牢记，N 示意的是字符，而不是字节。VARCHAR(N) 用来保留变长字符，N 的范畴为 0 ~ 65536， N 示意字符。 在超出 65536 个字符的状况下，能够思考应用更大的字符类型 TEXT 或 BLOB，两者最大存储长度为 4G，其区别是 BLOB 没有字符集属性，纯属二进制存储。 ...

Physical Storage MediaAccess time$$Access\ time = Seek\ time + Rotational\ latency + (Transfer\ time)$$ Disk BlockFeaturesA contiguous sequence of sectors from a single trackData is transferred between disk and main memory in blocksThe operating system stipulates that a disk block can only contain one file, so the space occupied by the file can only be an integer multiple of the disk blockBlock SizeCompareSmaller blocks: more transfers from diskLarger blocks: more space wasted due to partially filled blocksTherefore, Lareger block sizes may mean space wasted, smaller may lead to more IO times. ...

动机为什么想到用UUID做数据库主键呢？思考如此场景，有多个生产环境各自运行，有时要从一个环境导数据到另一个环境，因而要求主键不抵触，自增整数不能满足要求。搞个地方发号器服务如何？很多互联网公司都这么做了。但对于以上场景，那就须要各个生产环境依赖同一个发号器服务了，难以跨数据中心乃至跨地区。其实这须要一种去中心化的发号策略，无论哪个服务器都能够发号，而且这些号互不抵触。 有一种现成的去中心化发号的实现，这就是UUID！UUID叫做通用惟一标识符（Universally Unique Identifier），是128bit的整数，用算法计算失去。在分布式系统中的任一服务器只有依规范创立UUID值，就能保障在全局范畴不反复。 例如Java的UUID.randomUUID()是用SecureRandom实现的齐全随机数，这是一种在密码学意义上平安的随机数，随机位越多越平安（猜不到法则，而且不容易反复）。因为128bit全是随机位，实践上认为在地球上是不会反复的。 考查就不多介绍了，来讲讲它能不能作为数据库主键吧，看看优缺点： 长处 去核心化生成->无单点危险去核心化生成->无需特意设计就能并行生成（自增主键是串行生成的，比较慢）无状态生成->数据记录在存入数据库之前就能领有主键（自增主键要在数据记录存入数据库后能力获取），编程更容易毛病 无序->不能用主键排序代替工夫排序，以防止加载数据记录（个别实现能有序，但Java内置实现齐全无序）无序->升高数据库写入性能无序->升高数据库读取性能长处不必多说了，来探讨这些毛病吧。 首先弄清楚关系型数据库系统是怎么工作的。相似于文件系统，关系型数据库系统以页为单位来存放数据，一页（个别为4KB、8KB或16KB大小）能寄存一批数据记录。读写时也是整页地读取或写入。对于有主键列的表，默认提供主键索引，索引项蕴含了主键值并且以主键排序。MySQL的主键索引采纳聚簇索引，索引与数据融为一体，数据记录依照主键程序来存储。PostgreSQL的主键索引采纳非聚簇索引，索引与数据各存一份（索引相当于"主键值->数据寄存地址"的映射表），有专门的索引页和数据页。 (1) 不能用主键排序代替工夫排序，以防止加载数据记录。当一个查问只须要返回主键但须要按工夫排序时，如果主键是工夫有序的，就能够对主键排序。这时只需拜访索引而无需拜访数据记录就能实现查问，因为索引就蕴含了主键值。 (2) 升高数据库写入性能用INSERT语句增加数据记录时，要更新主键索引。UUID主键的随机性使得MySQL的数据页、PostgreSQL的索引页被随机写入，很可能一页只增加一行，因而须要读写很多页（从磁盘读入内存，批改再写回，命中缓存时不必读磁盘但仍要写回）。有序的主键更有可能把多行增加到同一页，因而能够写更少的页（数据库系统不会每写一行就刷盘，而会略微缓冲一小会，让一页有可能多收到几行）。简而言之，随机主键不能利用数据的空间局部性。PostgreSQL只是索引页受影响，比MySQL数据页受影响要好些。但PostgreSQL WAL的full_page_writes个性引起的写入放大使它也受不小的影响。 (3) 升高数据库读取性能相邻工夫增加的数据记录会随机散布在MySQL的很多个数据页。新建的数据记录可能比拟热门，然而它们随机放在很多个数据页，没有哪一页是热门的。而且一些范畴查问，例如按创立工夫查问，须要读取很多个数据页能力拿到所有匹配的数据记录。同样，PostgreSQL只是索引页受影响，比MySQL数据页受影响要好些。 还有一个问题是UUID（128bit）比BIGINT（64bit）大，若用char(32)来保留UUID则须要256bit，存储和计算的开销都更大。 这篇是Percona首席架构师的文章，探讨MySQL应用UUID主键的性能。https://www.percona.com/blog/...这两篇是一位PostgreSQL专家的文章，探讨PostgreSQL应用UUID主键的性能，以及full_page_writes遇到的写入放大问题。https://www.2ndquadrant.com/e...https://www.2ndquadrant.com/e... URL编码再思考URL编码的问题。主键须要在REST格调URL中用来标识资源，例如/users/{id}，id能够是任一主键值。此时主键要被编码为字符串，UUID的字符串模式至多也要32字节（若保留'-'分隔符，如Java UUID.toString()，则为36字节）。这个字符串模式理论是UUID的16进制写法。 如果对UUID做Base64编码，能够压缩到22字节。请留神要应用URL Safe Base64编码（Java提供这一编码模式），因为规范的Base64含有URL保留字符，使得id字符串须要被本义。 有一些版本的UUID是有序的，其字符串模式满足ASCII程序，Base64编码使其不恪守ASCII程序。可应用Firebase-style Base64编码，参见 https://firebase.googleblog.c... 。 有序ID能够同时取得工夫有序性和平安随机性的益处吗？能够。 一种工夫有序的去中心化惟一ID实现： 生成一个齐全随机的UUID，长度为128bit以以后unix time作前缀，这样总长度为192bitFirebase-style Base64编码，这样总长度为32字节，相当于一般UUID string一种更玲珑的实现是unix time配上64bit随机值，和UUID一样有32字节，Firebase-style Base64编码后长度为22字节。然而可能对碰撞率有影响，须要实践证实。还有一种实现是48bit unix time配上80bit随机数，编码前char(32)，编码后char(22)，这一类算法有Firebase在生产环境用了，举荐。Cassandra应用UUID v1，依赖微秒工夫和MAC地址。 有序ID的编码Firebase-style Base64有一个问题：以后的ID总是以'-'开始。用户体验不好，因为用户很容易疏忽这个字符，认为它不是ID的成分。 因而我从新设计了编码，还赠送一份Java实现代码给读者（48bit unix time配上80bit随机数，满足ASCII程序的URL Safe Base64编码）。 /** * (22 chars) 48bit milliseconds + 80bit random value (ASCII-ordered URL-safe Base64-encoded) */public final class UniqueIdUtil { private static final SecureRandom secureRandom = new SecureRandom(); private static final byte[] remapper = new byte[128]; static { byte[] oldCodes = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_".getBytes(StandardCharsets.US_ASCII); byte[] newCodes = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_abcdefghijklmnopqrstuvwxyz~".getBytes(StandardCharsets.US_ASCII); for (int i = 0; i < oldCodes.length; i++) { remapper[oldCodes[i]] = newCodes[i]; } } private UniqueIdUtil() {} public static String newId() { ByteBuffer byteBuffer = ByteBuffer.wrap(new byte[18]); byteBuffer.putLong(System.currentTimeMillis()); byte[] randomBytes = new byte[10]; secureRandom.nextBytes(randomBytes); byteBuffer.put(randomBytes); return newId(byteBuffer); } static String newId(ByteBuffer byteBuffer) { byte[] original = Arrays.copyOfRange(byteBuffer.array(), 2, 18); byte[] encoded = Base64.getUrlEncoder().withoutPadding().encode(original); for (int i = 0; i < encoded.length; i++) { encoded[i] = remapper[encoded[i]]; } return new String(encoded, StandardCharsets.US_ASCII); }}来比拟两种ID编码：Firebase-style Base64编码：-MPZFw-83QdUZ_vQ6UAMdF自制Base64编码：0NQ_LnK8m~Cv5uYuAOTzUG ...

建表规约表白是与否概念的字段,必须应用is_xxx命名,数据类型是unsigned tinyint(1-是,0-否) 任何字段如果是非正数,必须是unsignedPOJO类中的任何布尔型变量,都不要加is前缀须要在< resultMap >设置从is_xxx到Xxx的映射关系数据库示意是与否的值,应用tinyint类型保持is_ xxx的命名形式是为了明确取值含意和取值范畴表名,字段名必须应用小写字母(或数字),禁止呈现数字结尾,禁止两个下划线两头只呈现数字.数据库字段名的批改代价很大,因为无奈进行预公布,所以字段名称须要慎重考虑 MySQL在windows下不辨别大小写,但在Linux下默认是辨别大小写的因而,数据库名,表名,字段名,都不容许呈现任何大写字母表名不应用复数名词 表名应该仅仅示意表外面的实体内容,不应该示意实体数量对于DAO类名也是复数模式,合乎表白习惯禁止应用MySQL的官网保留字命名: descrangematchdelayed索引命名: pk_字段名: 主键primary key索引uk_字段名: 惟一unique key索引名idx_字段名: 一般index索引名小数类型为decimal, 禁止应用float,double float和double在存储的时候,存在精度损失的问题,很可能在值比拟时,失去不正确的后果如果存储的数据范畴超过decimal的范畴,倡议将数据拆分成整数和小数离开存储如果存储的字符串长度简直相等,应用char定长字符串类型varchar是可变长字符串,不事后调配存储空间,长度不要超过5000 如果长度大于此值,定义字符串类型为text, 独立进去一张表,用主键来对应,防止影响其它字段索引效率表必备的三个字段: id: 主键,类型为bigint,unsigned,单表时自增,步长为1gmt_create: 类型为datetime,当初时示意被动创立gmt_modified 类型为datetime,过去分词示意被动更新表的命名最好加上[业务名称_表的作用]库名与利用名称尽量统一如果批改字段含意或者对字段的示意状态追加时,须要及时更新字段正文字段容许适当冗余以进步查问性能,但必须思考数据统一.冗余的字段应遵循: 不是频繁批改的字段不是varchar超长字段,更不能是text字段 商品类目名称应用频率高,字段长度短,名称根本变化无穷,可在相关联的表中冗余存储类目名称,防止关联查问单表行数超过500万行或者单表容量超过2GB, 才举荐进行分库分表 如果预计三年后的数据量基本达不到这个级别,不要在创立表时就分库分表适合的字符存储长度,岂但节约数据库表空间,节约索引存储,更重要的是晋升检索速度 索引规约业务上具备惟一个性的字段,即便是多个字段的组合,也必须建成惟一索引 索引不会影响insert的速度,这个速度能够疏忽,但进步查找速度是显著的即便在应用层做了十分欠缺的校验管制,只有没有惟一索引,必然有脏数据产生超过三个表禁止join, 须要join的字段 ,数据类型必须相对统一. 多表关联查问时,保障被关联的字段须要有索引在varchar字段上建设索引时,必须指定索引长度,没必要对全字段建设索引,依据理论文本区分度决定索引长度即可 索引长度与区分度是一对矛盾体 个别对字符串类型数据,长度为20的索引,区分度会高达90%以上能够应用count(distinct left(列名, 索引长度)) / count(*) 的区分度来确定页面搜寻严禁左含糊或者全含糊,如果须要要应用搜索引擎来解决 索引文件具备B-Tree的最左前缀匹配个性,如果右边的值未确定,无奈应用此索引如果有order by的场景,要留神利用索引的有序性 .order by最初的字段是组合索引的一部分,并且放在索引组合程序的最初,避免出现file_sort的状况,影响查问性能 where a=? and b=? order by c;索引: a_b_c要是在索引中有范畴查找,那么索引有序性就无奈利用(WHERE a>10 ORDER BY b; 索引:a_b无奈排序) 利用笼罩索引来进行查问操作,防止回表 比方一本书须要晓得第11章是什么题目,只须要目录浏览一下就更好,这个目录就起到笼罩索引的作用可能建设索引的品种分为主键索引,惟一索引,一般索引三种,而笼罩索引只是一种查问的成果用explain的后果,extra列会呈现: using index利用提早关联或者子查问优化超多分页场景: MySQL不是跳过offset行,而是取offset+N行,而后返回放弃前offset行,返回N行当offset特地大的时候,效率就十分低下,要么管制返回的总页数,要么对超过特定阈值的页数进行SQL改写 先疾速定位须要获取的id字段,而后再关联:SELECT a.* FROM table1 a,(select id from table1 where condition LIMIT 100000,20) b where a.id=b.idSQL性能优化的指标: 至多要达到range级别,要求是ref级别,最好是consts级别 ...

概述实现了数据库的物理视图和逻辑视图的显示和切换,具体参考如下: 关上: https://www.freedgo.com/erd-i...制做E-R模型图减少表的逻辑名减少列的逻辑名进行逻辑与物理视图的切换在线ER模型生成数据库设计文件点击生成数据库文档

数据已成为很多公司的外围资产，而在数据开发的过程中会引入各种品质、效率、平安等方面的问题，而数据治理就是要一直打消引入的这些问题，保障数据精确、全面和残缺，为业务发明价值，同时严格管理数据的权限，防止数据泄露带来的业务危险。数据治理是数字时代很多公司一项十分重要的外围能力，本文介绍了美团酒旅平台在数据治理方面的实际。一、背景1. 为什么要做数据治理随着挪动互联网的衰亡，线下商业活动逐步开始向线上化发展，数据的产生速度有了极大的晋升。越来越多的公司开始意识到数据的重要性，并将其打造成为公司的外围资产，从而驱动业务的倒退。在数据相干的畛域中，“数据治理”这个话题近两年尤为炽热，很多公司特地是大型互联网公司都在做一些数据治理的布局和动作。 为什么要做数据治理？因为在数据产生、采集、加工、存储、利用到销毁的全过程中，每个环节都可能会引入各种品质、效率或平安相干的问题。在公司晚期的倒退阶段，这些数据问题对公司倒退的影响并不是很大，公司对问题的容忍度绝对也比拟高。然而，随着业务的倒退，公司在利用数据资产发明价值的同时，对数据品质和稳定性要求也有所晋升。此外，当数据积攒得越来越多，公司对数据精细化经营水平的要求也随之进步，会逐步发现有很多问题须要治理。 同时，在数据开发的过程中也会一直引入一些问题，而数据治理就是要一直打消引入的这些问题，保障数据精确、全面和残缺，为业务发明价值，同时严格管理数据的权限，防止数据泄露带来的业务危险。因而，数据治理是数字时代很多公司一项十分重要的外围能力。 2. 须要治理哪些问题数据治理是一项须要长期被关注的简单工程，这项工程通过建设一个满足企业需要的数据决策体系，在数据资产治理过程中行使权力、管控和决策等流动，并波及到组织、流程、管理制度和技术体系等多个方面。一般而言，数据治理的治理内容次要包含上面几个局部： 品质问题：这是最重要的问题，很多公司的数据部门启动数据治理的大背景就是数据品质存在问题，比方数仓的及时性、准确性、规范性，以及数据利用指标的逻辑一致性问题等。老本问题：互联网行业数据收缩速度十分快，大型互联网公司在大数据基础设施上的老本投入占比十分高，而且随着数据量的减少，老本也将持续攀升。效率问题：在数据开发和数据管理过程中都会遇到一些影响效率的问题，很多时候是靠“自觉”地堆人力在做。平安问题：业务部门特地关注用户数据，一旦泄露，对业务的影响十分之大，甚至能左右整个业务的生死。规范问题：当公司业务部门比拟多的时候，各业务部门、开发团队的数据规范不统一，数据买通和整合过程中都会呈现很多问题。 3. 美团酒旅数据现状2014年，美团酒旅业务成为独立的业务部门，到2018年，酒旅平台曾经成为国内酒旅业务重要的在线预订平台之一。业务倒退速度较快，数据增长速度也很快。在2017到2018两年里，生产工作数以每年超过一倍的速度在增长，数据量以每年两倍多的速度在增长。如果不做治理的话，依据这种靠近指数级的数据增长趋势来预测，将来数据生产工作的复杂性及老本累赘都会变得十分之高。在2019年初，咱们面临着上面五种问题： 数据品质问题重大：一是数据冗余重大，从数据工作增长的速度来看，新上线工作多，下线工作少，对数据表生命周期的管制较少；二是在数据建设过程中，很多应用层数据都属于“烟囱式”建设，很多指标口径没有对立的治理标准，数据一致性无奈进行保障，同名不同义、同义不同名的景象频发。数据老本增长过快：某些业务线大数据存储和计算资源的机器费用占比曾经超过了35%，如果不加以控制，大数据成本费用只会变得越来越高。数据经营效率低下：数据应用和征询多，数据开发工程师须要破费大量工夫一对一解答业务用户的各种问题。然而这种形式对于用户来说，并没有晋升数据的易用性，无奈无效地积攒和积淀数据常识，还升高了研发人员的工作效率。数据安全不足管制：各业务线之间能够共用的数据比拟多，而且每个业务线没有对立的数据权限管控规范。开发标准规范缺失：晚期为疾速响应业务需要，研发人员通常采纳“烟囱式”的开发模式，因为不足相应的开发标准束缚，且数据工程师的工作思路和形式差异性都十分大，导致数据仓库内的反复数据多，规范性较差。当产生数据问题时，问题的排查难度也十分大，且耗时较长。4. 治理指标2019年，美团酒旅数据团队开始被动启动数据治理工作，对数据生命周期全链路进行体系化数据治理，冀望保障数据的长期向好，解决数据各个链路的问题，并保持数据体系的长期稳固。具体的指标蕴含以下几个方面： 建设数据开发全链路的标准规范，进步数据品质，通过系统化伎俩治理指标口径，保障数据一致性。管制大数据老本，防止大数据机器老本收缩对业务营收带来的影响，正当控制数据的生命周期，防止数据反复建设，缩小数据冗余，及时归档和清理冷数据。治理数据的应用平安，建设欠缺的数据安全审批流程和应用标准，确保数据被正当地应用，防止因用户数据泄露带来的平安危险和商业损失。进步数据工程师的开发和运维效率，缩小他们数据经营工夫的投入，进步数据经营的自动化和系统化水平。二、数据治理实际其实早在2018年以前，酒旅数据组就做过数据治理，过后只是从数仓建模、指标治理和利用上单点做了优化和流程标准。之后，基于下面提到的五个问题，咱们又做了一个体系化的数据治理工作。上面将介绍一下美团酒旅数据团队在数据治理各个方向上的具体实际。 1. 数据治理策略数据治理计划须要笼罩数据生命周期的全链路，咱们把数据治理的内容划分为几大部分：组织、标准规范、技术、掂量指标。整体数据治理的实现门路是以标准化的标准和组织保障为前提，通过做技术体系整体保证数据治理策略的实现。同时，搭建数据治理的掂量体系，随时观测和监控数据治理的成果，保障数据治理长期向好的方向倒退。 2. 标准化和组织保障咱们制订了一个全链路的数据规范，从数据采集、数仓开发、指标治理到数据生命周期治理，全链路建设规范，在标准化建设过程中联结组建了业务部门的数据管理委员会。 2.1 标准化 数据标准化包含三个方面：一是规范制订；二是规范执行；三是在规范制订和执行过程中的组织保障，比方怎么让规范能在数据技术部门、业务部门和相干商业剖析部门达成对立。 从规范制订上，咱们制订了一套笼罩数据生产到应用全链路的数据规范办法，从数据采集、数仓开发、指标治理到数据生命周期治理都建设了相应环节的标准化的研发标准，数据从接入到沦亡整个生命周期全副实现了标准化。 2.2 组织保障 依据美团数据管理扩散的现状，专门建设一个职能全面的治理组织去监督执行数据治理工作的老本有点太高，在推动和执行上，阻力也会比拟大。所以，在组织保障上，咱们建设了委员会机制，通过联结业务部门和技术部门中与数据最相干的团队成立了数据管理委员会，再通过委员会去推动相干各方去协同数据治理的相干工作。 业务部门的数据接口团队是数据产品组，数据技术体系是由数据开发组负责建设，所以咱们以这两个团队作为外围建设了业务数据管理委员会，并由这两个团队负责联结业务部门和技术部门的相干团队，一起实现数据治理各个环节工作和流程的保障。组织中各个团队的职责分工如下： 数据管理委员会：负责数据治理策略、指标、流程和规范的制订，并推动所有相干团队达成认知统一。业务数据产品组：负责数据规范、需要对接流程、指标对立治理、数据安全管制以及业务方各部门的协调推动工作。技术数据开发组：负责数据仓库、数据产品、数据品质、数据安全和数据工具的技术实现，以及技术团队各个部门的协调推动工作。 3. 技术零碎数据治理波及的范畴十分广，须要合作的团队也很多，除了须要通过组织和流程来保障治理口头失常发展，咱们也思考通过技术系统化和自动化的形式进一步提效，让零碎代替人工。上面咱们将从数据品质、数据老本、数据安全和经营效率等几个方向，来逐个介绍技术实现计划。 3.1 数据品质 数据品质是影响数据价值最重要的因素，高质量的数据给带来精确的数据分析，谬误的数据会把业务疏导到谬误的方向。数据品质波及范畴较广，在数据链路的每一个环节都有可能呈现数据品质问题，酒旅业务现阶段的次要品质问题包含： 数仓规范性差，数仓架构无对立的强制标准执行束缚，数仓历史冗余数据重大。应用层数据属于“烟囱式”建设，指标在多个工作中生产，无奈保证数据的一致性。数据上游利用的数据应用无奈把控，数据精确较差，接口稳定性无奈失去保障。业务方对多个数据产品的指标逻辑无对立的定义，各个产品中数据不能间接对标。数据组的治理数据品质计划笼罩了数据生命周期的各个环节，上面将介绍一下整体的技术架构。 对立数仓标准建模（One Model）：通过对立数仓标准建模系统化保障数仓标准执行，做到业务数仓标准标准化，并及时监控和删除反复和过期的数据。对立指标逻辑治理（One Logic）：通过业务内对立的指标定义和应用，并系统化治理指标逻辑，数据应用层的数据指标逻辑都从指标管理系统中获取，保障所有产品中的指标逻辑统一。对立数据服务（One Service）：通过建设对立的数据服务接口层，解耦数据逻辑和接口服务，当数据逻辑发生变化后不影响接口数据准确性，同时监控接口的调用，把握数据的应用状况。对立用户产品入口（One Portal）：分用户整合数据产品入口，使同一场景下数据逻辑和应用形式雷同，用户没有数据不统一的困惑。 3.1.1 对立数仓标准建模（One Model） 在业务倒退初期，数据团队集中精力在疾速建设数仓来反对业务，数仓建模标准疏于治理。随着业务的倒退，数仓中的数据急剧增多，数据产品和上游利用疾速减少，数据工程师和数据应用方也变得越来越多，数仓的问题日益突显。业务数据仓库从初期倒退到当初次要裸露了3方面的问题： 数据规范性较差，不同工夫的数仓标准不同，数仓标准的执行审核须要较多的人力。数据不统一问题多，同一指标在多个ETL中生产，数据更新同步也不及时。历史数据冗余重大，数据存储形式较多，业务方查问不晓得该用哪个数据。数据团队次要通过数仓规范化制订、数仓分层架构和数仓规范化零碎来解决上述问题，上面是咱们的具体解决方案。 制订规范-数仓标准 做好数仓规范化最根本的前提是要制订一系列标准化的标准，并推动组内同学执行。标准化的适用性、全面性和可执行性间接影响到标准的执行成果。数仓标准次要从3个方面制订数据标准化： 数仓建模标准，数仓建设最根底的标准，包含分层、命名、码值、指标定义、分层依赖等维度。主数据管理标准，数仓各个主题的数据只有一份，团队共建复用，不能反复开发。数据应用标准，在查问数据时优先查问主题层，不再提供明细层和ODS层的查问拜访入口。工具保障-数仓规范化开发零碎-Dataman 在执行数据规范化的过程中，咱们发现团队中每个人对标准的了解不统一，很可能造成数据标准不对立，审核人在审核上线工作时须要思考标准的全副规定，审批须要投入的人力较多。在这样的流程下，数据规范性无奈从本源上进行管制，因而须要建设数据规范化的工具，通过零碎保障标准的一致性。数据组应用的数据层规范化工具-Dataman，次要包含3个功能模块：标准化标准、配置化开发和规则化验证。 标准化标准：制订业务数据仓库的标准规范并配置在零碎中，包含架构分层、字段治理、词根治理、公共维度和码值治理等，在ETL开发时通过对立的数仓标准开发，通过配置化实现数仓的命名、分层和码值，保障数仓长期的规范性。 配置化开发：系统化保障工程师在开发ETL过程中恪守数仓标准，Dataman能够用配置化的形式生成XT工作模板，模板中蕴含数据模型的根底信息，研发同学只须要在工作模板中开发数据生产逻辑。 规则化验证：跟进数据仓库底层元数据和标准化配置信息，定期扫描数仓的规范性状况，判断出不合乎数仓标准的工作和高类似度的数据表。3.1.2 对立指标逻辑治理（One Logic） 业务应用数据的第一步是搭建业务指标体系，业务的指标和策略的执行状况须要通过指标来剖析，指标体系的合理性和指标数据的品质间接影响到业务决策，指标的重要性显而易见。咱们通过系统化地治理数据指标，从本源上解决指标口径一致性问题，次要从以下3个方向动手： 指标定义规范化指标治理系统化数据查问智能化指标定义规范化 此处次要从指标的生成和治理上做好标准，确保业务同学和研发人员对指标体系治理的认知统一，确保指标的新建、更改和应用都依照标准执行。咱们通过上面2个方向来实现指标定义的标准对立。 业务指标体系的规范化：咱们在业务线内对立了指标体系标准，指标分为原子指标、计算指标和复合指标，通过应用这3类指标反对业务的数据分析需要，业务将来新增指标也要依照这个规范分类。指标的治理规范化：咱们与商业剖析团队一起梳理业务指标逻辑规范和录入流程，通过制订指标的新增和变更标准SOP，解决由指标治理流程引起的品质问题，使得指标定义、零碎录入、指标认证和应用各个环节都有严格的流程管控，经由业务侧数据产品经理、业务侧数据治数据管理员和数据工程师独特审批，确保标准规范的落地执行。指标治理系统化 物理数据表治理：数据表治理的信息次要包含表的根底元数据信息、表类型（维表或事实表）、表的举荐度、形容信息和样例数据等。数据表治理次要是面向数据开发同学，通过保护数据表信息，为数据模型和指标治理提供数据根底反对。 数据模型治理：是对物理数据表的模型构建，通过一个物理模型能够查问到指标和相干的维度数据。数据模型能够是星型模型或宽表，星型模型中保护多个数据表的关联形式、关联字段、维度表蕴含字段和模型的ER图等信息。 指标治理：次要包含2局部的内容，指标的业务信息和技术信息。 业务信息：为了保障业务的指标信息精确且对立，指标的业务信息须要数据产品经理与商业剖析团队探讨确定后录入，录入后须要指标所属数据主题的负责人审批后能力上线。技术信息：技术信息次要包含指标对应的物理模型以及指标的计算逻辑，技术信息的填写须要数据工程师配置。技术信息配置后会在零碎里生成技术元数据，指标管理系统通过技术元数据生成数据查问语句，提供给上游利用。 指标查问智能化 在指标管理系统中创立指标时，咱们系统化治理了指标与数仓物理模型的关联关系和取数逻辑，通过数据物理模型取得指标对应的字段和能够关联的维度，以此把指标解析为数据查问SQL语句，通过数据查问引擎执行生产的SQL，智能化取得指标数据。 在查问解析过程中，经常出现指标绑定了多个底层数据表的状况，此时须要咱们手动的选一个物理模型作为指标生产的底层数据。但问题是，如果一个指标对应的模型太多，每次解析都须要手动指定，研发人员不确定抉择哪个模型的性能最好。另外，随着物理模型的增多，大量旧的指标配置的关联模型不是最优解，就须要手动优化更改。为了解决这个问题，指标管理系统减少了智能解析模块，在抉择智能模式查问时，零碎会依据指标治理模型的数据量、存储性能和查问次数等信息主动选取最优的物理模型。 3.1.3 对立数据服务（One Service） ...

本文首发于 Nebula 公众号：图查询语言的历史回顾短文 前言最近在对图查询语言 GQL 和国际标准草案做个梳理，调研过程中找到上面这篇 mark 了没细看的旧文（毕竟珍藏就是看过）。做个简略的记录。 摘要本短文会波及到的图查询语言有 Cypher、Gremlin、PGQL 和 G-CORE。 背景本文次要摘录翻译自 [Tobias2018] （见参考文献），并未波及到 SPARQL 和 RDF，只探讨了属性图。 文章撰写的工夫是 2018 年，能够看做 GQL（Graph Query Language）的一些后期筹备。GQL 有多个相干的起源，参见上面这张图。 因为 Cypher 的历史和 Neo4j 严密相干，本文会提一些 Neo4j 晚期的历史。[Angles2008]（见参考文献）和 [Wood2012]（见参考文献）是两个不错的对于图模型和图查询语言的总结。 年表简述2000 年，Neo4j 的创始人产生将数据建模成网络（network）的想法。2001 年，Neo4j 开发了最早的外围局部代码。2007 年，Neo4j 以一个公司的形式运作。2009 年，Neo4j 团队借鉴 XPath 作为图查询语言，Gremlin 最后也是基于这个想法。2010 年，Neo4j 和 Marko Rodriguez 采纳术语属性图（Property Graph）来形容 Neo4j 和 Tinkerpop / Gremlin 的数据模型。[PG2010]（见参考文献）2011 年，第一个公开发行版本 Neo4j 1.4 公布了第一个版本的 Cypher。2012 年，Neo4j 1.8 为 Cypher 减少写入图的能力。2012 年，Neo4j 2.0 减少了标签和索引，Cypher 成为申明式的语言。2015 年，Oracle 为 PGX 创造查询语言 PGQL。2015 年，Neo4j 将 Cypher 开源为 openCypher。2015 年，LDBC 成立图查询语言工作组。2016 年，LDBC 工作组开始设计 G-CORE。2017 年，WG3 工作组开始探讨如何将属性图查问能力引入 SQL。2017 年，LDBC 工作组实现了 G-CORE 的初始设计 [GCORE2018]（见参考文献）。2018 年，Cypher 形式化语义的论文发表 [Cypher2018] （见参考文献）。Gremlin、Cypher、PGQL 和 G-CORE 的演进Neo4j 的晚期历史Neo4j 和属性图这种数据模型，最早构想于 2000 年。Neo4j 的创始人们过后在开发一个媒体管理系统，所应用的数据库的 schema 常常会产生重大变动。为了反对这种灵活性，Neo4j 的联结创始人 Peter Neubauer，受 Informix Cocoon 的启发，心愿将零碎建模为一些概念相互连接的网络。印度理工学院孟买分校的一群研究生们实现了最早的原型。Neo4j 的联结创始人 Emil Eifrém 和这些学生们花了一周的工夫，将 Peter 最后的想法扩大成为这样一个模型：节点通过关系连贯，key-value 作为节点和关系的属性。这群人开发了一个 Java API 来和这种数据模型交互，并在关系型数据库之上实现了一个形象层。 ...

本文首发 Nebula Graph 官网：https://nebula-graph.com.cn/posts/cluster-communication-heartbeat/在用户应用 Nebula Graph 的过程中，常常会遇到各种问题，通常咱们都会倡议先通过 show hosts 查看集群状态。能够说，整个 Nebula Graph 的集群状态都是靠心跳机制来构建的。本文将从心跳说起，帮忙你理解 Nebula Graph 集群各个节点之间通信的机制。 什么是心跳？有什么作用？ Nebula Graph 集群个别蕴含三种节点，graphd 作为查问节点，storaged 作为存储节点，metad 作为元信息节点。本文说的心跳，次要是指 graphd 和 storaged 定期向 metad 上报信息的这个心跳，借助心跳，整个集群实现了以下性能。（相干参数是 heartbeat_interval_secs） 在 Nebula Graph 中常常提及的 raft 心跳则是用于领有同一个 partition 的多个 storaged 之间的心跳，和本文提的心跳并不相同。1. 服务发现当咱们启动一个 Nebula Graph 集群时，须要在对应的配置文件中填写 meta_server_addrs。graphd 和 storaged 在启动之后，就会通过这个 meta_server_addrs 地址，向对应的 metad 发送心跳。通常来说，graphd 和 storaged 在连贯上 metad 前是无奈对外进行服务的。当 metad 收到心跳后，会保留相干信息（见下文第 2 点），此时就可能通过 show hosts 看到对应的 storaged 节点，在 2.x 版本中，也可能通过 show hosts graph 看到 graphd 节点。 ...

我的项目数据库设计标准步骤一、数据需要剖析Creates a new model 建好当前是这样的 而后咱们来建设实体，抉择左边的 Entity，间接在屏幕上点就能够，$\color{red}鼠标右键勾销$ 这里，咱们建设5个实体 这里咱们轻易建几个实体，大家跟我一起建就 ok双击进行编辑 先设置 General Name 写中文Code 写英文Comment 是形容 - 而后设置属性 - 简略说一下，第三个参数就是数据类型，咱们选 Variable char 就好，就相当于 MySQL 中的 varchar 类型 >这里，如果大家对 MySQL 有啥不懂的，能够看我的 [MySQL 教程](https://blog.csdn.net/qq_29339467/category_9715943.html) - $\color{red}留神：$前面的 P 代表主键，M 代表是否能够为空，D代表是否显示（上面的D都是有勾选的），咱们将编号设为主键，且三个属性都不可为空 - 其余几个相似，这里我就不一一介绍了，我间接贴图就好了- 学校实体- 院系实体 - 业余实体- 实验室成员实体 - 最初，咱们就建设了如下几个实例二、确定实体关系 CDM （ER模型设计、逻辑模型设计）实体曾经建设好，咱们就要确定它们之间的关系咱们拿用户和学校来举例，其余相似 确定 1-1 1-N N-N 一个用户只能对应一个学校，一个学校能够有多个用户，那么他们是 many-one的关系强制关系和非强制关系 强制与非强制就是说，一个学校必须有用户，这就是强制关系；反之，为非强制关系，这里，学院和用户之间、用户和学校之间就都是强制关系了（难不成还有没学生的学校？）既然曾经确定好关系，咱们就在软件中实现 首先点击左边的这个- 而后点击用户拖到学校即可，成果如下 而后咱们双击线段，进行批改即可，Mandatory 就是示意强制关系，设置完点确定即可 其余相似，我也就不一一解说了最初后果如下 $\color{red}留神：1. 找间接关系，不能找间接关系$            $\color{red}2. 设计逻辑模型时，不思考是什么数据库$三、物理模型设计（PDM）接下来咱们开始设计物理模型物理模型其实很简略，通过 CDM 生成即可 第一个能够抉择咱们的数据库类型，下拉能够看到支流的数据库类型都是有的 而后在 Detail 中把 Check model勾销勾选，点确定就能够生成 PDM 了 ...

IT168：很快乐有机会采访到您，请您介绍一下本人，所在公司及主打产品？ 陈雷：毕业之后去了方正，而后IBM11年，守业4年，始终从事数据畛域的产品研发，零碎交付工作。业务教训次要集中在金融、通信、能源等信息化当先行业，当初所在的公司DatePipeline是一家年老的中国外乡企业，咱们致力于成为中国的世界级数据中间件厂商，产品也叫DataPipeline，是一款数据集成畛域的下一代中间件产品，性能笼罩了实时数据采集、异构数据交融、实时数据处理等数据集成畛域的次要场景。 IT168：您是何时进入这个行业的？这其中有没有特地的起因或者契机？ 陈雷：中间件行业可能和互联网行业还不太一样，还是有肯定门槛的，我置信从事软件行业的人大部分都和我一样，没有什么特地偶尔的起因或者契机，就是从小喜爱计算机，依据趣味抉择了业余而后一路走过去，如果肯定要说起因的话，我感觉可能是咱们国家近几十年信息技术的高速倒退为咱们提供了一展拳脚的空间，没有让咱们放弃本人的趣味，这也是一个很幸福的事。 IT168：国内的市场格局是怎么的？都有哪些玩家？DataPipeline处于怎么的地位？ 陈雷：次要分为三大类。 第一类是传统的外企，比方IBM、Oracle、Informatica等，有很成熟的产品和服务体系，但面对中国市场的新技术要求的应答稍显迟缓，比方Informatica往年发表遣散了中国公司，IBM和Oracle对国内正在逐渐衰亡的数据库都无奈提供反对。 第二类是云厂商，特地是私有云厂商，在大规模数据管理和利用上有十分深刻的摸索和实际，比方OceanBase，也代表了将来的倒退方向，但在数据集成这个畛域还没有特地无力的产品，而且在面向重点行业企业信息化建设服务这一块还是有很多的工作要做。 第三类是一些有技术实力的行业集成商也在做相干畛域的工作，但大部分都是在我的项目施行过程中基于开源我的项目缓缓积攒，从商业产品角度来说适应性还有待验证。 DataPipeline从成立之初就保持专业化、产品化倒退的路线，保持技术驱动，深耕企业服务，精确地讲在产品的适应性上曾经超过了传统外企，但在产品成熟度上还有很多工作要做，咱们当初也宽泛的和云厂商与行业集成商单干，独特为企业客户提供更好的服务。 IT168：据您所知，数据交融市场的规模大略是多少？ 陈雷：数据中间件的上下游市场正在快速增长，倒逼数据交融需要一直增长，能够说中间件和数据库及数据利用市场在同一量级，2018年寰球市场320亿美元，预计到2022年，数据交融市场大略在120亿美元以上，合乎增长率14%，数据交融是中间件增长最快的细分市场。 IT168：对于企业来讲，在搭建数据管理平台过程中都会面临哪些挑战和问题？ 陈雷：这个内容就比拟多了，讲最重要的三个挑战吧。 第一，各类数据管理技术差别越来越大，全面、精确的实时数据获取艰难。随着数据技术的一直倒退，针对某些具体场景的个性在一直被加强，使得各类数据技术的差异性进一步扩充，但被纳入其中的数据自身不应该因技术栈不同而妨碍其价值开释。 1、交易系统、账务零碎、管理系统、剖析零碎、主数据、数据仓库与大数据平台采纳的数据库治理技术都不尽相同，数据交换困难重重； 2、数据价值一直凸显，业务翻新须要数据撑持，但大量数据没有纳入主数据管理系统，数据仓库与大数据平台又无奈满足时效性要求； 3、数据时效性要求越来越高，批量数据交换无奈满足需要，但针对不同数据库的增量数据实时采集须要大量的技术储备与研发老本； 4、增量识别字段等形式无奈获取精确残缺的增量数据，常常为实时数据利用造成阻碍，也晋升了实时数据的应用老本； 5、不同数据库治理技术在实例、库、模式、表等数据对象上，字段类型、精度、标度等语义模式上都有区别； 6、对上游的构造变动感知与应答都须要针对不同数据库技术区别对待； 7、传输过程中的一致性、抵触、特定类型的数据处理也须要区别对待。 第二，如何疾速响应实时数据需要，把握机会疾速建设竞争劣势。业务须要更高的敏捷性来应答外部环境的变动，这须要整个数字化组织能够体系化的进行多速、麻利的业务场景撑持，以及对突发业务流动有更多的可见性，以确保能够利用新呈现的机会并疾速建设竞争劣势。 1、端到端实时数据链路的构建，往往是以月为单位交付的，甚至更多； 2、新的数据需要须要大量的代码开发，交付周期也是以周为单位计算的； 3、数十种数据库技术，多家供应商，十几个反对电话，感觉本人也是是集成商； 4、实时数据处理技术栈门槛较高，人员流失率较高，刚刚用棘手的供应商总是换人； 5、数据组的要求无奈通过DBA的审核，利用研发对系统运维要求口碑载道； 6、资源应用与研发人员程度严密相干，无奈精确评估，遇到要害业务需要时顾此失彼。 第三，实时数据链路兼具业务经营与治理撑持要求，稳定性与容错性问题重重。从客户行为剖析到非交易类的触客业务到事件营销再到风控评分，实时数据链路逐步成为业务经营的重要撑持，但作为买通各业务零碎数据通道的中间层，受到的上下游的各类制约，对稳定性的影响尤其重大。 1、上下游节点的业务连续性和服务级别均高于实时数据链路，实时数据链路须要遵循上下游节点的认证、加密、权限、日志等管理机制； 2、上游数据对象构造变动与数据对象的解决机制对实时数据链路影响微小，例如构造变动采纳rename形式； 3、实时数据流量不仅仅须要参考业务交易量，与上游零碎的数据处理形式有很大的关系，经常出现一个语句百万行增量的状况； 4、随着企业多核心及多云策略的执行，部署在不同网域或云环境的系统配置，网络连通性乃至专线供应商与带宽都对稳定性有影响； 5、对打算、非打算的网络不可用，上下游系统维护，物理删除等非规操作及偶发的谬误数据及主键抵触数据没有相应的容错性策略配置； 6、呈现系统故障时，无奈保障各个组件的高可用，零碎复原艰难，特地是实时数据链路的数据完整性与数据一致性很难复原。 IT168：在过来一年中，DataPipeline在产品性能、技术研发，有哪些翻新和冲破？ 陈雷：在过来的一年里，咱们针对产品进行了一次较为彻底的革新，次要体现在几个方面。 第一，进一步增强了基于日志的增量数据获取技术（Log-based change data capture），能够为各类数据平台和利用提供实时、精确的数据变动，从而使得客户能够依据最新数据进行经营治理与决策制定。 第二，对数据节点注册、数据链路配置、数据工作构建、零碎资源分配等各个环节进行分层治理，在无效地满足零碎运维治理需要的前提下，晋升实时数据获取与治理在各个环节的配合效率。在数据节点、数据链路、交融工作及系统资源四个根本逻辑概念中，用户只须要通过二至三项简略配置就能够定义出能够执行的交融工作，零碎提供基于最佳实际的默认选项，实时数据需要的研发交付工夫从2周缩小为5分钟。 第三，为应答简单的实时数据场景需要，零碎提供限度配置与策略配置两大类十余种高级配置。用户能够通过这些配置对上游进行限度与治理，也能够通过这些配置来对立调整上游的执行范畴与策略利用范畴。同时，优化了零碎整体的分布式引擎，实现了组件级高可用。从产品配置到零碎部署两个方面保障实时数据链路的稳固高容错。 IT168：近年来，您察看到的数据交融市场产生了哪些变动，有哪些发展趋势，DataPipeline如何符合这些趋势？ 陈雷：数据交融市场产生的变动次要有以下几点变动。 第一，市场竞争和用户行为的巨大变化。 1、用户交互工夫越来越短，算法精度要求越来越高； 2、流量维度越来越多，不再局限于线上。必须适配场景来抢夺注意力； 3、曾经没有确定的价值锚点，企业必须一直放慢本身进化速度。 第二，转变经营模式要求多速IT的撑持。 1、以客户为核心的独立产品经营模式，企业逐步成为公共服务平台； 2、各个经营部门对数据的时效性、准确性、全面性要求都不雷同； 3、对作为根底公共服务的数据平台来说，不变的是对需要的疾速响应。 第三，数据需要响应从研发向配置转变。 1、数据撑持与利用开发、零碎运维的协调问题必须解决； 2、在保障数据资源可控的前提下，为数据利用提供更多的自主性与敏捷性； 3、零碎资源管理与零碎的部署扩大必须灵便不便且平滑稳固。 IT168：在国内上是否有相似数见科技数据交融的产品？相比之下有哪些差异化？国外的产品相比国内来讲有哪些借鉴意义？ 陈雷：IBM的 InfoSphere Data Replication、DataStage和Streams、Oracle的Golden Gate和Informatica的PowerExchange和PowerCenter。和这类国外产品相比，DataPipeline有以下几点区别； 第一，从功能性上来讲，IBM和Oracle对各自的数据库的反对毋庸置疑是最好的，但对新兴的数据库特地是国内正在宽泛应用的数据库的反对力度就低了很多，DataPipeline通过自主研发和生态上下游的单干，不仅反对传统的Oracle等关系型数据库，也反对GaussDB、TiDB、巨杉等新兴数据库的实时数据采集。 第二，从部署架构和售卖形式上来讲，传统数据采集和数据处理工作是采纳成对部署、成对售卖的形式，对客户进行高可用部署、零碎扩容都不非常敌对，而DataPipeline是分布式集群部署，在系统资源容许的状况下不限度用户注册数据节点，采纳容器化部署形式，反对Kubernetes，反对动静扩缩容。 IT168：数见科技在做数据交融的过程中，有没有什么让您印象粗浅的故事？比方第一个客户是怎么来的？比方研发过程中如何解决一个比拟大的难题。 陈雷：应该说印象粗浅的事件切实是太多，客户上线的喜悦，排除故障的辛苦，攻克技术难关的成就感，和每个创业者都会经验的压力，但这些其实也都很平时，这些就是一个技术人员的日常。用两句短句总结一下。 但凡过往，皆为序章，十余年沐雨栉风，百万里地北天南，也平时！ ...

ERP表构造的设计--第9篇用日志记录“开源软件”的诞生 赤龙 ERP 开源地址：点亮星标，感激反对，与开发者交换 kzca2000 码云：https://gitee.com/redragon/redragon-erp GitHub：https://github.com/redragon1985/redragon-erp 赤龙ERP官网：https://www.redragon-erp.com 前言上一篇文章说了ERP的零碎设计，数据库构造只是一笔带过，明天重点说说我在【赤龙ERP】的表构造外面的都做了哪些非凡的设计，并且为什么这么设计。 ID与编码我在每一个表简直无一例外的都减少了两个默认的字段，即ID和Code。这两个字段看似都是可标识数据的唯一性字段，但为什么要设计两个呢？它们当然各有用处。 （1）ID是一个表的主键，个别都是自增的，次要用于排序、定位、查问，因为它是数字所以更清晰、速度更快。 （2）Code是惟一键，类型多是字符。可用UUID或雪花算法等生成。当然在有具体业务场景的状况下，能够由用户输出或按逻辑生成。除了能够具备强语义外，还优先用于外键的关联。 这里做个非凡阐明：为什么要用Code做外键，ID也能够做外键啊。外键要具备两个最大的特点：惟一，不可变。ID因为多是自增或由数据库的特质生成，所以不能保障在数据迁徙时相对不变。所以应用Code更安全可靠一些。组织机构这个字段名为：org_code，示意组织机构。那什么是组织机构呢？简略说就是独立的公司或主体。作用次要是用于数据隔离，因为没有必要为不同公司建设不同的数据表，所以用一个字段将不同公司的数据隔离开。有点像财务的账套的概念。 操作记录在每个表都会减少四个字段，用来记录谁在什么工夫做了数据操作。别离为： （1）CREATED_DATE（创立工夫） （2）LAST_UPDATED_DATE（最初批改工夫） （3）CREATED_BY（创建人） （4）LAST_UPDATED_BY（最初批改人） 创建人和创立工夫，在数据新增的时候设置；最初批改人和最初批改工夫，在数据更新的时候设置数据权限信息化零碎都须要数据权限的管制，即什么人能够操作哪些数据。个别企业级信息化，数据权限的逻辑都是在组织架构的层面进行管制的。个别包含：本人操作本人的数据、不同级别部门内的数据可共享、整个公司的数据共享。 为了解决上述的数据权限管制的须要，所以减少一个字段DEPARTMENT_CODE(部门编码)。这个字段只会记录创立以后数据的人所属的部门，即这条数据的所属部门。代码层面再联合数据权限，即可实现数据权限的管控。 版本与日志表在须要记录数据版本的表中减少VERSION（版本号），常见的业务场景就是“变更性能”。上面举个例子，比方：洽购订单变更。当咱们创立了一个洽购订单，并且审批通过后，这个数据实质是不能批改的，但呈现须要批改的时候，咱们就须要用上洽购订单变更性能。当订单变更时，须要做的就是版本号+1，并且在日志表生成历史数据。 自定义字段自定义字段的作用是让用户能够依据本人的业务须要减少一个表的字段并保留数据。做法是须要在一个表中减少attribute字段，少数状况下会预留多个attribute字段，字段名attribute1、attribute2、attribute3以此类推。而后再通过可配置的性能来设置attribute字段和字段中文名的对应关系即可。 心愿您读完本文能够帮忙笔者进入【码云】或【GitHub】搜寻“赤龙ERP”点击星标。期待着您的反对！

摘要：数据库权限管理对大家都很熟悉，然而怎么做好数据库权限管理呢？在本文中将详细介绍 Nebula Graph 的用户管理和权限管理。 本文首发 Nebula Graph 博客：https://nebula-graph.com.cn/posts/access-control-design-code-nebula-graph/数据库权限管理对大家来说都已经很熟悉了。Nebula Graph 本身是一个高性能的海量图数据库，数据库的安全问题更是数据库设计的重中之重。目前 Nebula Graph 已支持基于角色的权限控制功能。在这篇文章中将详细介绍 Nebula Graph 的用户管理和权限管理。 Nebula Graph 架构体系 由上图可知，Nebula Graph的主体架构分为三部分：Computation Layer、Storage Layer 和 Meta Service。Console 、API 和 Web Service 被统称为 Client API。 账户数据和权限数据将被存储在 Meta Engine中，当Query Engine 启动后，将会初始 Meta Client，Query Engine 将通过 Meta Client 与 Meta Service 进行通信。 当用户通过 Client API 连接 Query Engine 时，Query Engine 会通过 Meta Client 查询 Meta Engine 的用户数据，并判断连接账户是否存在，以及密码是否正确。当验证通过后，连接创建成功，用户可以通过这个连接执行数据操作。当用户通过 Client API 发送操作指令后，Query Engine 首先对此指令做语法解析，识别操作类型，通过操作类型、用户角色等信息进行权限判断，如果权限无效，则直接在 Query Engine 阻挡操作，并返回错误信息至 Client API。 在整个权限检查的过程中，Nebula Graph 对 Meta data 进行了缓存，将在以下章节中介绍。 ...