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/301. 资源管理平台数据库 操作系统Red Hat Enterprise Linux Server releaseELF 32-bit LSB executable, Intel 80386, version 1 , for GNU/Linux , dynamically linked , for GNU/Linux , stripped32位Linux服务器，单独作为MySQL服务器使用。MySQL系统使用是，最新较之老版本有了大幅改善。关键表现在以下多个方面：1）默认存放引擎更改为InnoDBInnoDB作为成熟、高效事务引擎，现在已经广泛使用，但之前版本默认引擎均为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_queriesMySQL有两种查询日志：一般日志和慢速日志，它们全部会统计查询。一般日志统计了服务器接收到每一个查询，也包含了没有被实施查询，比如因为错误而未被实施查询，还有部分非查询事件，比如连接和断开连接，一般日志不包含实施时间或其它只有在查询结束以后才能得到信息。相反，慢速日志只包含了已经实施过查询，假如是开启状态，它统计了实施时间超出了特定长度查询。两种日志全部有利于分析，不过慢速日志更有利找到性能较慢查询。 一个相关配置是log_queries_not_using_indexes，它使服务器把没有使用索引查询统计到慢速查询日志中，不管它们实施速度有多快。尽管打开慢速日志相对于实施慢速查询来说，通常只增加了极少时间，不过假如没有使用索引查询很快，比如从小数据量表中查询，这么就会统计它们可能造成服务器变慢，甚至还会使用大量磁盘空间，慢速日志可能就会被那些快速高效查询塞满。 慢查询日志能够用来找到实施时间长查询，能够用于优化。慢日志打开后，经过设置long_query_time来配置统计查询超出指定时间，默认值为10秒，依据系统负载和性能要求进行设置。检验又长又慢查询日志会很麻烦，能够使用MySQLdumpslow命令取得日志中显示查询摘要来处理慢查询日志。系统两种日志全部没有开启，能够在需要时候打开慢速日志来帮助分析性能较慢查询。具体实施参考MySQL手册。需要注意是查询在日志中只出现一次并不意味着它是一个不好查询，也不意味未来也会慢，查询时快是慢有多个原因：1）表可能被锁定，造成查询处于等候状态；2）数据或索引可能没有被缓存在内存中；3）或正在进行批处理大量数据，使得磁盘I/O变慢；4）服务器可能同时在运行其它查询，影响了目前查询效率。