搜索有关构建大型企业系统的信息

Question

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

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

有没有人有什么想法，朝什么方向去挖掘？

• 开源项目（不管语言和平台，只要不是Ook就行）
• 书籍
• 文章
• Google 关键字
• 论坛或新闻组

任何帮助将不胜感激！

更新：

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

Answer 1

这是一本好书：

Patterns of Enterprise Application Architecture by Martin Fowler

Answer 2

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

对于 MS SQL 2005 中的分页，您需要了解有关使用 ROW_NUMBER 函数的更多信息。 Here is just a simple example，你会在谷歌上找到大量的（关键字：ROW_NUMBER paging SQL 2005）。不过不要挖掘太多——实现中没有魔法，而是你将如何使用/呈现分页本身。 Google 搜索就是一个很好的例子。

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

此外，您可能会对创建 FULLTEXT 索引和使用全文搜索感兴趣。 Here is MSDN article 用于创建全文索引，some info 用于全文搜索。

祝你好运。

Answer 3

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

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

• Product page
• Exception Handling Action Policies

Answer 4

丹迪卡斯，

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

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

Answer 5

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

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

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

这些有用吗？

Answer 6

与 SQL 分页相同 - 在大量的场景中不起作用 并发编辑（通过压力测试检测到）

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

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

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

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

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