On Friday, 15 April 2022 at 17:47:48 UTC+1 nicolas...@gmail.com wrote: > any feedback is welcome. >
The only feedback I can give is from your reading your documentation, which appears at this point to be very vague. I was looking for a proper architectural white paper that says exactly what CAP and transaction serializability tradeoffs you're making. The nearest I could find was this one-page "tech design": https://docs.matrixorigin.io/0.3.0/MatrixOne/Overview/MatrixOne-Tech-Design/matrixone-techdesign/ It's full of general statements like *"consistency protocols are proposed to ensure the consistency of replicate logs. Common consistency protocols include Paxos and Raft"* - rather than saying exactly what MatrixOne has chosen to do. There is a link that says "Please refer to AOE Technical Design <https://docs.matrixorigin.io/0.3.0/rfcs/20211210_aoe_overall_design.md> for more details", but that link gives a 404 error. Searching for the word "isolation", it appears in the glossary only, and nowhere else. In comparison, CockroachDB <https://www.cockroachlabs.com/docs/v21.2/architecture/overview.html> and FoundationDB <https://apple.github.io/foundationdb/technical-overview.html> have a ton of detailed documentation saying *exactly* how they handle things like overlapping transactions, consistency, node failures, shard splitting etc; and these change over time as they revisit the design decisions and trade-offs they made. I'm not saying you are positioning yourself against those two particular databases. I just give them as examples where the level of documentation is good enough to evaluate the database design for a particular application. Otherwise, I think it's a dangerous claim to make that MatrixOne suits almost all database use cases. For example, many use cases value data consistency and durability far above performance. If you're saying MatrixOne can match the consistency and durability of the best SQL databases, *and* give higher performance, then that is a bold claim to make without detailed justification. What level of stress and regression testing are you doing? Are you running any Jepsen-like scenarios? The happy path is easy to get right - dealing with all possible failure modes is hard. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c0972709-f2c9-4f08-bafc-35ff5cc4c2aan%40googlegroups.com.
