Tên tham số Giá trị mặc định Mô tả
--from Đường dẫn đến thư mục
chứa dữ liệu backup
--database graph.db Tên của database.
--force false Xác định xem có ghi đè lên
dữ liệu cũ hay không.
Trong Neo4j restore dữ liệu được tách thành hai loại: (1) restore cho Causal Cluster và (2) restore cho Single Database. Trình tự các bước thực hiện với cách restore cho Single Database gồm.
1. Tắt hoạt động CSDL.
2. Thực hiện chạy lệnh neo4j-admin restore. 3. Khởi động lại CSDL.
Ở Hình 2.48 sau đây biểu diễn các câu lệnh để thực hiện restore database. Với database có tên là graph.db từ thư mục 202204/graph.db-backup.
65 Để thực hiện restore cho Causal Cluster, các server trong Core Server cần được tách ra khỏi cụm. Các server trong Core Server được gắn kết với nhau (bind) khi Cluster được hình thành. Một server được tách (unbind) khỏi Core Server bằng cách chạy câu lệnh neo4j-admin unbind. Câu lệnh unbind không sử dụng cho các Read Replica server vì các server này khơng phải là thành phần của Core Server. Để thực hiện lệnh unbind, người quản trị bật terminal từ thư mục mã nguồn của Neo4j sau đó sử dụng câu lệnh có cú pháp như Hình 2.49 dưới đây.
Hình 2.49 Cú pháp câu lệnh unbind trong neo4j
Hình 2.50 dưới đây biểu diễn câu lệnh thực hiện unbind cho một server trong Core Server. Server này có tên database là graph.db.
Hình 2.50 Ví dụ cú pháp câu lệnh unbind trong neo4j
Restore đối với Causal Cluster được thực hiện theo trình tự các bước sau. 1. Tắt tất cả các CSDL đang chạy trong Cluster.
2. Chạy câu lệnh neo4-admin unbind cho mỗi Core Server.
3. Thực hiện restore dữ liệu trên mỗi Core Server bằng câu lệnh neo4j-admin restore.
4. Chạy lại các CSDL. Lúc này các server trong Core Server của Cluster sẽ tự bind với nhau.
66
CHƯƠNG 3. THỰC NGHIỆM
Cần phải đánh giá được hiệu năng của hệ thống API Service trên bốn mơ hình lưu trữ bên trên với bộ dữ liệu lấy từ công cụ sinh dữ liệu mô phỏng. Giải quyết vấn đề này tơi triển khai theo ba ý chính: (1) mơi trường thực nghiệm, (2) dữ liệu thực nghiệm và (3) đánh giá hiệu năng truy vấn thực nghiệm. Kết quả thu được phục vụ đánh giá mơ hình đã chọn và khả năng đáp ứng của máy chủ với từng nhóm câu hỏi.
3.1 Mơi trường thực nghiệm
Để thực hiện đánh giá mơ hình và hiệu năng của hệ thống cung cấp API Service, tôi lựa chọn một máy chủ local và một máy chủ cloud với cấu hình cụ thể lần lượt như sau:
❖ Máy chủ local:
• Hệ điều hành: Window 11 • Thơng tin phần cứng:
- CPU: core i7 10700F CPU @ 2.90 GHz - RAM: 16GB - SSD: 512GB ❖ Máy chủ cloud: • Hệ điều hành: Linux • Thơng tin phần cứng: - CPU: 32CORE - RAM: 64GB - SSD: 2TB 3.2 Dữ liệu thực nghiệm
Sau khi chuẩn bị mơi trường thực nghiệm, cần có bộ dữ liệu đủ lớn. Dữ liệu này được lấy từ công cụ sinh dữ liệu mô phỏng đã mô tả ở chương 2 phần 2; bộ dữ liệu được lựa chọn là 200M với 235.621.005 node, 728.000.060 relationship và 524.863.033 property. Bảng 16 mô tả thông tin dữ liệu trên hai máy chủ được sử dụng.
67 Bảng 3. 1. Bộ dữ liệu thực nghiệm Máy chủ Số lượng thực thể Số lượng relationship Thời gian sinh dữ liệu Thời gian import Local 235.621.005 node 728.000.060 ~ 875s ~ 2409s Cloud 235.621.005 node 728.000.060 ~ 781s ~ 2116s
3.3 Đánh giá hiệu năng truy vấn thực nghiệm
Với mỗi mơ hình đã đề xuất cần lựa chọn ra mơ hình tối ưu bằng cách đánh giá dựa trên số lượng dbhits của câu truy vấn và kết quả trả về. Từ đó đánh giá hiệu năng hệ thống API service được xây dựng bằng mơ hình dữ liệu tối ưu.
3.3.1 Đánh giá mơ hình dữ liệu
Bốn mơ hình được lựa chọn ở Chương 2 mục 3 được thực nghiệm đánh giá thơng qua hai nhóm câu hỏi với các câu truy vấn điển hình; kết quả chi tiết ở Bảng 17 bên dưới.
Bảng 3. 2. Đánh giá bốn mơ hình
STT Câu hỏi truy vấn Mơ hình
Thứ nhất Thứ hai Thứ ba Thứ tư 1 Truy vấn thông tin
người có name “Donald Trump” 208(dbhits) (38 kết quả) 208(dbhits) (38 kết quả) 208(dbhits) (38 kết quả) 208(dbhits) (38 kết quả) 2 Người có name “Donald
Trump” được nhắc đến trong bài báo nào.
315(dbhits) (60 kết quả) 315(dbhits) (60 kết quả) 315(dbhits) (60 kết quả) 315(dbhits) (60 kết quả) 3 Các thực thể quan hệ
trích xuất từ bài viết có link: https://link-new-1. 198(dbhits) (104 kết quả) 198(dbhits) (104 kết quả) 198(dbhits) (104 kết quả) 198(dbhits) (104 kết quả)
68 4 Chỉ ra các thực thể có
quan hệ với tổng thống Donald Trump trong bài viết 1. 883(dbhits) (58 kết quả) 883(dbhits) (58 kết quả) 883(dbhits) (58 kết quả) 883(dbhits) (58 kết quả) 5 Số lần tổng thống Donald Trump được đề cập đến trong cả ba bài viết. 1072 (dbhits) (281 kết quả) 1072 (dbhits) (281 kết quả) 1072 (dbhits) (281 kết quả) 1072 (dbhits) (281 kết quả) 6 Sự kiện tổng thống Donald Trump và chỉ tịch Kim Jong-un tham gia giả quyết vấn đề phi hạt nhân được lấy ra từ những bài báo nào?
3685 (dbhits) (9117 kết quả) 3518 (dbhits) (9117 kết quả) 3601 (dbhits) (9117 kết quả) 2940 (dbhits) (9117 kết quả) 7 Tổng thống Donald Trump đã từng gặp ai? 2834 (dbhits) (801 kết quả) 2834 (dbhits) (801 kết quả) 2773 (dbhits) (801 kết quả) 2142 (dbhits) (801 kết quả) 8 Những loại quan hệ mà Tổng thống Donald Trump đang có? 5127 (dbhits) (46 kết quả) 4935 (dbhits) (46 kết quả) 4892 (dbhits) (46 kết quả) 4611 (dbhits) (46 kết quả) 9 Tổng thống Donald Trump và tổng thống Vladimir Putin có những quản hệ gì? 1658 (dbhits) (9 kết quả) 1642 (dbhits) (9 kết quả) 1651 (dbhits) (9 kết quả) 1631 (dbhits) (9 kết quả) Nhận xét chung:
- Kết quả trả về ở mỗi mơ hình trên từng câu truy vấn giống nhau;
- Nhóm câu hỏi thứ nhất - từ dòng 1 đến dòng 5: số lượng dbhits của bốn mơ hình dữ liệu đều như nhau. Vì q trình truy vấn khơng xét quan hệ giữa các thực thể mà chỉ lấy thông tin thực thể nên cho kết quả giống nhau cả trên bốn mơ hình. Hay quá trình thực thi truy vấn cùng lấy từ mơ hình cơ bản ở Hình 2.1 ở trên.
69 - Nhóm câu hỏi thứ hai - từ dịng 7 đến dịng 9: truy vấn trên mỗi model có số lượng dbhits được sử dụng dễ dàng nhận thấy sự khác biệt. Do q trình truy vấn khơng chỉ lấy thơng tin thực thể mà cịn xét đến quan hệ của thực thể đấy. Thứ tự về số lượng dbhits đối với mỗi câu truy vấn: ở mơ hình bốn là ít nhất, theo sau đó là mơ hình thứ ba, cịn lại mơ hình thứ hai và thứ nhất có số lượng dbhits với các câu hỏi là như nhau. Hay hiểu cách khác số lượng dbhits ở mơ hình thứ tư là tốt nhất. Bởi vì kiểu relationship giữa fact- node và subject, object là trực tiếp.
3.3.2 Đánh giá truy vấn hiệu năng hệ thống
Để kiểm tra khả năng đáp ứng của hệ thống được xây dựng từ mơ hình tối ưu, u cầu thực nghiệm trên bộ dữ liệu đủ lớn trên những câu truy vấn điển hình. Tiêu chí đánh giá dựa theo thời gian thực hiện truy vấn. Bảng 18 dưới đây cho thấy thời gian thực thực hiện các câu truy vấn đối với mỗi máy chủ.
Kết quả cho thấy trên cùng một máy chủ thời gian thực hiện các câu truy vấn là khác nhau. Câu truy vấn càng phức tạp thì thời gian thực hiện càng tốn nhiều thời gian – hay độ phức tạp tỉ lệ thuận với thời gian thực hiện. Cụ thể với cấu cùng là tìm thực thể nhưng ở dịng thứ nhất chỉ đơn thuần là tìm thực thể cịn dịng thứ ba có thêm điều kiện trong những bài báo chỉ định. Ngoài ra các câu truy vấn liên quan đến thực thể sẽ cho tốc độ nhanh hơn so với câu truy vấn liên quan đến thực thể và quan hệ.
Thời gian thực hiện truy vấn không chỉ phụ thuộc vào độ phức tạp câu hỏi mà còn phụ vào cấu hình máy chủ. Với hai máy chủ thực nghiệm: máy chủ càng mạnh thì thời gian thực hiện càng ngắn.
Từ nhận xét trên giúp người phát triển đưa ra giải pháp phù hợp, tập trung cho những nhóm câu hỏi mất nhiều thời gian thực hiện hay nâng cấp, mở rộng phần cứng máy chủ.
70
Bảng 3. 3. Bảng hiệu năng truy vấn trên máy chủ
STT Câu truy vấn Máy chủ local Máy chủ cloud
1 Truy vấn thực thể có thơng tin: node Person có property name -
Person 1.
517ms (15 kết quả)
92ms
(15 kết quả) 2 Liệt kê thực thể và mối quan hệ giữa chúng trong một bài viết: với
property link - https://link-to-new-5.
32.27s (31 kết quả)
17.80s (31 kết quả) 3 Tìm thực thể xuất hiện trong những bài báo n với thông tin sau: node
Person: name là Person 2
40.18s
(45811 kết quả)
14.29s
(45811 kết quả) 4 Thống kê quan hệ giữa các thực thể đã cho với thực thể khác: node –
label: Person, và name - Person 3
62.33s
(1462 kết quả)
15.21s
(1462 kết quả) 5 Thống kê thực thể đã cho theo tháng có quan hệ với thực thể khác:
node – label: Person, name - Person 4 và label: time 10-2019.
54.50s
(130 kết quả)
12.95s
(130 kết quả) 6 Thống kê quan hệ của thực thể nào đó cùng tham gia: node – label:
Person, name - Person 2
70.59s (23 kết quả)
18.77s (23 kết quả)
71
CHƯƠNG 4. KẾT LUẬN
Với mục tiêu đặt ra ban đầu, tơi đã tìm hiểu, nghiên cứu cách thức lưu trữ dữ liệu bằng cơ sở dữ liệu đồ thị cho thực thể quan hệ trích xuất từ các bài viết tin tức Tiếng Việt. Hệ thống local và cloud hiện tại đang lưu trữ khoảng 235 triệu thực thể và 728 triệu quan hệ. Số lượng dữ liệu trên có khả quan nhưng khơng đáng kể khi so sánh với Knowledge Graph của Google. Tuy nhiên kết quả này là tồn bộ cơng sức tìm hiểu, nghiên cứu và học hỏi trong suốt quá trình thực hiện luận văn. Kết quả này sẽ là tiền đề, nền móng để tơi phát triển và cải thiện hệ thống trong tương lai.
Trong q trình thực hiện luận văn, tơi đã có thêm nhiều bài học cũng như kinh nghiệm hữu ích như: kiến thức về cơ sở dữ liệu đồ thị; cách thức biểu diễn dữ liệu trong đồ thị tri thức trên nền tảng Neo4j; kĩ năng phân tích cũng như đánh giá q trình thực hiện câu truy vấn; kiến thức về shell script. Đây là những kiến thức quý báu giúp cho quá trình phát triển sự nghiệp của tơi sau này
Đóng góp chính
Thiết kế mơ hình dữ liệu tối ưu cho việc lưu trữ các bài viết và thực thể quan hệ được trích xuất tự động từ các bài viết đó.
Triển khai cluster cho CSDL đồ thị Neo4j. Chế độ cluster của Neo4j đảm bảo hệ thống dữ liệu có khả năng dung lỗi, đảm bảo an toàn cho dữ liệu và cung cấp khả năng mở rộng khối lượng công việc liên quan đến truy vấn dữ liệu.
Xây dựng các service REST API cho phép truy vấn, lưu trữ các bài viết và các thực thể quan hệ.
Xây dựng giao diện hướng dẫn sử dụng API cho người phát triển.
Triển khai các giải pháp quản trị hệ thống CSDL (sao lưu, khơi phục). Viết shell script tự động hóa thao tác sao lưu dữ liệu.
Xây dựng công cụ sinh dữ liệu mơ phỏng dựa theo nguồn dữ liệu trích xuất từ các bài báo mạng, ngồi ra cơng cụ này cịn có thể tùy biến để sử dụng cho các mơ hình khác nhau.
72
Các vấn đề mà luận văn đã đạt được
Giao diện hướng dẫn sử dụng API cho người phát triển chưa thực sự tối ưu. So với nhiều hệ thống đang có trên thực tế và được triển khai thì hệ thống tơi đề xuất tập trùng vẫn chưa giải quyết được việc triển khai trên tồn máy chủ, chưa kiểm sốt được thông tin truy xuất người dùng.
Định hướng phát triển
Do nguồn dữ liệu tôi sử dụng đang là dạng dữ liệu mơ phỏng – dạng dữ liệu đã có cấu trúc nên mong muốn xây dựng thêm công cụ lấy dữ liệu thực tế. Công cụ này xử lý lấy dữ liệu tự động và từ dạng dữ liệu thô chưa có cấu trúc rồi chuyển thành dạng có cấu trúc để lưu vào CSDL trong bài luận này.
Có rất nhiều thơng tin có thể trích rút được từ nguồn dữ liệu đã được tổ chức thành đồ thị. Trong luận văn này, tơi chỉ thực hiện trích rút thơng tin bằng cách thực hiện truy vấn trực tiếp vào cơ sở dữ liệu. Do đó, số lượng câu hỏi mang ý nghĩa không nhiều. Vậy nên, trong tương lai, tơi sẽ tìm hiểu, cách áp dụng các mơ hình học máy, học sâu để trả lời các câu hỏi mang tính chất dự đốn như: Từ dữ liệu về các bài viết về du lịch, có thể đưa ra các địa điểm du lịch nổi tiếng; xếp hạng các địa điểm du lịch. Hay từ dữ liệu về các cuộc gặp gỡ của các nguyên thủ quốc gia, các hiệp định, ký kết, đánh giá xếp hạng một quốc gia.
Ngoài ra từ kiến thức đã nghiên cứu được tơi cịn muốn áp dụng vào lĩnh vực trí tuệ nhân tạo, ví dụ như: nhận diện sinh trắc học, ngôn ngữ tự nhiên,…
73
TÀI LIỆU THAM KHẢO
[1] Zeng, D., Liu, K., Chen, Y., & Zhao, J. (2015). Distant supervision for relation extraction via piecewise convolutional neural networks. In Proceedings of the 2015 conference on empirical methods in natural language processing (pp. 1753–1762).
https://ieeexplore.ieee.org/document/374370.
[2] Knowledge_graph, https://en.wikipedia.org/wiki/Knowledge_graph. [3] Cypher, https://en.wikipedia.org/wiki/Cypher_(query_language).
[4] M. Farber, B. Ell, C. Menne, A. Rettinger, and F. Bartscherer. Linked Data Quality of DBpedia, Freebase, OpenCyc, Wikidata, and YAGO. Semantic Web Journal, 2016. http://www.semantic-web-journal.net/content/linked- data-quality-dbpedia-freebaseopencyc-wikidata-and-yago.
[5] Michael Färber ∗,∗∗, Basil Ell, Carsten Menne, Achim Rettinger ∗∗∗, và
Frederic Bartscherer , Linked Data Quality of DBpedia, Freebase, OpenCyc, Wikidata, and YAGO, Karlsruhe Institute of Technology (KIT), Institute AIFB, http:www.semantic-web-journal.net/system/files/swj1366.pdf. [6] Named Entity Recognition and Normalization Applied to Large-Scale
Information Extraction from the Materials Science Literature, L. Weston, V. Tshitoyan, J. Dagdelen, O. Kononova, A. Trewartha, K. A. Persson, G. Ceder, and A. Jain*. https://pubs.acs.org/doi/abs/10.1021/acs.jcim.9b00470. [7] Open Research Knowledge Graph: Towards Machine Actionability in
Scholarly Communication, Mohamad Yaser Jaradeh,Sören Auer (Released date: January 2019),
https://www.researchgate.net/publication/330751750_Open_Research_ Knowledge_Graph_Towards_Machine_Actionability_in_Scholarly_ Communication.
[8] Ehrlinger và Wolfram Wưß, Towards a Definition of Knowledge Graphs, CERN, http://ceur-ws.org/Vol-1695/paper4.pdf.
74 [9] Diego Ongaro và John Ousterhout, In Search of an Understandable Consensus Algorithm (Extended Version), Stanford University, https://raft.github.io/raft.pdf.