Beanstalk 与 DB
我正在编写一个数据库日志记录 ruby gem，它将简单地从 Beanstalk 队列中取出一个作业并将其写入数据库中。
服务器 A 上的一个进程将一项作业（它想要记录的）放入服务器 B 上的 Beanstalk 队列中，服务器 B 上的日志进程将其取出并将其写入服务器 B 上的 mysql DB。
我想知道这值得吗？ 将作业放入 Beanstalk 队列比写入数据库更快。或者我想要记录到数据库的进程可以直接将其写入数据库而不是使用日志记录进程。
请注意，beanstalk 服务器和数据库都位于另一台服务器上。
Beanstalk 在内部进行从服务器 A 到服务器 B 的套接字调用。 我相信mysql也需要做同样的事情？
因此，mysql 到另一台服务器会比放入 beanstalk 队列慢。
I am writing a db logging ruby gem which will simply take out a job from a Beanstalk queue and write it in the DB.
That is one process on Server A puts a job (that it wants to log) in the Beanstalk queue on Server B, and my logging process on Server B takes it out and writes it to the mysql DB on Server B.
I want to know if this is worth it?
Is putting a job in the Beanstalk queue faster than writing to the DB. Or can my process that wants to log to DB directly write it to DB instead of using the logging process.
Note that both the beanstalk server and DB are on another server.
Beanstalk internally makes a socket call from Server A to Server B.
I believe mysql would need to do the same as well?
So therefore is mysql to another server going to be slower than putting in the beanstalk queue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
它会快得多，主要是因为默认情况下 Beanstalkd 作业存储在内存中 并且会丢失，例如，如果您的服务器断电，而 MySQL 是一个强 ACID 兼容的关系数据库，因此将花费大量精力将每个日志刷新到磁盘。
我想您会发现，在对系统生成的大量日志进行一些基准测试后，磁盘 I/O 将成为您的限制因素，而不是 TCP/IP 套接字的速度。当前系统的优点是，当服务器 A 在服务器 B 的 beanstalkd 实例上归档日志时，它只占用服务器 A 的很少的时间，并且服务器 B 可以定期将我们的许多日志从 beanstalkd 一次性刷新到 MySQL，从而使该过程更加高效。缺点是，批处理日志越多，在软件/电源故障时丢失的日志就越多，除非您使用 beanstalkd 的“-b”参数，该参数通过将作业写入磁盘来使作业持久化（因此使过程变慢）。
当然，真正解决这个问题的唯一方法就是对标！
It'll be much faster, primarily because Beanstalkd jobs, by default, are stored in-memory and are lost if, for example, you lose power on your server, whereas MySQL is a strongly ACID-compliant relational database, and hence will go to a lot of effort and flush each of your logs to disk.
I think you'll find that, after your do some benchmarking with a lot of logs being made by your system, that disk I/O will be your limiting factor, rather than the speed of TCP/IP sockets. Your current system's advantage is that when server A files a log on Server B's beanstalkd instance it takes up very little of Server A's time, and Server B can periodically flush our many logs at once from beanstalkd to MySQL, making the process more efficient. The disadvantage is that, the more you batch up the logs, the more logs you will lose in the event of a software / power failure, unless you use beanstalkd's "-b" parameter which makes jobs durable by writing them to disk (and hence making the process slower).
Of course, the only way to truly settle this question is to benchmark!