如何在Cloud Datastore中进行搜索 [英] How to search in Cloud Datastore

查看:102
本文介绍了如何在Cloud Datastore中进行搜索的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

E.g。我正在建造一个房地产目录。我需要,一堆属性和搜索参数,如客厅数量,城市,地图上的区域,价格范围等。这里可能的组合数量可以轻松超过200个指标限制。

或者这是某种基于标签的搜索。这里的变化数量几乎是无限的。



如果我理解正确,Cloud Datastore不适合这种情况。但根据我的经验,几乎所有我正在开发的应用程序都需要这样的功能那么,云数据存储是否仅适用于直接单键搜索? Plus Search API可以处理全文搜索。但就是这些。这似乎是不对的,所以我假设我在这里错过了一些基本点。

可能有一些额外的索引服务吗?或架构解决方案?

解决方案


因此,云数据存储仅适用于直接单键
仅搜索?


显然不是 - 您最多可以使用200个组合索引。我承认,对于某些应用程序来说,这可能还不够,但对于每个索引属性,数据存储区保留的任何数量的隐式索引都是不合适的。 在这种情况下,可能需要其他解决方案。也许甚至是将数据存储与其他索引技术相结合的混合?不知道,我还没有尝试过,因为我还没有遇到这样的需求。



但是在你的特定例子中,恕我直言,你可以使它适合200限制在实际功能上没有显着的损失。简单地通过不提供所有可能的组合 - 他们真的,真的需要吗?就我个人而言,我会发现在房地产应用程序中进行超过几十次(更不用说200次)各种搜索的能力,而不是混乱/压倒性的。

例如,如果没有指定其他2个参数,您是否可以通过价格范围,卧室数量或城市数量进行搜索?也许对于好奇,但恕我直言,没有真正的实际用途。如果你同意,那么简单地要求所有3个参数,而不是允许他们的任何组合,将有效地减少你所需的复合索引总数到原来的1/8。

也许按升序和降序对结果进行排序的能力并不那么重要 - 对于每个参数只有一个方向排序的复合索引数量可以减少一半。在高度主观的房地产环境中,排序不仅仅是一些属性,也可能没有多大价值。更少的排序组合 - 更少的组合索引。



仔细查看参数数量和实际意义上的组合数量。削减不是绝对需要的东西,也许你可以找到一个体面的妥协方案,而不需要你去更复杂的方法。


E.g. I'm building a real estate catalog. I need, well, bunch of properties and search by parameters like number of living rooms, city, area on the map, price range etc. The number of possible combinations here can easily exceed 200 indexes limit.

Or this is some kind of tag-based search. Number of variations here is nearly infinite.

If I understood it correctly, Cloud Datastore is not capable for such cases. But from my experience nearly all apps I was working on require such functionality. So, is Cloud Datastore suitable only for straight forward single-key search only? Plus Search API can handle full-text search. But that's all. That seems not right, so i assume I'm missing some fundamental point here.

May be there are some additional services for indexing? Or architectural solutions?

解决方案

So, Cloud Datastore suitable only for straight forward single-key search only?

Obviously not - you can use up to 200 composite indexes. And any number of the implicit indexes that the datastore keeps for each indexed property.

That may not be enough for some apps, I admit. In that case some other solution would probably be needed. Maybe even a hybrid combining the datastore with some other indexing technique? Not sure, I didn't try one yet as I didn't yet encounter such need.

But IMHO in your particular example you could make it fit in the 200 limit without a significant loss in practical functionality. Simply by not offering all the possible combinations - are they all really, really needed? Personally I'd find the ability to do more than a few dozens (let alone 200) different kinds of searches in a real estate application rather cluttering/overwhelming.

For example - does it make sense to search by either of price range, number of bedrooms or city only without specifying the other 2 parameters? Maybe for the curious, but IMHO without a real practical use. If you agree then simply requiring all 3 parameters instead of allowing any combination of them will effectively reduce your total number of required composite indexes to 1/8 of the original.

Or maybe the ability of sorting results in both ascending and descending order is not that critical - you can half the number of composite indexes for every parameter you sort by in only one direction. Sorting by more than just a few properties can also be of little value in the highly subjective real estate context. Less sorting combinations - fewer composite indexes.

Take a closer look at the number of parameters and the number of combinations that make practical sense. Cut what is not absolutely needed, maybe you can find a decent-enough compromise which doesn't require you to go to a more complicated approach.

这篇关于如何在Cloud Datastore中进行搜索的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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