46 Trong dữ liệu này gồm 2 properties: meta chứa kiểu, nhãn và định danh của meta và một property chứa tên của thực thể.
2.5.1.2. Truy vấn quan hệ trong bài viết
Đầu vào của service API truy vấn tồn bộ mối liên hệ trong bài viết có tham số ids - là chuỗi string các id của bài viết. Trong đó danh sách id của bài viết được ngăn cách với nhau bằng dấu phẩy và mô tả service API này ở Bảng 8 bên dưới.
Bảng 2. 6. Service truy vấn mối liên hệ
Đường dẫn /er-services/news
Phương thức get
Tham số + mô tả ids Danh sách các id của các bài viết được ngăn cách với nhau bằng dấu “,”.
Kết quả trả về dữ liệu ở dạng json là danh sách đối tượng – có 2 property chính:
properties và meta. Cụ thể property - meta: dùng để mơ tả metadata của node, trong đó
có type: kiểu dữ liệu của Relationship hoặc Node; label: nhãn của node – chứa mảng danh sách nhãn; id: xác định danh tính của node. Cịn property – properties chứa các thuộc
tính: name: tên của property, description: mô tả property.
Giả sử câu truy vấn thực thể quan hệ trong tập bài viết ở Hình 2.25 bên dưới và kết quả dữ liệu trả ở Hình 2.26 bên dưới.
47
Hình 2.26 Dữ liệu mối liên hệ trong bài viết 2.5.1.3. Truy vấn thống kê các bài viết mà thực thể xuất hiện 2.5.1.3. Truy vấn thống kê các bài viết mà thực thể xuất hiện
Đầu vào của service API thống kê các bài viết mà thực thể xuất hiện là id - định danh của thực thể, với mô tả service API truy vấn toàn bộ mối quan hệ trong bài viết được ở Bảng 9 bên dưới.
Bảng 2. 7. Truy vấn các thực thể có nhãn cho trước
Đường dẫn /er-services/entity_occurrences
Phương thức get
Tham số + mô tả id id của thực thể
Kết quả trả về dữ liệu ở dạng json là danh sách đối tượng. Cụ thể với mỗi node chứa thông tin như: link – đường dẫn của bài viết, extractedDate – thời gian thơng tin được trích xuất,... Giả sử câu truy vấn thống kê các bài viết được xuất hiện theo điều kiện
48
Hình 2.27 Truy vấn Cypher thống kê các bài viết theo điều kiện
Hình 2.28 Dữ liệu trả về thống kê các bài viết theo điều kiện 2.5.1.4. Truy vấn thống kê relationship của node với node cho trước 2.5.1.4. Truy vấn thống kê relationship của node với node cho trước
Đầu vào của service API liệt kê các thực thể có quan hệ với thực thể cho trước là các tham số: id - định danh của thực thể, relationship - quan hệ và mơ tả API truy vấn tồn bộ mối liên hệ trong bài viết được ở Bảng 10 bên dưới.
Bảng 2. 8. Truy vấn thực thể với nhãn đã cho
Đường dẫn /er-services/entity_with_relationship
Phương thức get
Tham số + mô tả id id của thực thể
49 Kết quả trả về dữ liệu ở dạng json là danh sách đối tượng - có 2 property: meta và
properties. Cụ thể property – meta: dùng mô tả metadata của node gồm: id – xác định
danh tính của node, label – danh sách nhãn của thực thể và type - kiểu dữ liệu của các
Node. Cịn property - properties là thuộc tính của node chứa thơng tin: name – tên của
thuộc tính, description - mơ tả thuộc tính.
Giả sử câu truy vấn “Tổng thống Donald Trump đã gặp gỡ những ai?” trong đó node - person “Donald Trump” có property – id: 1 và relationship: MEET ở Hình 2.29 bên dưới, và dữ liệu trả về ở Hình 2.30 bên dưới.
Hình 2.29 Truy vấn Cypher về thực thể khi thống kê các bài viết
50
2.5.1.5. Lưu trữ dữ liệu đã trích xuất
Đầu vào của service API lưu trữ bài viết là một file json có các thuộc tính: link - liên kết đến bài viết, extractedDate - ngày bài viết được trích xuất, entities – danh sách thực thể trích xuất được từ bài viết này, rels – danh sách dữ liệu chỉ ra quan hệ giữa các thực thể với nhau. Với thuộc tính entities là danh sách đối tượng biểu diễn về thực thể - có các thuộc tính: id - định danh thực thể trong danh sách entities. Cụ thể id viết tắt của
identify là định danh thực thể trong neo4j, giá trị của nó có thể có hoặc khơng. Trường
hợp thực thể đã tồn tại trong CSDL thì sẽ có thuộc tính này; ngược lại có thể bỏ qua. Các thuộc tính khác là name - tên của thực thể, label - nhãn của thực thể, description - mô tả của thực thể và một số thuộc tính khác. Cịn rels là danh sách các đối tượng, dùng để mô tả quan hệ giữa các thực thể - thuộc tính có: subjectId và objectId là giá trị chính và phụ được định danh của thực thể trong entities, type - kiểu của quan hệ, timeId – thời gian
được định danh của thực thể trong entities.
File dữ liệu chứa thông tin về bài viết và các thực thể được trích xuất tự động từ bài viết này cần lưu trữ được biểu diễn ở Hình 2.31 và câu truy vấn lưu trữ dữ liệu về bài viết được biểu diễn ở Hình 2.32 bên dưới.
51
Hình 2.31 File thơng tin thực thể quan hệ trong một bài viết cần lưu
52
2.5.2 Xây dựng giao diện API Service
Để hỗ trợ nhà phát triển sử dụng service API dễ dàng, thuận tiện; cần xây dựng giao diện GUI hướng dẫn sử dụng toàn bộ các service đã cung cấp. Với mỗi màn hình gồm một service và hướng dẫn sử dụng service; sử dụng service trên màn hình bằng cách nhập dữ liệu vào form và bấm nút thực hiện.
Demo service API truy vấn thông tin thực thể trong màn hình với tham số name là Person 1 và label: Person ở Hình 2.33. Trên trang này chứa bảng tham số đầu vào và nội dung mô tả cho service API. Khi người sử dụng muốn truy vấn về thơng tin thực thể họ tích chọn tìm kiếm chính xác theo tên hay không, chọn nhãn của thực thể trong ơ danh sách các nhãn sau đó nhập giá trị vào ơ tên. Cuối cùng họ bấm button “Truy vấn” để thực thi truy vấn.
Hình 2.33 Giao diện Service API lấy thông tin thực thể
Demo service API về truy vấn thực thể quan hệ trong nhiều tập bài viết với tham số mà người phát triển cần nhập giá trị các link cần tìm và bấm button “Truy vấn” để thực thi ở Hình 2.34 bên dưới.
53
Hình 2.34 Giao diện Service API truy vấn bài viết
Demo service API về thống kê các bài viết có xuất hiện thực thể e, với tham số mà người phát triển cần nhập giá trị các ID thực thể cần tìm và bấm button “Truy vấn” để thực thi ở Hình 2.35 bên dưới.
54
2.6 Xây dựng bộ hướng dẫn sử dụng để vận hành, bảo trì và triển khai cluster cho hệ thống CSDL hệ thống CSDL
Mỗi hệ thống ln có bộ tài liệu hướng dẫn sử dụng đi kèm khi đưa vào sử dụng. Trong mục này cung cấp cho người phát triển năm được những thành phần, chức năng, cách triển khai và phát triển khi cần, nội dung tập trung vào: (1) triển khai cluster, (2) backup và restore dữ liệu online và offline.
2.6.1 Triển khai cluster
Cluster là một kiến trúc nhằm đảm bảo khả năng sẵn sàng cho hệ thống máy tính. Cluster cịn là một hệ thống bao gồm nhiều máy chủ được kết nối với nhau theo dạng song song hay phân tán và được sử dụng như một tài nguyên thống nhất, và ở đây tôi sử dụng cluster cho hệ thống CSDL. Cách triển khai hệ thống chỉ bằng một server sẽ gặp nhiều vấn đề liên quan đến khả năng cung cấp và sử dụng dịch vụ trên toàn hệ thống. Giả sử xảy ra sự cố ở server cơ sở dữ liệu bị ngừng hoạt động dẫn đến toàn bộ hệ thống sập hoặc tê liệt. Hay việc yêu cầu mở rộng nghiệp vụ cho hệ thống, quá trình ghi cũng như đọc dữ liệu vẫn diễn ra bình thường và số lượng truy vấn xử lý dữ liệu rất lớn thì việc chỉ có một server CSDL đồ thị sẽ khơng đủ đáp ứng u cầu hệ thống.
Để tồn bộ hệ thống hoạt động một cách ổn định, chính xác và an tồn ta cần phải triển khai nhiều server CSDL đồ thị. Trong nền tảng công nghệ neo4j có hỗ trợ sẵn chế độ phân cụm Neo4j Causal Clustering bao gồm hai thành phần là Corer Server và Read Replica. Mỗi thành (instance) của Core Server cho phép các thao tác đọc – ghi và có trách nhiệm bảo vệ dữ liệu; các instance thực hiện nhiệm vụ bằng cách sao chép tất cả các giao dịch bằng phương thực Raft [8]. Raft đảm bảo rằng dữ liệu có độ bền an tồn trước khi xác nhận cam kết giao dịch với ứng dụng người dùng cuối. Nghĩa là khi một yêu cầu ghi dữ liệu được gửi đến một máy chủ Cluster, thì tất cả Core Server của các server sẽ được nhận yêu cầu ghi dữ liệu này [9]. Hành động thực hiện yêu cầu ghi này xảy ra, nếu hơn một nửa số server trong Core Server đồng ý với u cầu này, cịn khơng đủ số lượng Core Server đồng ý thì yêu cầu này sẽ không được thực hiện. Yêu cầu an tồn này có ảnh hưởng đến độ trễ ghi dữ liệu.
Read Replica là server chỉ có chức năng đọc dữ liệu; hỗ trợ khả năng nâng cấp, mở rộng khối lượng việc đọc dữ liệu. Việc lấy dữ liệu phục vụ thống kê, dự báo là những xử lý mất nhiều thời gian nhất. Lúc này việc đọc dữ liệu sẽ được Read Replica đảm nhiệm để hệ thống hoạt động xử lý u cầu nhanh chóng và trơi chảy.
Fault tolerance được nhắc đến là khả năng dung lỗi hay khả năng chịu lỗi của hệ thống máy tính, đặc biệt trong hệ thống lưu trữ dữ liệu trong bài luận này. Cụ thể Neo4j Cluster cung cấp cho hệ thống lưu trữ dữ liệu khả năng hoạt động liên tục mà không phải
55 dừng lại hay bị gián đoạn khi sự cố xảy ra ở một hoặc nhiều thành phần trong hệ thống. Hiểu cách khác là trong hệ thống khi có một server khơng hoạt động cũng khơng ảnh hưởng tới hệ thống chung – được gọi là dung một lỗi; trong hệ thống khi hai server dừng làm việc thì tồn bộ hệ thống chung vẫn làm việc – được gọi là dung hai lỗi. Điều này được tính theo cơng thức M = 2F + 1; trong đó M là số lượng các phiên bản Core cần thiết để chịu được lỗi F và F là số nguyên dương. Ví dụ: khi triển khai hệ thống phân cụm tối thiểu 3 core thì hệ thống có khả năng dung một lỗi, còn cluster với 5 core thì hệ thống có khả năng dung được hai lỗi.
Cần chú ý Causal Cluster 11 có thể triển khai với 2 server. Nếu một trong hai server khơng hoạt động thì tồn hệ thống vẫn hoạt động và chỉ cịn khả năng đọc dữ liệu. Mô tả về kiến trúc Causal Clustering của neo4j ở Hình 2.36 bên dưới.
Hình 2.36 Kiến trúc Causal Clustering
Muốn triển khai phân cụm – cluster thì yêu cầu phải cài đặt Neo4j Enterprise Edition lên server tham gia vào Causal Cluster. Trong mã nguồn bộ cài đặt neo4j chính thức chứa một thư mục conf và trong đó có sẵn một file cấu hình: neo4j.conf.
Cấu máy chủ phân tán với máy chủ SINGLE và READ_REPLICA, các tùy chọn cài đặt cấu hình quan trọng trong Bảng 11 bên dưới. Cụ thể triển khai với bốn máy chủ
56 gồm: một máy chủ SINGLE và ba máy chủ READ_REPLICA. Lưu ý: chúng ta cần hiểu máy chủ Primary (name: SINGLE) là máy chủ chính có cả hai chức năng đọc và ghi, còn máy chủ Secondary (name: READ_REPLICA) là máy chủ phụ chỉ có thể đọc dữ liệu.
Bảng 2. 9. Cài đặt quan trọng cho Cluster có phiên bản SINGLE
Tên tùy chọn Máy chủ Mô tả
dbms.default_advertised_ address All (Primary và Secondary)
Trong trường hợp điển hình, khi được yêu cầu kết nối từ các máy với nhau thì chúng thơng qua địa chỉ IP. Điều này phải được đặt thành tên miền đủ điều kiện hoặc địa chỉ IP của máy chủ này.
dbms.mode Primary Chế độ hoạt động của phiên bản máy chủ. Máy chủ chính được đặt là SINGLE.
Secondary Chế độ hoạt động của phiên bản máy chủ. Máy chủ phụ được đặt là
READ_REPLICA.
causal_clustering.enable=true Primary Cho phép một phiên bản duy nhất tạo thành một cụm và chỉ được đánh giá khi dbms.node=SINGLE.
causal_clustering.
initial_discovery_members
Secondary - Chỉ được cài đặt trên máy chủ chỉ đọc và chứa địa chỉ mạng của phiên bản máy chủ chính, những cũng có thể bao gồm cả máy chủ phụ.
- Tham số này phải được đặt thành cùng một giá trị trên tất cả các thành viên cụm.
- Trong cài đặt này có thể được sửa đổi bằng cách xác định lại cấu hình cài đặt: causal_clustering.discovery_type.
57 Ví dụ sau đây cho thấy cách thiết lập một cụm với một phiên bản SINGLE làm máy chủ Primary và ba phiên bản chỉ đọc (Read Replica) làm máy chủ Secondary. Cụ thể, một máy chủ chính có tên là single.example.com và ba máy chủ phụ: read_replica01.example.com, read_replica02.example.com, và read_replica03.example.com được cài đặt cấu hình lần lượt ở Hình 2.37, 2.38, 2.39, 2.40 bên dưới. Sử dụng truy vấn Cypher: CALL dbms.cluster.overview(); để kiểm tra danh sách cluster và thơng tin các cluster trong đó.
Hình 2.37 Cluster của máy chủ SINGLE
Hình 2.38 Cluster của máy chủ read_replica01
Hình 2.39 Cluster của máy chủ read_replica02
58 Cấu hình máy chủ phân tán với các phiên bản CORE, cụ thể cài đặt cấu quan trọng được tùy chọn trong Bảng 12 dưới đây. Các cấu hình này được tối ưu hóa cho khả năng chịu lỗi chuyển đổi dự phòng tự động và khả năng mở rộng tốt nhất và nó được khuyến nghị sử dụng cho khối lượng công việc giao dịch. Trong nhiều trường hợp và khi chúng được định cấu hình chính xác, các cụm này bảo vệ dữ liệu an tồn và chúng khơng u cầu bất kỳ cơng cụ bên ngồi cụ thể nào.
Bảng 2. 10. Cài đặt quan trọng cho Cluster có phiên bản CORE
Tên tùy chọn Máy chủ Mô tả
dbms.default_listen_ address All (Primary và Secondary) Với những máy sử dụng để lắng nghe tin nhắn tới bằng địa chỉ IP hay giao diện mạng . Đặt giá trị này thành 0.0.0.0 làm cho Neo4j liên kết với tất cả các giao diện mạng có sẵn. dbms.default_advertised_ address All (Primary và Secondary)
Tham số của dòng này chứa địa chỉ kết nối khi có máy khác yêu cầu. Trong trường hợp điển hình, điều này phải được đặt thành tên miền đủ điều kiện hoặc địa chỉ IP của máy chủ này.
dbms.mode Primary Chế độ hoạt động của phiên bản máy chủ. Máy chủ chính được đặt là CORE.
Secondary Chế độ hoạt động của phiên bản máy chủ. Máy chủ phụ được đặt là READ_REPLICA.
causal_clustering.minimum_ core_cluster_size_at_
formation
Primary Đây là tham số về số lượng CORE tối thiểu trong cụm lúc hình thành.
Một cụm sẽ khơng hình thành nếu khơng có số CORE được xác định bởi cài đặt này và điều này nói chung phải được định cấu
59 hình thành số lượng cố định và
đầy đủ. causal_clustering.minimum_
core_cluster_size_at_runtime
Primary Số lượng CORE tối thiểu sẽ tồn tại trong nhóm cluster.
causal_clustering. initial_discovery_members All (Primary và Secondary) - Địa chỉ mạng một tập hợp các cluster – CORE là có sẵn dùng để khởi động bản sao CORE hoặc READ_REPLICA.
- Trong trường hợp mặc định, initial_discovery_nembers được cung cấp dưới dạng danh sách cặp địa chỉ hoặc cổng được phân tách bởi dấu phẩy và cổng mặc định cho dịch vụ: 5000. Thông số này nên đặt cùng một giá trị trên tất cả máy chủ CORE.
- Trong cài đặt này có thể được sửa đổi bằng cách xác định lại