Судя по:
https://wiki.postgresql.org/wiki/PGStrom
хранение всей базы в оперативке как и в Redis для PostgreSQL тоже иногда используется

заинтересовался Redis из-за его быстрой работы со списками, множествами

интересно, PostgreSQL в этом плане сильно проигрывает по скорости Redis-у?

ursidosanyock2...

интересно, PostgreSQL в этом плане сильно проигрывает по скорости Redis-у?

Вы давно перестали пить коньяк по утрам? (с)

я Redis то еще и не использовал толком, так читаю про него, пробую

а с PostgreSQL упражнялся только на небольших базах

обратил внимание, что для Redis клиенты оптимизированы очень хорошо для закачки миллионов key-value за несколько секунд, сетевой канал очень эффективно при этом используется

http://www.opennet.ru/opennews/art.shtml?num=41333

Для выполнения заданий на GPU задействован OpenCL. Из присутствующих на данной стадии развития проекта ограничений отмечается возможность использования GPU только для данных, хранимых в оперативной памяти. Увеличение производительности операций слияния таких таблиц при использовании GPU увеличивается в десятки раз.

пишут про решение через sharding:
https://github.com/twitter/twemproxy

но что будет, если все приложения одновременно возжелают обратиться к одним и тем же данным ....

Redis is single threaded. How can I exploit multiple CPU / cores?

It's very unlikely that CPU becomes your bottleneck with Redis, as usually Redis is either memory or network bound. For instance, using pipelining Redis running on an average Linux system can deliver even 500k requests per second, so if your application mainly uses O(N) or O(log(N)) commands, it is hardly going to use too much CPU.

However, to maximize CPU usage you can start multiple instances of Redis in the same box and treat them as different servers. At some point a single box may not be enough anyway, so if you want to use multiple CPUs you can start thinking of some way to shard earlier.

You can find more information about using multiple Redis instances in the

http://redis.io/topics/partitioning

Parallelism has a cost: with the multiple sockets/multiple cores you can find on modern hardware, synchronization between threads is extremely expensive. On the other hand, the bottleneck of an efficient storage engine like Redis is very often the network, well before the CPU. Isolated event loops (which require no synchronization) are therefore seen as a good design to build efficient, scalable, servers.

With high-end configurations, the number of client connections is also an important factor. Being based on epoll/kqueue, the Redis event loop is quite scalable. Redis has already been benchmarked at more than 60000 connections, and was still able to sustain 50000 q/s in these conditions. As a rule of thumb, an instance with 30000 connections can only process half the throughput achievable with 100 connections.