第1章 实例和故事 试看7 节 | 50分钟
决定电商11大促成败的各个关键因素。
收起列表
视频：1-1 什么决定了电商双11大促的成败 (04:04)试看
视频：1-2 在双11大促中的数据库服务器 (06:03)
视频：1-3 在大促中什么影响了数据库性能 (07:55)
视频：1-4 大表带来的问题 (14:13)
视频：1-5 大事务带来的问题 (17:27)
作业：1-6 【讨论题】在日常工作中如何应对高并发大数据量对数据库性能挑战
作业：1-7 【讨论题】在MySQL中事务的作用是什么？
第2章 什么影响了MySQL性能 试看30 节 | 210分钟
详细介绍影响性能各个因素，包括硬件、 *** 作系统等等。
收起列表
视频：2-1 影响性能的几个方面 (04:08)试看
视频：2-2 CPU资源和可用内存大小 (10:54)
视频：2-3 磁盘的配置和选择 (04:44)
视频：2-4 使用RAID增加传统机器硬盘的性能 (11:30)
视频：2-5 使用固态存储SSD或PCIe卡 (08:35)
视频：2-6 使用网络存储SAN和NAS (07:16)
视频：2-7 总结：服务器硬件对性能的影响 (03:27)
视频：2-8 *** 作系统对性能的影响-MySQL适合的 *** 作系统 (03:50)
视频：2-9 CentOS系统参数优化 (11:43)
视频：2-10 文件系统对性能的影响 (03:29)
视频：2-11 MySQL体系结构 (05:29)
视频：2-12 MySQL常用存储引擎之MyISAM (13:23)
视频：2-13 MySQL常用存储引擎之Innodb (10:44)
视频：2-14 Innodb存储引擎的特性(1) (15:24)
视频：2-15 Innodb存储引擎的特性(2) (08:44)
视频：2-16 MySQL常用存储引擎之CSV (09:19)
视频：2-17 MySQL常用存储引擎之Archive (06:08)
视频：2-18 MySQL常用存储引擎之Memory (10:40)
视频：2-19 MySQL常用存储引擎之Federated (11:21)
视频：2-20 如何选择存储引擎 (04:33)
视频：2-21 MySQL服务器参数介绍 (08:04)
视频：2-22 内存配置相关参数 (09:24)
视频：2-23 IO相关配置参数 (10:01)
视频：2-24 安全相关配置参数 (06:13)
视频：2-25 其它常用配置参数 (03:41)
视频：2-26 数据库设计对性能的影响 (04:36)
视频：2-27 总结 (01:32)
作业：2-28 【讨论题】你会如何配置公司的数据库服务器硬件？
作业：2-29 【讨论题】你认为对数据库性能影响最大的因素是什么
作业：2-30 【讨论题】做为电商的DBA，建议开发选哪种MySQL存储引擎
第3章 MySQL基准测试8 节 | 65分钟
了解基准测试,MySQL基准测试工具介绍及实例演示。
收起列表
视频：3-1 什么是基准测试 (02:20)
视频：3-2 如何进行基准测试 (09:00)
视频：3-3 基准测试演示实例 (11:18)
视频：3-4 Mysql基准测试工具之mysqlslap (13:30)
视频：3-5 Mysql基准测试工具之sysbench (11:07)
视频：3-6 sysbench基准测试演示实例 (17:11)
作业：3-7 【讨论题】MySQL基准测试是否可以体现出业务系统的真实性能
作业：3-8 【实 *** 题】参数不同取值对性能的影响
第4章 MySQL数据库结构优化14 节 | 85分钟
详细介绍数据库结构设计、范式和反范式设计、物理设计等等。
收起列表
视频：4-1 数据库结构优化介绍 (06:52)
视频：4-2 数据库结构设计 (14:49)
视频：4-3 需求分析及逻辑设计 (11:00)
视频：4-4 需求分析及逻辑设计-反范式化设计 (06:44)
视频：4-5 范式化设计和反范式化设计优缺点 (04:06)
视频：4-6 物理设计介绍 (05:17)
视频：4-7 物理设计-数据类型的选择 (18:59)
视频：4-8 物理设计-如何存储日期类型 (13:37)
视频：4-9 物理设计-总结 (02:37)
图文：4-10 说明MyISAM和Innodb存储引擎的5点不同
作业：4-11 【讨论题】判断表结构是否符合第三范式要求?如不满足要如何修改
作业：4-12 【实 *** 题】请设计一个电商订单系统的数据库结构
作业：4-13 【讨论题】以下那个字段适合作为Innodb表的主建使用
作业：4-14 【讨论题】请为下表中的字段选择合适的数据类型
第5章 MySQL高可用架构设计 试看24 节 | 249分钟
详细介绍二进制日志及其对复制的影响、GTID的复制、MMM、MHA等等。
收起列表
视频：5-1 mysql复制功能介绍 (04:58)
视频：5-2 mysql二进制日志 (22:05)
视频：5-3 mysql二进制日志格式对复制的影响 (09:37)
视频：5-4 mysql复制工作方式 (03:08)
视频：5-5 基于日志点的复制 (20:06)
视频：5-6 基于GTID的复制 (22:32)
视频：5-7 MySQL复制拓扑 (13:58)
视频：5-8 MySQL复制性能优化 (09:23)
视频：5-9 MySQL复制常见问题处理 (08:31)
视频：5-10 什么是高可用架构 (14:09)
视频：5-11 MMM架构介绍 (08:09)
视频：5-12 MMM架构实例演示（上） (09:16)试看
视频：5-13 MMM架构实例演示（下） (18:55)
视频：5-14 MMM架构的优缺点 (08:01)
视频：5-15 MHA架构介绍 (10:02)
视频：5-16 MHA架构实例演示(1) (13:11)
视频：5-17 MHA架构实例演示(2) (16:54)
视频：5-18 MHA架构优缺点 (05:14)
视频：5-19 读写分离和负载均衡介绍 (11:42)
视频：5-20 MaxScale实例演示 (18:25)
作业：5-21 【讨论题】MySQL主从复制为什么会有延迟，延迟又是如何产生
作业：5-22 【实 *** 题】请为某互联网项目设计99.99%MySQL架构
作业：5-23 【讨论题】如何给一个已经存在的主从复制集群新增一个从节点
作业：5-24 【讨论题】给你三台数据库服务器，你如何设计它的高可用架构
第6章 数据库索引优化8 节 | 65分钟
介绍BTree索引和Hash索引，详细介绍索引的优化策略等等。
收起列表
视频：6-1 Btree索引和Hash索引 (20:09)
视频：6-2 安装演示数据库 (01:19)
视频：6-3 索引优化策略（上） (17:33)
视频：6-4 索引优化策略（中） (13:02)
视频：6-5 索引优化策略（下） (12:30)
作业：6-6 【讨论题】一列上建立了索引，查询时就一定会用到这个索引吗
作业：6-7 【讨论题】在定义联合索引时为什么需要注意联合索引中的顺序
作业：6-8 【实 *** 题】SQL建立索引，你会考虑那些因素
第7章 SQL查询优化9 节 | 62分钟
详细介绍慢查询日志及示例演示,MySQL查询优化器介绍及特定SQL的查询优化等。
收起列表
视频：7-1 获取有性能问题SQL的三种方法 (05:14)
视频：7-2 慢查询日志介绍 (08:57)
视频：7-3 慢查询日志实例 (08:27)
视频：7-4 实时获取性能问题SQL (02:21)
视频：7-5 SQL的解析预处理及生成执行计划 (16:02)
视频：7-6 如何确定查询处理各个阶段所消耗的时间 (09:35)
视频：7-7 特定SQL的查询优化 (10:34)
作业：7-8 【讨论题】如何跟据需要对一个大表中的数据进行删除或更新
作业：7-9 【讨论题】如何获取需要优化的SQL查询
第8章 数据库的分库分表5 节 | 48分钟
详细介绍数据库分库分表的实现原理及演示案例等。
收起列表
视频：8-1 数据库分库分表的几种方式 (04:34)
视频：8-2 数据库分片前的准备 (13:53)
视频：8-3 数据库分片演示(上) (11:40)
视频：8-4 数据库分片演示(下) (17:02)
作业：8-5 【讨论题】对于大表来说我们一定要进行分库分表吗
第9章 数据库监控7 节 | 29分钟
介绍数据库可用性监控、性能监控、MySQL主从复制监控等
收起列表
视频：9-1 数据库监控介绍 (04:46)
视频：9-2 数据库可用性监控 (07:20)
视频：9-3 数据库性能监控 (09:39)
视频：9-4 MySQL主从复制监控 (06:16)
作业：9-5 【讨论题】QPS是否可以真实的反映出数据库的负载情况
作业：9-6 【讨论题】如何正确评估数据库的当前负载状况
作业：9-7 【实 *** 题】开发一个简单监控脚本，监控mySQL数据库阻塞情况
如何选择数据库
柳树
公众号：柳树的絮叨叨
关注他
30 人赞同了该文章
我们正在做一个电子书小程序。
1.0 层次模型数据库
用户购买，生成订单，订单详情里有用户购买的电子书：
一层一层铺开，一对多，这是「层次模型数据库」（Hierarchical Database）。
2.0 网状模型数据库
一笔订单可以购买多本电子书，一本电子书也可以被多笔订单购买：
这就形成了「多对多」的「网状模型数据库」（Network Database）。
上面讲的两种数据库，也许你听都没听过。
我们用的，是「关系模型」，而非上面的「层次模型」或者「网状模型」。
为什么？
你会说，这样不方便遍历所有订单。
并不会，再加一个根节点就好：
你会说，这样查找效率很低。
也不会，因为可以优化下数据结构，比如换成 B+ 树。
为什么我们从一开始就在用「关系模型数据库」？
3.0 关系模型数据库
无论是层次模型还是网状模型，程序员看到的，都是实实在在的物理存储结构。
查询时，你要照着里面的数据结构，用对应的算法来查；
插入时，你也要照着数据结构，用对应算法来插入，否则你就破坏了数据的组织结构，数据也就坏掉了。
因为我们都没用过前面两种数据库，所以觉得「关系模型数据库」（以下简称 RDB）的一切都理所当然，但其实，它做出了一个革命性的变革：
用逻辑结构（logical representation of data）代替物理结构（physical representation of data）
所谓「逻辑结构」，也就是我们经常看到的「表格」，User 是一张表格，Order 是一张表格，Book 又是一张表格，它们之间的关系，用 id 来关联，这些 id，可能是 number 类型，也可能是 string 类型
但你看到的，不一定就是实际的，你看到的只是让你方便理解的「逻辑结构」，真实数据自然不是这样按表格来存储，表格无异于一个数组，数组查询是很慢的。
真实的「物理结构」，也许还是像「层次模型」和「网状模型」一样，是复杂的数据结构。
但到底是怎样的数据结构，你都无需关心，你只需把它想象成一张「表」去 *** 作，就连可视化工具，都会帮你把数据可视化成表，来方便你理解。
这个观念的提出，来自于 1970 年 Codd 的一篇论文，A Relational Model of Data for Large Shared Data Banks：
Future users of large data banks must be protected from having to know how the data is organized in the machine (the internal representation).
Activities of users at terminals and most application programs should remain unaffected when the internal representation of data is changed and even when some aspects of the external representation are changed.
—— Codd
Codd 的这种思想，其实就是经济学里提到的：分工产生效能。
程序员们不需要直接和物理结构打交道，只负责告诉数据库，他想做什么，至于数据是如何存储、如何索引，都交给数据库，最终他们看到的就是一张张特别直观、特别好理解的 excel 表格。
而数据库则把维护物理结构的复杂逻辑，交给了自己， 对程序员屏蔽了复杂的实现细节。
开发时写的代码少了，耦合性降低了，数据也不容易损坏，也就提高了生产效率（productive）。
一切能用同样的耗能，带来更多效能的技术，都会被广泛使用。
NoSQL
那后来为什么又有了 NoSQL 呢？
在 RDB 被发明的时代，软件多用于大型企业，比如银行、金融等等，人们对数据的要求非常纯粹：准确、可靠、安全，让数据按照期望，正确的写入，不要给老子算错钱就好，于是有了具有 ACID 特性的事务：原子性、一致性、隔离性和持久性。
那时候用网络的人很少，通过终端来访问客户端的人，更少，自然的，数据库的数据量和访问量都跟现在没法比，一台机器，足矣，最多再来个一主多从：
后来，你知道的，每个人手里都有个手机，每分每秒，都有成千上万的数据，写入你的数据库、从你的数据库被查出，于是有了「分布式」，有了 BASE 和 CAP。这时候，RDB 就会发现，自己之前的那一套 ACID，竟然有点作茧自缚了：
为了保证事务的隔离性，要进行加锁，在分布式的环境下，就要对多台机器的数据进行加锁；
为了保证事务的原子性，在机器 A 的 *** 作和在机器 B 的 *** 作，要么一起成功，要么一起失败；
…...
这些都要去不同节点的机器进行通讯和协调，实现起来非常复杂，而且要付出更多的网络 IO，影响性能。
ACID 在分布式系统上实现起来就会变得难以实现，即使实现了，也要付出很大的性能成本，于是才有了后来的各种「分布式一致性协议」，Paxos、Raft、2PC …… 而 Mysql 也提供了各种方案来实现分布式，当然，这些方案自然是很复杂的，比如 「NDB Cluster」 ：
而 NoSQL 则没有这么多承诺，它的一致性，一般都是最终一致性，当然你可以选择强一致，那自然就要付出点性能作为代价，当然你还可以弱一致，这样会更不安全，但是更快，一切取决于你对数据的要求。
除此之外，RDB 的「数据库范式」（Database Schema），也成了限制扩展性的瓶颈。为了避免数据冗余导致的各种问题（占用空间、删除异常、更新异常等等），我们在设计关系模型时，通常都是按照最小单位来设计的。
什么叫最小单位，比如用户有地址和爱好，那么在正确设计的关系模型（比如 3NF）里，这就是三张表：
如果这三张表被分散在不同的机器，那进行关联查询时，就需要多次跨机器的通讯；
而对于 NoSQL，这三类信息，都可以利用 Json 格式的数据，将它们存放在一起：
完整的存储进去，完整的取出来，不需要额外的 *** 作。
NoSQL 比 RDB 有更强的扩展性，可以充分利用分布式系统来提升读写性能和可靠性。
这不是谁设计好坏的问题，而是跟他们要解决的问题有关：RDB 诞生于互联网萌芽的时代，那时数据的准确、可靠是最重要的，而 NoSQL 诞生于互联网快速发展普及的时代，大数据、分布式、扩展性成了数据库的另一个重要特性。
总结一下：
RDB 首先得是准确、可靠，然后才向更高的「可拓展性」发展；
而 NoSQL 生而分布式，可拓展性强，然后才向更高的「准确性」发展。
NoSQL ，not only SQL，其实就是对那种打破了 RDB 严格事务和关系模型约束的那些数据库的泛指，而随着要解决的问题的不同，又诞生了各种各样的 NoSQL。
首先是「列式数据库」（Column-oriented DBMS），数据量上去了，我们想分析网站用户的年龄分布，简单说，就是你需要对同一个特征进行大数据量的分析统计，于是把原来 RDB 的「按行存储」的范式打破，变成了「按列存储」，比如 HBase；
然后你发现有些数据变动不是很大，但是经常需要被查询， 查询时还要关联很多张表，于是你把这些来自不同表的数据，揉成一个大对象，按 key-value 的格式存起来，比如 Redis；
再后来你需要对博客内容进行相关性搜索，传统 RDB 不支持相关性搜索，最重要的，还是扩展性差，增加机器的带来边际效益有限，于是有了「全文搜索引擎」，比如 Elasticsearch；
除此之外，还有「文档数据库」、「图形数据库」……
没有一种数据库是银d。
总结
这篇文章的题目是「如何选择数据库」，这是困扰很多人的问题，那么多数据库，到底要选什么好？
可是当你问出这样一个问题时，其实你是在问一种「手段」。我现在要做这样一个需求，用什么数据库可以帮我实现它？
但其实你需要的不只是一种「手段」，因为如果对方甩给你一个冷冰冰的名字，Mysql、Elasticsearch、MongoDB，你肯定会问，凭什么？
你需要的，是一种「解决方案」。如果你需要数据十分严格准确，分毫不差，那我会推荐你采用「事务」和「关系模型」来处理数据；如果你需要数据能够被大量读取和写入，那我会推荐你扩展性强的「分布式」；如果你的数据经常是整个读取、整个更新的，那「关系模型」就没有「文档模型」适合你。
「事务」、「关系模型」、「分布式」、「文档模型」等等，这些就是「解决方案」，知道用什么「解决方案」，用哪个数据库，自然水到渠成。
正如一位大牛说的：
设计实践中，要基于需求、业务驱动架构。无论选用 RDB/NoSQL，一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计。用户不会因为你用了 Mysql 或者 MongoDB 而使用你的软件，毕竟绝大多数用户都不知道 Mysql 和 MongoDB 是什么玩意。
现在学习软件开发还是有一定的难度的，当然，不管你学习什么知识都会有一定的难度，主要看你有没有相关的基础，个人的学习能力如何。不过，零基础的学员也不要担心，现在很多培训班都是针对0基础的学员设计的课程，都针对不同应用行业，不同语言做定向培训。所以，难不难也要因人而异。
就拿国内从业比较广泛的Java开发工程师来讲，高中毕业生都可以做。既然高中生都能从事于Java开发，说明软件开发实际上并没有我们想的那么难，毕竟目前所学的软件技术并不是做科研。
想要让软件开发变得简单，我们需选择一门容易上手的编程语言。从国内软件行业来看，目前Java的开发者数量还是相当庞大的，而且可从事的领域也比较广。当然，我并不是在这里劝你学习java，而是让自己选择适合的编程语言，并知道自己使用的编程语言能做什么，用在哪些地方。
对于零基础想学java的人，千万不要害怕，不要觉得没基础就学得很吃力，学不会等等。
刚开始零基础入门的学习进度是很慢的，不用着急，慢工才能出细活，说白了Java入门阶段也就是个熟练的过程花费的学习时间比较长。不可否认，大家在开始接受新事物的时候都会陷入困境的。
学习是循序渐进的，零基础入门Java到底难不难，只有自己接触到课程才知道。当然，没接触之前学起来可能会觉得有点难，但是当你入门后你就会发现越来越有趣了，不光是学习java语言，其他语言也一样。
记住，软件开发需要有一定的基础，但是并没有特别高的门槛，只要具备有一定的英文和数学基础（初高中水平就好了），就可以学软件开发，尤其是编程语言的使用，因此对于软件开发而言，只要能够长期坚持下去，并且多多从事实际项目的开发，就可以积累经验，达到一个比较高的水平，所以软件开发并不难学，只要坚持，就可以有所成就。
至于零基础学java所用的时间，我以培训时间为标准，大学生一般的学习时间是5-6个月，高中生确在两年左右。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）