Re: PG vs ElasticSearch for Logs - Mailing list pgsql-general

From Merlin Moncure
Subject Re: PG vs ElasticSearch for Logs
Date
Msg-id CAHyXU0zbX7F=yJiDM8FyMKJ01yir6v5YbdLQ9cvg1rh7FVpwbQ@mail.gmail.com
Whole thread Raw
In response to PG vs ElasticSearch for Logs  (Thomas Güttler <guettliml@thomas-guettler.de>)
List pgsql-general
On Fri, Aug 19, 2016 at 2:32 AM, Thomas Güttler
<guettliml@thomas-guettler.de> wrote:
> I want to store logs in a simple table.
>
> Here my columns:
>
>   Primary-key (auto generated)
>   timestamp
>   host
>   service-on-host
>   loglevel
>   msg
>   json (optional)
>
> I am unsure which DB to choose: Postgres, ElasticSearch or ...?

We use SOLR (which is similar to ElasticSearch) here for json document
retrieval.  Agreeing to do this was one of the biggest mistakes in my
professional career.  This choice was somewhat forced because at the
time jsonb was not baked.  In my opinion, jsonb outclasses these types
of services particularly if you are already invested in postgres.  The
specifics of your requirements also plays into this decision
naturally.  The bottom line though is that these kinds of systems are
not nearly as fast or robust as they claim to be particularly if you
wander off the use cases they are engineered for (like needing
transactions or joins for example).  They also tend to be fairly
opaque in how they operate and the supporting tooling is laughable
relative to established database systems.

Postgres OTOH can be made to do pretty much anything given sufficient
expertise and a progressive attitude.

merlin


pgsql-general by date:

Previous
From: Francisco Olarte
Date:
Subject: Re: Limit Heap Fetches / Rows Removed by Filter in Index Scans
Next
From: Andy Colson
Date:
Subject: Re: PG vs ElasticSearch for Logs