大数据量

1.数据层放弃SQL Server数据库和存储过程，全部迁移到Linux平台上的MySQL数据库上；
2.缓存不再依赖.net自身提供的缓存机制，迁移到部署在Linux平台上的分布式的Redis上；
3.服务之间的调用，避免使用.net自身专有协议，改成Restful的HTTP Web API调用；
4.静态资源请求，不再让IIS自己处理，分离到Linux平台上的nginx去处理；
5.需要读取的文件系统，也改成访问Linux平台上的分布式文件系统；
6.部署.net代码的Windows服务器放在LVS后面，用LVS做负载均衡和故障切换；

JD 换java的内幕是 CTO 是IBM 出来的 喜欢java 看不上.net

关于.net 系统架构的一些问题：
.net编程语言和框架，但是网站整体架构仍然去Windows化，概要说来：

简单说来，就是单纯让.net做应用层的编程语言和框架，其他都交给Linux平台的开源解决方案。而.net框架单纯做应用层，无论ASP.net MVC的开发效率，还是.net CLR虚拟机的运行效率都非常好，目前我们单台Windows服务器上跑几百万的动态请求毫无压力，而且应用层架构是可以横向扩展的：如果请求负载非常高，只需要添加更多Windows服务器即可。总之，做到了扬长避短。

京东架构

IIS 处理动态信息就行了
其他的 交给linux上
以后面试拿这去吹牛

这本来才是 iis该做的正事

其实还有很多方法啦，拆分表是需要条件的。
可以啊，如果我设计构架的话，我肯定会从这几个方面设计
说明：贵博主说的拆发表只是一个很特殊的表才可以的，在其他的范围内根本不使用，当然大数据使用负载均衡或者分布式肯定很好，如果采用一个服务器的话我基本上是按照下面几个步骤来的
一、数据库结构的设计 
二、查询的优化 
三、算法
四、建立高效的索引 
五、页面静态化技术和负载均衡技术
六、如果是java的话JVM调优
七、缓冲池技术
八、ehcache缓存技术+LRU等淘汰算法

分区只是Sql利用我们事先定义好的分区方案，对数据进行分区存储。对用户来说是不可见的。我们写insert,delete,select,update与普通表的操作没有任何区别哈！^_^

哈哈， 作为存储数据的媒介， 可以变通的使用他来存储一个Data Collection，之前也使用过。当然灵活与变通，在于设计者本身，只有自己才明白去选择适合自己的那种存储方式。现在很多orm都支持直接操作sql/以及事物、存储过程等。比如这个
http://www.cnblogs.com/_popc/archive/2012/12/26/2834726.html
:）
这技术我不知道，算是长见识了！
你看写博客不仅利人，也利已。

不建议使用多个mdf, 主数据库文件中存储了其它ndf,ldf，filegroup等信息，如果使用多个mdf,数据库能正常运行，但万一哪天你要分离附加数据库了，你必须指定真实的主数据库文件，当然你也可以循环去试那些mdf...

sqlserver 的约定是： 
主数据文件为.mdf（只有一个主数据文件），辅助数据文件扩展名为.ndf（可以有多个）
你说一个数据库当然可以有多个MDF文件，严格说也没错，就比如你的windows操作系统中，把所有的系统的非系统的文件都塞进C盘，当然也木问题，但是为了方便管理，你还是会分出来D盘，E盘，另外就是@周强说的问题，我暂时没有遇到过，有时间验证下（我从来不会建立多个mdf文件的）。

另外楼主在说分区的时候一直强调文件组和文件，其实没有必然联系，不同的分区也可以建立在同一个文件组的同一个文件上。

海量数据提高效率思路
数据库端：分库，分区，分表从大到小
应用程序段：群集负载
客户端：缓存，轻量化设计
一点经验