Todd Nine created USERGRID-470:
----------------------------------
Summary: Implement an upper bound on field delta for a given
entity type
Key: USERGRID-470
URL: https://issues.apache.org/jira/browse/USERGRID-470
Project: Usergrid
Issue Type: Story
Reporter: Todd Nine
Currently users can change fields in an entity type at will. This causes
severe performance bottlenecks, because the master must apply mapping to all
writes in ES as the new document flows through the write path. Usergrid
should detect this issue, and stop accepting new formats from the users. Note
that this is not a limit on the number of fields in an entity type, but rather
the number of unique fields that can appear for a given type over type. I.E
every POST/PUT should not add a new field type to the entity.
Per Dave's suggestions, I think we should perform the following.
*Implementation*
# Create a local guava cache that will hold unique type count by application
and collection type. This should refresh on a set timer in the background so
our user does not wait for it. This can create a hotspot and will put load on
the master.
# If the number of uniquely mapped fields passes a set threshold (at the system
level), an error is returned to the user, indicating they have too many field
changes in their document.
*To rectify*
# A "remove mapping" call into our query index module will need to be created
# This will remove the mapping for the type, and allow the users to start
constructing their data model again. Note that users may need to delete their
entities to remove them from the system to avoid them bloating the mapping
again.
TO DO: Figure out how to allow our users to trigger this remove mapping. It's
an admin function, and we want to ensure they know what the repercussions are
when they trigger it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
