国内优秀网站设计,怎样在网上建网站做电商生意,2024新冠又来了吗,动画设计师月薪多少我们做管理软件的#xff0c;主要核心就在数据存储管理上。所以数据库设计是我们的重中之重。为了让我们的管理软件能够稳定、可扩展、性能优秀、可跟踪排错、可升级部署、可插件运行#xff0c;我们往往研发自己的管理软件开发平台。我们总是希望去学习别人的开发平台#…我们做管理软件的主要核心就在数据存储管理上。所以数据库设计是我们的重中之重。为了让我们的管理软件能够稳定、可扩展、性能优秀、可跟踪排错、可升级部署、可插件运行我们往往研发自己的管理软件开发平台。我们总是希望去学习别人的开发平台如用友或金蝶或SAP但我们却总是感叹管理软件业务处理细节繁多而数据库管理软件却简单的SELECT、INSERT、DELETE、UPDATE四个命令就搞定。我们多希望有一天能做出一个架构也可以这么简单就搞定管理软件。我们往往研究别人的架构却忘记了我们身边我们最熟悉的数据库的架构。所以今天我想带领大家一起剖析一下数据库的架构来探索数据库的架构思想。而我本人呢只熟悉SQLSERVER这一种数据库产品所以我就拿SQLSERVER来分析。 在讲SQLSERVER内部原理的之前我觉得非常有必要向大家介绍一下SQLSERVER的历史。让我们站在1999年看看计算机数据库业界到底处于什么状态。 1999年Oracle已经于1998年9月发布了Oracle 8i可能中文版在1999年才来到中国。Oracle 8i支持用JAVA编写存储过程支持XML支持Linux。1999年1月SQLSERVER7正式发布。SQLSERVER7重构了整个数据库引擎相当于重写了SQLSERVER。SQLSERVER第一次完整性的支持了行锁有没有搞错过去人是怎么使用数据库产品的。1988年Oracle6就支持行锁。另外1988年Oracle就开始研发ERP产品。谁说Oracle是ERP门外汉可以参考这个。 看看他们俩的前一个版本。如果你入行比较晚2000年以后可能对以下文字更感到惊讶。 1992年Oracle7发布。有了存储过程、触发器、引用完整性校验、分布式事务处理。天哪Oracle7才有了这些东西。1995年SQLSERVER6发布。SQLSERVER6是微软真正意义上的第一个数据库产品真是爆料大家没想到SQLSERVER6才是微软第一个数据库产品那版本6之前的5、4、3、2、1是怎么度过的。因为1994年微软和Sybase掰了Sybase是第一个运行于PC上的C/S数据库产品。微软为了进入数据库产品领域自己又没有经验于是和Sybase一起合作当时微软是全世界第一大软件公司微软1986年上市。Sybase有产品缺钱。微软缺产品有钱。于是一拍即合。直到1994年微软也不需要Sybase了已经学会了数据库技术Sybase也感觉微软太狼子野心于是合作分裂。微软开始自己做自己的数据库。 历史说完。我们言归正传。很多入门级做管理软件的SQL语句玩的熟练从子查询到Having到交叉表统计SQL都能做出来甚至存储过程能写2000多行游标、自定义函数、触发器、约束用的眼花缭乱。再入点门在SQL查询器中可以使用SQL分析优化索引用SQL Profile可以跟踪SQL甚至在性能查看器中监测SQLSERVER内存、CPU、线程、I/O的运行状态甚至为自己会使用DBCC而沾沾自喜。 你是如此熟悉SQLSERVER又是对SQLSERVER如此陌生。 我今天就用架构的角度来给大家分析一下SQLSERVER架构和原理。短短一篇博文肯定只能面上的多一些深一层的可能需要连载数篇文章甚至一块大砖头书才能讲完整。不过我希望我的博文能够抛砖引玉使大家能从一个过去没有想过的角度去看SQLSERVER。 SQLSERVER作为一个数据库产品我个人认为最重要的就是两大块存储引擎和查询引擎。 其他的日志、事务、锁、索引等等都是围绕他们来工作的。 SQLSERVER是C/S产品所以一条SQL语句要让SQLSERVER执行必须要传输到SQLSERVER服务器端。传输我们当然知道需要NetBEUI、TCP/IP等等网络传输协议。但是光有这些还不行。客户端如何发服务器端如何收如何确认发的和收的正确完整如何确实发的和收的已经结束如何发和收能跨越各种网络协议如UNIX和WINDOWS和NOVELL通讯如何保证数据安全校验如何保证数据收发是同步还是异步就需要在网络传输协议之上再构造一层协议。SQLSERVER既支持IPC机制也支持RPC机制。你想想你的管理软件开发平台是否有这一层。当然现在的消息服务器已经专业的提供了这一机理可靠的、安全的、高效的、异步的、消息压缩、消息拆分、智能路由、集群跨越不同的操作系统、不同的编程语言、不同的通讯协议、不同的硬件平台的消息数据传输。可能你过去不了解消息中间件通过这一案例可以知道消息中间件的用途。 SQL语句被可靠无误的发送到了服务器端SQLSERVER引擎中第一个模块就来接待这个SQL数据。这个模块的名字叫Open Data Services。它监听新的连接清除失败连接将结果集、消息和状态返回给客户端。 SQLSERVER客户端和服务器端之间传输数据数据包是有格式的。在SQLSERVER中被称为tabular data stream。这个数据流是令牌控制客户端和服务器端对话否则客户端说了N句话服务器端返回N句话没有令牌就混在一起了不知道哪个回答是对应哪个请求的。我们往往不能直接和Open Data Services打交道把数据放进来。而是我们必须通过ODBC、ADO或DB-Library来发送tabular data stream。而SQLSERVER返回的数据结果也是通过这些ODBC之类发回tabular data stream。你看看SQLSERVER设计的多巧妙一个通用数据访问接口屏蔽了你和SQLSERVER之间就如同WINDOWS API屏蔽了内核让你无法访问就如同DirectX屏蔽了UI和外设的操控。 SQL语句-ODBC-编码成tabular data stream-IPC或RPC-网络协议-IPC或RPC-解码tabular data stream-ODBC-Open Data Services。 Open Data Services监测客户端连接。如果并发太多它会创建连接如果服务完它会自己维护连接归入池中。在池中保留一段生命期它会自己释放连接。如果有的客户端连接中途突然断掉如客户端重启了它在侦听后无回应它也会自己整理自己的连接的。我们在SQLSERVER线程中看到的连接就是Open Data Services创建的。 Open Data Services有了连接可能是创建的可能是从池里拿出来的池化、创建、销毁都是非常讲究技能的。池化多少上下文资源如何保留池化多长时间什么时候该销毁调度不当就会严重消耗资源就把SQL接住。这时是接到了Open Data Services的读缓冲区里面。这个缓冲区为高性能处理数据的SQLSERVER带来一丝喘息机会而就这一丝喘息机会让SQLSERVER可以游刃有余你的设计有吗。而Open Data Services有一个写缓冲区。SQLSERVER把检索到的数据检索出来就立即放进写缓冲区写缓冲区一满就立即被Open Data Service发走。当我过去研究SQLSERVER原理的时候我常常赞叹一个小小的SQLSERVER外围模块都设计如此精妙实在让人佩服。我们经常在追求海量数据存储和Cache架构我们却无视我们手边的SQLSERVER。 SQL语句放到读缓冲区SQLSERVER的关系引擎就开始工作了。它总是在侦听这个读缓冲区。 SQL语句遇到的关系引擎的第一个模块就是命令分析器。我们在SQL查询分析器中看到的查询分析结果就是它的输出杰作。它来构造查询树。首先是将你的SQL语句规范化你想想你写的软件代码输入数据来了什么都不管就直接处理连输入数据校验都没有怎能稳定否则以后的步骤将不好操作如果你的SQL语句有语法错误这个查询树的构造就无法完成于是中断。而要规范一个SQL语句首先要从SQL语法库中抽取SQLSERVER现有支持的各种语法和函数。 一旦构造成功关系引擎的第二个模块就是命令优化器来裁剪这棵树。一个SQL语句可以生成多种执行和优化的方案如果你使用过那种SQL优化工具的话你就能理解SQLSERVER会选择最节省内存、CPU利用率、I/O次数I/O是性能优化最要命的地方往往性能就瓶颈在I/O上的那一种方案。优化器会根据每张表的数据统计有时候你为了性能优化必须定时期同步更新一下统计否则优化就会有误差。而且优化器也会根据查询树去选择合适的索引如果使用索引代价大它会自动选择全表扫描优化器也会根据查询树知道先取哪些表的数据然后再内存中如何合并数据以得到你想要的结果有时候想想优化器真伟大你一个SQL过去它需要在极短的时间内做多少事啊为了能在极短时间内确定一个相对优化的方案它也不可能穷举所有可能的方案所以我们做海量数据优化的时候往往评估多种方案然后修改自己的SQL语句以符合产生最优的方案。 规范化、优化完SQL语句就要产生执行计划了。SQL管理器负责执行计划的产生。因为你发过来的SQL语句可能是一个SELECT也可能是一个INSERT或UPDATE。即使SELECT也面临着用户权限的限制你如果设置过某一个SQLSERVER用户的对象权限和列权限你就会明白。而INSERT之类更新语句又会涉及到权限、默认值、约束、表达式、主外键、触发器。一个优化完的SQL具体要真正让SQLSERVER从内存或硬盘上把数据找出来或者更新回去需要很多细节的步骤。 查询执行器来负责SQL的执行。因为SQL的执行要涉及到事务、锁、等待、CPU调度内存页失效影响、I/O存取影响所以查询执行器会协调很多其他模块但各个模块来负责处理而查询执行器并不真正全部包办否则让事务管理器、锁管理器、索引管理器、页面文件管理器、缓冲管理器、行管理器、日志管理器干吗去。 查询执行器是查询引擎的最后一个模块接下来的模块都属于存储引擎的范畴。所以从上看查询引擎最主要是构造SQL查询树、优化裁剪SQL查询树根据查询树产生执行计划然后协调执行查询树把结果返回去。 而真正要把数据取出来或存进去就需要存储引擎来工作了。 首先根据执行计划要存取哪些数据页和索引页。这就是访问方法管理器access methods manager要做的事情。但其实真要打开这些页还不是访问方法管理器自己要亲手干的。 亲手干这个活的是一个叫“缓冲区管理器”的模块。因为在硬盘上的数据是不可能计算处理的必须要在内存中才能让CPU来计算。所以要存取那些数据页和索引页就通知让缓冲区管理器来做。如果数据没有在内存中就让缓冲区管理器来读入如果数据已经在内存中了缓冲区管理器只有返回即可。这个过程是被缓冲区管理器来屏蔽的对于访问方法管理器是透明的。大家可不要以为访问方法管理器啥事不做只是一个发布调度命令的。这可错怪了它。因为SQLSERVER要保证高速处理必须预先预测好哪些数据页和索引页要处理。不能人家缓冲管理器已经处理完你访问方法管理器才计算下一步将要处理的页面。要知道这些管理器可是不分哪个用户来处理的。如果接受来自100多个并发的用户发来各种各样的数据处理请求你怎么能预测到哪些数据页和索引页要处理呢这就需要一个统一的调度。而且这个统一的调度也影响着缓冲区管理器。你不能请求一个大数据缓冲区管理器这才火烧屁股才扩大缓冲区然后装载数据那样流水线就停下了。缓冲区管理器必须预先知道将在不久要有一个大数据所以在并行运算的时候就有独立线程来扩展了缓冲区。因为扩大缓冲区还和操作系统有关。你要扩大缓冲区正好遇到WINDOWS页面失效就涉及到你的虚拟文件的变化。而页面失效又会影响CPU和I/O。所以页面失效是一个性能影响很大的问题。而提高命中率是我们性能优化一直努力的重点。如果数据长时间不用缓冲区管理器就要让这块内存数据过期可以被新的数据覆盖。否则缓冲区老加载不卸载也不行。再说有些数据已经被更新了你数据老化了不重新读入你的数据就引起读错误了。 我们知道数据页包含数据行。索引页包含索引行。数据行就由行管理器来控制。而索引行由索引管理器来负责。 而单行上的检索、修改、执行又被事务管理器和锁管理器影响着。事务有显性事务和隐性事务两种。而锁又有共享锁、排它锁、更新锁、意向锁。而锁还分为行锁、页锁、表锁、数据库锁。而锁又有死锁的可能性。锁的不同加上事务的影响这个行是否能读、能修改能怎样的读读一致还是脏读是等待事务和锁还是可以进行就受了很多影响。因为一张数据页上放的行是有限的尤其还有填充度的影响如填充度为80%就这个数据页面只能填充80%就必须分页以防以后有数据插入的时候就非常影响数据插页这也是性能影响比较大尤其在插入数据比较多的情况下。SQLSERVER的一张数据页默认是64K除去填充度和数据头也没有多少可存储的数据了。这就是为了关系型数据库都劝阻大家要小表大数据。也就是说列要少列要短频繁访问的列要在前。数据可以海量。如果行长了你想要检索和更新多少数据页这需要多少页面调度面临着页面失效和锁机制的影响。而且大文本和可变行都是指针存储需要跳转查找更浪费了不少时间。 而索引管理器最主要在维护着索引B树。没有索引页我们就要做全表扫描了那需要载入多少数据页而且还要逐行扫描如果遇上事务和更新锁就更有问题。所以索引是非常重要的。而一个表可以建立很多索引。索引能直接找到所需要的行而无须全表扫描。但是你的索引如果仅仅是男女或者你的索引涉及到可变行都对索引不利。索引不宜建立多。否则维护索引页的成本和消耗也非常多。索引页更要涉及到插页、拆页频繁改动涉及到索引的字段会让索引页剧烈变动尤其数据量越大影响越大。我就不在这里讲解如何利用索引优化SQL了否则一本书也讲不完。 数据不断存取数据不断被维护载入内存或从内存中写入硬盘。其实都是惰性写入器在照顾。惰性写入器来定期扫描老化数据让硬盘和内存中的数据是一致的。有这个惰性写入器就有了内存和硬盘的差异时间窗。就有可能出现异常。一旦服务器突然断电没有来得及写会磁盘的怎么办。也也涉及到另一个模块日志管理器。日志管理器利用检查点的机制维护着日志文件。在服务器重新启动的时候重写载入日志来把数据恢复到一致性。写日志当然要比写数据要容易的多快的多。因为写数据要操控内存和硬盘还要注意权限、锁、事务所以突然断电你还没反应就来不及了。所以日志这种轻量级的方法就可以在恢复一致性上有很好的帮助当然也丢失数据。日志页也没来得及写入硬盘。 讲到这里就剩下事务管理器、锁管理器。这两个管理器和显性事务、隐性事务、显性锁、隐性锁、事务隔离级别、锁级别、行管理器、索引管理器都有很多关系。微软有WINDOWS优势又有Jim Gray这样的巨师坐镇Jim Gray是图灵奖获得者就是此爷提出了数据库事务这一概念。盖茨为了让此爷为微软工作而此爷不喜欢雷德蒙天天下雨的天气于是在加州阳光中给此爷单独建了一座研究院。所以在性能上我个人认为SQLSERVER的性能是非常优秀的你想想一个数据库产品的性能受什么方面的影响。至于业界老称SQLSERVER无法管理海量数据性能不佳我个人感觉都是业界在以讹传讹。而尤其中国内地IT业界大部分都是入门级在跟帖嘈杂尤其还有一批更不懂技术的媒体记者或写手。 如果真要去说SQLSERVER不行大型海量数据管理必须用某某数据库产品我建议从内部原理、内部架构、内部实现三个层次诸多方面来剖析到底在不在理。 最后就是I/O管理器了。我一直不认同SQLSERVER内核中有I/O管理器。因为SQLSERVER使用的是和WINDOWS同样的页面调度和页面分配方法。何必要自己另创一套呢。就如同SQLSERVER把页面、硬盘、内存、线程、CPU交给了WINDOWS一样。SQLSERVER作为WINDOWS上的一个应用软件应该和WINDOWS上的其他软件一样被WINDOWS管理。SQLSERVER又不跨平台无须自己管理。 除了SQLSERVER这些内核涉及精妙以外SQLSERVER的外围工具也设计的相当好。如SQLSERVER的用户安全性管理方法、对象分类表、列、约束、默认、索引、触发器、存储过程、视图、主键、对象权限方法、元数据自管理方法、SQL语言、SQL查询分析器、SQL跟踪器、SQL性能分析器、SQL数据库master/msdb/tempdb/model。 想一想你的管理软件平台有这些架构思想吗 转载于:https://www.cnblogs.com/javait03/archive/2008/04/05/2403766.html
