Thompsonbry.systap added a comment.
The analytic query mode does offer some ability to bound memory but it is not
100% across all queries. For example, quads mode queries do not currently put
the distinct triple pattern filter on the native heap. ORDER BY is not
currently on the native heap, property paths are not currently on the native
heap (though they now support incremental eviction and are executed much more
efficiently). Also the native DISTINCT solutions operator can not be used with
queries that must preserve order (e.g., where LIMIT or ORDER BY are in use).
Finally, we do not buffer the input queues for the operators on the native heap
in the analytic query mode. These things all limit our ability to strictly
bound native memory usage.
You probably also want to place a limit on the #of solutions emerging from an
unconstrained join (full Cartesian cross product). The ability to do this is
built into a least the solution set hash join operators.
It sounds like we should define an interface with a variety of query complexity
and similar security options and then expose a means to configure that
interface so we can coordinate the enabling and disabling of relevant features
as well as collocate the set of features that could be of concern. I suggest
creating a ticket at trac.bigdata.com for this and cross linking it with your
issue tracker. We can then work to define the appropriate interface and ensure
that the desired restrictions can be enforced.
The HTTP interface can be made read-only via a web.xml configuration. See
SparqlEndpointConfig and web.xml. However, this does not restrict your ability
to have a plugin for the database that listens to the update feed and applies
mutations. Thus you can make it read-only to the world but still get updates.
if (getConfig(servletContext).readOnly) {
buildAndCommitResponse(resp, HTTP_METHOD_NOT_ALLOWED, MIME_TEXT_PLAIN,
"Not writable.");
// Not writable. Response has been committed.
return false;
}
TASK DETAIL
https://phabricator.wikimedia.org/T90115
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign
<username>.
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: csteipp, Thompsonbry.systap
Cc: GWicke, Thompsonbry.systap, Smalyshev, Joe, Liuxinyu970226, csteipp,
Beebs.systap, Haasepeter, Aklapper, Manybubbles, jkroll, Wikidata-bugs,
Jdouglas, aude, daniel, JanZerebecki
_______________________________________________
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
