leading people to Event Sourcing (which sometimes doesn’t end well especially once CQRS gets involved).
Oooh, why? Tbh, I have been totally sold on event sourcing..
mmport80
2
yurko
Database is a tool that we sometimes overuse, but I think dropping it completely would solve nothing and will probably cause more harm then good.
I agree with @cmkarlsson in that we must differentiate between the “permanent” kind of data that is meant to be held in the Database and will probably outlive the app and other kinds that do not belong there. If the application only has “other kinds” of data then it’s a good case to go database-less, I never had a chance to work on such an app as of yet though 
2
jeremyjh
I don’t think event source applications typically would apply the change to application state before it is written to durable storage. Typically a write to the log (e.g. Kafka) is the first thing that happens.
2
peerreynders
Which makes sense if consistency is the primary concern (e.g. bank accounts) - waiting for the write to complete is going to delay updating application state - as always, it’s about making tradeoffs.
Usually because they go for CQRS/ES - Martin Fowler comments on it in his CQRS portion of his talk.
3
dwahyudi
There are some ways to build an OLAP (analytical) and OLTP (transactional), each of them serve different purpose. And btw, most of the time, indexing on both of them are using B-Tree, which is good enough. Other indexing types are okay and good if used correctly. We can think relational database as a safe-zone to store our data, before we contemplate to use other faster and specific-purpose of storage. That is, I prefer to look really carefully on my tools before I scale and relational database is probably the safest (although not fastest) approach, because:
- It has ACID principle, full featured transactions, and lots of useful constraints,
- It has the most supporting tools available,
- It is one of the oldest technology,
- It is backed by giant corporations and math
.
I do say that RDBMS is the safe-zone, because it has the smallest possibility of being dead in comparison to other storage products.
I think, unless we are building the next Alibaba or Linkedin, RDBMS is good enough.
Though, I also use cache in my apps (redis or ETS) to quicken things up.
N.B. And that’s why I thankful that Ecto is more explicit than ActiveRecord, I no longer stuck fixing N+1 query ever again in Phoenix. This is a basic thing to do, but gives dramatic performance improvements in some cases.
3
hubertlepicki
There’s a few more cases where I would say it’s not good enough in addition to “massive systems” that you have in mind here I think too, but generally I agree with all that you are saying. For highly event-driven systems (such as backing IoT or messaging, game servers) they don’t really have to be massive for making sense for stuff to run in memory / other type of storage than RDBMS
2
mkunikow
mmport80
I wonder what’s the difference between the Erleans ‘Grain’ approach, and a garden variety NoSQL database… It seems to be kind of reinventing the wheel, no?
In my head, something like Joe Armstrong’s save-binary-to-disk idea, seems more natural (but also more restrictive, in terms of the amount of storage) but not reinventing the wheel either.
1
mmport80
In a way that’s what riak_core and now lasp are - your application is your database.
I never heard of Lasp before - thanks for this.
They both have an emphasis on distribution - I’d rather something simpler. Like SQLite, but just binary data..
0
namelos
Some times stateful solutions are very useful and powerful, and it could simplify a lot of things for modern/future apps.
Say we are creating a react, which mostly would having a datastore in the front-end, and views observes the data store and renders.
If you change something in the datastore, the views automatically changes. Instead of manually update the DOM like 10 or 15 years ago.
However if you call fetch to update a resource, you may have to refetch some resources and invalidate the cache case by case, according you business rules.
If you put the observable store concept in the back-end, over WebSocket, doing diff on back-end (could be done with generic library similar to redux and react-redux) views and push updated data, all of those case by case refetch logic could be deleted.
I feel there should be a simpler solution compared to event sourcing. Pretty much like just auto backup snapshot for actor states without event sourcing.
Event sourcing is a way to let you easily map to different projections even based on past events, which could give you great advantage of exploring business possibilities.
It’s great but might be a overkill for most of the apps. It’s really a great and beautiful functional architecture.
However, as a consultant, I keep hearing organizations fails to manage the problems caused by event sourcing – including but not limited to performance issue when bulk load projection, missing event, mental overhead. Although ideally there should be an excellent library automatically manage everything magically, because the nature of event sourcing is pretty easy. But we are not there yet. There are several implementation is really great like Akka persistence, eventsourced and other awesome libraries that cares most things for you, but yet they’re not letting you hand-off and stop worrying.
My thought there should be a light weight actor behaviour just automatically backup & persist actor state, and resume state when it fails. So that you wouldn’t have to worry about projection, event versioning, differences between commands / events etc.
I’m curious about riak_core recently but haven’t yet got time to spike anything about it. I’m not sure it could be distributed storage or actors.
I believe the ideal way of modeling is to bind callbacks with actor instead of storing them to the databases to cold data and revive them when using them, in which case they have no power to do things actively.
2