我有一些人的主表。我的Django应用程序中的所有内容都与一个或多个人相关,或者直接或通过长fk链。而且,我所有的模型都有标准的记账字段“created_at”和“updated_at”。我想在Person表上添加一个名为“last_active_at”的字段,主要用于原始sql排序。在
创建或编辑某些相关模型会为这些对象生成新的时间戳。我需要用这些值更新Person'last'u active_at'。从功能上来说,这并不难实现,但我担心应用程序会受到过度压力。在
我最担心的两个原因是我被限制在一个真正的db字段中——我不能将函数作为@property分配给Person表——其中一个“活动”模型从我无法控制的外部数据源接收和处理新实例,偶尔一次接收大量数据。在
我的第一个想法是在“活动”模型中添加一个post_save钩子。看起来还是我最好的选择,但我对他们一无所知,他们对数据库的冲击有多大等等
我的第二个想法是写一些脚本,通过一天的活动,并在晚上更新这些模型。不过,我的雇主是“活”的。在
我的第三个想法是修改post_save algo,以检查“updated_at”是否与此人的“last_active_at”相差不到半小时,如果为真,则不更新此人。在
我的想法是否在向可扩展的方向发展?我还有其他的方法吗?在
有人说,过早优化是所有问题的根源。你应该从最简单的实现开始(每次都要更新),然后测量并(如果需要的话)用更有效的方法替换它。在
首先,让我们使用一个方法来更新
last_active_at
上的last_active_at
字段。这样,所有的更新逻辑都集中在这里,我们以后可以很容易地修改它。在这些信号非常容易使用:它只是声明一个函数并将其注册为一个接收器,它将在每次发出信号时运行。完整的解释请参见the documentation,但以下是它可能的样子:
至于更新本身,从最愚蠢的方法开始。在
^{pr2}$然后测量并判断是否有问题。如果这是个问题,你可以做的一些事情是:
这些只是一些基于你的提议,但正确的选择取决于你的数据类型。确定你要承受什么样的负荷,这个领域需要什么样的反应时间,然后进行实验。在
相关问题 更多 >
编程相关推荐