更新mongodb中异步复制数据的最佳实践 [英] Best practices to update asynchronously duplicated data in mongodb

查看:47
本文介绍了更新mongodb中异步复制数据的最佳实践的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在权衡从关系SQL数据库迁移到Web应用程序的mongodb的利弊.这是因为性能问题*.

I am weighing the pros and cons of migrating from a relation SQL database to mongodb for a web application. This for performance issues*.

将所有对象相关性存储在对象本身中,可以快速读取" ,以向用户显示数据.另一方面,一些数据存在于不同的集合中(例如,用户名既在用户集合中,又在评论集合中).我想知道如何处理此重复数据的更新,以便也具有快速写入" .

Storing all object dependencies in the object itself permits quick "reads" for displaying data to users. On the other hand, some data are presents in different collections (for example username is in the users collection but also in the comments collection). I am wondering how to deal with updates of this duplicated data in order to also have quick "writes".

我想避免同步处理这些重复项的更新.

I would like to avoid dealing with the updates of these duplications synchronously.

您有哪些异步更新选项?有好的做法吗?

我对此的想法是依赖于特定的mongodb机制(我不知道),或将所需的更新堆叠在memcache/redis/zeromq引擎中,以由独立进程异步播放.

(*)我的问题不是关于如何优化联接,索引和sql数据库引擎,SO上的其他帖子对此进行了讨论.

推荐答案

基本上,您有3个选择:

Basically you have 3 options:

  1. 只需存储 userId ,然后分别获取用户.这样一来,您始终可以获得最新数据方面的最佳结果.但是,它当然要慢一些.关系数据库基本上就是这样做的.SQL DB只会查看外键并通过id来获取数据.

  1. Just store the userId and then fetch the user seperately. This way you always get the optimal results in terms of fresh data. But of course it is slower. That's basically what a relational database does. A SQL DB will just have a look at the foreign key and fetch the data by id.

包含过时的数据.将用户名的副本存储在注释中.有时这是期望的行为,因为这样您就可以准确地表示数据的存储状态.这意味着:如果John创建了一条注释,后来他的用户名被更新为Paul,您仍然可以看到,这是作为John创建的.(对于发票而言,这尤其有用,当您在此引用某人并且地址发生更改时,您不想更新旧发票的地址)

Live with out of date data. Store a duplicate of the username inside the comments. Sometimes this is desired behavior, because this way you can represent the data exactly as it was when it was stored. This means: If John creates a comment and later his username gets updated to Paul, you are still able to see, that is has been created as John. (This is especially useful for i.e. invoices, when you reference a person there and the address changes, than you don't want to update the address of an old invoice)

当用户名更新时,更新包含用户名的所有内容.这也不错,因为用户名通常不应更改.因此读取总是很快的,因为名称存储在注释中.而且,如果名称更改,则必须更新涉及用户的所有内容.当然,这是一个缓慢的任务,但是因为它不应该每分钟都发生,所以可以容忍.

Update everything that contains a username, when the username gets updated. This isn't bad either, because a username should normally never change. So reads will always be fast, because the name is stored inside the comment. And if the name changes, you've got to update everything where the user is involved. This is a slow task of course, but because it shouldn't happen every minute, it's tolerable.

3.1您可以优化:如果用户名更改,则将其存储在某个地方并在午夜应用.这样,您可以收集多个名称更改并同时更新所有内容.

3.1 You could optimize things: if username changes, this gets stored somewhere and been applied at midnight. This way you can collect multiple name changes and update everything at the same time.

如您所见: NoSQL是您的选择.您可以做最适合您数据的事情.当然,这始终是一个权衡:速度更快/更慢,编写的代码更少/更多,维护更容易/更难.

As you can see: NoSQL is about choice. You can do the things that fit your data best. Of course it's always a tradeoff: Slower/faster, more/less code to write, easier/harder to maintain.

总结为:

  1. 快速写入,一致的数据,慢速读取
  2. 快速写入,连续数据,快速读取
  3. 在更新过程之后,快速写入,快速读取和数据保持一致,这可能需要一些时间.而且更新过程当然很慢.

这篇关于更新mongodb中异步复制数据的最佳实践的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆