Hi Seref,

We tested with lots of queries, not with large datasets (tens of thousands)
within the system itself. But given the nature of the "normal" relational
DB schema and queries, this should be no problem at all. It's good old
postgres..:-).

Jan-Marc

Op di 26 jan. 2016 om 10:53 schreef Seref Arikan <
serefari...@kurumsalteknoloji.com>:

> Hi Jan-Marc,
>
> To clarify: when you say huge: do you mean that the result set is huge, or
> the the amount of existing data is huge? Are you able to comment on how
> query performance changes/stays the same when the result set size begins to
> grow?
>
> On Tue, Jan 26, 2016 at 9:38 AM, Jan-Marc Verlinden <
> jan-m...@medvision360.com> wrote:
>
>> 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 吕旭东 <lxdlxd7...@gmail.com>:
>>
>>> 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 <sk...@moss.gr.jp>:
>>>
>>>> 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 <i...@freshehr.com>:
>>>>
>>>>> 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: i...@freshehr.com
>>>>> twitter: @ianmcnicoll
>>>>>
>>>>> Co-Chair, openEHR Foundation ian.mcnic...@openehr.org
>>>>> Director, freshEHR Clinical Informatics Ltd.
>>>>> Director, HANDIHealth CIC
>>>>> Hon. Senior Research Associate, CHIME, UCL
>>>>>
>>>>> _______________________________________________
>>>>> openEHR-technical mailing list
>>>>> openEHR-technical@lists.openehr.org
>>>>>
>>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> openEHR-technical mailing list
>>>> openEHR-technical@lists.openehr.org
>>>>
>>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>>>
>>>
>>> _______________________________________________
>>> openEHR-technical mailing list
>>> openEHR-technical@lists.openehr.org
>>>
>>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
>> --
>>
>> 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
>> openEHR-technical@lists.openehr.org
>>
>> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org
>>
> _______________________________________________
> openEHR-technical mailing list
> openEHR-technical@lists.openehr.org
>
> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

-- 

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
openEHR-technical@lists.openehr.org
http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org

Reply via email to