如果在一个会话中上传和处理500000条数据记录是正常操作(C#.NET 3.5 + MS SQL 2005),那么如何组织信息管理系统的数据库层,业务逻辑和跨平台API?
我特别感兴趣的是经过生产验证的分页模式,它在并发性,可伸缩性和可靠性方面表现良好。
有没有人有任何想法,在哪个方向挖掘?
任何帮助都会非常感谢!
更新
答案 0 :(得分:2)
这是一本很好的书:
Martin Fowler的答案 1 :(得分:2)
对于大量数据的数据库优化,您最有可能从使用“BigTable”技术中受益。我发现article here非常有用。简而言之,我们的想法是使用数据库非规范化来交换磁盘空间以获得更好的性能。
对于MS SQL 2005中的分页,您需要查找有关使用ROW_NUMBER函数的更多信息。 Here is just a simple example,您会发现大量使用谷歌(关键字:ROW_NUMBER分页SQL 2005)。不要过多考虑 - 实现中没有魔法,而是你将如何使用/呈现分页本身。 Google搜索就是一个很好的例子。
注意:我们发现NHibernate框架本机分页支持对我们的解决方案来说还不够。
您也可能对创建FULLTEXT索引和使用全文搜索感兴趣。 Here is MSDN article用于创建全文索引,some info用于全文搜索。
祝你好运。答案 2 :(得分:1)
完成实施。我最近得到通知,其中一个上传大约是2148849条记录。在上传过程中,Tiers成功处理了数据库级别的几个断开的连接和数十个死锁。
如果有人需要一些信息:
答案 3 :(得分:0)
dandikas,
感谢您提及部分非规范化。是的,这是我正在考虑提高某些查询性能的方法。
不幸的是,NHibernate ORM不适合该解决方案,因为它增加了性能开销。与SQL分页相同 - 它在大量并发编辑的场景中不起作用(由stress-testing检测到)
答案 4 :(得分:0)
我负责管理企业数据仓库,该数据仓库上传了数十万条记录的一些订阅源 我不确定这是不是你的情况,但是我们:
运行得相当好,但我们强制上传顺序。即当饲料到达时,它们进入队列,我们在查看其余部分之前完全处理队列头部的饲料。
这有什么用吗?
答案 5 :(得分:-1)
与SQL分页相同 - 它在众多场景中不起作用 并发编辑(通过压力测试检测到)
正如我所提到的,实现分页没有任何魔力 - 您可以使用ROW_NUMBER或临时表。这里的神奇之处在于评估您最常见的真实世界使用场景。使用临时表以及用户跟踪可能有助于克服并发编辑方案。虽然我觉得你会通过回答问题赢得更多:
在首先回答上述问题然后只处理真正重要的情况之前,尽量不要专注于如下问题:“如何在分页时处理任何可能的并发编辑方案?”。
另一个注意事项是UI。查看尽可能多的分页UI,因为有比左右箭头更好的解决方案,或排列页码。一些解决方案有助于隐藏/克服技术上不可解决的分页方案。
P.S。如果这个答案很有用,我会将它与我的第一个结合起来。