-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AQL: Filter Search #14
Comments
Group and count amenities (this is pretty fast, ~500ms): RETURN MERGE(
FOR doc IN arangobnb
FOR a IN doc.amenities
COLLECT amenity = a WITH COUNT INTO count
RETURN { [amenity]: count }
) It's apparently free-text, not sure how suitable it is for auto-complete. We could still display a list of everything that has a count of over 20 or so and provide auto-complete for that. To implement this server side, we would need another View and collection (update periodically with a Foxx job?). |
Why the merge? This seems to provide the expected results and is ~150ms:
This could have a LIMIT and then we could have a separate query for text search. WDYT? |
MERGE() is merely used to create a mapping, amenity to count, instead of returning an object per amenity with two keys. It's just for displaying the result in a more compact way here. 150ms is still not particularly fast for production purposes if we consider that this is Berlin only and that query caching would potentially not help in a real world application where the data changes quite often. It's fine for demonstration purposes, but this seems like an important point if we want to show scalability. |
We can get this down to around 1ms if we combine it with the I would need to test the performance of loading the increased number of markers with each map drag, instead of only adding new ones. Increasing the LIMIT on the listings returned does not add much to the query time, it would just be a matter of response time.
|
Returning the filters with the results, increasing the number of listings returned, and displaying more markers on-screen has a negligible performance impact.
This results in a fast query that is able to return the filters found in the results as well as filter the results based on user-selected criteria. This also takes advantage of more ArangoSearch optimization with However, the new issue that has arisen is the need to refactor the map markers to handle the higher volume and update when filters are selected.
|
The AQL query that support #13 to allow for keywords to restrict the results shown. This may be a search over the description of the rental or whatever makes the most sense for the dataset.
The text was updated successfully, but these errors were encountered: