代码之家 › 专栏 › 技术社区 › coolk

rdbms的自动保存性能

scalability performance

coolk · 技术社区 · 7 年前

在我的应用程序中,我想自动保存为用户类型的一些内容中的用户类型。save调用并不是针对每次击键,而是仅当用户暂停超过200ms时才自动保存。因此,在一个典型的段落中,有15-20个服务器调用。内容不会经常阅读,所以我需要优化写作。

我正在考虑的一种方法是,不直接将数据保存在mssql中,而是将其保存在Cassandra或redis中,然后最终(可能以固定的时间间隔)将其写入mssql。

更新: 我用对2个表的简单更新调用替换了现有逻辑,现在我看到了改进。有一个很长的存储过程,在负载下最多需要10秒。所以现在我还没有解决这个问题。不过,我想知道我是否可以在应用服务器层上做些什么来减少频繁的DB调用。

1 回复 | 直到 7 年前

rlb 7 年前

很难直接回答你的问题,但这里有一些基于我们在多个活跃用户情况下所做的提示。

如果每次击键时都要写入/触发,请将击键传递到后台线程,不要执行数据库写入或任何网络调用,同时阻止用户键入。一个打字速度快的打字员每秒可以击20次键,你无法承受延迟。

你真的需要保存每一次击键,还是每N秒一次可以接受?每个保存操作最终都会变成一个磁盘操作,因此您确实希望合并尽可能多的保存。做某事最快的方法就是根本不做。

如果您正在记录到数据库,那么更新现有行通常会更快,前提是您可以先通过直接键获取它。不幸的是,有时插入新行并在以后清理多余的行会更快。如果表的索引很少,则情况往往如此。哪个更快取决于正在使用的数据库引擎及其使用方式。我们使用这两种方法。

在使用数据库时,请记住,它们通常会保存某种类型的日志,因此如果您经常更新,则可能会在日志文件上产生较大的负载。

如果您正在使用诸如fopen之类的技术(使用C术语),那么fwrite这些技术可以很好地执行,但如果您担心系统故障恢复,则可能需要调用fsync,这会限制您的最大性能速率。如果需要fsync,数据库可能更好。

您可能希望考虑非常频繁地写入transactionlog表,然后每N秒发布到实际存储器。例如,如果我输入一个客户的名字,我可能会将每次击键记录到一个keylog表中,然后让后台作业读取keylog表并将数据传输到customers表。这有助于减少对customers表的操作,同时允许优化keylog表以记录击键。但是,以服务器端的更多代码为代价。

总的来说,你需要这样的逻辑

关于键控处理器

唤醒背景线程

背景线程

作为一项操作写入数据库/网络/文件等。(现在可以是同步呼叫)

记住以上内容,用户可以键入并立即点击close,因此您的最终缓冲区写入可能尚未刷新。你需要处理这件事。

如果正确,用户将不会注意到任何延迟。在我们的使用中,我们平均每秒记录约1000次击键,所有击键都通过专用网络路由到中心点。这种负载几乎是暂时的,即使网络监控也看不到如此少量的流量。