Re:SQL is 43 years old – Here’s why we still use it today
by scarface74 on Tuesday May 02, 2017 @08:42AM
(#14245858)
I've reached a point where my default design is relational database augmented with memcache/redis. The relational DB is the authoritative source of truth, redis absorbs all (most) reads and memcache is, well a distributed cache. Writes go to both redis and relational. Redis data can always be rebuilt, and is regularly rebuilt, from relational data.
I'm really becoming a big fan of CQRS/event sourcing where we have two read models - one NoSql for live data and one relational for BI/Reporting. Events are stored separately in JSON because that's how they come in anyway through the API.
Re:SQL is 43 years old – Here’s why we still use it today
by remotehack on Tuesday May 02, 2017 @10:27PM
(#14252558)
Wow. Let the maintenance begin.
Re:SQL is 43 years old – Here’s why we still use it today
by scarface74 on Wednesday May 03, 2017 @09:25AM
(#14255424)
CQRS is not rocket science. In any case, your schema for your reporting database is usually different from your online database.
At project onset, usually only redis or memcache are in use.
It's a model that has served me well, apart from bugs that cause divergence between redis and relational. These are usually the class of bugs that would corrupt data were I relying on redis alone, so I just think of them as a lesser evil.
There's an obvious bottleneck on writes to the relational DB but I've so far managed to keep from hitting that ceiling.