Community mailing list archives

community@mail.odoo.com

Re: Odoo on Crate Craziness

by
DevCO Colombia , David Arnold
- 08/02/2016 03:18:47
Hi Raphael, thanks for pointing this out! I think your efforts are definitely queued for deeper analysis going forward. Let me describe a devised pattern with crate as this as the persistency layer (let's not call it "database" for the sake of properly scoped conceptualization):
- Use a resilient (probably therefore single) write entry point
- Use the whole power of heavily distributed queries in crate for reads.

This would not only affect e-commerce, but improve the responsiveness of somewhat considerable BI operations throughout the whole ERP Stack, as it is not forked off at the application layer but rather plugged in as the underlying primary persistence solution.

Of course there are alternatives, like PostgresXL, but they are not new and shiny (coordinating layer in bash/ash/zsh and breaking on alpine). And: Being new and shiny nowadays is a very successful mindset! The bold (!) "disregard and rebuild paradigm" has brought many very interesting innovations to us throughout the last few years... ;)

El mar., 2 ago. 2016 a las 1:13, Raphaël Valyi (<rvalyi@akretion.com>) escribió:
Hello David,

We have some customers in production with the Solr connector but sadly the economic crisis in Brazil is impacting this customer so our dev with solr is a bit frozen at the moment. On the other hand, for our new ecommerce, we are starting with Algolia a hosted no-SQL index much like Solr. So we developed an Algolia exporter that you can find here: https://github.com/akretion/connector-nosql
Eventually we will refactor/reimplement a Solr or ElasticSearch connector again if we have enough customers on this product to afford it.
Not idea about crate sorry.

Regards.
On Mon, Aug 1, 2016 at 11:37 PM, David Arnold <dar@devco.co> wrote:

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 ;-)

Kristian Koci <kristian.koci@gmail.com> schrieb am Mo., 1. Aug. 2016 um 10:52:
Interesting David

Going to check it out

Do you plan to port a fork into crate.io or something?

Or is this more or less like an addition to Odoo?
On Mon, Aug 1, 2016 at 9:13 AM, Cody Kitterman <ckitterm@gmail.com> 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...



On Monday, August 1, 2016, David Arnold <dar@devco.co> wrote:
From crate docs: "If a query specification results in a get operation, 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?

El dom., 31 jul. 2016 a las 23:35, David Arnold (<dar@devco.co>) escribió:
Some related infos:
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
El dom., 31 jul. 2016 a las 23:07, Kristian Koci (<kristian.koci@gmail.com>) escribió:
Sounds very interesting

Tell us more about it :P, do You have an idea so far?
On Sun, Jul 31, 2016 at 10:12 PM, David Arnold <dar@devco.co> wrote:
Hi,

who is in for investigating some Odoo on Crate.io craziness? 
Stuff keeps changing... :)

Best,

David

_______________________________________________




--
Kristian Koci
Linux User #582221

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--
Kristian Koci
Linux User #582221

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe

_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe




--
Raphaël Valyi
Founder and consultant
+55 21 3942-2434


_______________________________________________
Mailing-List: https://www.odoo.com/groups/community-59
Post to: mailto:community@mail.odoo.com
Unsubscribe: https://www.odoo.com/groups?unsubscribe