|
On 30.04.2017 16:25, Steve Atkins
wrote:
You can use postgresql for caching, but caches don't require the data durability that a database offers, and can be implemented much more efficiently. I for one can understand Thomas' need for a single solution. Just recently I needed a cache which was supposed to be set up in a SERIALIZABLE manner as in https://www.postgresql.org/docs/devel/static/transaction-iso.html#xact-serializable Available cache mechanisms would have produce erroneous results. So, I went for PG. But it's still a cache, isn't it? You can use postgresql to provide message queue services and it does so reasonably well, particularly when the messages are generated within the database. But it's not going to do so as efficiently, or be as easy to monitor, to make highly redundant or to scale across a whole datacenter as a dedicated message queue service. You could use postgresql to store binary blobs, but it'd be a horrifically inefficient way to do it. (Using postgresql to store the metadata, while the content is stored elsewhere, sure). Use the right tool for the job. I think it's not as easy as ads and buzz words make us believe it is. Especially when it comes to reinventing the wheel, I prefer a single solution. With the better JSON support, PG made NoSQL obsolete. I don't see why this cannot happen with blob storage and massive scale out. Just a matter of time, if you ask me. Regards, Sven |
