3 ms·
Looks like someone non-LinkedIn posted this so the rest of the team is unlikely to be around for a few more hours. Let me know if you have any questions! I work
by joshhart 15y ago
Looks like someone non-LinkedIn posted this so the rest of the team is unlikely to be around for a few more hours. Let me know if you have any questions! I worked mostly on the distribution & rpc piece.
- threepointone 15y agoCongratulations on the project, and compliments on the breadth of documentation. Nicely done. (Nitpick - none of the urls change. Some js error where you're not doing a pushState? You should report this.) edit - this works -http://senseidb.github.com/sensei/index.html http://senseidb.github.com/sensei/index.html
- joshhart 15y agoThanks! I'll make sure that gets corrected.
- lemming 15y agoHow does the consistency model work? I saw the page describing the eventual consistency referred to a routing parameter (which I assumes routes to the same node to enforce read-your-writes), but I assume you can have conflicts between writes from separate sessions? How is the conflict resolution handled?
- joshhart 15y agoThis is exactly how it works. Queries based on some kind of id will always hit the same server, except when the server goes down. Sensei expects a semi-durable "data stream" for writes, which is very different from how most other databases work. Imagine a near-real time processing system though where updates go into a queue to be processes (financial transactions work like this). SenseiDB works great for indexing these types of events. Text search is a good example here - after you update your profile, it's put into a queue to be indexed. We don't want to wait for your profile to be indexed before we'll let you move onto another page.