如何让SQL Server支持高并发环境

kelsoncong

dinglang_2009 发表于 2012-9-14 22:05
sqlserver横向扩展 的几种方案
1.Service Oriented Database Architecture (SODA)

恩，这几个东西我感觉看起来有点似是而非，简单的说都是通过类似于SOA的方式，封装一些技术细节，然后通过SOAP或者其他协议，进行通讯。
这种东西其实已经和数据库本身关联不大了，后台可以是SQL Server或者MY Sql什么都可以了。
但是问题是，具体到某个具体的节点，某个具体的高并发的应用，问题还是存在的。
这个和Oracle的RAC还是有着本质上的区别的。

个人观点，如果有不准确的地方，请帮忙指正

kelsoncong

lfree 发表于 2012-9-17 10:23
问题以后还会再现.

呵呵，还好了，已经过了两年了，性能基本稳定了。
主要是底层的查询优化器做了很大的提升，用微软自己的说法是，实现了从中小企业数据库向大型应用数据库的转变

shanks_gao

kelsoncong 发表于 2012-9-17 10:05
复制的问题前面大家聊了比较多了，主要对复制本身的延时和性能开销有点疑惑，可能需要实际测试数据的支持 ...

提到复制开销,延时,我想任何类型的数据库在这功能上都存在吧.
MSSQL在08中提出了压缩,这个我认为就是他不上进的一种表现,内部的数据结构他可能也没太多精力去做.
关于MSSQL复制的性能,本身根据数据的不同代理里进行复制的参数也有一定调整余地,
另外复制本身的架构也很重要，发布,分发,订阅,三者如何设计得根据现实环境来操作.
提到高并发处理,2012的alwaysON倒是作用不小,技术上算个小革新吧，但本质应该没变,性能上我没用过，不好说.

zaorv

週日（一天） DBA重整 INDEX ,今天效率高了一倍多。
有很多低效率的SQL需要修改的。
自定義函數、系統函數的使用 。

mengmou

kelsoncong 发表于 2012-9-17 10:12
垂直的硬件升级的空间很小，尤其是对于跑windows的PC服务器上而言，能够插多少CPU完全受制于整体架构的

我的意思是没有那么多CPU，其他方面无论你怎么优化2000～3000的并发也实现不了。你们开会研究了半天结果是正确的，但是理由不对，要想高并发，CPU是先决条件。

当然这里的并发指的是真正数据库某一刻同时处理的请求数量，而不包括那些只访问应用服务器缓存就能得到数据的请求。

kelsoncong

mengmou 发表于 2012-9-17 22:36
我的意思是没有那么多CPU，其他方面无论你怎么优化2000～3000的并发也实现不了。你们开会研究了半天结果是 ...

每个CPU只能支持16个连接？这个结论似乎有点问题吧?

kelsoncong

zaorv 发表于 2012-9-17 16:29
週日（一天） DBA重整 INDEX ,今天效率高了一倍多。
有很多低效率的SQL需要修改的。
自定義函數、系統函數 ...

确实，定期的数据库维护是必要的

cgx_4

学习，学习

mengmou

kelsoncong 发表于 2012-9-18 08:49
每个CPU只能支持16个连接？这个结论似乎有点问题吧?

http://msdn.microsoft.com/en-us/library/ms187024(v=sql.105).aspx

上面链接是SQL Server自动配置的默认最大连接数，对于64位系统，差不多每增加一颗CPU增加16个并发，你可以算算。

另外文档里也写的很清楚一般情况下，对于绝大多数系统建议我们直接使用默认值的。

mengmou

如果没有那么多CPU，就只能用两台复制了

这分两种情况，如果数据库中某一些表跟另一些表的关系不大，那么完全可以拆分数据库，每台服务器通过复制得到自己需要的“部分”数据。

如果数据库中表的关系非常紧密，就只能用peer to peer复制，每台服务器完全复制对方有的自己没有的“所有”数据。如果单台服务器需要处理2000个请求，1000个读，1000个写，那么两台peer to peer复制后，
对于写，一边500个写，但是这些写还是要同步到对方的，所以还是要增加500个写的开销，也就是写的开销一边仍然是1000。
对于读，就可以分摊开了，一边500个读。

也就是说复制后每边的开销变成1000个写+500个读，还是有用的。