_______________________________________________Hi Samuel,
Thanks for the question (and attending our WDC session!).
Our plan is still currently to migrate off of Blazegraph as our primary priority for scaling WDQS. Our main goal in the first half of this calendar year is to identify a viable alternative to Blazegraph, and answer some questions around what a technical scaling plan looks like.
As mentioned in the Jan scaling update, Andrea Westerinen has just joined our team as a Contract Graph Consultant, and will be helping us with identifying a Blazegraph replacement. Please visit her (sub)page(s) for some more good information, questions and discussions on the process!
Mike
On 29January, 2022 at 11:23:00, Samuel Klein (meta.sj@gmail.com) wrote:
_______________________________________________Thanks Mike! A plan shared at WDC was to migrate off of blazegraph "as soon as a viable alternative is identified" – is that still the plan? As how does this affect scaling work?On Fri, Jan 28, 2022 at 3:55 PM Thad Guidry <thadguidry@gmail.com> wrote:Yes it does, I'll add my comment to the discussion then:
"As the Search team has looked into this already and stated they see no alternative to knowing which users are issuing problematic queries that can bring down the service to all, then I think to ensure minimum availability to all users that authentication should be required.As came up in the live discussion about this (I don't recall if notes were published somewhere, or I'd link them) -- there are other ways to guess which Query Service user or session issued a problematic query without requiring full authentication; and there is no evidence that problematic query generators would try to get around simpler ways of identifying their session (or try to ignore clear feedback that their query was harmful).'Requiring all users to auth' has known immediate downsides, and still won't prevent a user from reissuing a problematic query, until some process for feedback + warning is implemented. So it doesn't seem like an obvious next step even if it turns out to be important in the end //SJ
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-leave@lists.wikimedia.org
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-leave@lists.wikimedia.org