
Datomic: Can Simple be also Fast? - espeed
http://www.dotkam.com/2013/05/31/datomic-can-simple-be-also-fast/
======
ryanbrush
Whether through Datomic or something else, it seems like some version of
"database-as-a-value" (as described by Rich Hickey) is bound to happen. We're
keeping immutable version histories of as much as our hardware and systems
will allow, from source code management through other types of media. Why in
the world wouldn't we do this with our data if we could?

It'll be interesting to see how this plays out. Widespread adoption of
technology tends to follow a path of least resistance. Does Datomic offer a
simple enough path to pull many people over? I also know many of us have a
preference for building on open source systems; will this be an obstacle for
Datomic?

~~~
t0mas88
Take a look at Event Sourcing, commonly used with CQRS. The approach is indeed
to store data as change-events in an event-store (which could by a SQL
database or NoSQL store, that depends on your needs) and then built one or
more views (separate databases, Lucene indexes, files, anything really) to
service the type of requests that the application handles.

For an example of CQRS with Event Sourcing in Java:
[http://axonframework.org](http://axonframework.org)

~~~
strictfp
SQL databases also do this. They have events called 'SQL statements' which are
written to a 'journal' and applied to the domain which resides in the 'tables'
of the database :)

~~~
Tuna-Fish
You seem to not understand the point. SQL databases don't count because these
mechanisms are not visible, and the _programming model_ is changing data in
place.

No-one really cares how DB's are implemented under the hood, we just care
about the programming model. (And speed, CAP, ACID, etc...)

~~~
strictfp
I do get the point, in fact I'm building such an app right now, but my
statement is still true and I find that quite amusing.

~~~
jimbokun
Given the underlying architecture of most relational databases, is it
realistically possible to do "point in time queries", without requiring
playing back the entire log history into a clean database up to the point in
time you want? That's not going to be very efficient.

I've only seen SQL logs presented as solutions to replication and disaster
recovery, not point in time functionality.

What I'm getting at, is it even possible in principle to expose part of the
inner workings of some relational database systems to get this kind of
capability?

~~~
strictfp
Snapshotting and log replay should be fairly straightforward, if you save all
sql statements in their entirety. Snapshots would stop the world, which might
pose a problem, but I presume this is no different to other event sourcing
solutions. Given the concurrency of a db, I'm also not sure that there's a
strict ordering of all incoming statements.

Edit: Seems like at least Oracle is already doing this:
[http://en.wikipedia.org/wiki/Redo_log](http://en.wikipedia.org/wiki/Redo_log)

------
joevandyk
One database pattern I use is to have new data/events be inserted into tables.
Then use either window functions, views, and/or triggers to get a snapshot of
the most current version of the data. It takes more space, but it allows me to
figure out why the database is in the state that it is.

For example, if I want to track ups shipments, I'd set up a shipment_events
table. Every time I check the status of a shipment, I'd insert into the
shipment_events table. If the shipment changes state from in_transit to
delivered, then I'd set shipments.state="delivered".

------
philjackson
Never Trust Sheep - isn't it the sheep that spot the bugs, scaling issues in
real-world scenarios, indirectly help get the funding for the parent company
so that they can scale teams and isn't it sheep that write tools, clients and
community documentation?

~~~
rgbrgb
If you're talking about enterprise companies--the type of company where suits
often make engineering decisions--they seem to rarely release any of their
"tools, clients and community documentation".

~~~
philjackson
I'm talking about companies like mongodb, what was mysql and postgres - the
ones with the large communities (sheep).

~~~
dvanduzer
Not all flocks are made of sheep.

~~~
sliverstorm
Ah, you fancy yourselves as flocks of wolves?

~~~
dvanduzer
I don't like Mongo or MySQL. That doesn't mean other people don't have good
reasons to use those platforms.

------
est
I am always interested in Datomic's approach. How can you build a simple
thread-safe counter with it?

If you do it in a time-series db fashion, there will soon be too many facts to
count.

~~~
vmind
You can define functions inside the database and then use them inside a
transaction [1] so that you can get atomic update, if that's the question. You
can also mark attributes as noHistory [2] if you don't care about the past
state.

[1] [http://docs.datomic.com/database-
functions.html](http://docs.datomic.com/database-functions.html)

[2] [http://docs.datomic.com/schema.html](http://docs.datomic.com/schema.html)

------
wheaties
Isn't HornetQ the queue that allows one "ack" to speak for the past five
messages. That is, if I were to lose one of the past five messages I sent, I
would never know because the system would consider the message delivered. To
me, that is a severe flaw and could open you up to a nightmare of debugging if
used improperly. Either go full acks or go ack-less.

~~~
leif
Sounds like mongodb's batched write semantics.

