Improve speed of converting SQLite to FHIR
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 25/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- python, sqlite
- 領域
- databases, performance
調査の方向性
まず、レポートに記載されている semsql の変換経路と、変換後の hpo.db と hpo.owl のサイズを調べます。SQLite の作成と、その後の OAK への読み込みの両方をプロファイリングし、遅延の原因がファイルサイズ、データベース構造、または不要な解析処理のいずれであるかを特定します。担当コンポーネントと具体的な最適化方針を特定できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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
- 主要言語
- Python
- スター
- 70
- フォーク
- 7
- 平均マージ
- 4時間 18分
- マージ済み PR（30日）
- 1
環境構築
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
INCATools/semantic-sql のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 52/100
INCATools/semantic-sql#124 ·
-
Migrate direct raw-S3 bbop-sqlite consumers to the semanticsql CDN再び着手できるかも @caufieldjh が 91 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンhelp wanted
INCATools/semantic-sql#115 · コメント 7 件 · 担当者 1 名 ·
-
[bot] Cut a semsql release including the semanticsql.berkeleybop.io default再び着手できるかも @caufieldjh が 91 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンenhancement
INCATools/semantic-sql#114 · コメント 2 件 · リアクション 1 件 · 担当者 1 名 ·
-
enhancement
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
INCATools/semantic-sql#111 · コメント 1 件 ·
-
Integrate ENERO Foundry ontologies into Semantic-SQL対応中かも @cmungall が 197 日前に担当しました。 オープンenhancement
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
INCATools/semantic-sql#107 ·
INCATools/semantic-sql の issue をすべて見る
似ている issue
-
effort: low prio: low ready
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
digitalfabrik/integreat-cms#4616 ·
メンテナーはふだん 5 日以内に返信
-
bug difficulty:2 good first issue help wanted
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
MakazhanAlpamys/Soup#1865 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
FinanceFlash/unvibecode#233 ·
メンテナーはふだん 1 日以内に返信
-
area: agents area: docs good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
openapi/gknowledge#23 ·
-
useless-suppression reported for deprecated-* messages that should be exempt対応中かも @adityasinha-ghub が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
pylint-dev/pylint#11656 ·
メンテナーはふだん 1 日以内に返信