最新mssql大数据解决方案.docx
《最新mssql大数据解决方案.docx》由会员分享，可在线阅读，更多相关《最新mssql大数据解决方案.docx（8页珍藏版）》请在冰豆网上搜索。
最新mssql大数据解决方案
mssql大数据解决方案
mssql大数据解决方案
篇一：
大数据处理方案
篇二：
数据库解决方案比照分析
数据库解决方案比照分析
对于互联网应用，随着访问量的增加，当数据库数据量到达GB以上时将不可防止的面临数据库性能瓶颈的问题，因此在数据存储方案的选择上对应用的性能、后期扩展等方面将会有很大的影响，下面我将从几个角度对目前主流的几款商用数据库和Dbshards+MySql进行比照，为您的选择提供参考。
开放性
sqlserver：
只能在windows上运行，没有丝毫的开放性，操作系统的系统的稳定对数据库是十分重要的。
windows9x系列产品是偏重于桌面应用，ntserver只适合中小型企业。
而且windows平台的可靠性，平安性和伸缩性是非常有限的。
它不象unix那样久经考验，尤其是在处理大数据量的关键业务时。
Oracle：
能在所有主流平台上运行。
完全支持所有的工业标准。
采用完
全开放策略。
可以使客户选择最适合的解决方案。
对开发商全力支持。
db2：
能在所有主流平台上运行。
最适于海量数据。
db2在企业级的应用最为广泛,在全球的500家最大的企业中,几乎85%以上用db2数据库效劳器,而国内到97年约占5%.
Dbshards+MySql：
能在所有主流平台上运行。
完全支持所有的工业标准。
采用完全开放策略。
可以使客户选择最适合的解决方案。
对开发商全力支持。
并行性
sqlserver：
并行实施和共存模型并不成熟。
很难处理日益增多的用户数和数据卷。
伸缩性有限。
Oracle：
平行效劳器通过使一组结点共享同一簇中的工作来扩展windownt的能力,提供高可用性和高伸缩性的簇的解决方案。
如果windowsnt不能满足需要,用户可以把数据
库移到unix中。
db2：
db2具有很好的并行性。
db2把数据库管理扩充到了并行的、多节点的环境.数据
库分区是数据库的一局部，包含自己的数据、索引、配置文件、和事务日志。
数据库分区有时被称为节点或数据库节点。
Dbshards+MySql：
Dbshards+MySql具有优秀的并行性。
DbShards将数据库拆分为
独立子节点，多节点通过Dbshards形成一个透明的数据库集群，任何数据操作都可在独立子节点执行也可多节点并行，每个操作在更小的子节点完成，性能更优。
平安性
同
使用风险
sqlserver：
完全重写的代码，经历了长期的测试，不断延迟，许多功能需要时间来证明。
并不十分兼容早期产品。
使用需要冒一定风险。
Oracle：
长时间的开发经验，完全向下兼容。
得到广泛的应用。
完全没有风险。
db2：
在巨型企业得到广泛的应用，向下兼容性好。
风险小。
Dbshards+MySql：
长时间的开发经验，完全向下兼容。
得到广泛的应用。
风险小。
可扩展性
sqlserver：
sqlserver版本杂乱，并且微软公司对其旗下产品的升级、兼容策略存在很大隐患，因此sqlserver扩展性较差。
Oracle：
Oracle向下兼容，可扩展性强。
Dbshards+MySql：
Dbshards不是数据库，Dbshards是大数据库拆分工具，当性能出现瓶颈时使用该工具对数据库进行拆分优化从而提升性能，扩展本钱低。
本钱
sqlserver
软件本钱：
企业版在30-40万左右；作为一款商用数据库软件，存在很多不同的版本，造成使用者在选择时的困惑，并对后期升级造成困难〔不同版本互不兼容〕；实施本钱：
只能在windows平台下进行实施，当应用存在异构环境时，其实施难度将大大提升，甚至会造成额外的实施本钱〔如为了能在异构环境中安装sqlserver，需要购置虚拟机软件来安装windows平台〕，实施局限且本钱高；
维护本钱：
sqlserver作为一款商用软件，其配套的操作工具同样也是商用软件，因此，其产生的并不仅仅是数据库自身的本钱，还包括了维护数据库所需的工具软件本钱；
扩展本钱：
对于互联网应用，尤其是云平台集成第三方应用，融合多语言环境是必须面对的情况，而sqlserver对于第三方和多语言的集成和兼容都需要大量商用软件的支持，因此在平台扩展时同样会造成本钱的蔓延。
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
更低；是一个数据库拆分工具，具有数据库无关性，因此实施本钱
维护本钱：
作为一款工具具有友好的操作、管理界面，同时安久具有专业的售后服
务团队，维护本钱更可控；
扩展本钱：
作为一款工具软件，其主要作用是拆分数据库，提高数据访问性能，并
不会随着数据库的增加而增加，这样从整体上降低了扩展的本钱。
兼容性
sqlserver：
面对复杂应用，需要多数据库集成时，集成能力弱。
篇三：
mysql性能优化解决方案
MySQL数据库性能优化
Renhao20XX/11/30
1.资源管理平台数据库
操作系统
RedHatEnterpriseLinuxServerrelease
ELF32-bitLSBexecutable,Intel80386,version1,forGNU/Linux,dynamicallylinked,forGNU/Linux,stripped
32位Linux效劳器，单独作为MySQL效劳器使用。
MySQL
系统使用的是，最新的较之老版本有了大幅改良。
主要表达在以下几个方面：
1〕默认存储引擎更改为InnoDB
InnoDB作为成熟、高效的事务引擎，目前已经广泛使用，但之前的版本默认引擎均为MyISAM，此次终于将默认数据库存储引擎改为InnoDB，并且引进了Innodbplugin。
此次更新对数据库的好处是显而易见的：
InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟。
InnoDBPlugin支持数据压缩存储，节约存储，提高内存命中率，并且支持adaptiveflushcheckpoint,可以在某些场合防止数据库出现突发性能瓶颈。
MultiRollbackSegments：
原来InnoDB只有一个Segment，同时只支持1023的并发。
现已扩充到128个Segments，从而解决了高并发的限制。
2〕多核性能提升
MetadataLockingFramework替换LOCK_openmutex，使得及过去版本在多核心处理器上的性能瓶颈得到解决。
3〕制功能加强
过去的异步复制方式意味着极端情况下的数据风险，将首次支持半同步在MySQL的高可用方案中将产生更多更加可靠的方案。
4〕增强表分区功能
MySQL的分区更易于使用的增强功能，以及TRUNCATEPARTITION命令都可以为管理和维护数据库节省大量的时间，并且具有更加灵活高效的分区方式。
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|grepflags|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〕效劳器可能同时在运行其他的查询，影响了当前查询的效率。
升级会员 