Improve speed of converting SQLite to FHIR

Offen
  • Stimmt etwas nicht?
#64 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Muss geklärt werden
Aktivitätsstatus
Veraltet
Tech-Stack
python, sqlite
Bereich
databases, performance

Rechercherichtung

Beginne damit, den semsql-Konvertierungspfad und die im Bericht beschriebenen Größen von hpo.db im Vergleich zu hpo.owl zu untersuchen. Profiliere sowohl die Erstellung der SQLite-Datenbank als auch das nachgelagerte Laden in OAK, um festzustellen, ob die Dateigröße, die Datenbankstruktur oder unnötige Parsing-Arbeit die Verzögerung verursacht; abgeschlossen ist die Aufgabe, wenn die verantwortliche Komponente und ein konkreter Optimierungspfad identifiziert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Overview

I tried to convert HPO to FHIR using semsql as an intermediary. However, after about 40 minutes, I decided to give up and switch to Obographs for speed. I think it took about 10 minutes to convert to a .db, and the rest of the time in my process was just OAK trying to load the DB. Normally semsql is much faster to load than using rdflib, but not in this case. I looked and saw that my hpo.db was about 1GB, which is about 10x larger than my hpo.owl. I looked at some of my other conversions, and it looks like this 5-10x file size was normal.

If I'm correct that the issue is not so much OAK performance, but just the file size in general, is there anything we can do to reduce these file sizes? Or maybe it's not so much the size, but the structure that is taking OAK a long time to parse downstream? If this is more of an OAK issue (or both an OAK issue and a semsql issue), I can open up a ticket over there.

Potential causes

May be 1 or more of the following that's taking a lot of time.
a. Semsql: File size
b. Semsql: Non-optimal structures for downstream parsing
c. OAK: Not parsing optimally
d. OAK: Spending time doing things that are maybe not needed for my use case

Vorherrschende Sprache
Python
Sterne
72
Forks
7
Keine gemergten PRs in 30 T.

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus INCATools/semantic-sql

Alle Issues in INCATools/semantic-sql

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.