
Eva – A distributed entity-attribute-value database in Clojure - CurrentB
https://github.com/Workiva/eva/
======
CurrentB
I'm excited that some of the ideas from Datomic are starting to make it into
some open source projects. With crux last month and now Eva, there are now
multiple options for modern clojure databases.

While there are many excellent ideas embedded in Datomic and these projects,
for me just being able to persist the same data structures you're using at a
repl and query for them with data is a huge win vs having to start translating
types and concepts and query strings to and from SQL is a huge win.

~~~
eternalban
I suspect by "ideas from Datomic" you are referring to ideas predating Datomic
(and Clojure) that are _used and possibly refined_ in Datomic.

~~~
abc_lisper
I think he meant to say they were not mainstream

------
lwb
> Workiva has decided to discontinue closed development on Eva, but sees a
> great deal of potential value in opening the code base to the OSS community.

I'm confused -- does this mean that Workiva themselves are not using Eva? Or
are they still using it, but not officially developing it any more? If they
were really invested in it, why would they only allow employees to work on it
in their 10% time?

~~~
glesica
It was open sourced because it was a cool piece of technology and it would
have been a shame to keep it back, but it is no longer in use at Workiva.

Source: I work there, although I have literally nothing to do with this
project.

~~~
lwb
Interesting! Are you guys switching to another EAV store like Datomic or
something else?

------
methehack
Question for Eva and Datomic users: How often does your org miss having a
separate relational database around for data folks and product folks capable
of (read only) SQL? Do you find yourself making a separate store/s to support
them?

~~~
valw
One thing that's nice with Datomic (don't know about Eva, but probably the
same) is that syncing data to other stores is straightforward, thanks in
particular to the the easy change detection.

------
FpUser
Oh sweet memories

I have created almost identical implementation of this as an embeddable
library in a year 2000 along with proprietary SQL language. The reason was
that my client had inventory of products with some crazy amount of attributes
and each product can have its own set and the client kept changing, creating,
deleting those. It was in memory but with persistence and atomic transactions.
No history though. It was blindingly fast on complex queries. And the schema
of the database was kept as a set of entities with some predefined names,
values and range of id's .

For a while I was contemplating releasing it as a standalone product but as I
had enough tasks on my plate decided not to do it. Kinda feel sorry now ;(

So all in all very close by idea.

------
marcrosoft
Last time I saw the EAV pattern used was in Magento. It was an absolute
nightmare to query against.

~~~
jwr
I don't think Magento used it right.

I used EAV in an application and it was fine (I used Datascript on the client-
side, with server-side data being stored in a JSON document database,
RethinkDB). I did run into some annoying issues with the lack of nil value
handling. I'd say writing queries was difficult, but not significantly more
difficult than in any other language, if you care about performance and want
to know what the query actually does.

Overall, I felt there was a good mapping between my domain model and EAV.

I eventually dropped this solution in favor of Clojure data structures: if you
have an in-memory (in-browser) database anyway, why keep the data in
Datascript, if you can simply keep it as ClojureScript data structures?

~~~
gouggoug
As I mentioned here:
[https://news.ycombinator.com/item?id=20308175](https://news.ycombinator.com/item?id=20308175)
, I think Magento did use it right, but EAV is impractical on a relational
database not designed for EAV. This fact, however, doesn't show itself until
you've reached a certain (arguably low by today's standards) scale.

------
znpy
If someone wants to really make money, please clone the Versant Object
Database.

~~~
emmanueloga_
Can someone explains how anybody is willing to even give a chance to a
software product that is sold like this? [1]

* Generic/"bootstrappy" looking site, mostly marketing speak.

* Not even one code example of what it looks like to solve a problem with this DB.

* Gigantic "Get a Trial" button that links to a lengthy form that I'm sure has 99% abandonment rate.

There are a lot of other software products that are marketed like this, so I'm
genuinely curious how this works.

1: [https://www.actian.com/data-management/nosql-object-
database...](https://www.actian.com/data-management/nosql-object-database/)

~~~
znpy
> "the website uses bootstrap, the product must be crap"

congrats on speaking about a product you haven't even tried.

------
briandear
The name of this is a bit confusing since there is another language by the
same name that also is related to databases:
[https://link.springer.com/chapter/10.1007/978-3-7091-7557-6_...](https://link.springer.com/chapter/10.1007/978-3-7091-7557-6_61)

------
AtlasBarfed
E-A-V is basically a JSON/BSON document store, perhaps with typing. Anything
that distinguishes it from those datastores?

~~~
refset
It's the other covering indexes (i.e. AVE, AEV, VAE) that make it interesting
because they allow the query engine to perform efficient ad-hoc graph
traversals.

------
foobar_
EAV is the best schema. How you can do NoSQL in SQL.

------
beders
Glad to see another contender in the EAVT field! Yay!

------
AtlasBarfed
AP or CP?

~~~
refset
Definitely CP. With Eva and Datomic, transactions are serialised through a
single transactor node at a time.

The transaction log design is a fundamental design tradeoff that
Eva/Datomic/Crux share, which means system throughput is limited by the
throughput of a single process. The argument in favour of such a design is
that most businesses & business applications don't actually experience
transactional data volumes over 10K tx/sec.

------
Dowwie
EAV is generally an anti-pattern. How does Eva break away from its long, dark
history?

~~~
lukev
I reject the premise of your statement. It's only a failure when implemented
on top of relational databases which are (obviously) not optimized for it.

What are the failures of EAV except when applying it to a database optimized
for something different?

