Method Article
מחקר זה משווה יחסיים, שאינם יחסיים (NoSQL) סטנדרטיות מערכות מידע רפואי. מורכבות חישובית זמני התגובה של שאילתות כגון מערכות ניהול מסדי נתונים (DBMS) מחושב באמצעות הכפלה בגודל מסדי נתונים. תוצאות אלו מסייעים הדיון נאותות של כל מסד הנתונים לגישה תרחישים שונים ובעיות.
מחקר זה מראה פרוטוקול כדי להעריך את הסיבוכיות של שאילתות יחסיים, שאינם יחסיים (NoSQL (לא רק שפת שאילתות מובנית)) סטנדרטיות בריאות אלקטרונית הרשומה (EHR) מידע רפואי מערכות מסדי נתונים (DBMS). היא משתמשת סט של שלוש הכפלה בגודל מסדי נתונים, קרי מסדי נתונים לאחסון 5000, 10,000 ל 20,000 מציאותי סטנדרטית EHR תמציות, בשלוש מערכות ניהול שונות של מסדי נתונים (DBMS): מיפוי אובייקטי-רלציוני MySQL רלציוני (ORM), מבוסס-מסמך NoSQL MongoDB, שפת סימון מורחבת מקורית (XML) NoSQL קיים.
זמני התגובה הממוצע 6 שאילתות מורכבות-הגדלת חושבו, התוצאות הראו התנהגות ליניארי במקרים NoSQL. בשטח NoSQL, MongoDB מציג מדרון להחמיא הרבה של ליניארי יותר קיימים.
מערכות NoSQL יכול להיות גם מתאים יותר לשמור על מערכות מידע רפואי מתוקנן בשל אופיו המיוחד של מדיניות עדכון של מידע רפואי, אשר לא תשפיע על העקביות והיעילות של הנתונים המאוחסנים NoSQL מסדי נתונים.
מגבלה אחת של פרוטוקול זה הוא העדר תוצאות ישירות של מערכות יחסיים משופר כגון מיפוי רלציוני ארכיטיפ (זרוע) עם הנתונים. אולם, האינטרפולציה של תוצאות מסד הנתונים בגודל הכפלת לאלה שהוצגו בספרות, אחרים שפורסמו תוצאות מרמז כי מערכות NoSQL עשוי להיות מתאים יותר הרבה תרחישים ספציפיים ובעיות להיפתר. לדוגמה, ייתכן NoSQL המתאים עבור משימות המבוססות על המסמך, כגון EHR תמציות בשימוש הקלינית, מהדורה, ויזואליזציה, או מצבים שבהם המטרה היא לא רק שאילתה המידע הרפואי, אלא גם כדי לשקם את EHR בדיוק בצורתו המקורית.
NoSQL (לא רק SQL) DBMS שהתגלו לאחרונה כחלופה כדי מסורתי יחסיים DBMS (RDMBS). RDBMS יש שלטה הדרך היו מאוחסנים נתונים במערכות של מסדי נתונים במשך עשרות שנים. אלגברה רלציונית למד היטב ומובן. על הצד יש להבטיח את יעילות והעקביות של RDBMS1. NoSQL מערכות לא אהפוך תחליפים עבור מערכות יחסיים, אולם הם יכולים להתנהג ביתרון בתרחישים מסוימים, תחת מספר תנאים.
חלקם של אלה תרחישים מסוים התנאים להתרחש בעת עיצוב התמדתו של מסד נתונים של מערכות שיא הבריאות אלקטרונית (EHR) נהגו לנהל ולאחסן מידע רפואי. על מנת להיות ומתמשכות בפועל, מספר תקנים בינלאומיים כגון ISO/EN 13606, openEHR HL72,3,4,5 שימשו כדי לתקנן EHR תמציות.
מספר תקנים ISO/EN 13606 ו openEHR יש להפריד מידע וידע בשתי רמות שונות של הפשטה, המיוצג על-ידי הפניה מודל (RM) ומבני נתונים מיוחד שנקרא ונושמים. ההפרדה הזאת נקרא לעתים קרובות כפול דגם וההיתרים זה מערכות EHR סמנטי לשילוב הידע להתפתח ללא תיכנות מחדש את כל המערכת EHR, וכתוצאה מכך כדי להיות maintainable ובר קיימא בפועל6 . עם זאת, המודל הכפול מיושם במערכות EHR מתוקננת דורשת כי הארגון של המידע להלן מבנה ספציפי, זה השלכות עמוקה דרך שרמת התמדה מסד הנתונים של המערכת הוא מעוצב7.
אובייקט מיפוי יחסיים (ORM)8 הוא אחד מתודולוגיה ליישום מערכת EHR באמצעות הפרדיגמה של מסדי נתונים יחסיים. ORM מפות בדקדקנות את המבנה של מתוקננת EHR תמציות XML (שפת סימון מורחבת) קבצים בשימוש על ידי המערכת עבור מסדי נתונים יחסיים. ORM בונה טבלאות יחסיים רבות ומגובה בעקבות המבנה של הקבצים XML מתוקננת EHR תמציות. טבלאות יחסיים אלה קשורות זו לזו באמצעות מפתחות זרים רבים, ייתכן כי לא תהיה למערכת וכתוצאה מכך מאוד יעיל.
הוצעו מספר שיפורים יחסיים ORM. צומת + נתיב של openEHR9 יקטין את מספר השולחנות יחסיים בעריכה בסידרה של עצי משנה של התמצית כל קובץ XML לתוך כתמים (אובייקטים גדולים בינארי). עם זאת, זו הפשטה גורמת מורכבות לאחזור לוגיקה, פגיעה שאילתות מורכבות. ארכיטיפ מיפוי יחסיים (זרוע)10 יוצר מודל מסד הנתונים מונע על ידי ונושמים, בניין סכימה יחסיים חדשה המבוססת על מיפויים בין טיפוסים וטבלאות יחסיים. כתוצאה מכך, חלק מהמידע שאינם רפואיים של התמצית EHR אובד.
מסדי NoSQL מבוססי מסמכים רבים לאחסן מסמכים כל כמו כתמים כל כיבוד בקובץ XML המקורי או JSON (בסימון אובייקט JavaScript) עיצוב. משמעות הדבר היא כי אין שולחנות יחסיים בנויים. מסדי נתונים אלה NoSQL יש ללא סכימה, הם אינם תומכים או צירופים או מאפיינים (חומצה)11, קרי, atomicity, עקביות, בידוד או עמידות. כתוצאה מכך, הם עשויים להיות מאוד יעיל אם רכיב של מסמך מפנה אלמנטים של אותו או כאלה מסמכים אחרים ניצול קישור כיופמיזם. זה קורה כי, כדי לשמור על עקביות, מכלול המסמכים המופנה חייב להיות מעובד באופן רציף. עם זאת, ייתכן מסד נתונים שאינם יחסיים עדיין המתאים אם המשימה העיקרית שבוצעה על-ידי ה-DBMS היא פעילות המבוססות על המסמך. זה בגלל נתונים עשויים להישאר בצורה יותר מקרוב קירוב הייצוג האמיתי שלו באמצעות מסד NoSQL המבוססות על המסמך, למרות זאת גם בשל המדיניות התמדה מיוחד על ידי EHR מסמכים רפואיים (עיין בסעיף הדיון).
המטרה של שיטות אלה היא להציג מספר ניסויים כדי להשוות בין יישום שכבת התמדה של מערכת EHR מתוקננת באמצעות שלושה Dbms שונים: אחד יחסיים (MySQL) ו NoSQL שני (קיים מבוסס-מסמך MongoDB ו- XML המקורי). הסיבוכיות שלהם היה מחושב, והשוו באמצעות שלושה הגדלת גודל מסדי נתונים שונים ו- 6 שאילתות מורכבות-הגדלת שונים. שרתי מסד נתונים שלוש יש הותקן והוגדר באופן מקומי בבאותו מחשב שבו הוצאו להורג של השאילתות. ראה טבלה של חומרים עבור פרטים טכניים.
ניסויים מקביליות גם נערכו על מנת להשוות את הביצועים של MySQL ו NoSQL MongoDB Dbms יחסיים. השיפורים ORM המתואר (צומת + נתיב וזרוע) גם מושווים באמצעות הרלוונטיים התוצרות מכל10ספרות.
מערכות ניהול מסדי נתונים מתפתחים באופן רציף בקצב מאיץ. אף אחד לא יחשוב על התפתחות מעריכית זו הפרדיגמה הקיימת היחיד היה במודל. ניקח דוגמה, ראה למשל12, שבו הוצע מודל ליישם את התגובה בזמן משופרת מסדי נתונים יחסיים שמירה על המאפיינים חומצה.
1. לבנות של DBMS MySQL יחסיים כדי לאחסן את מסדי הנתונים של תמציות EHR סטנדרטית בגודל כפול שלוש
2. לבנות של DBMS NoSQL MongoDB לאחסון מסדי נתונים של תמציות EHR סטנדרטית בגודל כפול שלוש
3. לבנות NoSQL קיים DBMS על החנות שלוש כפול בגודל סטנדרטית EHR תמציות מסדי נתונים
4. עיצוב וביצוע במסדי הנתונים MySQL יחסיים 3 6 שאילתות מורכבות-הגדלת
5. עיצוב וביצוע במסדי הנתונים-NoSQL MongoDB 3 6 שאילתות מורכבות-הגדלת
6. תכנון וביצוע של 3 NoSQL קיימים מסדי נתונים 6 Increasing-המורכבות שאילתות
7. תכנון וביצוע ניסוי מקביליות באמצעות MongoDB 5,000 תמציות מסדי נתונים MySQL
הערה: הנתונים קיימים הוסר מן הניסוי בשלב זה בשל ביצועים גרועים בניסויים הקודמים.
6 שאילתות שונות המבוצעות על מציאותי תמציות EHR סטנדרטית המכילה מידע על הבעיות של המטופלים, לרבות שמות, תאריכים התחלתי וסופי חומרה, מוצגים בטבלה 1.
זמני התגובה הממוצע של השאילתות 6 במסדי הנתונים הכפלה בגודל שלושה ב DBMS כל מוצגים בטבלאות 2-4. המספרים 1-6 הצג את אותן תוצאות בצורה גרפית (שים לב כי הצירים האנכי להשתמש סולמות שונים מאוד לאורך כל הדמויות).
ההתנהגות ליניארית חזקה של הסיבוכיות ניכרת לאורך כל השאילתות של מסדי הנתונים NoSQL, למרות בזהירות המתאימה בשל גודל קטן יחסית של 3 datasets בשימוש. עם זאת, מסד הנתונים היחסי ORM מראה על התנהגות ליניארי לא ברור. הנתונים של MongoDB יש מדרון להחמיא הרבה יותר מסד הנתונים קיימים.
תוצאות לפי מערכת יחסיים משופרת נדון בהקדמה שפורסמו בספרות ניתן למצוא טבלה 5. אינטרפולציה תוצאות MongoDB בלוח 3 עם שאילתות דומות וגדלים של מסד הנתונים של הזרוע נובע טבלה 5 שווה בשתי מערכות מסדי נתונים ב- Q1, אבל מעדיף MongoDB ב- Q3.
ניתן למצוא את התוצאות של הניסויים מקביליות טבלה 5 ו לטבלה6. MongoDB פעימות MySQL בשני בזמן תפוקה ותגובות. למעשה, MongoDB מתנהגת יותר טוב מקביליות מאשר בבידוד, ועומד כמסד נתונים מרשימים בביצוע בו-זמניות.
איור 1 : אלגוריתמי המורכבות ORM MySQL, MongoDB, קיימים DBMS עבור שאילתות Q1 ו- Q4. איור זה שונה מ-7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/) ומראה זמני תגובה בשניות עבור 5,000, 10,000 ו בגודל 20,000 EHR תמציות מסדי נתונים עבור DBMS ושאילתות בכל רבעון 1, רבעון 4. אנא לחץ כאן כדי להציג גירסה גדולה יותר של הדמות הזאת.
איור 2 : המורכבות אלגוריתמית של DBMS MySQL ORM לשאילתה Q2. איור זה מציג זמני תגובה בשניות עבור 5,000, 10,000 ו בגודל 20,000 EHR תמציות מסד הנתונים ORM MySQL לשאילתה Q2. אנא לחץ כאן כדי להציג גירסה גדולה יותר של הדמות הזאת.
איור 3 : המורכבות אלגוריתמית של MongoDB קיימים DBMS עבור שאילתות Q2 ו ש5. איור זה שונה מ-7 באמצעות רשיון Creative Commons (http://creativecommons.org/licenses/ על ידי / 4.0) מראה זמני תגובה בשניות עבור 5,000, 10,000, ו בגודל 20,000 EHR תמציות מסדי נתונים עבור DBMS ושאילתות בכל רבעון 2 ו- Q5. אנא לחץ כאן כדי להציג גירסה גדולה יותר של הדמות הזאת.
איור 4 : אלגוריתמיות מורכבות ORM MySQL DBMS עבור שאילתות Q3 ו ש5. מראה זמני תגובה בשניות עבור 5,000, 10,000 ו בגודל 20,000 EHR תמציות מסדי נתונים עבור כל DBMS ושאילתות Q3 ו- Q5. אנא לחץ כאן כדי להציג גירסה גדולה יותר של הדמות הזאת.
איור 5: אלגוריתמי המורכבות קיימים של MongoDB DBMS עבור שאילתת Q3. איור זה שונה מ-7 באמצעות רשיון Creative Commons (http://creativecommons.org/licenses/ על-ידי/4.0 /) ומראה זמני תגובה בשניות עבור 5,000, 10,000 ו בגודל 20,000 EHR תמציות מסדי נתונים לכל DBMS או השאילתה Q3. אנא לחץ כאן כדי להציג גירסה גדולה יותר של הדמות הזאת.
איור 6 : המורכבות אלגוריתמית של ORM MySQL, קיימים וכל DBMS MongoDB עבור שאילתה Q6. איור זה שונה מ-7 באמצעות רשיון Creative Commons (http://creativecommons.org/licenses/ על-ידי/4.0 /) ומראה זמני תגובה בשניות עבור 5,000, 10,000 ו בגודל 20,000 EHR תמציות מסדי נתונים לכל DBMS או השאילתה Q6. אנא לחץ כאן כדי להציג גירסה גדולה יותר של הדמות הזאת.
שאילתה | |
Q1 | למצוא את כל הבעיות של המטופל יחיד |
Q2 | למצוא את כל הבעיות של כל המטופלים |
Q3 | למצוא תאריך ראשוני, רזולוציה תאריך וחומרת |
בעיה אחת של המטופל יחיד | |
Q4 | למצוא תאריך ראשוני, רזולוציה תאריך וחומרת |
כל בעיה בעיות של המטופל יחיד | |
Q5 | למצוא תאריך ראשוני, רזולוציה תאריך וחומרת |
כל בעיה בעיות מכל המטופלים | |
Q6 | למצוא את כל החולים עם הבעיה 'דלקת גרון", |
ראשוניות תאריך > = 16/10/2007 ', ברזולוציה תאריך | |
< = ' 06/05/2008 "וחומרת 'גבוהה' |
טבלה 1: השאילתות 6 לבצע יחסי ו NoSQL מסדי נתונים EHR סטנדרטית המכילה תמציות אודות בעיות של חולים- טבלה זו שונתה מ7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/) ומציג את השאילתות המורכבות הגוברת 6 ביצע שלושה הגדל גודל במאגרי המידע עבור כל DBMS לידי ביטוי טבעי השפה.
ORM/MySQL | הרופאים 5000 | הרופאים 10,000 | הרופאים 20,000 |
Q1 (s) | 25.0474 | 32.6868 | 170.7342 |
Q2 (s) | 0.0158 | 0.0147 | 0.0222 |
Q3 (s) | 3.3849 | 6.4225 | 207.2348 |
Q4 (s) | 33.5457 | 114.6607 | 115.4169 |
Q5 (s) | 9.6393 | 74.3767 | 29.0993 |
Q6 (s) | 1.4382 | 2.4844 | 183.4979 |
גודל מסד הנתונים | 4.6 GB | 9.4 ג'יגה-בתים | 19.4 GB |
תמציות סה | 5000 | 10,000 | 20,000 |
בטבלה 2: ממוצע זמני תגובה תוך שניות על השאילתות 6 במסדי נתונים בגודל הכפלה של ה-DBMS יחסיים ORM MySQL. טבלה זו מציג שש פעמים תגובה עבור כל שאילתת עבור שלושה הכפלה בגודל מסדי הנתונים באמצעות ה-DBMS יחסיים ORM MySQL ואת הגודל בזיכרון של שלושה מסדי הנתונים.
MongoDB | הרופאים 5000 | הרופאים 10,000 | הרופאים 20,000 | מדרון (*10exp(-6)) |
Q1 (s) | 0.046 | 0.057 | 0.1221 | 5.07 |
Q2 (s) | 34.5181 | 68.6945 | 136.2329 | 6,780.99 |
Q3 (s) | 0.048 | 0.058 | 0.1201 | 4.81 |
Q4 (s) | 0.052 | 0.061 | o.1241 | 4.81 |
Q5 (s) | 38.0202 | 75.4376 | 149.933 | 7460.85 |
Q6 (s) | 9.5153 | 18.5566 | 36.7805 | 1,817.68 |
גודל מסד הנתונים | 1.95GB | 3.95GB | 7.95 ג'יגה-בתים | |
תמציות סה | 5000 | 10,000 | 20,000 |
טבלה 3: ממוצע זמני תגובה תוך שניות על השאילתות 6 במסדי נתונים בגודל הכפלה של ה-DBMS NoSQL MongoDB. טבלה זו שונתה מ7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/) ומציג את זמני תגובה 6 של כל שאילתה עבור שלושה הכפלה בגודל מסדי הנתונים באמצעות ה-DBMS MongoDB NoSQL ואת הגודל בזיכרון של שלושה מסדי הנתונים. המדרון ליניארי של כל שאילתה גם מוצג.
קיים | הרופאים 5000 | הרופאים 10,000 | הרופאים 20,000 | מדרון (*10exp(-6)) |
Q1 (s) | 0.6608 | 3.7834 | 7.3022 | 442.76 |
Q2 (s) | 60.7761 | 129.3645 | 287.362 | 15,105.73 |
Q3 (s) | 0.6976 | 1.771 | 4.1172 | 227.96 |
Q4 (s) | 0.6445 | 3.7604 | 7.3216 | 445.17 |
Q5 (s) | 145.3373 | 291.2502 | 597.7216 | 30,158.93 |
Q6 (s) | 68.3798 | 138.9987 | 475.2663 | 27,125.82 |
גודל מסד הנתונים | 1.25 ג'יגה-בתים | 2.54 ג'יגה-בתים | 5.12 ג'יגה-בתים | |
תמציות סה | 5000 | 10,000 | 20,000 |
בטבלה 4: ממוצע זמני תגובה תוך שניות על השאילתות 6 במסדי נתונים בגודל הכפלה של קיימים NoSQL DBMS. טבלה זו שונתה מ7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/) ומציג זמני תגובה 6 של כל שאילתה המאגרים הכפלה בגודל שלוש באמצעות על NoSQL קיים DBMS ואת הגודל בזיכרון שלושה מאגרי המידע. המדרון ליניארי של כל שאילתה גם מוצג.
נייר הזרוע | זרוע (s) | צומת + נתיב (s) | |
Q1 | השאילתה 2.1 | 0.191 | 24.866 |
Q3 | השאילתה 3.1 | 0.27 | 294.774 |
גודל מסד הנתונים | 2.90 ג'יגה-בתים | 43.87 ג'יגה-בתים | |
תמציות סה | 29,743 | 29,743 |
טבלה 5: ממוצע הזמן בשניות של שאילתות דומה Q1 Q3 של מערכות יחסיים משופרת שהוצגו 10 . טבלה זו שונתה מ7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/) ומציג את שתי שאילתות דומות-רוב ועד Q1 Q3 המוצגים10 המייצגים שתי מערכות של מסדי נתונים יחסיים משופר זמני התגובה שלהם. המפה מראה גם גודל מסד הנתונים שני.
ORM/MySQL | תפוקת | זמן תגובה |
Q1 (s) | 4,711.60 | 0.0793 |
Q3 (s) | 4,711.60 | 0.1558 |
Q4 (s) | 4,711.60 | 0.9674 |
טבלה 6: ממוצע תפוקה וזמן התגובה בשניות של שאילתות Q1, Q3 ו- Q4 של MySQL ORM DBMS יחסיים בביצוע בו-זמניות. טבלה זו שונתה מ7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/), מציג את התפוקה הממוצעת הגבוהה ביותר של השאילתות יחיד-חולה שלושה ואת זמני התגובה הממוצע שלהם בו-זמניות ביצוע הניסוי באמצעות מערכת יחסיים ORM MySQL.
MongoDB | תפוקת | זמן תגובה |
Q1 (s) | 178,672.60 | 0.003 |
Q3 (s) | 178,672.60 | 0.0026 |
Q4 (s) | 178,672.60 | 0.0034 |
טבלה 7: ממוצע תפוקה וזמן התגובה בשניות של שאילתות Q1, Q3 ו- Q4 של MongoDB NoSQL DBMS בביצוע בו-זמניות. טבלה זו שונתה מ7 באמצעות רשיון Creative Commons (http://creativecommons.org/ licenses/by/4.0/), מציג את התפוקה הממוצעת הגבוהה ביותר של השאילתות יחיד-חולה שלושה ואת זמני התגובה הממוצע שלהם בו-זמניות ביצוע הניסוי באמצעות מערכת MongoDB NoSQL.
משלים איור 1: צילום מסך מראה למסך תוכנת כדי להתחבר לשרת ה-MySQL. אנא לחץ כאן כדי להוריד את הדמות הזו.
משלים איור 2: המסך מראה את ממשק SQL לשרת ה-MySQL שבו נכתב שאילתת SQL הראשונה. אנא לחץ כאן כדי להוריד את הדמות הזו.
משלים איור 3: MongoDB 2.6 localhost שרת מופעל באמצעות חלון מערכת DOS על ידי הפעלת את השרת mongod. אנא לחץ כאן כדי להוריד את הדמות הזו.
משלים באיור 4: צילום המסך מראה את השאילתה בכתב לתיבות הטקסט של בונה השאילתות, כפי שמוצג בשלבים 5.7.1 דרך 5.7.4. צילום מסך מדגים צעד 5.7.3. אנא לחץ כאן כדי להוריד את הדמות הזו.
משלים איור 5: המסך מראה את הצעד 5.7.6. אנא לחץ כאן כדי להוריד את הדמות הזו.
משלים איור 6: צילום מסך ממחיש את הכתיבה של שאילתת XPath בחלק theupper של תיבת הדו-שיח. אנא לחץ כאן כדי להוריד את הדמות הזו.
פרוטוקול זה מראה כי מערכות טהור ORM יחסיים שאינם נראים מעשי עבור שאילתות יחיד-מטופל (Q1 Q3, ש4) שכן זמני התגובה איטית יותר, כנראה בגלל מספר רב של טבלאות יחסיים ביצוע פעולות צירוף יקרים רבים, בשל מערכת אחסון בשימוש על-ידי סוג מסוים של מסד נתונים. מסדי נתונים NoSQL לאחסן נתונים באופן מבוסס-מסמך, בעוד מערכות יחסיים משתמשים אופנה המבוססת על טבלה שמתפשט בכל מסמך ברחבי במסד הנתונים כולו. מערכות NoSQL יציג מדרון ליניארי, עם MongoDB ביצוע משמעותית מהר יותר מהקיימות DBMS. ב מקביליות, MongoDB גם מתנהג הרבה יותר טוב מאשר MySQL ORM יחסיים7.
פרוטוקול זה מציג פרוטוקול לפתרון בעיות עבור התוצאות שהוצגו ב-7 לגבי ה-DBMS MySQL ORM. מערכת MySQL עודכן לגירסה העדכנית ביותר ואת התוצאות השתנו במקצת. נקודה קריטית במערכות NoSQL מבוסס-מסמך בנוסף, כגון MongoDB הוא כי הם עשויים לשמור על עקביות כאשר לאחסון מידע רפואי7 כי תמצית EHR מתעדכן, זה לא יוחלף, אבל שלם חדש לחלץ עם הנתונים החדשים היא נוצר ומאוחסן במערכת, ואת תמצית המקורית נשמרת. הסיבה לכך היא דרישה קפדנית של מידע רפואי, והופיעו רפואית שעשיתי החלטות רפואיות חשובות בהתבסס על הנתונים המקוריים.
מערכת משופרת יחסיים הזרוע באופן דרסטי פוחת מספר הטבלאות יחסיים ומשפר ביצועים יחסיים. עם זאת, מאז הוא משנה את סכימת יחסיים, יכול להיות שאילתה מידע רפואי שנערך על ידי תמציות, אבל לא ניתן לשחזר תמציות בצורות המקורי המדויק שלהם.
עבור מסדי נתונים גדול מאוד משנית משתמשים (מחקר), לא ברור באיזו מערכת מסד נתונים מתאים יותר, מאחר שהשאילתות כל-מטופל (Q2 ו ש5) מתנהג יותר טוב ב ORM מאשר במערכות NoSQL, אך מערכות אלה ביצועים טובים יותר פשוטה יחסיים מערכות ב- 12. אנו רואים Q6 שאילתה מיוחד בין הקלינית והמשני להשתמש שהתנהגותו לא יכול להיקבע על ידי התוצאות הניבו על ידי ניסויים אלה.
עם זאת, מגבלה אחת של השיטה היא inavailability של ניסויים ישירה השוואת שיפור יחסי הזרוע המערכת עם NoSQL MongoDB בנוגע לשאילתות אימון בודד-החולה, רפואיים בדיוק את אותם נתונים המשמשים את הפרוטוקול. אנחנו קיימו את התוצאות אינטרפולציה טבלה 3 ו -5 שולחן בנוגע לשאילתות יחיד-מטופל עד בוצע הניסוי כולל זרוע ממוטבת בפרוטוקול. אנחנו יוצאים ניסויים אלה עבור יישומים עתידיים. צעד קריטי אחד בתוך הפרוטוקול הוא הבחירה של מסד נתונים ללא תשלום, גירסאות תוכנה דומה מן השנים האחרונות, כך ייתכן שנשווה את המדויק המדינה-של-the-art של שלוש טכנולוגיות.
. זה אחד הניסיונות הראשונים להשוות ישירות יחסיים, מערכות NoSQL באמצעות מידע רפואי בפועל, מציאותי, מתוקננת עם זאת, מערכת ספציפית כדי לשמש תלוי הרבה תרחיש בפועל ואת הבעיה יהיה פתור8.
המחברים אין לחשוף. Datasets שימוש בניסויים אלה נמסרו על-ידי מספר בתי חולים הספרדית תחת רישיון עבור ניסויים אלה, וכתוצאה מכך אינם זמינים בפומבי. סכימת ה-XML RM 13606 ISO/EN סופק על ידי המרכז בלונדון קולג האוניברסיטה לאינפורמטיקה בריאותית & Multiprofessional חינוך (פעמון).
המחברים רוצה להודות ד ר דיפאק Kalra, המנהיג של כוח המשימה EHRCom מוגדר תקן של ISO/EN 13606 וצוותו אוניברסיטת לונדון המכללה על שאישרו לנו להשתמש ISO/EN 13606 W3C של סכימת XML.
עבודה זו נתמכה על ידי אינסטיטוטו דה סאלוד Carlos III [גרנט מספרים PI15/00321, PI15/00003, PI1500831, PI15CIII/00010 ו- RD16CIII].
Name | Company | Catalog Number | Comments |
MySQL 5.7.20 | MySQL experiments | ||
Red Hat Enterprise Linux Server release 7.4 (Maipo), 2.60GHz, RAM 16GB | |||
MongoDB 2.6 | MongoDB experiments | ||
Windows 7, 2.66GHz, RAM 12GB | |||
eXist 3.0RC1 | eXist experiments | ||
Windows 7, 2.66GHz, RAM 12GB | |||
Studio 3T 5.5.1 | 3T Software Labs Gmbh | MongoDB GUI |
Request permission to reuse the text or figures of this JoVE article
Request PermissionThis article has been published
Video Coming Soon
Copyright © 2025 MyJoVE Corporation. All rights reserved