电子商务日志策略建议
我最近继承了一个电子商务应用程序（Java/Struts），并将其移植到 Rails。
问题是，我们经常必须通过仔细研究日志文件来对订单进行取证，而使用旧应用程序的日志（log4j 文本墙），当几个人同时下订单时，很难理解各个订单。
因此，我正在征求有关记录这些订单的良好策略的建议，例如可能根据唯一的购物车 ID 将每个单独的订单记录到其自己的 MongoDB 集合中？或者可以按 IP 地址对它们进行分组？完全不同的东西吗？
本质上，记录在线商店以便轻松回溯每个用户与网站的交互的最佳方法是什么？
I recently inherited an e-commerce app (Java/Struts) that I'm porting to Rails.
The thing is, we frequently have to do forensics on orders by poring through the log files, and with the old app's logs (log4j wall of text) it's pretty hard to make sense of the individual orders when several people are placing orders simultaneously.
So I'm soliciting advice on a good strategy for logging of these orders, like maybe logging each individual order to its own MongoDB collection based on unique cart ID? Or maybe group them by IP address? Something different entirely?
Essentially, what is the best approach for logging of an online store so that it's easy to backtrace each user's interaction with the site?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不应该将每个订单记录到其自己的集合中，因为集合会产生太多开销。我有一个包含所有交互的集合。决定是否要为每个订单存储一份或多份文档。如果每个订单仅存储一个文档，则该文档可以包含一组“交互”文档。将另一个交互推送到每个文档上很容易。
如果您要对交互进行大量切片和切块，那么我会说每个操作一个文档，为您将要执行的查询类型添加适当的索引。
You shouldn't log each order to its own collection, as collections incur too much overhead. I'd have a single collection containing all interactions. The decide if you want to store one or multiple documents per order. If you store just one document per order, that document can contain an array of 'interaction' documents. It's easy to push another interaction onto each document.
If you're going to do lots of slicing and dicing of interactions, then I'd say one document per action, adding the appropriate indexes for the kinds of queries you'll be doing.