Community mailing list archives
Re: Odoo on Crate Crazinessby
After I read all this, I think resilience guarantees are still not strong enough. But I guess in one years time, as elasticsearch becomes more resilient, and newer versions are incorporated into crate, ir is definitely a candidate to look for. Wasn't akretion working on a solr integration because they were unhappy with read performance just as I am? Crate is like bringing this idea to the next level.
However Jodok, the Co-Founder told me that the single entry write strategy would need to be handeled by the application. I guess that's fine, however I'd like to keep monitoring this space, as there IS a more general use case also for applications like ERPs, which habe a very characteristic DB read/write pattern.
Single write entriy strategy i guess could alteady be solved by a simple load balancer and rule based routing. Not alltogether bad ;-)Or is this more or less like an addition to Odoo?Do you plan to port a fork into crate.io or something?Interesting DavidGoing to check it outOn Mon, Aug 1, 2016 at 9:13 AM, Cody Kitterman <firstname.lastname@example.org> wrote:
Dave:I haven't had time to read through yet, but it sounds a lot like "Lambda architecture", am I right? Food for thought, either way...From crate docs: "If a query specification results in a
getoperation, changes are visible immediately. This is achieved by looking up the document in the translog first, which will always have the most recent version of the document. The common update and fetch use-case is therefore possible. If a client updates a row and that row is looked up by its primary key after that update the changes will always be visible, since the information will be retrieved directly from the translog. " sounds like good news, "client" presumably being the odoo codebase talking to the db backend. This would mean, even in a scaled out odoo application, if user sessions are sticky - a common pattern -, from the perspective of one single user, the DB appears to be always consistent. Am I right?
Questions:- atomicity only on the row level might probably not be enough.- No Transactions, what's optimistic concurrency control?Some related infos:Here is a list of be-tested soltions: https://github.com/aphyr/jepsenIt would be nice to get a clearer picture on pareto efficiency of such a solution, because one need to understand:Benefits can come at a cost, but those cost can only affect the beneficial part, so there should be an unbiased assessment as there can be a fair chance of being overall "better" (= pareto efficient).I think, if it's possible to eliminate concurrent writes out of the equation, the most business critical problem class disappears and writes architecture would be "quite" similar to the actual postgres setup, while batteries still included: speed of distributed reads, HA, replication, leadership election, split brain healing, etc.Do you know if one of the be-tested solutions https://github.com/aphyr/jepsen allows to specify a sinlge write point?Best