Rya AdministrationClient Configuration Status Quo Currently Rya configuration
- Slides: 5
Rya Administration/Client Configuration
Status Quo • Currently Rya configuration is completely delegated to the client • Client creates a configuration object that contains deployment specific information: – How all the triples in the instance have been serialized – What secondary indexers are currently enabled
Issues with Status Quo • It is very easy for a client to screw this up and potentially corrupt the Rya instance • Example: – – User doesn’t know geo indexing is enabled User only configures pre-computed joins and free text indexing User inserts a ton of data Geo index now is out of date with other indexes • Even worse example: – User doesn’t know that the hash prefix for individual rows has been enabled to improve ingest performance – User doesn’t set that configuration value to true – User inserts tons of data – All of Rya is now corrupted!
Potential solutions • Introduction of some sort of a service layer to arbitrate inserts • Moving deployment specific configuration out of the client set up
Moving to a centralized configuration • Have the Rya instance store some of the administration information: – Whether prefix hashing is enabled – Secondary indexers – Other things? • Thoughts on this approach? – What are some administrative information that we should move out of the client? – How do we want installation to look? How do we make this easier?
