Where does that page claim perfect ACID semantics? It's meant to describe what Sensei gives you for each aspect of ACID.
Sensei needs an event stream to process. We've open-sourced and apache-fied Kafka which is a great candidate for an event stream. For Atomicity and Isolation, the event stream must provide these guarantees.
Consistency is handled with a routing parameter. Requests partitioned around an id will always go to the same searcher, so they won't go backwards in the stream except in failure scenarios. This is eventually consistent, but tries to keep things sane.
Durability: The event stream helps with this. We don't immediately flush while indexing in Lucene, so if there's a crash we can replay the persistent event stream.
Does this make sense? SenseiDB is not intended for purely transactional processing. For some applications, sensei would make a good candidate for replacing your DB. For others, not so much.
Where does that page claim perfect ACID semantics? It's meant to describe what Sensei gives you for each aspect of ACID.
And they're all well and good features! I can tell SenseiDB isn't transactional. Like I said, I skimmed the source and understand at a high level what it's does. I could see it being very useful in certain conditions as LinkedIn currently does and I'm sure others will.
However, I think the copy is confusing (at least it was for me). On the guarantees page there's an "ACID-ity" headline. For each aspect of ACID, as you say, the page describes what Sensei offers. The confusing part was that I was mentally comparing each aspect against what I understand to be the common semantics of ACID. I think it would be more clear if there was some distinction under the main headline that acknowledges this difference.
I think the structure of the page is probably confusing people. The big header on the page is "Data guarantees: Things we promise on how we manage your data," and the first subheader underneath that is "ACID-ity". This strongly (even if unintentionally) suggests that you guarantee ACID-compliance.
I'd suggest rewriting the copy as something along these lines:
# Data guarantees: How we manage your data
## Not quite ACID (and that's not a bad thing)
Although the principles of ACID are important, strict conformance has its costs. Sometimes it's the right tradeoff — but not always. By relaxing those requirements, Sensei can offer superior performance and durability. Here's how we approach the four ACID principles, and why you might prefer to do things Sensei's way:
Sensei needs an event stream to process. We've open-sourced and apache-fied Kafka which is a great candidate for an event stream. For Atomicity and Isolation, the event stream must provide these guarantees.
Consistency is handled with a routing parameter. Requests partitioned around an id will always go to the same searcher, so they won't go backwards in the stream except in failure scenarios. This is eventually consistent, but tries to keep things sane.
Durability: The event stream helps with this. We don't immediately flush while indexing in Lucene, so if there's a crash we can replay the persistent event stream.
Does this make sense? SenseiDB is not intended for purely transactional processing. For some applications, sensei would make a good candidate for replacing your DB. For others, not so much.