Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Elasticsearch SQL

elastic.co

Post reply on HN
Print view View original

21–30 of 63 posts

Re: Elasticsearch SQL

#21

Post by BeefySwain »

yarg wrote: post #20
bearjaws wrote: post #10

I look forward to a future where everything is SQL at this point. It seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data. I recently started using Steampipe and it has made my life about 30x better not having to deal with the AWS or Slack API. Essentially a tool to let you query their APIs using SQL, behind the scenes it boots up a Postgres dat…

The syntax is still backward though. > SELECT blah FROM source vs > FROM source SELECT blah Fixing this would permit some very useful developer features.

Is this the part where I mention that trailing commas should be permitted?

Re: Elasticsearch SQL

#22

Post by chasil »

Beltalowda wrote: post #12
bearjaws wrote: post #10

I look forward to a future where everything is SQL at this point. It seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data. I recently started using Steampipe and it has made my life about 30x better not having to deal with the AWS or Slack API. Essentially a tool to let you query their APIs using SQL, behind the scenes it boots up a Postgres dat…

The biggest upshot of SQL is that it makes migrating from one system to the next a lot easier. I can write something against SQLite or PostgreSQL, and when it comes time to move to $something_else for a particular aspect for some reason I ... just can, without having to rewrite the lot. Of course, not all is perfect because no one actually supports ANSI SQL, and everyone has their own extensions and incompatibilities…

There is plenty of lock-in with commercial databases, although the problem is improving.

SQL/PSM originated with Oracle, and the ADA syntax is slowly creeping into many database products (but notably not Microsoft/Sybase).

If you use PSM, then a number of database products are off the table.

https://en.wikipedia.org/wiki/SQL/PSM

Re: Elasticsearch SQL

#23

Post by jefurii »

Why the f*** couldn't they just build Elasticsearch with a SQL query language from the start? I hate their JSON query syntax and now that this is out I feel like I wasted all the time I spent making my applications work with it.

Re: Elasticsearch SQL

#24

Post by ignoramous »

bearjaws wrote: post #10

I look forward to a future where everything is SQL at this point. It seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data. I recently started using Steampipe and it has made my life about 30x better not having to deal with the AWS or Slack API. Essentially a tool to let you query their APIs using SQL, behind the scenes it boots up a Postgres dat…

> ...seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data.

It isn't that SQL is the best way (that these solutions keep gravitating towards it), it is just that SQL is pretty much the industry standard at this point. And supporting it is a predictable and usual ploy to expand userbase further.

More so for the fact that ClickHouse continues to threaten seemingly a critical portion of the business of both Snowflake and Elastic.

Re: Elasticsearch SQL

#25

Post by slickrick216 »

yarg wrote: post #20
bearjaws wrote: post #10

I look forward to a future where everything is SQL at this point. It seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data. I recently started using Steampipe and it has made my life about 30x better not having to deal with the AWS or Slack API. Essentially a tool to let you query their APIs using SQL, behind the scenes it boots up a Postgres dat…

The syntax is still backward though. > SELECT blah FROM source vs > FROM source SELECT blah Fixing this would permit some very useful developer features.

It’s because it’s streaming I’d bet so really just a wrapper on;

index=blah | fields foo

Re: Elasticsearch SQL

#26

Post by munk-a »

bearjaws wrote: post #10

I look forward to a future where everything is SQL at this point. It seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data. I recently started using Steampipe and it has made my life about 30x better not having to deal with the AWS or Slack API. Essentially a tool to let you query their APIs using SQL, behind the scenes it boots up a Postgres dat…

Nothing could quite match my disappointment when I realized that Splunk (a large scale logging storage and retrieval product) decided to create a Splunk Query Language and eschew SQL... except maybe when I realized that they had no equivalent of `val IN(1,2,3...)` instead requiring `val = 1 OR val = 2 OR val = 3 ...`

I have taught several non-techy business analyst type people how to write SQL during my years of employment - it really isn't that hard when most of the time it's just "SELECT what you want FROM where you want it" and teaching more complex concepts when and if they come up.

Re: Elasticsearch SQL

#28

Post by munk-a »

BeefySwain wrote: post #21
yarg wrote: post #20

Earlier quoted context omitted.

The syntax is still backward though. > SELECT blah FROM source vs > FROM source SELECT blah Fixing this would permit some very useful developer features.

Is this the part where I mention that trailing commas should be permitted?

I'd really like to see trailing commas and I think in most cases they wouldn't actually break with standards requirements. I can accept that I don't have a perfect knowledge of SQL and may be wrong, but I believe `, FROM` `, WHERE` `, LIMIT` would all be pretty easy to detect.

Re: Elasticsearch SQL

#29

Post by ransom1538 »

bearjaws wrote: post #10

I look forward to a future where everything is SQL at this point. It seems we have spent a significant amount of effort avoiding it, but it time and time again is the best way to query your data. I recently started using Steampipe and it has made my life about 30x better not having to deal with the AWS or Slack API. Essentially a tool to let you query their APIs using SQL, behind the scenes it boots up a Postgres dat…

Put me at any company. Give me a mysql/oracle/etc replica to look at tables with SQL. I will understand your business pretty quickly. Give me a "key/value" store, i know nothing -- until i read the code.
Post reply on HN