Interesting discussion..:-). Concerns for our current architecture:
- Should be completely according openEHR IM - Accessible for external developers (front-end) through an API. - KISS; hide all openEHR complexity for GUI developers. So no pathvalues output, just simple GET and PUT. - Scalable, should be able to handle large queries and large datasets without any (huge) challenges. - Providing REST access (Json documents) - Access with Javadocs Some options we compared: - Exist DB is not ACID https://en.wikipedia.org/wiki/ACID. So in fact not usable at all. Also performance sucks.. (we tested). - Oracle rdbms is indeed ACID. You have to convert the archetype (ADL or XML) to XSD, that will be used to store the XML in a relational DB (for better performance). - Like Bert already stated; MarkLogic is somewhat pricey..;-), but -could- provide better performance. We never tested. So we came back to good old postgres and store the archetype Object model into a relational DB straight forward. None of the compared systems could even come close in matters of performance and scalability. In the end we -could- provide XML access alongside with current Json, but no GUI developer asked for it..:-). Other papers that show the same: - Performance of XML Databases for Epidemiological Queries in Archetype-Based EHRs. By Sergio Miranda Freire, Erik Sundvall, Daniel Karlsson and Patrick Lambrix - AN OPENEHR REPOSITORY BASED ON A NATIVE XML DATABASE. By Linda Velte, Tiago Pedrosa, Carlos Costa and José Luís Oliveira. Thanks for all input, Jan-Marc Op di 26 jan. 2016 om 10:38 schreef Jan-Marc Verlinden < [email protected]>: > I believe your paper is about performance of an openEHR based system with > a relational database. It does not argues if this is the right approach. > And specifically on the performance we could not agree more...:-). > > In the past year we worked on three different versions, all completely > openEHR compliant. We compared them, so I believe we are entitled to > discuss. Let's see: > > 1. Our first version was Java based with a postgres DB, everything > stored as path/values. > Every query would take about a second. We did not even try complex > queries..:-). Also the GUI side did not know what to do with the > pathvalues. > 2. Second version was completely XML based, lots of Java with an Exist > DB. This version can be found in GitHub. > Results: a single query over 900 records took 100ms. But the scary > part was that performance exploded linear, so 90000 would take about 10 > seconds, even for the most simple (already indexed and optimized) query. > 3. Our current stack converts archetypes to an Object model and > persists this model to postgres. Indeed this needs some fancy tricks > (@Thomas), but it's doable...:-). > Performance is comparable with the findings in the paper, even with > huge queries. Performance is steady at about 1 to 3ms per query. No > optimization done yet, is not yet needed but could/will make it even > faster. > > Cheers, Jan-Marc > > Op di 26 jan. 2016 om 09:55 schreef 吕旭东 <[email protected]>: > >> Dear all, >> >> I just found there are lots of comments on our recent paper. Thanks for >> all these comments, I will read them and reply later. >> >> @Shinji, Of course the slides could be shared. >> >> Regards >> Xudong >> >> 2016-01-26 10:44 GMT+08:00 Shinji KOBAYASHI <[email protected]>: >> >>> Hi Ian and all, >>> >>> We, openEHR Japan had an unconference with Dr Lu and he gave us a >>> presentation for us about this research. >>> I will ask him if the slides would be shareble. >>> >>> Shinji KOBAYASHI >>> >>> 2016-01-25 22:04 GMT+09:00 Ian McNicoll <[email protected]>: >>> >>>> Interesting paper from China >>>> >>>> >>>> http://bmcmedinformdecismak.biomedcentral.com/articles/10.1186/s12911-015-0212-0 >>>> >>>> Ian >>>> >>>> Dr Ian McNicoll >>>> mobile +44 (0)775 209 7859 >>>> office +44 (0)1536 414994 >>>> skype: ianmcnicoll >>>> email: [email protected] >>>> twitter: @ianmcnicoll >>>> >>>> Co-Chair, openEHR Foundation [email protected] >>>> Director, freshEHR Clinical Informatics Ltd. >>>> Director, HANDIHealth CIC >>>> Hon. Senior Research Associate, CHIME, UCL >>>> >>>> _______________________________________________ >>>> openEHR-technical mailing list >>>> [email protected] >>>> >>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>>> >>> >>> >>> _______________________________________________ >>> openEHR-technical mailing list >>> [email protected] >>> >>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org >>> >> >> _______________________________________________ >> openEHR-technical mailing list >> [email protected] >> >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > > -- > > Jan-Marc Verlinden > MedVision (mobile) > -- Jan-Marc Verlinden MedVision (mobile) -- *MedVision BV* Aagje Dekenkade 71 2251 ZV, Voorschoten www.medvision360.com This e-mail message is intended exclusively for the addressee(s). Please inform us immediately if you are not the addressee.
_______________________________________________ openEHR-technical mailing list [email protected] http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
