好的，这是场景。我有一个处理大量记录的实用程序，并相应地将信息输入数据库。
它适用于多线程批处理中的这些记录。每个这样的批处理都写入相同的日志文件，以便为每条记录创建工作流程跟踪。潜在地，我们可以在一天内完成近百万次日志写入。
此日志是否应该驻留在另一台服务器上的数据库中？考虑：
是否可以对这两种方法进行任何优化？
感谢。
答案 0 :(得分：6)
有趣的问题，如果您决定登录数据库，您在哪里记录数据库连接错误？
如果我正在登录数据库，我总是有一个辅助日志位置（文件，事件日志等）以防通信错误。它确实可以让以后更容易诊断问题。
答案 1 :(得分：3)
我想到的一件事是，您可以让每个线程都写入自己的日志文件，然后每天批量运行以组合它们。
如果您要登录数据库，则可能需要进行一些调整和优化，尤其是在数据库将通过网络时。至少你需要重用数据库连接。
此外，您是否有任何特定需要登录数据库？如果您只需要一个“grep”，那么我认为您通过登录数据库获得的收益并不高。
答案 2 :(得分：2)
我在这里回答其他答案，取决于您对数据的处理。
我们在这里有两个场景：
大多数日志记录都是针对数据库的，因为我们构建的产品的管理员用户需要能够在他们漂亮的小应用程序中查看它们，并且所有的花里胡哨。
我们将所有诊断和调试信息记录到文件中。我们不需要真正“美化”它和TBH，我们甚至不经常需要它，所以我们只是记录和存档大部分。
我会说如果用户正在做任何事情，然后登录到DB，如果它适合你，那么文件就足够了。
答案 3 :(得分：2)
不确定它是否有帮助，但是还有一个名为Microsoft LogParser的实用程序，您可以使用它来解析基于文本的日志文件并将它们用作数据库。来自网站：
日志解析器功能强大，功能多样 提供通用查询的工具 访问基于文本的数据，如日志 文件，XML文件和CSV文件，如 以及关键数据来源 Windows®等操作系统 事件日志，注册表，文件 系统和ActiveDirectory®。您 告诉Log Parser你有什么信息 需要以及如何处理它。 您的查询结果可以是 基于文本的输出自定义格式， 或者他们可以坚持到更多 专业目标，如SQL，SYSLOG或 图表。大多数软件都是为了 完成数量有限的 具体任务。 Log Parser是 不同......它的方式数量 使用仅限于需要 和用户的想象力。该 world是您使用Log的数据库 解析器。
我自己没有用过这个程序，但看起来很有意思！
答案 4 :(得分：2)
或者如何记录到队列？这样，只要您想登录不同的东西，就可以切换出轮询器。它使滚动和归档日志文件等事情变得非常容易。它也很好，因为您可以添加记录到不同内容的轮询器，例如：
答案 5 :(得分：1)
数据库 - 因为你提到了多个线程。同步和过滤检索是我回答的原因 在决定切换到文件之前，查看是否存在性能问题 “Knuth：过早的优化是所有邪恶的根源”我在那本书中没有得到任何进一步......：）
答案 6 :(得分：1)
有一些方法可以解决文件记录的限制。
您始终可以使用某种线程ID启动每个日志条目，并刷新各个线程ID。或者每个线程的不同日志文件。
我以前在较低优先级的单独线程中登录过数据库。我必须说，当你想弄清楚出了什么问题时，可查询性是非常有价值的。
答案 7 :(得分：1)
如果要记录到数据库文件，比如一个SQLite数据库呢？我认为它可以处理多线程写入 - 尽管它也可能有自己的性能开销。
答案 8 :(得分：0)
我认为这在很大程度上取决于你之后对日志文件做了什么。
写入日志文件的两个操作中的速度会更快 - 特别是当您建议写入另一台服务器上的数据库时。
但是，如果您正在尝试定期处理和搜索日志文件，那么最好的地方就是数据库。
如果您使用log4net之类的日志框架，他们通常会提供基于配置文件的简单方法，将输入重定向到文件或数据库。
答案 9 :(得分：0)
我喜欢Gaius的回答。将所有日志语句放在线程安全队列中，然后从那里处理它们。对于DB，您可以批量处理它们，在一个批处理中说100个日志语句，对于文件，您可以在它们进入队列时将它们流式传输到文件中。
文件还是Db？正如许多人所说;这取决于你需要的日志文件。