【技术交流】Plinq与SQL大PK

各位大侠，有没有相关的开发经验，针对以下两种场景，在百万级别的数据量，性能哪个快些？
1）SQL server按业务分存储过程，业务和逻辑层只进行简单调取。
2）SQL server只按照基本操作查询，业务层通过PLINQ等手段做关联。 --------------------编程问答-------------------- 如果单单比较性能，PLINQ也比不过SQL（访问数据库）
但是PLINQ的优势不在这里，它提供了灵活性、可编程性，以及对内存在线数据的高效处理。

随着内存价格的下降，越来越多的架构倾向只把数据库作为持久化的后端，而越来越多的操作被放入内存交给前端的程序，所谓存储即计算，这是一个趋势，(P)LINQ顺应了这个趋势，大有作为。 --------------------编程问答-------------------- 那您的意思是偏向第二种了？就是说SQL只提供简单的查询，在逻辑层里面进行拼实体的集合。 --------------------编程问答-------------------- 这两者一点也不矛盾，不是用了sql就不能用linq了。另外linq to ef、linq to db之类的技术其实本质上和你使用sql是一样的，区别在于，一个是手写sql，一个是自动产生的sql，但是都是在数据库端过滤数据。 --------------------编程问答-------------------- 我想知道的是，我的存储过程，是按照业务每个业务对应一个存储过程，还是存储过程里只提供基础查询，说白了，就是把业务放在数据库层，还是放在代码层，从灵活性，扩展性或者性能方面，应该是各有千秋吧，但是对于高并发的访问量，哪种方式好一些呢？ --------------------编程问答-------------------- 首先，你一开要有一个判断，你的系统是为性能而设计的，还是为业务而设计的，如果是前者，果断使用存储过程，甚至你可以考虑NoSQL。反之，如果性能至上的场合不多（百万数据谈不上海量），那么你可以使用前端的数据库技术，并且进行压力测试，在确实存在性能问题的地方局部调优。 --------------------编程问答-------------------- 多加点内存，开发效率与运行效率都会有的 --------------------编程问答-------------------- SQL效率是要比PLINQ高一些，曹版主说的有理 --------------------编程问答-------------------- 当你的技能就是拿个大锤子、然后见到钉子就砸一砸的时候，你自然觉得抡锤子是最“快”的。在这个层次，肯定觉得瑞士军刀、甚至电动工具都不上锤子更快。可见这跟最终的需求场景有关。

所以最终要负责的人是用测试说话，不是死抠底层技术。 --------------------编程问答-------------------- 瑞士军刀、甚至电动工具都不上锤子更快  -->  瑞士军刀、甚至电动工具都比不上抡锤子更快更有技能 --------------------编程问答-------------------- 如果对性能要求很高的话那一定是存储过程好
但是第一种方式需要开发人员对数据库原理有一定的了解，所以开发成本比第二种高 --------------------编程问答--------------------

引用 5 楼  的回复:

首先，你一开要有一个判断，你的系统是为性能而设计的，还是为业务而设计的，如果是前者，果断使用存储过程，甚至你可以考虑NoSQL。反之，如果性能至上的场合不多（百万数据谈不上海量），那么你可以使用前端的数据库技术，并且进行压力测试，在确实存在性能问题的地方局部调优。

如果是业务比性能重要10倍左右的系统，那么是不是就是在业务层来拼对象比较合理了呢？ --------------------编程问答-------------------- 这里就运用28原则 核心部分 经常被用到的 性能要求高的 可以考虑直接用原生SQL 非核心部分就用前端的ORM工具 就跟操作系统一样 核心部分和高性能要求的用汇编写 一般的用C/C++写 再一般的用C#写~

引用 11 楼  的回复:

引用 5 楼 的回复:

首先，你一开要有一个判断，你的系统是为性能而设计的，还是为业务而设计的，如果是前者，果断使用存储过程，甚至你可以考虑NoSQL。反之，如果性能至上的场合不多（百万数据谈不上海量），那么你可以使用前端的数据库技术，并且进行压力测试，在确实存在性能问题的地方局部调优。


如果是业务比性能重要10倍左右的系统，那么是不是就是在业务层来拼对象比较合理了呢？

--------------------编程问答--------------------

引用 11 楼  的回复:

引用 5 楼  的回复:

首先，你一开要有一个判断，你的系统是为性能而设计的，还是为业务而设计的，如果是前者，果断使用存储过程，甚至你可以考虑NoSQL。反之，如果性能至上的场合不多（百万数据谈不上海量），那么你可以使用前端的数据库技术，并且进行压力测试，在确实存在性能问题的地方局部调优。


如果是业务比性能重要10倍左右的系统，那么是不是就是在业务层来拼对象比较合理了呢？

请不要选择性理解我的话，我在3L说的很清楚，两者不矛盾。 --------------------编程问答-------------------- 开个玩笑 nosql  ssd ^_^ --------------------编程问答--------------------

引用 14 楼  的回复:

开个玩笑 nosql  ssd ^_^

呵呵，现在的系统在数据存储方面要求具备庞大的水平扩展性，NoSQL可以处理超大量的数据，
关系数据库存储数据上似乎固定了数据格式，NoSQL在这方面要灵活得多。
Google的 BigTable 和Amazon 的Dynamo使用的就是NoSQL型数据库

言归正传，PLINQ 查询对任何内存中 IEnumerable 或 IEnumerable<T> 数据源进行操作，并推迟执行，这意味着在枚举查询之前不会开始执行这些操作。 主要区别是 PLINQ 尝试充分利用系统中的所有处理器。 它利用所有处理器的方法是，将数据源分成片段，然后在多个处理器上对单独工作线程上的每个片段并行执行查询。 在许多情况下，并行执行意味着查询运行速度显著提高。
就像上面几位所说，确实得看什么情况下使用，并非所有查询操作在 PLINQ 中都运行得更快。 事实上，并行降低了某些查询的速度。
而SQL，可能我们没找更好地发挥他们优化的方法（可能连oracle或者微软的数据库工程师、DBA都没找到）
我们在SQL的高并发性的设计和优化上应该有很大的提升空间。 --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- 不错，就是不太懂 --------------------编程问答-------------------- 好好好好好好 --------------------编程问答-------------------- 其实我不懂。 --------------------编程问答-------------------- --------------------编程问答-------------------- 做数据量大对性能要求高的项目，我绝对不用PLINQ --------------------编程问答-------------------- 其实我不懂 --------------------编程问答-------------------- 不错，就是不太懂 --------------------编程问答-------------------- 这两者一点也不矛盾，不是用了sql就不能用linq了。另外linq to ef、linq to db之类的技术其实本质上和你使用sql是一样的，区别在于，一个是手写sql，一个是自动产生的sql，但是都是在数据库端过滤数据。 --------------------编程问答-------------------- 不错 ，正是我需要的， --------------------编程问答--------------------

引用楼主  的回复:

各位大侠，有没有相关的开发经验，针对以下两种场景，在百万级别的数据量，性能哪个快些？
1）SQL server按业务分存储过程，业务和逻辑层只进行简单调取。
2）SQL server只按照基本操作查询，业务层通过PLINQ等手段做关联。

1)是必须有的；
2)是锦上添花的。

但是要把2)稍微修改一下：SQL server该干嘛还干嘛，该建表就建表，该建视图就建视图，该建存储过程就建存储过程，业务层可以直接用数据库查询、存储过程调用返回的结果集，也可以把这些返回的结果集通过PLINQ等手段做关联得到进一步的结果。 --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答--------------------

引用 22 楼  的回复:

做数据量大对性能要求高的项目，我绝对不用PLINQ

为什么呢？ --------------------编程问答--------------------

引用 27 楼  的回复:

引用楼主  的回复:
各位大侠，有没有相关的开发经验，针对以下两种场景，在百万级别的数据量，性能哪个快些？
1）SQL server按业务分存储过程，业务和逻辑层只进行简单调取。
2）SQL server只按照基本操作查询，业务层通过PLINQ等手段做关联。



1)是必须有的；
2)是锦上添花的。

但是要把2)稍微修改一下：SQL server该干嘛还干嘛，该建表就建表……

可能是我表达的不好，我举个例子吧，比如我现在有100个业务，这100个业务可能会涉及跨库或者关联表的相关操作，但是表实际上只有5张，于是1）和2）就变成了：
1）针对100个业务，写100个存储过程，每个存储过程该跨库就跨库，该关联表就关联表。
2）针对5张表，写关于这五张表的增删改查共20个存储过程，程序里通过代码来拼业务。 --------------------编程问答-------------------- --------------------编程问答-------------------- 性能于我如浮云.  --------------------编程问答-------------------- --------------------编程问答-------------------- SSS --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- 搭车问个LINQ，3个数据表使用Include 连接后，生成的SQL语句很多，有什么好办法减少？

谢谢各位 --------------------编程问答-------------------- --------------------编程问答-------------------- --------------------编程问答-------------------- 有道理 --------------------编程问答-------------------- --------------------编程问答-------------------- 在百万级别的数据量，性能哪个快些？
觉得存储过程更适合，方便优化SQL语句，提高执行效率。 --------------------编程问答-------------------- linq 对数组等排序什么的挺牛的 --------------------编程问答-------------------- 牛吗？鸡吧？ --------------------编程问答-------------------- --------------------编程问答-------------------- 暂且认为楼主的意思是比较linq to sql（linq to ef）和SQL。 

插一句，plinq的优势在于以最简单的方式实现并发，它的强项是操作内存中的数据，可以充分利用每个CPU核心的计算能力，而不需要coder去关心比较复杂的多线程编程。对于访问数据库来说，对一个单一DB实例的访问，性能瓶颈在于DB，而不在于App Server的CPU，plinq并没有什么优势，只有在交叉查询多个DB实例的情况下，plinq才能显示出一点优势来。

至于linq to sql和sql的比较，只能说各有利弊。澄清一点，linq本身并不存在性能问题，执行的仍然是sql，实际中之所以出现不少问题，主要还是人的问题，代码质量的问题。linq开发效率高，成本低，但是不容易监控和跟踪，调优比较麻烦。当业务逻辑足够复杂的时候，如果在开发过程中没有严格的代码review，菜鸟coder可能写出垃圾查询，对DB造成比较大的压力。百万级并不是什么大数据量，只要数据库调优不要太差，coder的水平不是太菜的话，两种技术并不会有太大的差别。

真正挑战在于，当你的业务足够大、足够复杂以后，业务模块和数据的垂直切分问题，呵呵，当你需要读N个数据库实例、N个API才能获取到你需要的数据，并且数据的筛选、排序条件分散在各个不同地方，你就会真正的感到头疼了^_^所以，在系统可以承受的情况下，尽可能保持DB和DAL层的单纯吧，除非必须，尽量把逻辑提到domain（logic）层。

我的建议，如果系统比较简单，业务逻辑稳定，不会总变，并且开发人员总体水平不是太差的话，可以考虑用linq，如果系统比较大，模块多，或者在可预见的将来可能变化比较频繁，并且系统对稳定性、可监控、可调优等方面要求较高的话，建议用SQL。

至于系统的复杂度，什么算大，什么算小，这个几句话不好说，呵呵，自己体会吧
--------------------编程问答-------------------- 先实现基本的功能再去谈效率，否则就得不偿失了！ --------------------编程问答--------------------

引用 53 楼  的回复:

暂且认为楼主的意思是比较linq to sql（linq to ef）和SQL。 

插一句，plinq的优势在于以最简单的方式实现并发，它的强项是操作内存中的数据，可以充分利用每个CPU核心的计算能力，而不需要coder去关心比较复杂的多线程编程。对于访问数据库来说，对一个单一DB实例的访问，性能瓶颈在于DB，而不在于App Server的CPU，plinq并没有什么优势，只有在交叉查询多……

我理解有两点重要
1）多实例DB，比如我可能会有大批量的跨库查询，甚至跨SQL语言的查询(sql server,mysql,oracle等)，我就只能Plinq
2）猫大（先这么称呼吧）建议在业务层拼数据

是这样么? --------------------编程问答-------------------- 俺们从来不是这么考虑问题的

俺们通常是“疑罪从无”，只要你没有任何直接证据证明他是由效率问题的那么我们就假定他没有问题。

基于这种原则，自然优先采用利于开发的plinq

同样另外一个原则是功能单一，功能最小，可替换，---------也就是即使这个小点上有问题那有如何，他可以被替换就成

所以我们的答案是“别矫情，优先实现。只要你的架构合适，至于里面的手段无所谓，OO不只是是代码，也不只是口号，谁是我一个最小功能可以被pinq实现，就不能被sql语句给重载呢” --------------------编程问答-------------------- LINQ EF 也支持存储过程。 性能上和ADO.NET直接调存储过程没有明显差异 如果是 实体表的操作也要按一定的经验来考虑。 SQL作为一个合格成程序一定要有良好基础。 --------------------编程问答-------------------- 是否选择存储过程或者linq不仅仅由一个数据量来确定. 数据量虽然大,用户如果只有一个呢, 用户很多,但服务器只有一个呢, 服务器有很多,但数据库服务器只有一个呢,这所有问题你都没提及,无法确定存储过程还是linq更适用 --------------------编程问答-------------------- 总之大数据量大并发的系统在语言选择上的性能可以忽略,也就是可以忽略linq和sql的性能影响, 究竟用什么合适需要由架构确定 --------------------编程问答--------------------

引用 8 楼 sp1234 的回复:

当你的技能就是拿个大锤子、然后见到钉子就砸一砸的时候，你自然觉得抡锤子是最“快”的。在这个层次，肯定觉得瑞士军刀、甚至电动工具都不上锤子更快。可见这跟最终的需求场景有关。

所以最终要负责的人是用测试说话，不是死抠底层技术。

是这个理 --------------------编程问答--------------------

引用 44 楼 xml111024 的回复:

搭车问个LINQ，3个数据表使用Include 连接后，生成的SQL语句很多，有什么好办法减少？

谢谢各位

 selcct new 新表

补充：.NET技术 ,  LINQ