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 -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
