mssql大数据解决方案.docx

mssql大数据解决方案

- 16 -
2020年4月19日
文档仅供参考
mssql大数据解决方案

　　篇一：大数据处理方案
　　篇二：数据库解决方案对比分析
　　数据库解决方案对比分析
　　对于互联网应用，随着访问量的增加，当数据库数据量达到GB以上时将不可避免的面临数据库性能瓶颈的问题，因此在数据存储方案的选择上对应用的性能、后期扩展等方面将会有很大的影响，下面我将从几个角度对当前主流的几款商用数据库和Dbshards + MySql进行对比，为您的选择提供参考。
　　开放性
　　sql server：只能在windows上运行，没有丝毫的开放性，操作系统的系统的稳定对数据库是十分重要的。windows9x系列产品是偏重于桌面应用，nt server只适合中小型企业。而且windows平台的可靠性，安全性和伸缩性是非常有限的。它不象unix那样久经考验，特别是在处理大数据量的关键业务时。
　　Oracle：能在所有主流平台上运行。完全支持所有的工业标准。采用完
　　全开放策略。能够使客户选择最适合的解决方案。对开发商全力支持。db2：能在所有主流平台上运行。最适于海量数据。db2在企业级的应用最为广泛,在全球的500家最大的企业中,几乎85%以上用db2数据库服务器,而国内到97年约占5%.
　　Dbshards + MySql：能在所有主流平台上运行。完全支持所有的工业标准。采用完全开放策略。能够使客户选择最适合的解决方案。对开发商全力支持。 并行性
　　sql server：并行实施和共存模型并不成熟。很难处理日益增多的用户数和数据卷。伸缩性有限。
　　Oracle：平行服务器经过使一组结点共享同一簇中的工作来扩展windownt的能力,提供高可用性和高伸缩性的簇的解决方案。如果windowsnt不能满足需要, 用户能够把数据
　　库移到unix中。
　　db2：db2具有很好的并行性。db2把数据库管理扩充到了并行的、多节点的环境.数据
　　库分区是数据库的一部分，包含自己的数据索引、配置文件、和事务日志。数据库分区有时被称为节点或数据库节点。
　　Dbshards + MySql：Dbshards + MySql具有优秀的并行性。DbShards将数据库拆分为
　　独立子节点，多节点经过Dbshards形成一个透明的数据库集群，任何数据操作都可在独立子节点执行也可多节点并行，每个操作在更小的子节点完成，性能更优。 安全性
　　sql server：没有获得任何安全证书。 oracle：获得最高认证级别的iso标准认证。 db2：获得最高认证级别的iso标准认证。 Dbshards + MySql：GNU宽通用公共许可证
　　性能
　　sql server多用户时性能不佳 oracle：性能最高， 保持windowsnt下的tpc-d和tpc-c的世界记录。 db2：适用于数据仓库和在线事物处理性能较高。 Dbshards + MySql：脱离数据库自身性能限制，经过Dbshards数据拆分技术提高数据
　　I/O性能。
　　客户端支持及应用模式
　　sql server：c/s结构，只支持windows客户，能够用ado,dao,oledb,odbc连接.
　　 db2：跨平台，多层结构，支持odbc,jdbc等客户 Dbshards + MySql：多层次网络计算，支持多种工业标准，能够用odbc,jdbc,oci等网络客户连接

　　操作简便
　　sql server：操作简单,但只有图形界面. Oracle：较复杂, 同时提供gui和命令行，在windowsnt和unix下操作相同 db2：操作简单,同时提供gui和命令行，在windowsnt和unix下操作相同 Dbshards + MySql：操作简单,同时提供gui和命令行，在windowsnt和unix下操作相同
　　使用风险
　　sql server：完全重写的代码，经历了长期的测试，不断延迟，许多功能需要时间来证明。并不十分兼容早期产品。使用需要冒一定风险。
　　Oracle：长时间的开发经验，完全向下兼容。得到广泛的应用。完全没有风险。 db2：在巨型企业得到广泛的应用，向下兼容性好。风险小。 Dbshards + MySql：长时间的开发经验，完全向下兼容。得到广泛的应用。风险小。 可扩展性
　　sql server：sql server版本杂乱，而且微软公司对其旗下产品的升级、兼容策略存在很大隐患，因此sql server扩展性较差。
　　Oracle： Oracle向下兼容，可扩展性强。
　　Dbshards + MySql：Dbshards不是数据库，Dbshards是大数据库拆分工具，当性能出现瓶颈时使用该工具对数据库进行拆分优化从而提升性能，扩展成本低。 成本
　　sql server
　　软件成本：企业版在30-40万左右；作为一款商用数据库软件，存在很多不同的版本，造成使用者在选择时的困惑，并对后期升级造成困难（不同版本互不兼容）； 实施成本：只能在windows平台下进行实施，当应用存在异构环境时，其实施难度将大大提升，甚至会造成额外的实施成本（如为了能在异构环境中安装sql server，需要购买虚拟机软件来安装windows平台），实施局限且成本高；
　　维护成本：sql server作为一款商用软件，其配套的操作工具同样也是商用软件，因此，其产生的并不但仅是数据库自身的成本，还包括了维护数据库所需的工具软件成本；
　　扩展成本：对于互联网应用，特别是云平台集成第三方应用，融合多语言环境是必须面正确情况，而sql server对于第三方和多语言的集成和兼容都需要大量商用软件的支持，因此在平台扩展时同样会造成成本的蔓延。
　　Oracle
　　软件成本：企业版在30-40万左右；
　　实施成本：Oracle
　　维护成本：Oracle是一款庞大而复杂的数据库软件，操作复杂、难度高，其对实施、维护人员的要求非常高，也就造成了实施、维护的人力成本高昂； 作为一款商用软件，其配套的操作工具同样也是商用软件，因此，其产生的并不但仅是数据库自身的成本，还包括了维护数据库所需的工具软件成本；而且维护人员成本高；
　　扩展成本：Oracle按CPU个数进行收费；当性能出现瓶颈需要版本升级或更换、
　　增加硬件时就必须根据CPU数量购买Oracle授权（企业版一颗CPU授权价格在30-40万左右，最普通的一台服务器CPU数量在两颗以上，也就是说每增加一台服务器Oracle成本将至少增加60万以上），成本将成倍增长。
　　db2
　　软件成本：企业版在60-70万左右；
　　实施成本：db2是IBM一款常见于企业应用的数据仓库软件，操作复杂、难度高。
　　其对实施、维护人员的要求非常高，也就造成了实施、维护的人力成本高昂； 维护成本：db2作为一款商用软件，其配套的操作工具同样也是商用软件，因此。
　　其产生的并不但仅是数据库自身的成本，还包括了维护数据库所需的工具软件成本；而且维护人员成本高；
　　扩展成本：IBM在设计db2时专门为其配套一款商用工具PB，因此其在扩展时需要
　　特定专业人才方可实施，有一定局限（中国PB程序员属于小众群体，比较少），扩展成本较高。
　　Dbshards + MySql
　　软件成本： 一套40万；
　　实施成本：dbShards
　　更低； 是一个数据库拆分工具，具有数据库无关性，因此实施成本
　　维护成本：作为一款工具具有友好的操作、管理界面，同时安久具有专业的售后服
　　务团队，维护成本更可控；
　　扩展成本：作为一款工具软件，其主要作用是拆分数据库，提高数据访问性能，并
　　不会随着数据库的增加而增加，这样从整体上降低了扩展的成本。
　　兼容性
　　sql server：面对复杂应用，需要多数据库集成时，集成能力弱。
　　篇三：mysql性能优化解决方案
　　MySQL数据库性能优化
　　Renhao 20XX/11/30
　　1. 资源管理平台数据库
　　 操作系统
　　Red Hat Enterprise Linux Server release
　　ELF 32-bit LSB executable, Intel 80386, version 1 , for GNU/Linux , dynamically linked , for GNU/Linux , stripped
　　32位Linux服务器，单独作为MySQL服务器使用。
　　MySQL
　　系统使用的是，最新的较之老版本有了大幅改进。主要体现在以下几个方面：
　　1）默认存储引擎更改为InnoDB
　　InnoDB作为成熟、高效的事务引擎，当前已经广泛使用，但之前的版本默认引擎均为MyISAM，此次终于将默认数据库存储引擎改为InnoDB，而且引进了Innodb plugin 。此次更新对数据库的好处是显而易见的：InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟。InnoDB Plugin 支持数据压缩存储，节约存储，提高内存命中率，而且支持adaptive flush checkpoint, 能够在某些场合避免数据库出现突发性能瓶颈。
　　Multi Rollback Segments： 原来InnoDB只有一个Segment，同时只支持1023的并发。现已扩充到128个Segments，从而解决了高并发的限制。
　　2）多核性能提升
　　Metadata Locking Framework替换LOCK_open mutex ，使得及过去版本在多核心处理器上的性能瓶颈得到解决。
　　3）制功能加强
　　过去的异步复制方式意味着极端情况下的数据风险，将首次支持半同步在MySQL的高可用方案中将产生更多更加可靠的方案。
　　4增强表分区功能
　　MySQL 的分区更易于使用的增强功能，以及TRUNCATE PARTITION命令都能够为管理和维护数据库节省大量的时间，而且具有更加灵活高效的分区方式。
　　 CPU
　　系统所用CPU是单个4核CPU。对于CPU密集的负载，MySQL一般从更快的CPU中获益，而不是更多CPU。的架构对多CPU的扩展性不好，而且MySQL不能在多个CPU上并行地运行某个查询，因此在对于单个CPU进行密集的查询时，CPU速度限制了响应时间。为了实现低延迟，即快速响应时间，需要快速的CPU，因为单个查询只能使用一个CPU。值得注意的是，在多核心处理器上的性能有了很大的提升。另外，MySQL在64位架构上工作得更好，比32位架构更能有效地使用大量内存。
　　尽管本系统使用的是32位操作系统，CPU运行在32位模式下，但它仍支持64位计算。（cat /proc/cpuinfo | grep flags | grep ' lm ' | wc -l）
　　 磁盘空间
　　系统的磁盘空间当前没有压力。
　　 内存
　　内存总大小为4G，只供操作系统和数据库使用。
　　 数据库的表和文件
　　数据库addb共有339张表：其中InnoDB表303张，MyISAM表34张，MEMORY表2张。
　　InnoDB数据文件ibdata1大小为30138MB，一周后ibdata1大小为30234MB， MyISAM数据文件（包括表结构、索引及数据）总大小约为1642MB，一周后约为1639MB。能够看出，数据库的数据量较稳定，InnoDB数据文件增加了约106MB，总大小一周内没有大的变化。MyISAM表中，值得注意的是表terminalalarm_bak，该表总大小约为1623MB，占整个MyISAM表总大小比重近99%。
　　二进制日志单个文件大小为1GB，二进制日志文件总大小接近20GB。
　　 数据分布情况
　　服务器某时间点非精确值：
　　观察系统中数据量很大且未进行表分区的InnoDB表
　　adrotateresultdetail_fail的数据量达到4千万，createTime列是datatime类型。
　　且有索引，意味着存在以该列为查询条件或关联条件查询的需求，因此能够在该列上以自然月份进行表分区。
　　terminalalarm的数据量也突破千万，AlarmTime列是datatime类型，且有索
　　引，意味着存在以该列为查询条件或关联条件查询的需求，因此能够在该列上以自然月份进行表分区。在事件ev_terminalalarm中会查询该表，若进行表分区，也能一定程度上提高事件的执行效率。
　　terminalalarminfo表仅自增列有索引，主要用于存储数据，可不用分区。 Terminallogin表的loginTime列是datatime类型，且有索引，意味着存在以
　　该列为查询条件或关联条件查询的需求，因此能够在该列上以自然月份进行表分区。
　　adplayinfo_bak表存在多个以INT类型为索引的列，根据实际业务情况选择
　　查询频率高且能以范围值来分区的整型列对该表进行分区。
　　adrotateresultdetail的createTime列是datatime类型，且有索引，意味着存在
　　以该列为查询条件或关联条件查询的需求，因此能够在该列上以自然月份进行表分区。
　　upfile_bak表仅自增列有索引，若存在查询或者统计业务则能够createTime
　　列进行分区，若该表没有查询方面业务可不必进行分区。
　　除去配置参数等属性表，对于数据量大且不断递增的业务数据表，最直接的办法能够按照时间字段进行分区，或是根据查询业务来选择合适的列进行表分区和创立索引，这样能够有效提高存储和查询效率。
　　 服务器配置参数
　　记录查询：普通日志log、慢速日志log_slow_queries
　　MySQL有两种查询日志：普通日志和慢速日志，它们都会记录查询。普通日志记录了服务器接收到的每一个查询，也包含了没有被执行的查询，比如因为错误而未被执行的查询，还有一些非查询事件，比如连接和断开连接，普通日志不包含执行时间或其它只有在查询结束之后才能得到的信息。相反，慢速日志只包含了已经执行过的查询，如果是启动状态，它记录了执行时间超过了特定长度的查询。两种日志都有助于分析，可是慢速日志更有利找到性能较慢的查询。 一个相关配置是log_queries_not_using_indexes，它使服务器把没有使用索引的查询记录到慢速查询日志中，无论它们执行速度有多快。尽管打开慢速日志相对于执行慢速查询来说，一般只增加了很少的时间，可是如果没有使用索引的查询非常快，例如从小数据量表中查询，这样就会记录它们可能导致服务器变慢，甚至还会使用大量的磁盘空间，慢速日志可能就会被那些快速高效的查询塞满。 慢查询日志能够用来找到执行时间长的查询，能够用于优化。慢日志打开后，经过设置long_query_time来配置记录查询超过的指定时间，默认值为10秒，根据系统的负载和性能要求进行设置。
　　检查又长又慢的查询日志会很麻烦，能够使用MySQLdumpslow命令获得日志中显示的查询摘要来处理慢查询日志。系统两种日志都没有开启，能够在需要的时候打开慢速日志来帮助分析性能较慢的查询。具体实施参考MySQL手册。
　　需要注意的是查询在日志中只出现一次并不意味着它是一个不好的查询，也不意味将来也会慢，查询时快是慢有多种原因：
　　1）表可能被锁定，导致查询处于等待状态；
　　2）数据或索引可能没有被缓存在内存中；
　　3）或者正在进行批处理大量的数据，使得磁盘I/O变慢；
　　4）服务器可能同时在运行其它的查询，影响了当前查询的效率。