1. Trang chủ
  2. » Thể loại khác

HealthDL - Một hệ thống thu thập, lưu trữ dữ liệu Y tế lớn

9 42 0

Đang tải... (xem toàn văn)

THÔNG TIN TÀI LIỆU

Hiện nay, ứng dụng công nghệ lưu trữ lớn, khai phá dữ liệu trong lĩnh vực y tế để chẩn đoán, phòng ngừa và điều trị bệnh nhằm can thiệp nâng cao tình trạng sức khỏe con người là hướng nghiên cứu có nhu cầu thực tiễn. Trong nghiên cứu này, các tác giả giới thiệu HealthDL - Một hệ thống thu thập và lưu trữ dữ liệu y tế. HealthDL có kiến trúc phân tán, xây dựng từ các thành phần khả mở cho dữ liệu lớn, gia tăng liên tục theo thời gian thực. Hệ thống tối ưu cho dữ liệu nhận về từ các thiết bị y sinh và dữ liệu thông tin lịch sử bệnh án đến từ hàng triệu thiết bị phân tán về mặt địa lý. Các thử nghiệm, đánh giá trên hệ thống thực bằng các công cụ đánh giá tiêu chuẩn với dữ liệu mô phỏng cho kết quả tốt.

Khoa học Kỹ thuật Công nghệ HealthDL - Một hệ thống thu thập, lưu trữ liệu y tế lớn Phan Tân1*, Trần Việt Trung1, Nguyễn Hữu Đức1, Nguyễn Thanh Tùng2,3 Viện Công nghệ thông tin Truyền thông, Trường Đại học Bách khoa Hà Nội Khoa Quốc tế, Đại học Quốc gia Hà Nội Trường Đại học Nguyễn Tất Thành Ngày nhận 29/5/2017; ngày chuyển phản biện 1/6/2017; ngày nhận phản biện 26/6/2017; ngày chấp nhận đăng 30/6/2017 Tóm tắt: Hiện nay, ứng dụng công nghệ lưu trữ lớn, khai phá liệu lĩnh vực y tế để chẩn đốn, phòng ngừa điều trị bệnh nhằm can thiệp nâng cao tình trạng sức khỏe người hướng nghiên cứu có nhu cầu thực tiễn Trong nghiên cứu này, tác giả giới thiệu HealthDL - Một hệ thống thu thập lưu trữ liệu y tế HealthDL có kiến trúc phân tán, xây dựng từ thành phần khả mở cho liệu lớn, gia tăng liên tục theo thời gian thực Hệ thống tối ưu cho liệu nhận từ thiết bị y sinh liệu thông tin lịch sử bệnh án đến từ hàng triệu thiết bị phân tán mặt địa lý Các thử nghiệm, đánh giá hệ thống thực công cụ đánh giá tiêu chuẩn với liệu mô cho kết tốt Từ khóa: Cơ sở liệu phân tán, dịch tễ học, liệu lớn, thời gian thực Chỉ số phân loại: 2.2 HealthDL - A system for collecting and storing big data in the medical field Tan Phan1*, Viet Trung Tran1, Huu Duc Nguyen1, Thanh Tung Nguyen2,3 School of Information and Communication Technology, HUST VNU - International School (VNU-IS) Nguyen Tat Thanh University Received 29 May 2017; accepted 30 June 2017 Abstract: At present, applications of large storage technology and data mining in the medical field to diagnose, prevent, and treat diseases with the purpose of improving human health are preferred the practical researches In this study, we would like to introduce HealthDL: A system for collecting and storing medical data HealthDL has a dispersal architecture, is built from open components for large data, and continuously increases in real time An optimal system retrieves database from biomedical devices and medical record database coming from millions of geographically dispersed devices Tests and evaluations on the real system using standard assessment tools with simulated database show good results Keywords: Big data, dispersed database, epidemiology, real time Classification number: 2.2 Mở đầu Hiện nay, ứng dụng công nghệ lưu trữ lớn, khai phá liệu lĩnh vực y tế để chẩn đốn, phòng ngừa điều trị bệnh nhằm can thiệp nâng cao sức khỏe người hướng nghiên cứu có nhu cầu thực tiễn, quan tâm tích cực cộng đồng nhà nghiên cứu Tại Việt Nam, thiết bị y sinh (thiết bị đo thông số tim mạch, huyết áp…) sử dụng rộng rãi để giám sát người bệnh theo thời gian thực Các thiết bị đưa thơng số đo có tính liên tục, cập nhật theo chu kỳ lần/s Hiện nay, nguồn liệu chưa lưu trữ tập trung thách thức liên quan đến độ lớn liệu đến từ hàng triệu thiết bị đo, liên tục phân tán rộng mặt địa lý Bên cạnh nguồn liệu từ thiết bị y sinh, trạng hồ sơ bệnh án lưu trữ cách rải rác, khơng có chia sẻ Do đó, bác sỹ, trung tâm y tế khác gặp nhiều khó khăn để tìm kiếm thơng tin lịch sử bệnh tật bệnh nhân để đưa phác đồ điều trị hợp lý Vì vậy, việc lưu trữ bệnh án tập trung nhu cầu cấp thiết để phục vụ cơng tác phân tích, chẩn đốn Theo Ercan Lane (2014) [1], hệ thống bệnh án điện tử (Electronic Health Record - EHR) truyền Tác giả liên hệ: Email: phantan@gmail.com * 18(7) 7.2017 28 Khoa học Kỹ thuật Công nghệ thống, data lưu trữ dạng ghi bảng sở liệu quan hệ Nghiên cứu rằng, mở rộng ngày tăng lượng thông tin dịch vụ chăm sóc sức khỏe dẫn đến nút thắt nghẽn cổ chai việc lưu trữ, truy xuất đặt thách thức tính sẵn sàng cao việc sử dụng mơ hình sở liệu truyền thống Hơn nghiên cứu AndreuPerez cs (2015) [2], tác giả đa dạng liệu y tế ngày tăng với phát triển công nghệ, liệu từ sensor, mobile, liệu ảnh đòi hỏi phải nghiên cứu tìm kiếm cách thức tổ chức lưu trữ liệu y tế phù hợp. Nghiên cứu Ercan Lane (2014), Dobre Xhafa (2015) [1, 3] yêu cầu thiết yếu EHR đề xuất sử dụng mơ hình liệu phi quan hệ (NoSQL [4]) cho toán lưu trữ xử lý liệu lớn y tế Tuy nhiên nghiên cứu đưa gợi ý hướng tiếp cận chung, không đưa thiết kế tổng thể thu thập, lưu trữ EHR, không thử nghiệm, cài đặt đánh giá hiệu hệ thống Nghiên cứu thống sở liệu khoá - giá trị (một dạng NoSQL) giải pháp tốt cho liệu đơn giản, truy xuất thơng qua khố, giá trị đồng cấu trúc, khơng có cập nhật hay truy xuất dựa cấu trúc giá trị liệu Ví dụ thơng số an sinh xã hội khách hàng, thông tin số bảo hiểm y tế Cơ sở liệu hướng văn (một dạng NoSQL) giải pháp cho việc lưu trữ hồ sơ bệnh án y tế, bao gồm hồ sơ bệnh nhân, báo cáo nghiên cứu, báo cáo phòng thí nghiệm, hồ sơ bệnh viện, báo cáo chụp X quang, chụp cắt lớp… Các tác giả Ercan Lane (2014) [1] đề xuất sử dụng Dynamo Amazon [5], dịch vụ lưu trữ liệu điện toán đám mây Amazon để lưu trữ luồng liệu liên tục từ thiết bị y sinh Kiến trúc Dynamo Amazon dựa hàm băm quán cho chế mở rộng, sử dụng nút ảo để phân tán liệu đồng nút máy chủ vật lý, sử dụng vector clock [6] để giải xung đột phiên liệu sau trình ghi tương tranh đồng thời HealthDL hệ thống tổng thể, thành phần lưu trữ liệu theo mơ hình NoSQL nghiên cứu liên quan, HealthDL tích hợp hệ thống hàng chờ thơng điệp phân tán để thu thập luồng liệu đến từ thiết bị 18(7) 7.2017 y sinh phân tán mặt địa lý HealthDL xây dựng triển khai thực nghiệm, đánh giá hiệu lưu trữ môi trường phân tán Trong nghiên cứu này, giới thiệu HealthDL - Một hệ thống phân tán, thu thập lưu trữ liệu y tế tối ưu cho liệu nhận từ thiết bị y sinh liệu thông tin lịch sử bệnh án Xây dựng HealthDL toán nghiên cứu liệu lớn, gia tăng liên tục theo thời gian thực đến từ hàng triệu thiết bị phân tán mặt địa lý HealthDL cho phép thống kê, tìm kiếm phân tích liệu HealthDL hỗ trợ cơng việc chuyên viên dịch tễ học công tác thu thập, phân tích liệu đốn bệnh Đặc trưng liệu y tế Dữ liệu y tế nghiên cứu phân thành nhóm: Dữ liệu thu thập từ thiết bị y sinh liệu thông tin bệnh án Phần mô tả đặc trưng nguồn liệu đầu vào cho hệ thống HealthDL Dữ liệu y sinh Các thiết bị y sinh máy đo nhịp tim, huyết áp gửi thông số đo khoảng 540 bytes/s Trung bình bệnh nhân đo tiếng/ngày, số lượng gói liệu sinh tháng ứng với 1.000 bệnh nhân 216.000.000 gói liệu Mỗi gói trung bình 540 bytes, xét 1.000 bệnh nhân với máy đo độc lập, lượng liệu thu thập tương ứng 116 Gigabytes thông số bệnh nhân tháng Dữ liệu bệnh án Xét liệu bệnh án tìm hiểu nhóm bệnh, gồm: Bệnh tăng huyết áp (kích thước ghi 800-1.000 bytes); bệnh lao phổi (kích thước ghi 400-600 bytes); bệnh hen phế quản (kích thước ghi 500-700 bytes); bệnh đái tháo đường (kích thước ghi 800-1.000 bytes) Đặc điểm liệu bệnh án cấu trúc liệu linh hoạt Đối với bệnh nhân đái tháo đường, văn bệnh án có khoảng 150 trường liệu riêng biệt với cấu trúc chia nhỏ từ đến tầng (bảng 1) Đối với bệnh nhân tăng huyết áp, văn bệnh án có khoảng 75 trường liệu riêng biệt với cấu trúc chia nhỏ đến 4-5 tầng 29 Khoa học Kỹ thuật Công nghệ Bảng Một phần bệnh án đái tháo đường (ĐTĐ) từ thiết bị y sinh; 4) Khối lưu trữ bệnh án So với mơ hình truyền thống, HealthDL xây dựng thành phần phân tán, có tính khả mở, tối ưu hoá cho luồng liệu lớn Đầu vào hệ thống có luồng chính: Dữ liệu đầu vào từ thiết bị y sinh (dữ liệu đưa qua hàng chờ lưu trữ vào sở liệu); liệu đầu vào bệnh án, lưu trữ vào sở liệu chuyên biệt tối ưu hoá cho liệu bệnh án có cấu trúc linh hoạt Mơ hình tổng thể hệ thống mơ tả hình Trong báo này, chúng tơi khơng trình bày thiết bị y sinh mà vào thành phần khối lại với nhiệm vụ thu thập tổ chức lưu trữ liệu phân tán Mục tiêu hệ thống đảm bảo hiệu năng, khả mở rộng cao với liệu vào theo luồng liệu có cấu trúc linh hoạt, nguồn liệu phân tán rộng mặt địa lý Như thấy, nguồn liệu y tế hệ thống HealthDL mang đặc trưng liệu lớn Cụ thể: Kích thước lớn: Xét 1.000 bệnh nhân với máy đo độc lập, lượng liệu thu thập tương ứng 116 Gigabytes thông số bệnh nhân tháng Như vậy, số bệnh nhân tăng lên thời gian đo kéo dài, lượng liệu cần thu thập vô lớn Tốc độ lớn: Các thiết bị y sinh tạo liệu liên tục với tốc độ cao (tần suất ghi liệu/s) đòi hỏi hệ thống lưu trữ cần đảm bảo tính sẵn sàng cao, đáp ứng tương tranh đồng thời tiến trình ghi liệu tiến trình đọc, xử lý liệu theo thời gian thực Tính đa dạng: Các bệnh án liệu bán cấu trúc có lược đồ khơng đồng Việc lưu trữ liệu đòi hỏi hệ quản trị sở liệu phải có lược đồ liệu linh hoạt, điều mà hệ quản trị sở liệu quan hệ truyền thống không đáp ứng Mang lại giá trị lớn: Dữ liệu y tế lưu trữ khai thác mang lại hiệu cao việc chẩn đốn, điều trị bệnh, góp phần cải thiện chất lượng khám chữa bệnh giảm chi phí xét nghiệm Mơ hình hệ thống Chúng tơi xây dựng HealthDL hệ thống có kiến trúc tổng thể chia làm phần chính, gồm: 1) Khối thiết bị y sinh đo thông số cần thiết từ người bệnh; 2) Khối tiếp nhận chuyển tiếp liệu; 3) Khối lưu trữ liệu 18(7) 7.2017 Hình Thiết kế tổng quan HealthDL Cơng nghệ đề xuất Apache Kafka cho hàng chờ thông điệp Apache Kafka [7] hệ thống truyền thông điệp phân tán, độ tin cậy cao, dễ dàng mở rộng có thơng lượng cao Apache Kafka cung cấp chế offset (có thể hiểu tương tự số mảng) để lấy thông điệp cách linh hoạt, cho phép ứng dụng xử lý xử lý lại liệu việc xử lý trước bị lỗi Ngồi ra, chế “đăng ký” theo dõi cho phép việc lấy thông điệp gần tức thời liệu vào hàng chờ Apache Kafka thiết kế hỗ trợ tốt cho việc thu thập liệu theo thời gian thực Với tính chất này, Apache Kafka lựa chọn phù hợp cho khối thu thập liệu HealthDL Apache Kafka hệ thống lưu trữ thông điệp phát triển LinkedIn với đặc điểm sau: Tốc độ nhanh: Với máy đơn cài đặt Apache Kafka xử lý số lượng liệu từ việc đọc ghi lên tới 30 Khoa học Kỹ thuật Công nghệ hàng trăm megabytes/s từ hàng ngàn máy khách Khả mở rộng: Apache Kafka thiết kế cho phép dễ dàng mở rộng suốt với người dùng (nghĩa khơng có thời gian chết - ngừng hoạt động thêm nút vào cụm) Khi Apache Kafka chạy cụm, luồng liệu phân chia vận chuyển tới nút cụm, cho phép trung chuyển liệu có khối lượng lớn nhiều so với sức chứa máy đơn Độ tin cậy: Dữ liệu vào hàng chờ lưu trữ ổ đĩa chép tới nút khác cụm để ngăn ngừa việc liệu, Apache Kafka đảm bảo tính chịu lỗi cao Khi so sánh với hệ thống truyền thông điệp truyền thống lâu đời RabbitMQ [8] cho thấy Apache Kafka có lượng liệu đọc ghi cao nhiều so với RabbitMQ Ngược lại, lượng tài nguyên mà Apache Kafka chiếm dụng lại nhiều Do đó, Apache Kafka thích hợp cho ứng dụng xử lý theo thời gian thực với lượng liệu lớn Một số khái niệm cần nắm rõ vận hành Apache Kafka: 1) Topic: Là “chủ đề”, thông thường liệu liên quan tương tự nhóm chủ đề Mỗi chủ đề coi nguồn liệu riêng biệt; 2) Broker: Apache Kafka chạy cụm bao gồm nhiều máy (nút), nút gọi broker; 3) Partition: Mỗi topic phân chia thành nhiều phân mảnh (partition), partition đơn vị cho phép lưu để phục hồi đến broker khác; 4) Producer: Thành phần sinh liệu, ghi liệu tới broker; 5) Consumer: Thành phần “tiêu thụ” liệu, đọc liệu từ broker Hình mơ tả kiến trúc Apache Kafka chạy cụm với broker, với topic tên MCL chia thành partition, partition có chép broker khác để phục vụ chế lưu, khắc phục lỗi Mỗi partition có broker làm vai trò trưởng nhóm (leader), broker lại có lưu trữ partition gọi nút theo dõi (follower), có nhiệm vụ lưu liệu Mỗi partition cấu hình tham số nhân (replication factor) Trong hình 2, replication factor = 2, nghĩa partition lưu trữ broker Zookeeper [9] thành phần cung cấp dịch vụ lõi cho hệ thống phân tán như: Dịch vụ quản lý cấu hình hệ thống, bầu trưởng nhóm (leader election), định danh (naming) Zookeeper Apache Kafka bầu tự động leader cho partition, quản lý danh sách nút máy chủ hoạt động, quản lý danh sách topic Cơ sở liệu Cassandra cho lưu trữ liệu từ thiết bị y sinh Cassandra [10] sở liệu hướng cột, phân tán (một mơ hình liệu NoSQL) có khả mở rộng cao (highly scalable), thiết kế để quản lý lượng lớn liệu có cấu trúc Cassandra đảm bảo tính sẵn sàng cao với thiết kế có khả chịu lỗi, nút máy chủ cụm Cassandra đồng theo thiết kế ngang hàng (peer-to-peer [11]), khơng có thành phần hệ thống điểm hỏng thắt cổ chai (bottle-neck) Cassandra có số đặc điểm sau: Tính khả mở co dãn được: Cassandra có tính khả mở cao, cho phép thêm vào hệ thống máy chủ để đáp ứng với nhu cầu tải từ phía ứng dụng, đồng thời cho phép rút bớt ra, tháo khỏi hệ thống máy chủ để giảm điện tiêu thụ, thay phục hồi, sửa lỗi mà tạm dừng khởi động lại hệ thống Kiến trúc sẵn sàng: Cassandra khơng có điểm hỏng hóc đơn lẻ, có chế cho phép hệ thống hoạt động liên tục, đáp ứng ứng dụng thương mại quan trọng mà khơng chấp nhận hỏng hóc Hình Mơ hình truyền thơng điệp phân tán Apache Kafka 18(7) 7.2017 Mơ hình liệu linh hoạt: Cassandra hệ sở liệu hướng cột với mơ hình liệu linh hoạt cho phép lưu trữ liệu có cấu trúc, bán cấu trúc phi cấu trúc (hình 3) Cassandra tiếp nhận liệu với cấu trúc động mà không cần định nghĩa trước lược đồ liệu sở liệu quan hệ 31 Khoa học Kỹ thuật Công nghệ thao tác ghi liệu Cassandra sử dụng chế hàm băm quán phân tán (distributed consistent hashing [12]) tổ chức nút máy chủ thành cụm theo định dạng vòng tròn liệu phân tán theo vòng tròn theo hàm băm qn (hình 4) Hình Mơ hình liệu hướng cột Cassandra (Row key 1: Bản ghi liệu với khoá “key 1”; Column 1: Định nghĩa thuộc tính cột thứ nhất; Value 1: Giá trị thuộc tính thứ tương ứng với ghi liệu) Dễ dàng phân tán liệu: Cassandra thiết kế theo mô hình phân tán liệu Dynamo Amazon [5] sử dụng hàm băm quán (consistent-hashing [12]) để phân tán liệu Điều cho phép tối ưu trình di chuyển liệu cấu hình hệ thống thay đổi Các nút máy chủ thêm vào hay rút khơng làm ảnh hưởng đến việc phân bố lại tồn không gian liệu Cho phép ghi liệu nhanh, thông lượng lớn: Cassandra thiết kế chạy máy tính phổ thơng có cấu hình thấp cho phép đáp ứng hiệu cao với thao tác đọc, ghi liệu thông lượng lớn, lưu trữ hàng trăm terabyte liệu Thiết kế Cassandra khơng có điểm chết tập trung Cassandra có thiết kế dựa kiến trúc mạng ngang hàng, tất nút máy chủ hệ thống có vai trò khơng có nút máy chủ đóng vai trò máy chủ trung tâm mà việc hỏng hóc máy chủ kéo theo đánh sập hồn tồn hệ thống kiến trúc chủ - khách truyền thống Các nút máy chủ Cassandra độc lập Mỗi nút xử lý thao tác ghi đọc liệu, không phân biệt liệu lưu trữ cách vật lý máy chủ hệ thống Khi nút hệ thống bị hỏng hóc dừng hoạt động, thao tác đọc ghi liệu xử lý nút khác hệ thống Q trình hồn tồn suốt với ứng dụng, cho phép ẩn hỏng hóc hệ thống ứng dụng Trong Cassandra, đối tượng liệu nhân lưu giữ nhiều máy chủ Nếu máy chủ lưu phiên liệu bị lỗi phiên cập nhật liệu nhất, Cassandra có chế đồng để đảm báo thao tác đọc trả liệu Cơ chế thực thi trình đọc liệu (read repair) thay đồng thao tác ghi liệu, điều cho phép tăng hiệu 18(7) 7.2017 Hình Bảng băm quán biểu diễn dạng vòng tròn địa Cơ sở liệu MongoDB để lưu trữ liệu bệnh án MongoDB [13] sở liệu hướng văn bản, khái niệm làm việc với MongoDB: Document: Document hay văn đơn vị liệu MongoDB Document có cấu trúc tương tự kiểu liệu JSON [14], bao gồm cặp khóa - giá trị, giá trị bao hàm trường khố - giá trị Document hiểu giống ghi liệu sở liệu quan hệ, nhiên khác biệt cặp khố giá trị văn khơng giống document Do vậy, document linh hoạt mặt cấu trúc Mỗi văn có định danh id collection Collection: Collection nhóm tài liệu (document), tương đương với bảng (table) sở liệu quan hệ Các collection khơng có ràng buộc quan hệ tham chiếu lẫn bảng hệ quản trị sở liệu quan hệ Database: Database sở liệu, database gồm nhiều collection Một máy chủ MongoDB tạo nhiều sở liệu Các tính quan trọng MongoDB: Mơ hình liệu linh hoạt: Mơ hình liệu hướng văn MongoDB cho phép dễ dàng lưu trữ kết hợp liệu có cấu trúc động mà khơng làm giảm việc kiểm soát ràng buộc kiểu, miền giá trị liệu 32 Khoa học Kỹ thuật Cơng nghệ Tính khả mở cao, cho phép triển khai nhiều trung tâm liệu: MongoDB mở rộng trung tâm liệu triển khai phân tán nhiều trung tâm liệu phân tán mặt địa lý Tính sẵn sàng cao: Người quản trị hệ thống dễ dàng tăng giảm số lượng máy chủ tham gia vào hệ sở liệu thời điểm nào, không cần phải tạm dừng khởi động lại hệ thống Nhiều tính tích hợp kèm hệ sinh thái sử dụng MongoDB: Các tính phân tích liệu, trình diễn liệu, đánh mục, xử lý liệu đồ thị, liệu khơng gian dễ dàng tích hợp với sở liệu MongoDB thơng qua trình điều khiển kết nối chuẩn hố hỗ trợ mạnh mẽ Nhân bản: Nhân tính vơ quan trọng MongoDB khuyến cáo sử dụng cài đặt MongoDB cho môi trường thực tế (ứng dụng thực, liệu thực) Kỹ thuật nhân tức đối tượng liệu nhóm máy chủ khác Trong nhóm máy chủ có máy chủ máy chủ nhân máy lại máy chủ nhân thứ cấp (phụ) Máy chủ nhân đóng vai trò tổng quản, nơi mà thao tác ghi, cập nhật đối tượng liệu cần phải thông qua máy chủ Các máy chủ thứ cấp sử dụng cho việc đọc liệu để cân tải MongoDB có chế độ chuyển đổi dự phòng (failover) tự động máy chủ nhân bị lỗi máy chủ thứ cấp bầu làm máy chủ thay để đảm bảo thao tác ghi liệu thực thi thành cơng (hình 5) Sharding: Khi kích thước liệu gia tăng, máy tính đơn lẻ khơng thể đủ để lưu liệu cung cấp xử lý đọc ghi thông thường Sharding kỹ thuật cho phép văn MongoDB phân tán nhiều máy chủ Việc phân tán liệu có ý nghĩa quan trọng góp phần mở rộng khả lưu trữ xử lý hệ thống, đồng thời tăng khả chịu lỗi Song song với việc tự động hoá phân tán liệu, máy chủ liệu bị gặp lỗi hệ thống có chế tự động định tuyến lại thao tác đọc ghi máy chủ bị lỗi qua máy chủ khác Hình giải thích việc collection A chia shard A B colllection B nằm shard A Hình Kỹ thuật phân mảnh liệu sharding MongoDB (Shard: Một khối lưu trữ liệu độc lập; Collection: Tập hợp văn có tính tương đồng cấu trúc) Với thiết kế dạng liệu hướng văn bản, MongoDB sở liệu thích hợp để lưu trữ thơng tin bệnh án gồm nhiều trường thông tin, trường không đồng bệnh án khác bệnh án bệnh khác Cấu trúc hướng văn MongoDB cho phép người dùng tạo mục thuộc tính văn để tìm kiếm nhanh, điều khác biệt MongoDB so với Cassandra Đây lý để lựa chọn MongoDB thay cho Cassandra lưu trữ thông tin bệnh án Đánh giá thực nghiệm Hình Nhân MongoDB (Client Application: Ứng dụng phía người dùng; Writes: Tác vụ ghi liệu; Reads: Tác vụ đọc liệu; Primary: Máy chủ nhân chính; Secondary: Máy chủ nhân thứ cấp; Replication: Quá trình nhân liệu) 18(7) 7.2017 Trong phần này, đánh giá hiệu hệ thống HealthDL thao tác đọc, ghi liệu môi trường phân tán, gia tăng kết nối tương tranh đồng thời Chúng cài đặt tiến hành chạy đánh giá MongoDB Cassandra với công cụ đánh giá tiêu chuẩn YCSB [15] Cassandra-stress [16] Hai công cụ 33 Khoa học Kỹ thuật Công nghệ đo số thao tác vào trung bình thực thi s với khối liệu vào cung cấp sẵn Đánh giá thành phần lưu trữ thông tin bệnh án MongoDB MongoDB cài đặt mơi trường ảo hố sử dụng docker-compose, cụm máy tính gồm 30 nút ảo chia sẻ cấu hình: CPU (Haswell 2.3 G), SSD (Intel 800 GB SATA Gb/s), RAM (128 GB) Kết kịch đọc ghi cho hiệu cao với tốc độ đạt từ 70.000 đến 100.000 ghi/s, độ trễ đến 1,5 s với số lượng client kết nối tới lên đến 100 client tương tranh đồng thời (hình 7A 7B) Hình 7A Kịch ghi liệu MongoDB Trong hình 7A 7B, đường kẻ màu tím mơ tả độ trễ trung bình, đường kẻ màu xanh dương mơ tả độ trễ trung bình 5% tác vụ có độ trễ cao nhất, đường kẻ màu xanh mô tả độ trễ trung bình 1% tác vụ có độ trễ cao Từ biểu đồ kết cho thấy, 1% tác vụ có độ trễ cao 3,5 s Với kịch tác vụ đọc ghi tỷ lệ 50/50 (vừa đọc vừa ghi) cho kết tốt, với tốc độ trung bình 70.000 ghi/s, độ trễ trung bình 1,4 s (hình 8) Trong hình 8, đường kẻ màu xanh dương mơ tả độ trễ trung bình tác vụ đọc, đường kẻ màu tím mơ tả độ trễ trung bình tác vụ ghi Từ kết cho thấy rằng, độ trễ hai dạng tác vụ không chênh lệch với Hình Kịch đọc ghi đồng thời MongoDB (50/50 read/write workload: Kịch đọc ghi đồng thời; Ops/sec: Số tác vụ thực thi thành công s; Theads: Số lượng kết nối đến hệ thống; Throughput: Giải nghĩa ops/sec; AverageLatencyRead: Độ trễ trung bình tác vụ đọc liệu; AverageLatencyWrite: Độ trễ trung bình tác vụ ghi liệu) Mặc dù xây dựng cụm MongoDB phân tán ảo docker-compose, nút không sử dụng trọn vẹn tài nguyên phần cứng tốt nhất, kết trả khả quan yêu cầu việc nhập liệu, lưu trữ chia sẻ bệnh án Hình 7B Kịch đọc liệu MongoDB Trong đó: 100% write workload: Kịch ghi; 100% read workload: Kịch đọc; Ops/sec: Số tác vụ thực thi thành công s; Theads: Số lượng kết nối đến hệ thống; Throughput: Giải nghĩa ops/sec; 95thPercentileLatency: Độ trễ 5% tác vụ có độ trễ cao nhất; 99thPercentileLatency: Độ trễ 1% tác vụ có độ trễ cao nhất; AverageLatency: Độ trễ trung bình 18(7) 7.2017 Đánh giá thành phần lưu trữ liệu từ thiết bị y sinh Cassandra Cassandra cài đặt máy chủ riêng biệt với cấu hình máy sau: CPU (Haswell 2.3 G), SSD (Intel 800 GB SATA Gb/s), RAM (128 GB) Kịch thử nghiệm đo số lượng thao tác đọc, ghi/s độ trễ trung bình Các thử nghiệm qua gia tăng số lượng tiến trình client thực thi thao tác đọc, ghi liệu tương tranh đồng thời 34 Khoa học Kỹ thuật Công nghệ Trong thử nghiệm tiến trình tương tranh thực thi thao tác ghi (hình 9A), tiến trình tương tranh thực thi thao tác đọc (hình 9B), Cassandra đáp ứng hiệu cao với số thao tác xử lý từ 250.000 đến 300.000 ghi/s Độ trễ trung bình từ 0,2 đến 0,3 ms Với kịch đọc, ghi tương tranh (hình 10) Cassandra đáp ứng số thao tác từ 250.000 đến 300.000 ghi/s Đường kẻ màu tím mơ tả độ trễ trung bình, đường kẻ màu xanh dương mơ tả độ trễ trung bình 5% tác vụ có độ trễ cao nhất, đường kẻ màu xanh mơ tả độ trễ trung bình 1% tác vụ có độ trễ cao Từ kết nhận thấy rằng, có 1% tác vụ có độ trễ cao 1,6 ms Hình 10 Đọc ghi tương tranh đồng thời Cassandra (50/50 read/write workload: Kịch đọc ghi đồng thời; Ops/sec: Số tác vụ thực thi thành công s; Theads: Số lượng kết nối đến hệ thống; Throughput: Giải nghĩa ops/sec; AverageLatencyRead: Độ trễ trung bình tác vụ đọc liệu; AverageLatencyWrite: Độ trễ trung bình tác vụ ghi liệu) Hình 9A Gia tăng thao tác tương tranh ghi Các kết thử nghiệm với MongoDB Cassandra môi trường tương tranh cho thấy, thành phần đáp ứng hiệu cao điều kiện đọc ghi tương tranh đồng thời Về hiệu năng, Cassandra cho hiệu cao số thao tác/s, phù hợp với lưu trữ liệu đến từ thiết bị y sinh thời gian thực Kết luận Trong báo này, giới thiệu HealthDL, hệ thống thu thập lưu trữ liệu lớn cho y tế Kết đánh giá hiệu thành phần lưu trữ môi trường thử nghiệm chứng minh khả đáp ứng tốt với yêu cầu nghiệp vụ đọc ghi liệu tương tranh đồng thời Về thiết kế tổng thể, hệ thống cấu thành từ thành phần phân tán, có tính khả mở cao, hỗ trợ mơ hình liệu linh hoạt Trong tương lai, triển khai hệ thống thực tiễn tiến hành tích hợp với thành phần phân tích liệu y tế phân tán Hình 9B Gia tăng thao tác tương tranh đọc Trong đó: 100% write workload: Kịch ghi; 100% read workload: Kịch đọc; Ops/sec: Số tác vụ thực thi thành công s; Theads: Số lượng kết nối đến hệ thống; Throughput: Giải nghĩa ops/sec; 95thPercentileLatency: Độ trễ 5% tác vụ có độ trễ cao nhất; 99thPercentileLatency: Độ trễ 1% tác vụ có độ trễ cao nhất; AverageLatency: Độ trễ trung bình 18(7) 7.2017 LỜI CẢM ƠN Các tác giả xin cảm ơn Chương trình KH&CN cấp nhà nước phục vụ phát triển bền vững vùng Tây Bắc tài trợ nghiên cứu thông qua đề tài “Ứng dụng triển khai hệ thống phần mềm tích hợp kết nối thiết bị điện tử y sinh mạng truyền thông hỗ trợ theo dõi sức khoẻ dịch tễ cộng đồng khu vực Tây Bắc” (mã số KHCN-TB.06C/13-18) 35 Khoa học Kỹ thuật Công nghệ TÀI LIỆU THAM KHẢO [8] A Videla, J.J.W Williams (2012), RabbitMQ in action, Manning [1] M Ercan, M Lane (2014), “An evaluation of NoSQL databases for EHR systems”, Proceedings of the 25th Australasian Conference on Information Systems, pp.8-10 [9] P Hunt, M Konar, F.P Junqueira, B Reed (2010), “ZooKeeper: Wait-free coordination for Internet-scale systems”, USENIX Annual Technical Conference, 8, p.9 [2] J Andreu-Perez, C.C.Y Poon, R.D Merrifield, S.T.C Wong, G.Z Yang (2015), “Big data for health”, IEEE J Biomed Heal informatics, 19(4), pp.11931208 [10] A Lakshman, P Malik (2010), “Cassandra: A decentralized structured storage system”, ACM SIGOPS Oper Syst Rev., 44(2), pp.35-40 [3] C Dobre, F Xhafa (2015), “NoSQL technologies for real time (patient) monitoring”, Advanced Technological Solutions for E-Health and Dementia Patient Monitoring, pp.183-210 [4] K Grolinger, W.A Higashino, A Tiwari, M.A Capretz (2013), “Data management in cloud environments: NoSQL and NewSQL data stores”, J of Cloud Comput.: Adv Syst Appl., 2, pp.2-22 [5] G Decandia, D Hastorun, M Jampani, G Kakulapati, A Lakshman, A Pilchin, S Sivasubramanian, P Vosshall, W Vogels (2007), “Dynamo: Amazon’s highly available key-value store”, ACM SIGOPS Oper Syst Rev., 41(6), pp.205220 [6] D.S Parker, G.J Popek, G Rudisin, A Stoughton, B.J Walker, E Walton, J.M Chow, D Edwards, S Kiser, C Kline (1983), “Detection of Mutual Inconsistency in Distributed Systems”, IEEE Trans Softw Eng., SE-9(3), pp.240247 [7] N Garg (2013), Apache Kafka, Packt Publishing Ltd 18(7) 7.2017 [11] S Androutsellis-Theotokis, D Spinellis (2004), “A survey of peer-topeer content distribution technologies”, ACM Comput Surv., 36(4), pp.335-371 [12] D Karger, E Lehman, T Leighton, M Levine, D Lewin, R Panigrahy (1997), “Consistent Hashing and Random Trees: Distributed caching protocols for Relieving hot Spots on the world wide web”, Proceedings of the twenty-ninth annual ACM symposium on Theory of computing, pp.654-663 Inc [13] K Chodorow (2013), MongoDB: The definitive guide, O’Reilly Media, [14] T Bray (2014), “The javascript object notation (JSON) data interchange format”, Standards Track, pp.1-16 [15] B.F Cooper, A Silberstein, E Tam, R Ramakrishnan, R Sears (2010), “Benchmarking Cloud Serving Systems with YCSB”, Proceeding of the 1st ACM symposium on cloud computing [16] Cassandra Stress, Available, http://docs.datastax.com/en/cassandra/2.1/ cassandra/tools/toolsCStress_t.html 36 ... đồng Việc lưu trữ liệu đòi hỏi hệ quản trị sở liệu phải có lược đồ liệu linh hoạt, điều mà hệ quản trị sở liệu quan hệ truyền thống không đáp ứng Mang lại giá trị lớn: Dữ liệu y tế lưu trữ khai... đánh giá hiệu lưu trữ môi trường phân tán Trong nghiên cứu n y, giới thiệu HealthDL - Một hệ thống phân tán, thu thập lưu trữ liệu y tế tối ưu cho liệu nhận từ thiết bị y sinh liệu thông tin... trợ cơng việc chuyên viên dịch tễ học công tác thu thập, phân tích liệu đốn bệnh Đặc trưng liệu y tế Dữ liệu y tế nghiên cứu phân thành nhóm: Dữ liệu thu thập từ thiết bị y sinh liệu thông tin

Ngày đăng: 15/01/2020, 21:08

Xem thêm:

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w