Le 02 févr. 2017 à 20:00, Rob Nikander écrivait :
> Hi,
>
> I'm working on a project with multiple different data storage backends. I'd
> like to consolidate and use Postgres for more things. In one new situation
> we're starting to use Redis, thinking it will perform better than Postgres for
> a table that is updated a lot by concurrent background jobs.
>
> I'm skeptical of no-sql stuff for various reasons. I'm wondering what PG
> experts think -- is there is a way to configure Postgres to handle a table
> differently, so that it could compete with Redis? Or are there some workloads
> where it is definitely better to use an alternative data store?
>
> This table will have a few million rows, five small columns. Rows will be
> updated, read, or inserted 5-10 million times a day, by concurrent processes.
> It operates like a key-value store in that most selects will be getting one
> row, and maybe updating that row. Ideally these processes could work without
> stepping on each other's toes and competing for locks.
>
> Rob
>
>
Hi!
While I have found existing tools for benchmarking both postgres and
redis (hammerdb by eg), AFAIK they are not compatible with custom
queries.
I wonder if such procedure would give some precise insight:
For each database kind:
1. ask the community to optimise your design
2. create your optimised table
3. populate the database
4. write a scripting program with both postgres/redis connectors and
able to run concurent queries (python?)
5. write methods to run queries (insert/update) for both database kind
6. get the timing
7. return to 1. or next
8. give your feedback to both communities
