2008-09-30 34 views
1

如果在一个会话中上载和处理500000个数据记录是正常操作(C#.NET 3.5),如何组织信息管理系统的数据库层,业务逻辑和跨平台API + MS SQL 2005)?搜索有关构建大型企业系统的信息

我特别感兴趣的是经过生产验证的分页模式,它的并发性,可伸缩性和可靠性表现良好。

有没有人有任何想法,在什么方向挖?

  • 开源项目(不关心的语言或平台,只要它不是OOK)
  • 文章
  • 谷歌关键字
  • 论坛或新闻组

任何帮助将不胜感激!

更新:

  • 简单分页(即:在ROWNUMBER SQL 2005)不起作用,因为有 很多并发改变 到数据库。在页面请求之间删除或插入的项目会自动使当前页面索引无效。

回答

1

完成实施。我最近被告知,其中一个上传的内容大约是2148849条记录。在此上传过程中,分层成功地处理了几个断开的连接和数据库级别的数十个死锁。

如果别人需要的一些信息:

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

祝你好运。

+0

要知道,非规范化引入不仅仅是额外的磁盘空间使用情况的详细问题。还有需要保持同步以及其他问题的重复数据的问题。确保你了解这些权衡。 – 2008-09-30 11:20:12

0

dandikas,

谢谢你提到的部分非规范化。是的,这是我正在考虑改进某些查询性能的方法。

不幸的是,NHibernate ORM不适合解决方案,因为它增加了性能开销。与SQL分页一样 - 它不适用于多个并发编辑(如stress-testing检测到的情况)

0

我照顾企业数据仓库,该仓库上传数十万条记录的某些订阅源。
我不知道这是否是您的情况,但我们:

  • 接收界河我们上传到Sybase数据库的文本文件。
  • 使用awk格式化不同的提要,以便它们采用通用格式。
  • 使用bcp将它们加载到非规范化的中间表中。
  • 运行存储过程来填充规范化数据库structre。
  • 从非规范化中间表中删除。

这运行得很好,但我们强制我们的上传顺序。即当Feed到达时,他们进入队列,我们​​在完成队列头部的处理之前完全处理Feed,然后查看其余的队列。

这有帮助吗?

-1

同样与SQL分页 - 它不会在众多 并发修改的情况下工作(通过压力测试检测)

正如我提到的,在实现分页没有魔法 - 您使用ROW_NUMBER或临时表。这里的神奇之处在于评估您最常用的真实世界使用场景。使用临时表和用户跟踪可能会有助于克服并发编辑方案。虽然我感觉你会通过回答问题赢得更多:

  1. 用户在转到另一页之前停留多长时间?
  2. 用户从第一个页面移动到其他页面的频率?
  3. 用户将浏览的常见页面数量是多少?
  4. 当用户从一个页面移动到另一个页面并返回时,如果某些信息发生变化,它有多重要?
  5. 当用户位于显示信息的页面上时,如果某些信息被删除,它有多重要?

在你首先回答上述问题,然后只处理真正重要的情况之前,尽量不要专注于如下问题:“如何在分页时处理任何可能的并发编辑方案?”。

另一个说明是UI。查看尽可能多的分页UI,因为有更好的解决方案,而不仅仅是右箭头和左箭头,或排列页码。一些解决方案有助于隐藏/克服技术上不可解决的寻呼场景。

P.S.如果这个答案很有用,我会把它和我的第一个结合起来。

+0

谢谢你的广泛评论。然而,它是不同的。 我正在讨论的是帖子中的跨平台API,而不是UI。 想象一下,一个客户在5-10分钟内上传/删除500000条记录的情况。同时记录正在被自动化服务分页。 – 2008-10-01 08:30:42