I've seen the best success in the NoSQL world when you treat data like a history book rather than a moment in time.
What I mean by this is creating entities, mutating them, and trying to maintain a state is the natural pattern to assume, but it is often wrong. It leads to a many issues reported here and elsewhere and people declaring "such and such DB sucks". This is a SQL approach to using data and NoSQL fails badly at this generally speaking and should not be used to store "state" since state often requires ACID and relationships.
Treating data as a history book, or log of events over time is a safer way to use NoSQL as an authoritative source. It plays well with their ability to scale simply and naturally and event data has no relations. Everything in the single event is immutable as it is a fact of occurrence. Invalidating a past event is as simple as generating a later event that says that event is now invalid from this point in time.
From this you can generate "entities" which describe a relationship between your events. From your log data you can generate a session, for instance. These are not authoritative sources and if found to be invalid you recalculate the entity, or state, from the collection of events.
I could create an entire social network profile for a person by aggregating and querying the history of events that make up their current state. And the real power is I can generate their state at precisely any point in time in the past and possibly predict what their state will be in the future based on their past stream of events and derivative states. If a past event was found to be invalid, a new event declares this and with a greater timestamp authorizes that fact and I can recalculate the entity that describes their "current state".
This takes work and thought though and one of the promises you've seen from some NoSQL vendors is they save you work. The work is always there but you need to get comfortable thinking of data in a different way and not all data needs this approach. But, in many cases, NoSQL is not trash.
It really does and can be extrapolated to many, many use cases.
To me, this is the real power of document data stores. It's not for everything such as configuration or business rule data. But for a lot of generated data in the form of events it's a useful way to organize data.
What I mean by this is creating entities, mutating them, and trying to maintain a state is the natural pattern to assume, but it is often wrong. It leads to a many issues reported here and elsewhere and people declaring "such and such DB sucks". This is a SQL approach to using data and NoSQL fails badly at this generally speaking and should not be used to store "state" since state often requires ACID and relationships.
Treating data as a history book, or log of events over time is a safer way to use NoSQL as an authoritative source. It plays well with their ability to scale simply and naturally and event data has no relations. Everything in the single event is immutable as it is a fact of occurrence. Invalidating a past event is as simple as generating a later event that says that event is now invalid from this point in time.
From this you can generate "entities" which describe a relationship between your events. From your log data you can generate a session, for instance. These are not authoritative sources and if found to be invalid you recalculate the entity, or state, from the collection of events.
I could create an entire social network profile for a person by aggregating and querying the history of events that make up their current state. And the real power is I can generate their state at precisely any point in time in the past and possibly predict what their state will be in the future based on their past stream of events and derivative states. If a past event was found to be invalid, a new event declares this and with a greater timestamp authorizes that fact and I can recalculate the entity that describes their "current state".
This takes work and thought though and one of the promises you've seen from some NoSQL vendors is they save you work. The work is always there but you need to get comfortable thinking of data in a different way and not all data needs this approach. But, in many cases, NoSQL is not trash.