1

如果在一个会话中上传和处理 500000 条数据记录是正常操作（C# .NET 3.5 + MS SQL 2005），您如何组织信息管理系统的 DB 层、业务逻辑和跨平台 API？

我对经过生产验证的分页模式特别感兴趣，这些模式在并发性、可伸缩性和可靠性方面表现良好。

有没有人有任何想法，在什么方向挖掘？

  • 开源项目（不管语言和平台，只要不是Ook）
  • 图书
  • 文章
  • 谷歌关键词
  • 论坛或新闻组

任何帮助将不胜感激！

更新：

  • 简单的分页（即：SQL 2005 中的行号）不起作用，因为数据库有很多并发更改。在页面请求之间删除或插入的项目会自动使当前页面索引无效。
4

6 回答 6

2

这是一本很好的入门书：

Martin Fowler的企业应用架构模式

于 2008-09-30T05:01:08.257 回答
2

当涉及到大量数据的数据库优化时，您很可能会从使用“BigTable”技术中受益。我发现这里的文章非常有用。不久的想法是使用 DB 非规范化来交换磁盘空间以获得更好的性能。

对于 MS SQL 2005 中的分页，您需要找到有关使用 ROW_NUMBER 函数的更多信息。这只是一个简单的例子，你会发现很多使用谷歌（关键字：ROW_NUMBER paging SQL 2005）。不过不要挖掘太多——实现中没有魔法，而是你将如何使用/呈现分页本身。谷歌搜索就是一个很好的例子。

注意：我们发现 NHibernate 框架原生分页支持不足以满足我们的解决方案。

此外，您可能会对创建 FULLTEXT 索引和使用全文搜索感兴趣。这是有关创建全文索引的 MSDN 文章，以及有关全文搜索的一些信息。

祝你好运。

于 2008-09-30T08:43:23.107 回答
1

完成了实施。我最近被告知其中一个上传是大约 2148849 条记录。在此上传期间，Tiers 确实成功地处理了数据库级别的几个断开的连接和数十个死锁。

如果其他人需要一些信息：

于 2008-12-19T11:29:35.957 回答
0

丹迪卡斯，

感谢您提及部分非规范化。是的，这就是我正在考虑提高某些查询性能的方法。

不幸的是，NHibernate ORM 不适合该解决方案，因为它增加了性能开销。与 SQL 分页相同 - 它在大量并发编辑的情况下不起作用（由压力测试检测到）

于 2008-09-30T09:02:50.390 回答
0

我负责管理一个上传数十万条记录的提要的企业数据仓库。
我不确定这是否是您的情况，但我们：

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

这运行得相当好，但我们强制我们的上传是顺序的。即，当提要到达时，它们进入队列，我们​​在查看其余提要之前完全处理队列头部的提要。

这些有帮助吗？

于 2008-09-30T09:21:53.963 回答
-1

与 SQL 分页相同 - 它在大量并发编辑的情况下不起作用（由压力测试检测到）

正如我所提到的，实现分页并没有什么神奇之处——您可以使用 ROW_NUMBER 或临时表。这里的魔力在于评估您在现实世界中最常见的使用场景。使用临时表和用户跟踪可能有助于克服并发编辑场景。虽然我感觉你会通过回答问题赢得更多：

  1. 用户在移动到另一个页面之前在一个页面上停留了多长时间？
  2. 用户多久从第一个页面移动到任何其他页面？
  3. 用户将浏览的常见页面数是多少？
  4. 如果在用户从一个页面移动到另一个页面并返回时某些信息发生变化，这有多重要？
  5. 如果用户在显示信息的页面上时删除了某些信息，这有多重要？

尽量不要专注于这样的问题：“如何在分页时处理任何可能的并发编辑场景？” 在您首先回答上述问题之前，然后只处理真正重要的情况。

另一个注意事项是 UI。尽可能多地查看分页 UI，因为除了左右箭头或排列页码之外，还有更好的解决方案。一些解决方案有助于隐藏/克服技术上无法解决的分页场景。

PS如果这个答案有用，我会将它与我的第一个答案结合起来。

于 2008-10-01T07:34:50.033 回答