re: Storing user customisations and settings. How do you do it? VIEW POST

FULL DISCUSSION
 

Hi, PostgreSQL + JSON is a nice solution, however, I didn't test it under heavy load.

I will recommend you also to take a look at Aerospike, specially this Use Case related to User Profile (aerospike.com/solutions/technology...).

I believe it matches the desired features, however, it is expensive, therefore you would need to measure again, or just ignore it if cost is not a problem (unlikely).

Hope my comment can help you to find the ultimate solution.

NOTE: I didn't any list Aerospike features here, just take a deep look to the website! And you will see, it rocks!

BTW picking one database helps, but usage patterns, sharding, caching and so on cannot be underestimated. So consider hybrid (crazy) solutions as well. This site highscalability.com/ has a lot of good examples and sketches.

Have fun!

 

Thank you for the comment and the links. I'll give them a good read tomorrow morning before work!

I've actually fought with this decision a lot and, I've actually ended up using two databases.

MongoDB for the settings.
Postgres for relational items.

There's a whole heap of reasons why I decided to go this route and many of them are in the omitted detail behind my original post, but I wanted to keep the question broad enough to provoke some answers without getting buried in details.

Ultimately though, it's come down to:

  • Finding adapters, access methods, ORMs etc. that would play nicely across an existing website and existing set of integrations into other systems drove me in the direction that right now it feels as though the world needs to catch up with JSONB (Specifically) being available through psql. I've actually got quite a decent setup right now where I can query across and join multiple data sources regardless to the underlying db which means the pain is quite low for me to incorporate more into my architecture.

  • Im fine with running multiple databases, if they have a clear purpose and scope. Settings and only settings are required to be stored in my doc store and I'm happy with that model. It also means I can move towards beta much quicker based on my already known data model from the old system.

  • Familiarity.. I took a good look into the postgres queries and execution required to pull data out as well as running updates and modifications to the JSONB structures. There's a lot of functions, a lot of new principles to understand which right now, I could waste a lot of time on without moving forward in my development timeline. I'll definitely be coming back to it, but I am much more productive at this stage running due to what I know.

  • Docker made it too easy.

  • I have a few services which actually need to know info about the settings (message bots/chat bots) so encapsulating the doc store with relevant APIs around it has turned it into a service for others.

code of conduct - report abuse