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

41–50 of 63 posts

Re: Elasticsearch SQL

#41

Post by sqlcommando »

dataminded wrote: post #31
ignoramous wrote: post #24

Earlier quoted context omitted.

> ...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 th…

What query languages have you found that are better than SQL? [edit] Typo.

https://learn.microsoft.com/en-us/azure/data-explorer/kusto/... gets linked here from time to time, along with this similar one https://github.com/prql/prql. I'm not sure either one claims SQL parity at this point but one thing they each have going for them is queries start with the entities, rather than the columns, which makes type-ahead completion more natural.

I think if you were going to do SQL over you would probably do it that way. SQL is definitely not perfect or optimal, just ubiquitous.

Re: Elasticsearch SQL

#43

Post by [deleted] »

jrochkind1 wrote: post #35
jefurii wrote: post #23

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.

I guess one question, then, is why the f** you couldn't just have used an rdmbs instead of ES from the start....

[deleted]

Re: Elasticsearch SQL

#44

Post by robertlagrant »

TotoHorner wrote: post #11
synthc wrote: post #3

Seems like all the NoSQL databases eventually implement SQL, maybe we should use EventuallySQL instead NoSQL

What other prominent NoSQL databases eventually implemented SQL for queries?

Microsoft's CosmosDB (their DocumentDB clone) has a SQL-like (yes) interface.

Re: Elasticsearch SQL

#47

Post by starik36 »

I spent a ridiculous amount of time trying to get their ODBC driver to work as a linked server from SQL Server. I opened tickets and tested various versions. Finally I just gave up because I moved to a company that wasn't using ES.

I wonder if they ever got the ODBC driver to work.

Re: Elasticsearch SQL

#48

Post by ilyt »

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…

> 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.

Meanwhile no matter how simple query I write I always manage to hit some difference between MySQL/SQLite/PostgreSQL... just recently I discovered SQLite/PostgreSQL have EXCEPT but MySQL does not.

MySQL in particular is usually the problem

Re: Elasticsearch SQL

#49

Post by stanislavb »

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…

And improving your SQL skills is almost always a good choice. No-matter what tech-role you hold at the moment.

Re: Elasticsearch SQL

#50

Post by deckard1 »

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…

> at least tweak some things

That's really understating the problem. Oracle, for example, can be wildly different from MySQL or PostgreSQL. SQLite makes selects extremely cheap, so cheap, that if you try to do a straight migration to a server-based DB it will probably just choke. Assuming any devs on your team realized the benefits of SQLite and took advantage of them.

But it gets worst with SQL on things that are not relational DBs. The exact person that SQL-on-Elasticsearch is designed for is also going to be the person that won't know the idiosyncrasies of Elasticsearch well enough to know when they are in trouble.[1] They will end up trying to get explanations for what is going on in Elasticsearch in terms of what they know (i.e. SQL on a relational DB). The end result will then be confusion and ultimately re-learning Elasticsearch from the ground up.

[1] https://youtu.be/MO0r930Sn_8?t=368

Post reply on HN