mssql大数据解决专项方案.docx

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类型为索引列，依据实际业务情况选择
　　查询频率高且能以范围值来分区整型列对该表进行分区。
　　adrotateresultdetailcreateTime列是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）服务器可能同时在运行其它查询，影响了目前查询效率。