处理 MongoDB 中的架构更改

发布于 12-10 23:49 字数 790 浏览 0 评论 0原文

我在我的一个 Java 项目中使用 MongoDB。在数据库架构更改之后,我发现自己在很多地方修改了现有代码来执行更改,例如:

Object result = collection.findOne();

现在

Object result = collection.findOne().get("ThisField").get("ThatField");

,在 findOne() 情况下,事情相对简单,但它们变得更加复杂当 find() 和关联的光标开始运行时。

在大多数情况下,如果我可以修改查询,而不是其结果,事情会容易得多。我已经尝试过 仅检索特定字段,但是据我所知,这只会掩盖其余字段 - 它不会改变对象的结构。

  • 是否可以指定一个查询,以便将构成特定字段值的对象“提升”为顶级对象,从而删除 .get("this").get(" that") 调用?

  • 更进一步,MongoDB 是否支持与视图等效的任何内容,正如传统数据库中所见?可能允许现有代码在架构更改的情况下继续工作?

I use MongoDB in one of my Java projects. After a DB schema change, I found myself modifying existing code at a lot of places to perform the change from e.g.:

Object result = collection.findOne();

to

Object result = collection.findOne().get("ThisField").get("ThatField");

Now, things are relatively simple in the findOne() case, but they get more complex when find() and the associated cursors come to play.

In most cases, it would have been far easier if I could modify the query, rather than its result. I have already experimented with retrieving specfic fields only, but as far as I can tell, that only masks the rest of the fields - it does not change the structure of the object.

  • Is it possible to specify a query so that the objects that form the values of a specific field are "promoted" to a top-level object, thus removing the .get("this").get("that") calls?

  • As a further step, does MongoDB support any equivalent to the views, as seen in conventional databases? Something that might allow existing code to continue working in case of a schema change?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

謸气贵蔟2024-12-17 23:49:33

MongoDB 目前似乎没有任何相当于关系数据库视图的服务器端。 MongoDB Map/Reduce 支持 显然只适合批量操作,这使得它对于实时更新的在线数据库。

作为解决方法,我转向了客户端解决方案。我利用了 Java 驱动程序是开源的这一事实,因此我可以轻松地弄清楚它的结构。

更具体地说,我能够扩展和 替换感兴趣的集合的默认 BSON 解码器,并透明地重新定位已移动的字段。

It seems that MongoDB does not currently have any server-side equivalent of the relational database views. The MongoDB Map/Reduce support is apparently suitable only for batch operations, which makes it useless for an online database with real-time updates.

As a workaround, I turned to a client-side solution. I took advantage of the fact that the Java driver is open source and thus I could easily work out how it is structured.

More specifically, I was able to extend and replace the default BSON decoder for the collections of interest and transparently relocate the fields that had moved.

把人绕傻吧2024-12-17 23:49:33

第二个问题的答案可能是Map/Reduce函数。但是,有一些注意事项:

  • Map/Reduce 通常用于进行聚合计算,但可以用作视图,因为它将遍历集合中的每个对象并生成一个输出集合,其中您的文档所在聚合(计数、总和等)或转换(对于每个文档,如果存在 ThisField,则返回 ThisField,否则返回 ThatField

  • 它在服务器上运行,因此您可以安排作业来生成集合(代表视图的概念);但是,您需要考虑MapReduce 不适合在线查询。它旨在执行后台作业以非常有效地转换数据,但不运行查询(除非您只有一个小集合)。

因此,我要补充一点,如果您想“迁移”模式,您可以运行映射/归约并将其保存为具有新模式的新永久集合。要继续针对新模式进行编程,您所需要做的就是使用新集合。

The answer to your second question is probably a Map/Reduce function. However, there are some considerations:

  • Map/Reduce is usually to do aggregate calculations, but can be used as a View in the sense that it will go through every object in the collection and will generate an output collection where your documents are aggregated (counts, sums, etc.) or are transformed (for each document, if ThisField is present return ThisField, otherwise return ThatField)

  • It runs on the server so you can schedule jobs to generate your collections (representing the concept of a View); however, you need to consider that MapReduce is not good for online queries. It is intended to do background jobs to transform data very efficiently, but not to run queries (unless you only have a small collection).

So I would add that if you want to 'migrate' your schema, you could run a map/reduce and save it as a new permanent collection with the new schema. All you need to do to continue programming against the new schema is to use the new collection.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文