re: nested data structure is in the roadmap, but no target date yet. There are 2 ways of implementing this:
1) pre-pend field name reflecting the nesting, much like elasticsearch
2) encoding payloads in the term list indicating nested nature.
1) is straightforward, but can be restrictive if you want to in-nest faceting.
We are still debating on the route to take.
As for schema changes, we should document that better: certain schema changes simply requires you bouncing the node, but if there are data integrity changes, you would need to reindex. We will work on more documentation on the specifics.
My apologies for the confusion! The intent of the page is to provide a transparency of data guarantees in the database language. And the goal is to provide an explanation of trade-offs between respect performance and data distribution and the strong ACID guarantees of a database. Any suggestions of wording changes is greatly appreciated!
Database-side aggregation is something in the works. We are incorporating a patch as we speak. We find more and more in house projects using Sensei as a BI tool, we see this functionality more and more important, so stay tuned :)
Would you guys be interested in collaborating on that? At Mozilla, we've been using ElasticSearch in a few places as a NoSQL style BI tool. I read through the SenseiDB docs and can see many places it could be almost as good of a fit as ES, and with a little work, I bet it could be just the thing.
We love Kafka!