Amazon SQS是处理数据库分析日志数据的好工具吗？

Question

我们有一些nodejs服务器,其中每个请求的详细信息和有效负载需要记录到SQL Server以进行报告和其他业务分析.

服务器之间的请求数量和需求相似性让我想通过集中式日志服务来解决这个问题.我的第一直觉是使用类似Amazon SQS的东西,让它直接作为SQL Server的缓冲区,或者构建一个小的日志记录服务器,这将使SQS指导数据库调用.

这对SQS来说听起来是不是很好用,还是我缺少一个广泛使用的工具来完成这项任务？

Answer 1

解决方案将取决于您使用的数据量,因为每项服务都有限制.仅举几例:

SQS

• 首先,因为您正在处理日志,所以您不希望重复.考虑到这一点,您需要一个FIFO(先进先出)队列.
• SQS本身并没有真正调用任何东西.什么你想在这里做的是设置队列,然后拨打电话通过AWS JS SDK提交的消息.然后,当你在你的回调得到消息回来,得到的消息ID和数据传递到被调用的lambda函数(你可以写在那些作为的NodeJS孔)存储在您的数据库所需要的信息.
• 这就是说知道SQS队列中的消息有大小限制很重要:

最小消息大小为1个字节(1个字符).最大值为262,144字节(256 KB).

要发送大于256 KB的消息,你可以使用Java的亚马逊SQS扩展客户端库.该库允许您发送包含在Amazon S3的消息负载参考亚马逊SQS消息.最大有效负载大小为2 GB.

CloudWatch Logs

(不要与高级云监视服务本身混淆,后者更多是发送指标)

• 这里的想法是您将事件数据提交给CloudWatch日志
• 它也有一个限制:

事件大小:256 KB(最大).此限制无法更改

• 与SQS不同,CloudWatch日志可以自动将日志数据传递给Lambda,然后可以将其写入SQL服务器.AWS文档解释了如何设置它.

S3

只需设置一个存储桶,让服务器向其写入数据.这里的好处是,由于S3用于存储大文件,因此您实际上不必担心前面提到的大小限制.S3存储桶还具有可以触发lambda函数的事件.然后,您可以愉快地继续发送徽标数据.

如果您的日志数据足够大,您可以扩展到AWS Batch之类的东西,它可以为您提供可用于处理日志数据的容器集群.最后,您还可以获得数据备份.如果您的数据库发生故障,您就会将日志数据存储在S3中,并且可以将一个脚本放在一起以加载所有内容.您还可以使用生命周期策略将旧数据迁移到成本较低的存储,或者直接将其全部删除.