Postgres Hstore 与 Redis - 性能方面
我阅读了关于 Postgres中的HStores的内容Redis 也提供了这一点。
我们的应用程序是用 NodeJS 编写的。两个问题：
性能方面，Postgres HStore 与 Redis 相当吗？
对于会话存储，您会推荐什么 - Redis 或具有其他类型数据类型的 Postgres（例如 HStore，甚至可能是常见的关系表）？一个选项与另一个选项相比有多糟糕？
另一个限制是，我们需要使用 PostgreSQL 中已有的数据并将其与活动会话结合起来（我们目前不确定存储在 Redis 或 PostgreSQL 中的位置）。
根据我们所读到的内容，我们被指出使用 Redis 作为会话管理器，但由于 PostgreSQL 的限制，我们不确定如何将两者结合起来以及可能出现的性能问题。
谢谢！
I read about HStores in Postgres something that is offered by Redis as well.
Our application is written in NodeJS. Two questions:
Performance-wise, is Postgres HStore comparable to Redis?
for session storage, what would you recommend--Redis, or Postgres with some other kind of data type (like HStore, or maybe even the usual relational table)? And how bad is one option vs the other?
Another constraint, is that we will need to use the data that is already in PostgreSQL and combine it with the active sessions (which we aren't sure where to store at this point, if in Redis or PostgreSQL).
From what we have read, we have been pointed out to use Redis as a Session manager, but due to the PostgreSQL constraint, we are not sure how to combine both and the possible performance issues that may arise.
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Redis 会比 Postgres 更快，因为 Pg 为您的数据提供可靠性保证（当提交事务时，保证它位于磁盘上），而 Redis 有一个在需要时写入磁盘的概念，所以不应该用于关键数据。
Redis 似乎是存储会话数据的不错选择，甚至可以存储在 cookie 或客户端 Javascript 中。但是，如果您的每个请求都需要数据库中的数据，那么可能甚至不值得使用 Redis。这很大程度上取决于您的应用程序。
Redis will be faster than Postgres because Pg offers reliability guarantees on your data (when the transaction is committed, it is guaranteed to be on disk), whereas Redis has a concept of writing to disk when it feels like it, so shouldn't be used for critical data.
Redis seems like a good option for your session data, or heck even store in a cookie or in your client side Javascript. But if you need data from your database on every request then it might not be even worth involving Redis. It very much depends on your application.
使用 PostgreSQL 作为会话管理器通常是个坏主意。
对于 9.1 之前的版本，每秒事务的物理限制基于持久媒体参数。对于会话管理，您通常不需要 MGA（因为没有冲突），这意味着 MGA 是开销，并且没有 MGA 和 ACID 的数据库必须明显更快（10 或 100）。
我知道一个用例，其中 PostgreSQL 用于会话管理，性能非常糟糕且不稳定 - 这是一个有大约 10000 个活动会话的 eshop。当会话管理转移到 memcached 时，性能和稳定性显着提高。 PostgreSQL 可以使用 100 个活动会话，可能没有问题。对于更高的数字，有更好的工具。
Using PostgreSQL as session manager is usually bad idea.
For older than 9.1 was physical limit of transaction per second based on persistent media parameters. For session management you usually don't need MGA (because there are not collision) and it means so MGA is overhead and databases without MGA and ACID must be significantly faster (10 or 100).
I know a use case, where PostgreSQL was used for session management and Performance was really terrible and unstable - it was eshop with about 10000 living sessions. When session management was moved to memcached, then performance and stability was significantly increased. PostgreSQL can be used for 100 living session without problem probably. For higher numbers there are better tools.