Hacker News Reader

Comment by cphoover | Hacker News Reader

Interesting. I'm not sure why I would chose this over Elasticsearch though? How does performance stack up against ElasticSearch? If the API is compatible with ES does that mean I can use the ELK stack including logstash for ingestion, and kibana for analysis?

Also... One of the things I didn't like about ES was the JSON DSL. It would be nice to create a friendlier query language, maybe something like SQL to query data. I find ES queries written to be ugly to look at, and not intuitive.

View on HN

Did you know that OpenSearch has JDBC/ODBC drivers? https://github.com/opensearch-project/sql

Manticore Search [1] is a good alternative to Elasticsearch if you prefer SQL

[1]: https://manticoresearch.com/blog/manticore-alternative-to-el...

I've been working on something similar as I dislike ES's JSON DSL or Kibana's interface: https://log-store.com/

It's not open source but old skool '90s-style freeware. The current single-node version will remain free forever, but the next multi-node (distributed) version will be for-pay.

Elasticsearch supports a subset of SQL for querying:

https://www.elastic.co/guide/en/elasticsearch/reference/curr...

Quite limited subset: only SELECTs and even that is limited, e.g. you can't do "SELECT id"

Zinc is a little too early for performance benchmarks (Still not at 1.0). fluentbit, logstash, filebeat can be used as is with ZincSearch. Kibana is not yet supported but you could use the UI of Zinc (Still in very early phase) which is embedded and you don't have to install separately.

It looks like the selling point is easier setup and operation. Elasticsearch is kind of a pain in the ass to take care of. Maybe they've made that better? That'd be valuable to me.

> Elasticsearch is kind of a pain in the ass to take care of.

Any specific issues you are referring to? At work, we've been using ES heavily for many years and it isn't really something taking up time apart from updating the software every once in a while.

Are you constantly adding new users and having to update retention policies as users try to fill up your machines?

I guess you are referring to the "log search" use case? We don't use it for that so that isn't really an issue, and it's mainly about beefing up memory / cpu.

And yeah, We definitely need a better query language. We are working on it.

perhaps a lisp DSL?

Reply on news.ycombinator.com