Hello everyone We started using Druid using 0.13 ...
# general
g
Hello everyone We started using Druid using 0.13 and upgraded from time to time to 0.22.1 which we are using currently. At this starting moment, using SQL seemed to us to be slightly discouraged (as a new feature) and for that, we disabled the /sql endpoint to enforce our users to use Json queries only. From reading the current docs & commits, it seems now SQL is way more stable and encouraged. Are we right in saying that after having upgraded to latest version, we could open the SQL endpoint with no issues even in production ? Could it have some drawbacks ? Are we missing something ? (maybe our first impression wasn't right 😛 )
j
Hi Giom, Yes, Druid SQL has come a long way and is pretty stable now. The new MSQ engine only supports SQL, not native query format, so if you want to use MSQ you will have to use SQL. I am a longtime Oracle and SQLServer veteran, and in the past 18 months my use of Druid queries has been exclusively via SQL. I do like the fact that SQL queries submitted against the regular (non-MSQ) engine are parsed into JSON native format, and you can view that format via the Explain facility in web console. MSQ has a similar "Explain plan for ..." syntax that you can use. I would definitely encourage you to try using it, and use this forum for help and collaboration in your efforts. Thanks. John
g
Oh I already use it myself on the UI or for testing purposes. I was more wondering about end users usage :) But I think we'll open it. Especially if it opens a wider range of possibilities like MSQ. Let's first upgrade ^^
👍 1
b
You might also look in to query laning or tiering. And either educating users or some other way, to avoid queries without time filters when possible.
My point being that it's not too hard to write ad-hoc queries that hog resources. It's a powerful tool!
(Query laning is an idea to separate end-user ad-hoc queries and other queries.)