Hacker News Reader

Comment by polyrand | Hacker News Reader

I think replacing Elasticsearch with SQLite is a great idea. Even more if you use the full-text search functions that SQLite includes.

I recommend checking out scout[0], which, I think, can be a good replacement for Elasticsearch in some cases. I'm also working on an Elasticsearch replacement built on top of SQLite for my litements[1] project, but it will still take a few weeks to have a working version.

[0] https://github.com/coleifer/scout [1] https://github.com/litements/

View on HN

It definitely depends on what you're doing with it. In the article the author is using it to parse only nginx logs to report page hits counts - I probably would have not gone with Elasticsearch to begin with. I find it strange that the issue with InfluxDB was the lack of 'Group by'; you can use 'Distinct' with other aggregation functions with the same result - and without having to write and maintain your own stack.

I appreciate - and often indulge - in writing stacks of software that are better implemented other open source, but I wouldn't say that the article describes a solution that is viable as a replacement for Elasticsearch.

I think it's best put as a replacement for ElasticSearch for those who don't really need ElasticSearch.

Edit - i.e. where ES is overkill for the use case, however for an appropriate use case ElasticSearch is amazing

I didn't read the article, but I think this is a sizable audience.

Similar to litements litecache is DiskCache[0]. It is a pure python Redis/Memcached alternative which is faster than them for reads. Under the hood it uses shared Sqlite.

[0] https://github.com/grantjenks/python-diskcache

Yes, I’m aware of DiskCache. Wonderful library and also very useful, I enjoyed reading the source code too. I have taken a few ideas from it that I would like to implement in the future.

This is quite interesting! How can be a disk based cache be faster than redis? (They claim this on their Github page)

I would say:

1. No network round trips 2. SQLite runs in the same process as your app, so reading from SQLite is basically like calling a function in your program (from a performance point of view).

I checked the benchmarks page [0], they run the Redis in same machine. And also, running Redis in different machine and connecting over networking isn't same compared to using diskcache.

> SQLite runs in the same process as your app, so reading from SQLite is basically like calling a function in your program

But SQLlite needs to write to disk, which will be much costly.

[0] - http://www.grantjenks.com/docs/diskcache/cache-benchmarks.ht...

Reply on news.ycombinator.com