3.1 Data StorageWe propose a hybrid

3.1 Data Storage
We propose a hybrid (row-column) two-layered cloud-enabled data storage structure. Each of these layers is designed to store a special set of DICOM attributes. For that, we decompose DICOM attributes into three categories: (1) Mandatory/frequently used attributes (2) frequently accessed together attributes; and (3) optional/private attributes. Then, we propose the most appropriate layer to store each of them. We link these two layers by creating an internal unique identifier (row-id) that allows us to reconstruct our DICOM files. Both layers are cloud-based, which ensures the elasticity and fault tolerance (e.g. GFS [16] stores automatically several copies of data on geographically separated areas, so a server crash is not a problem). As a consequence, that will ensure the needed availability of medical data at any time. Another important aspect is the pay-per-use feature. A good level of normalization of our data and the choice of the appropriate cloud-enabled storage system for each layer could reduce enormously the storage cost.
3.1.1 Row-oriented layer:
We propose to store mandatory/frequently used attributes and the frequently accessed together attributes (e.g. patient name, birthdate) in a row-oriented database. As a result, we improve the query execution time, by minimizing the tuple reconstruction time for the attributes that are frequently accessed together. The advantage of this layer is its write-optimized feature (each tuple insertion in row-oriented databases needs one disk block I/O for insertion alone). Thus, having a lot of inserts over this layer will not be challenging. For example, if we have one thousand DICOM files, there will be one thousand inserts in this layer (for the mandatory attributes such as study date). Since we store the frequently used attributes in this layer, daily queries access mostly this layer. Sharded DB, like Azure or RDS, is candidate solution for such a layer. However, in order to reduce cost and have a more scalable solution, our current study focus on shared nothing MapReduce based approaches like Pig, Hive or Jaql.
3.1.2 Column-Oriented Layer
Optional/private attributes vary enormously from one medical file/center to another. For this highly heterogeneous attributes we propose storing them in column-oriented databases. Only non-null attributes values will be inserted into their corresponding columns (which improves significantly the performance). Therefore, this model copes perfectly with our heterogeneous data. This layer offers the ability to perform efficiently ad-hoc queries since column-oriented databases are OLAP-optimized. Additionally, it provides a good solution for the evolutive schema issue, since each column is stored in a separate disk block, so adding new columns is not challenging. Attributes stored in this layer are less frequently accessed together, so we minimize the result reconstruction time. Examples of possible implementation are BigTable, Cassandra, Vertica, HBase, and HyperTable. In fact, the high cost and proprietary features of Vertica and BigTable and the OLTP workload orientation of Cassandra lead us to focus on the other systems (HBase, HyperTable).
3.1.3 Column Mover
Our proposal includes a column mover, the column mover is a process that moves (when necessary) some attributes from the row layer to the column layer and vise versa according to: DICOM's evolutive schema, the previous queries and the data (for example optional attributes initially stored in the column layer which are in practice used in most of files can be moved to the row level). This process can be performed periodically (i.e. each month) to maintain the best distribution of attributes over this structure. The implementation of this process includes some important issues such as determining when to execute this process (ideally at off-peak time), under which conditions, and how to treat currently running and incoming queries while executing this process.

ผลลัพธ์ (ไทย) 1:

3.1 เก็บข้อมูลเราเสนอโครงสร้างเก็บข้อมูลการเปิดใช้งานคลาวด์ชั้นสองไฮบริด (แถวคอลัมน์) แต่ละชั้นเหล่านี้ถูกออกแบบมาเพื่อจัดเก็บชุดพิเศษของแอตทริบิวต์ DICOM ที่ เราเปื่อย DICOM คุณลักษณะออกเป็นสามประเภท: (1) บังคับ/ใช้คุณลักษณะร่วมกัน (2) การเข้าถึงแอตทริบิวต์ และแอตทริบิวต์เพิ่มเติมห้อง (3) เรานำเสนอชั้นที่เหมาะสมที่สุดจะเก็บไว้ เราเชื่อมโยงเหล่านี้สองชั้น ด้วยการสร้างภายในเฉพาะรหัส (รหัสแถว) ที่ช่วยให้เราสร้างของเราไฟล์ DICOM ทั้งสองชั้นมีเมฆตาม ที่มั่นใจยอมรับข้อบกพร่องและยืดหยุ่น (เช่น GFS [16] จัดเก็บอัตโนมัติหลายสำเนาของข้อมูลในพื้นที่แยกต่างหากกันทางภูมิศาสตร์ ดังนั้นความผิดพลาดของเซิร์ฟเวอร์ มีปัญหา) ผล ที่จะช่วยให้ความจำเป็นต้องใช้ข้อมูลทางการแพทย์ตลอดเวลา สำคัญด้านคุณลักษณะค่าจ้างต่อใช้ได้ ระดับดีฟื้นฟูข้อมูลและทางเลือกของระบบการจัดเก็บใช้งานคลาวด์ที่เหมาะสมสำหรับแต่ละชั้นสามารถลดไปเก็บต้นทุน3.1.1 แถวชั้น:เรานำเสนอคุณลักษณะบังคับ/มักใช้จัดเก็บและเข้าถึงบ่อยกันคุณลักษณะ (เช่นชื่อผู้ป่วย วันเกิด) ในฐานข้อมูลแถว ดังนั้น เราเพิ่มเวลาดำเนินการแบบสอบถาม โดยลดเวลาฟื้นฟูทูเพิลสำหรับแอททริบิวต์ที่จะเข้าถึงกัน ข้อดีของชั้นนี้คือ (แทรกแต่ละทูเพิลในฐานข้อมูลแถวต้องดิสก์หนึ่งบล็อก I/O สำหรับแทรกอยู่คนเดียว) ของคุณลักษณะเหมาะเขียน ดังนั้น มีจำนวนมากแทรกผ่านชั้นนี้จะไม่ได้ท้าทาย ตัวอย่าง ถ้าเรามีไฟล์ DICOM หนึ่งพัน จะมีหนึ่งพันแทรกในชั้นนี้ (สำหรับแอตทริบิวต์ที่ระบุเช่นวันศึกษา) เนื่องจากเราสามารถเก็บแอตทริบิวต์ที่ใช้บ่อยในชั้นนี้ แบบสอบถามทุกวันเข้าถึงส่วนใหญ่ชั้นนี้ DB sharded เช่น Azure หรือ RDS เป็นโซลูชันผู้สมัครในชั้นที่ อย่างไรก็ตาม การลดต้นทุน และมีโซลูชันที่สามารถต่อขยายเพิ่มเติม ปัจจุบันศึกษามุ่งร่วมไม่ MapReduce ตามวิธีเช่นหมู กลุ่ม หรือ Jaql3.1.2 แนวคอลัมน์ชั้นเลือกห้องแอตทริบิวต์มหาศาลจากหนึ่งแฟ้ม/ศูนย์การแพทย์อื่นแตกต่างกันไป สำหรับแอตทริบิวต์นี้แตกต่างกันมาก เราเสนอเก็บในแนวคอลัมน์ฐานข้อมูล เฉพาะค่าแอตทริบิวต์ไม่ใช่ null จะถูกแทรกลงในคอลัมน์ที่สอดคล้องกันของพวกเขา (ซึ่งเพิ่มการประสิทธิภาพการทำงานอย่างมีนัยสำคัญ) ดังนั้น รุ่นนี้ copes อย่าง มีข้อมูลแตกต่างกัน ชั้นนี้มีสามารถดำเนินการได้อย่างมีประสิทธิภาพแบบสอบถามกิจตั้งแต่แนวคอลัมน์ฐานข้อมูล OLAP ปรับ นอกจากนี้ อีกทั้งวิธีเหมาะสมสำหรับปัญหาแผน evolutive เนื่องจากแต่ละคอลัมน์จะถูกเก็บในดิสก์แยกบล็อก เพื่อเพิ่มคอลัมน์ใหม่ไม่ท้าทาย แอตทริบิวต์ที่จัดเก็บไว้ในชั้นนี้จะเข้าถึงน้อยกว่ากัน เพื่อให้เราลดเวลาฟื้นฟูผลลัพธ์ ตัวอย่างของการนำไปคือ BigTable, Cassandra, Vertica, HBase และ HyperTable ในความเป็นจริง ต้นทุนสูง และคุณลักษณะเป็นกรรมสิทธิ์ของ Vertica และ BigTable และแนวงาน OLTP ของ Cassandra นำเราเน้นระบบอื่น ๆ (HBase, HyperTable)เป็น 3.1.3 คอลัมน์ดี Moverข้อเสนอของเรามีดี mover เป็นคอลัมน์ คอลัมน์ที่ดี mover เป็นกระบวนการที่ย้ายชั้นบางแอตทริบิวต์จากชั้นแถวในคอลัมน์ และในทางกลับตาม vise (เมื่อจำเป็น): เป็น DICOM evolutive แบบแผน การสอบถามก่อนหน้านี้และข้อมูล (เช่นเลือกแอตทริบิวต์เริ่มต้นเก็บไว้ในชั้นคอลัมน์ซึ่งในทางปฏิบัติที่ใช้ในแฟ้มส่วนใหญ่สามารถเคลื่อนย้ายไปยังระดับแถว) กระบวนการนี้สามารถดำเนินการเป็นระยะ ๆ (เช่นแต่ละเดือน) เพื่อรักษาแจกจ่ายแอททริบิวต์มากกว่าโครงสร้างนี้ได้ ดำเนินงานของกระบวนการนี้มีบางประเด็นที่สำคัญเช่นการกำหนดวิธีการรักษาแบบสอบถามกำลังทำงานอยู่ และเข้ามาขณะดำเนินกระบวนการนี้และเมื่อดำเนินการกระบวนการนี้ (ห้องในช่วงเวลา), ภายใต้เงื่อนไขใด