在不使用普通 SQL 数据库的情况下记录数据？答案

【问题标题】：Logging data without using a normal SQL database?在不使用普通 SQL 数据库的情况下记录数据？
【发布时间】：2011-07-07 12:20:56
【问题描述】：

我目前正在将我网站上的每个“失败”（登录/注册/等）记录到数据库中，以便我可以监控是什么让我的用户遇到困难 - 或者哪些 ips/用户正在做可疑的事情。

但是，我发现我真的只需要大约一周左右的数据，因为我每天都检查它，并且最多需要查看过去一周的活动。

我在想，也许我应该尝试保存我的数据库从所有这些日志记录中承受的一些负载，并将数据放在 memcached 或 couchdb 之类的东西中。但是，我不确定如何将数据查询到结果集中。

如何使用键值对存储或文档数据库来监控日志并跟踪活动之间的关系？ 是否值得向服务器添加另一个数据存储或只保留数据库从处理它？我提到 memcached 和 couchdb 是因为如果需要，两者的 RAM 使用率都非常低（与 mongodb 和 redis 不同）。

让我举个例子。 IP 0.0.0.0 在 3 小时内登录失败 37 次（每次记录），它还在 2 小时内为有效电子邮件重置密码 84 次失败。多亏了我的日志，我现在可以研究（并阻止）这个机器人。另一方面，我看到在 5827 个注册用户中 - 有 2188 次注册尝试失败。这告诉我，我的注册表单有问题，导致许多人至少有一次未能通过该表单。

再次，赏金是一个使用键值或文档存储来记录数据的工作示例。

【问题讨论】：

“我不确定如何将数据查询到结果集中”？为什么不？你读了什么？任何文档数据库（或键值存储）都非常非常好地做到了这一点。你为什么不确定？你不确定什么？您想知道如何在没有 SQL 的情况下进行查询吗？
我不确定如何将数据查询到结果集中。我很确定它可以完成 - 我只是不知道怎么做。
到目前为止，您在 memcached 或 couchdb 上读到了什么？请提供具体的链接或报价，以便我们知道您在说什么。两者都有非常简单的 API，使得检索数据变得非常简单。
我不确定如何将数据查询为有用的格式。我没有任何链接，因为我不知道该怎么做。获取数据是一回事 - 将数据查询到有组织的结果中是另一回事。您如何使用其中任何一个来汇总数据以模拟我发布的示例？
至强，我们在这里谈论多少数据？ 500 万行/天？ 5000 万行？多少个网络服务器？ 1、5、100？你是在 Linux 还是 Windows 上工作？我有几个想法给你，但我想确保在我开始提出解决方案之前了解你的范围和规模。 :)

标签： database logging memcached nosql key-value

【解决方案1】：

只需写入日志文件并离线分析即可。日志记录是一个已解决的问题，将一行文本写入磁盘上的文件几乎与 IO 和 CPU 一样便宜，这是你可能得到的。日志轮换也是一个已解决的问题，重新发明轮子确实没有意义。

一旦日志数据在磁盘上，您可以将其复制到另一台机器上，以便使用您想要的任何工具包进行解析和分析，如果您想使用文档存储，那就是介绍它的地方。无需让您的前置生产机器承担这项工作的负担。

【讨论】：

如果您擅长 sed/awk/perl 或有其他喜欢的数据解析语言，这也是一个很好的解决方案。如果您的日志是一致分隔的，您可以创建脚本，这些脚本将每天翻阅它们并为您提供您正在寻找的指标。您可以使用 grep 查找围绕特定 IP 地址或用户或页面的日志事件。

【解决方案2】：

键值存储或基于文档的数据库are not a panacea。如果您只是为了好玩而想和他们一起玩，那很好，但如果您想这样做为我的数据库节省一些负载，我强烈建议不要浪费您的时间。让我解释一下。

首先，您必须意识到这些数据结构最近变得流行是因为超大型网站（LinkedIn、Facebook 等）需要可扩展性。更重要的是，他们以方便为代价提供了这部分的可扩展性。

将这些新一代数据存储视为没有表间关系和 SQL 层的精简数据库。因此写入变得便宜，因为无需担心依赖数据。但是读取可能会变得昂贵（如果您没有索引），因为您必须处理 O(n) 复杂性。对于密钥 ID 总是已知的情况或响应时间不是什么大问题的后处理作业，这是可以的。或者，您可以在平面文档上使用索引进行快速搜索，但不要期望自动处理外键。

如果您要将数据记录到 kv 存储中，您可以通过将整个记录记录到 kv 存储中并分别为“失败”情况记录键（id）来解决您的查询问题（例如，可以存储在特殊键下） .之后，您可以在 O(1) 时间内找到违规记录。需要快速查找不同的案例（重置密码失败、注册失败）？没问题，只需添加另一个“特殊”键并重新索引所有现有数据 :) 您已被警告过失去便利！

如果您要将数据记录到文档存储中，只有当您的日志记录是平坦的（非规范化）时，您才能受益。否则，我看不到您如何首先将数据存储在其中。然后，您可以根据事件类型创建索引并通过它进行查询。但是，我看不出与您现在所拥有的有什么大的不同/改进。

但是想一想。您可能会花费数周（如果不是数月）重写、调试和测试现有的日志记录代码。您必须定义不同的备份策略。你会很痛苦地向你的系统管理员、老板等解释这一点。或者你可以购买价值几百美元的 SSD disk 并获得相同的结果，如果不是更好的话。

【讨论】：

【解决方案3】：

所以，如果我理解正确的话：

您的日志数据存储中有 50-7000 万条滚动记录。
读取延迟并不重要（亚秒级），因为您每天都会根据站点异常或客户请求等触发器进行检查。
您的日志记录数据库和 OLTP 数据库当前驻留在同一台服务器上。
根据您的个人资料和上面的回答，我猜测您使用的是 MySQL，而不是 MSSQL。
我还假设，由于您将日志记录数据库设置为 7 天，因此备份并不是您关心的事情（同样如此）。

关于非关系解决方案和面向文档的存储的一些事情： 1. 他们不要求你是 Facebook 或 Twitter。 MongoDB 和 CouchDB 的设置不必是企业任务。 2.它们非常适合存储日志和事件数据。 3. CouchDB 和 MongoDB 都将利用尽可能多的内存来缓存它们的索引。 4. MongoDB 提供了一个“上限”集合，它对存储的数据设置大小限制，然后在数据行/消息过期时滚动它们。如果您实现 MongoDB，这似乎特别适合您的需求，因为它不需要您不断地对关系数据库运行大量删除。 5.查询界面与你习惯的SQL有本质区别。两者都可以获取基于 JSON 的查询文档并返回结果。 MongoDB 的函数库对于关系开发人员来说更容易上手，恕我直言。

也就是说，问题来了： 1. 如果您不打算在不同的机器上设置它，您将无法解决负载问题。非关系存储在磁盘或内存方面的效率不如 MySQL 实例。 2. 两者都以 JSON 格式存储数据。如果您的日志记录组件不使用 JSON，则需要对其进行编码。 3. 如果你依赖正则表达式，Couch 不会这样做。蒙哥会。

Mindas 说得对，他说非关系存储通过剥离关系存储的基本方面来实现其规模：ACID 事务、强类型数据、明确定义的结构、优化的连接关系、高效的数据存储。

也就是说，具有有限生命周期的日志记录、可变内容和扁平结构是文档存储的理想选择，并且不需要太多的基础架构。我已经花费了数十年的时间来构建关系结构，这些结构适用于系统的 90%，并通过一系列变通方法将其余部分硬塞进去。

对我来说，非关系型存储提供了以更自然的形式保持扁平、模式变化的数据的机会。

我希望这可以帮助您找到适合您的路径。

【讨论】：

实际上，我使用 PostgreSQL 是因为它（假定）具有更高的并发率（尽管我发现它和 InnoDB 之间没有太大区别）。我认为你和 Mindas 都是对的，负载应该由更快的磁盘来处理，而不是尝试新的数据库系统。也许我应该去找一个提供 SSD 而不是 RAID 的主机。
或者您可以购买第二个用于日志记录和离线分析的盒子。如果你这样做了，你可以以最适合你的优势和加载/查询的任何形式存储它，而不会影响你的生产箱。