We all know about "meeting that should've been an email" and there are too many of "session that should've been a blog post". I've heard from some people that they go to the roadmap sessions and find them valuable. What I want to ask every time: did you really have to travel to a live event for this though? The roadmap explorer is out there online. Is it really necessary to have like a public ("Hear ye, hear ye...") reading of the document?
Totally! After TechEd I was very underwhelmed and actually thought that, “well that could’ve been an email/blog post”. I wish I could’ve made it to ASUG Connect, it sounded like it was a breath of fresh air.
Look mom I'm famous, I've got my picture on the internet! It's funny to compare your session ranking to what we got at OXP, the customer stories are not as interesting as the learning and new features. And roadmap are always asked about during AMA, but Odoo generally refuses to communicate on features before they're developed.
Huh. My guess would be this is because (a) Odoo better communicates the features, use cases, etc. (b) you don't have the same "spread" in the ecosystem as SAP. Many SAP customers are running ERP versions that are decades old. This creates some interesting (and sometimes unhealthy) effects. E.g. IT professionals so busy keeping the lights up on such systems that they're struggling to keep up with what's going on. Then when it's finally an upgrade time, the knowledge gap is like Grand Canyon.
Yeah I agree with you, the "half-life" of Odoo instances are much shorter, for reference any version older than 3 years is not officially supported. I felt like being in the middle age working for the last two years on the version released in 2019 at my last company.
BTW go check odoo.com just under the list of apps for a fun reference :)
Re: It’s the stories -- I totally agree. The best TechEd presentation I saw was about how InfoZoom architected one of their processes with BTP and Stripe.
What makes you think that HANA is faster than ordinary relational databases? I mean, outside SAPs marketing? Even Hasso Plattner himself expects a 10% gain in speed at best on transactional processing once the index btree is already cached by the db-system. While in ordinary DBs you have to read the record from the hard disk, in HANA you have do go through decompression and tupel- reconstruction. In memory it's faster but considerably more workload.
In-memory DB has advantages when using aggregates. But honestly, outside analytical processing there is very very very little need for using aggregates.
What is left is that you have to rework you old code so it does not slower on HANA than with you old Oracle system, e.g. replacing SELECT * with a field list in the SELECT to limit the dictionary lookups for decompression.
Um... What makes you think it's not? Have you used it?
"Fast is not a number" is a valid point. I'm not a DBA but there are benchmark figures out there, it's not some kind of secret. Here is just one source: https://www.sap.com/dmc/exp/2018-benchmark-directory/#/sd I think these days benchmark data can be found somewhat easily if anyone is actually interested in it.
I also have a certificate of completion from Hasso Plattner's institite (HPI) for In-Memory DB course, which I highly recommend: https://open.hpi.de/courses/imdb2017 It is not SAP specific and talks about in-memory data management in general. There is a clear advantage when reading data. (Aggregation is just one specific use case.) There is less advantage when writing data. Writing has always been more "expensive" and again, it's not some "dirty secret", it's common knowledge. However, it represents much lower percentage of operations than reading data.
SELECT * (unless the whole record is actually needed) was never a good or even acceptable practice in ABAP. Never ever. Complaining about changing it as some kind of anti-HANA argument is not very impressive, sorry.
I was exactly referring to Hassos lecture at HPI when quoting him. He says that in a well tuned OLTP database you have 98-99% hit rate of cached data already. In-memory database would increase the "hit rate" to 100% but adds costs of dictionary lookups for decompression. It's in one of the introductionary sessions, my may want to look it up if interested.
He even reasons the whole in-memory architecture with the speed gain in aggregates and the usage of aggregates in OLAP while the OLTP speed advantages are miniscule. The whole in-memory processing is supposed to abolish data warehouses (as long you have only one source system) and the need of predefine the aggregations you want to have for future analytical processing. It is NOT about speeding up your transactional ERP system. More likely it will slow down because you brought back processing analytics concurrently on the same dbs.
Sorry, I'm not really sure what you are trying to argue at this point... I've already agreed that write/transactional processing is not going to be much faster. There is no story in this issue that talks about transactional processing.
The CDS story is about data reading, not writing. And the blog series I wrote about is also about fine-tuning CDS views for more efficient data selection basically. That's the only context I wrote about. Sorry if this wasn't clear.
We all know about "meeting that should've been an email" and there are too many of "session that should've been a blog post". I've heard from some people that they go to the roadmap sessions and find them valuable. What I want to ask every time: did you really have to travel to a live event for this though? The roadmap explorer is out there online. Is it really necessary to have like a public ("Hear ye, hear ye...") reading of the document?
Totally! After TechEd I was very underwhelmed and actually thought that, “well that could’ve been an email/blog post”. I wish I could’ve made it to ASUG Connect, it sounded like it was a breath of fresh air.
Look mom I'm famous, I've got my picture on the internet! It's funny to compare your session ranking to what we got at OXP, the customer stories are not as interesting as the learning and new features. And roadmap are always asked about during AMA, but Odoo generally refuses to communicate on features before they're developed.
Huh. My guess would be this is because (a) Odoo better communicates the features, use cases, etc. (b) you don't have the same "spread" in the ecosystem as SAP. Many SAP customers are running ERP versions that are decades old. This creates some interesting (and sometimes unhealthy) effects. E.g. IT professionals so busy keeping the lights up on such systems that they're struggling to keep up with what's going on. Then when it's finally an upgrade time, the knowledge gap is like Grand Canyon.
Yeah I agree with you, the "half-life" of Odoo instances are much shorter, for reference any version older than 3 years is not officially supported. I felt like being in the middle age working for the last two years on the version released in 2019 at my last company.
BTW go check odoo.com just under the list of apps for a fun reference :)
@jelena - how many years did you hear me scream about the power of customer stories?
Re: It’s the stories -- I totally agree. The best TechEd presentation I saw was about how InfoZoom architected one of their processes with BTP and Stripe.
What makes you think that HANA is faster than ordinary relational databases? I mean, outside SAPs marketing? Even Hasso Plattner himself expects a 10% gain in speed at best on transactional processing once the index btree is already cached by the db-system. While in ordinary DBs you have to read the record from the hard disk, in HANA you have do go through decompression and tupel- reconstruction. In memory it's faster but considerably more workload.
In-memory DB has advantages when using aggregates. But honestly, outside analytical processing there is very very very little need for using aggregates.
What is left is that you have to rework you old code so it does not slower on HANA than with you old Oracle system, e.g. replacing SELECT * with a field list in the SELECT to limit the dictionary lookups for decompression.
Um... What makes you think it's not? Have you used it?
"Fast is not a number" is a valid point. I'm not a DBA but there are benchmark figures out there, it's not some kind of secret. Here is just one source: https://www.sap.com/dmc/exp/2018-benchmark-directory/#/sd I think these days benchmark data can be found somewhat easily if anyone is actually interested in it.
I also have a certificate of completion from Hasso Plattner's institite (HPI) for In-Memory DB course, which I highly recommend: https://open.hpi.de/courses/imdb2017 It is not SAP specific and talks about in-memory data management in general. There is a clear advantage when reading data. (Aggregation is just one specific use case.) There is less advantage when writing data. Writing has always been more "expensive" and again, it's not some "dirty secret", it's common knowledge. However, it represents much lower percentage of operations than reading data.
SELECT * (unless the whole record is actually needed) was never a good or even acceptable practice in ABAP. Never ever. Complaining about changing it as some kind of anti-HANA argument is not very impressive, sorry.
I was exactly referring to Hassos lecture at HPI when quoting him. He says that in a well tuned OLTP database you have 98-99% hit rate of cached data already. In-memory database would increase the "hit rate" to 100% but adds costs of dictionary lookups for decompression. It's in one of the introductionary sessions, my may want to look it up if interested.
He even reasons the whole in-memory architecture with the speed gain in aggregates and the usage of aggregates in OLAP while the OLTP speed advantages are miniscule. The whole in-memory processing is supposed to abolish data warehouses (as long you have only one source system) and the need of predefine the aggregations you want to have for future analytical processing. It is NOT about speeding up your transactional ERP system. More likely it will slow down because you brought back processing analytics concurrently on the same dbs.
Sorry, I'm not really sure what you are trying to argue at this point... I've already agreed that write/transactional processing is not going to be much faster. There is no story in this issue that talks about transactional processing.
The CDS story is about data reading, not writing. And the blog series I wrote about is also about fine-tuning CDS views for more efficient data selection basically. That's the only context I wrote about. Sorry if this wasn't clear.