6 lời khuyên để tối ưu hóa một cơ sở dữ liệu XML nguyên gốc pdf

6 lời khuyên để tối ưu hóa một cơ sở dữ liệu XML nguyên gốc
Các hướng dẫn thông dụng cho việc sử dụng XQuery với các cơ sở dữ liệu XML
nguyên gốc
Donnie Cameron, Nhà phân tích lập trình viên cao cấp, R.R. Bowker, LLC
Tóm tắt: RSS, Atom, các ứng dụng (mashup), các yêu cầu tìm kiếm đặc biệt và
các sự phát triển khác đang làm cho các cơ sở dữ liệu XML nguyên gốc cho một
hệ điều hành nào đó trở thành một phần quan trọng trong các ứng dụng và các dịch
vụ tìm kiếm. Các loại cơ sở dữ liệu này vượt trội về hiệu quả tìm kiếm thông qua
các bộ sưu tập lớn của dữ liệu bán cấu trúc. Trong bài này, bạn sẽ tìm thấy một số
hướng dẫn thông dụng để đạt hiệu năng tối đa cho các ứng dụng sử dụng XQuery
và các cơ sở dữ liệu XML nguyên gốc.
Các cơ sở dữ liệu XQuery và cơ sở dữ liệu XML nguyên gốc
Các từ viết tắt thường dùng
 RAM: Random-access memory - Bộ nhớ truy cập ngẫu nhiên.
 RSS: Really Simple Syndication - Tập hợp dữ liệu đơn giản.
 XML: Extensible Markup Language - Ngôn ngữ đánh dấu mở rộng.
 XSLT: Extensible Stylesheet Language Transformations - Các chuyển đổi
ngôn ngữ bảng định kiểu mở rộng.
Việc sử dụng XQuery (một ngôn ngữ chức năng được thiết kế để truy vấn các bộ
sưu tập dữ liệu XML) với các hệ thống cơ sở dữ liệu XML nguyên gốc có thể vô
cùng có ích trong một số tình huống. Khi dùng cho các truy vấn phức tạp và chủ
yếu là chỉ đọc, được so sánh với các cơ sở dữ liệu quan hệ chuẩn, các cơ sở dữ liệu
XML nguyên gốc cung cấp các thời gian đáp ứng nhanh hơn và các thời gian phát
triển nhanh hơn. Với hệ thống chuyển đổi-dữ liệu mạnh nhất, đơn giản nhất có sẵn
hiện nay được xây dựng ngay trong ngôn ngữ truy vấn, bạn đạt được các thời gian
phát triển nhanh hơn vì bạn không cần phải thiết kế một hệ thống lập chỉ mục
toàn-văn bản riêng biệt hay lắp ghép nhiều dữ liệu cho người dùng.
Với cái giá chèn và cập nhật chậm hơn, các cơ sở dữ liệu XML nguyên gốc có thể
cung cấp các thời gian đáp ứng ngoài hộp tốt hơn hẳn vì chúng giữ cho dữ liệu của
mình phần lớn không được tiêu chuẩn hóa, cung cấp các chỉ mục mặc định và làm
cho việc sử dụng bộ nhớ RAM có sẵn tốt hơn nhiều. Tuy nhiên, khi xử lý các tập

hợp dữ liệu rất lớn, bạn có thể cải thiện hơn nữa các thời gian đáp ứng truy vấn
của một cơ sở dữ liệu XML nguyên gốc bằng cách làm theo một vài hướng dẫn
thông dụng chung sau:
 Tránh tiêu chuẩn hóa.
 Sử dụng các tên phần tử duy nhất.
 Ước tính trước các giá trị.
 Chuyển đổi dữ liệu theo các truy vấn của bạn.
 Mô tả sơ lược mã Xquery.
 Giữ một danh sách tối ưu hóa.
Các hướng dẫn này là phổ biến và thích hợp cho nhiều cơ sở dữ liệu XML nguyên
gốc đang có sẵn hiện nay, bao gồm cả DB2® Express-C của IBM, Mark Logic
Server, eXist và thậm chí cả XML của Berkeley DB Oracle (xem Tài nguyên để
có các liên kết). Bây giờ chúng ta hãy xem xét chi tiết các hướng dẫn tối ưu hóa.


Tránh tiêu chuẩn hóa
Điều quan trọng nhất mà bạn có thể làm khi bạn thiết kế một lược đồ cơ sở dữ liệu
XML nguyên gốc là tránh sự cám dỗ về tiêu chuẩn hóa dữ liệu theo cùng một cách
mà bạn làm khi bạn thiết kế một cơ sở dữ liệu quan hệ.
Việc tiêu chuẩn hóa dữ liệu cho một cơ sở dữ liệu XML nguyên gốc bao gồm việc
thiết kế nhiều loại tài liệu XML liên kết với nhau theo những cách tương tự như
những cách mà các bảng mô hình-quan hệ liên kết với nhau. Tuy nhiên, trong hầu
hết các trường hợp, bạn sẽ cần phải tiêu chẩn hóa một chút nếu có bất kỳ dữ liệu
nào cho một cơ sở dữ liệu XML nguyên gốc. Thường khá phổ biến là đặt các dữ
liệu trong hàng chục bảng mô hình-quan hệ vào trong một loại tài liệu XML đơn.
Hầu hết các việc hiện thực của XQuery hiện có ngày nay thực hiện các kết nối
kém đến mức ngay cả một truy vấn đơn giản bao gồm một vài nghìn bản ghi có
thể mất một khoảng thời gian xử lý không thể chấp nhận được. Điều này tạo ra
tiêu chí để quyết định xem bạn có nên tiêu chuẩn hóa dữ liệu đơn giản không:
Đừng bao giờ tiêu chuẩn hóa dữ liệu đến mức mà một truy vấn được hỗ trợ sẽ cần

phải thực hiện một phép toán nối để chọn các bản ghi.
Một truy vấn được hỗ trợ là một truy vấn mà bạn có thể mong đợi những người sử
dụng tạo dữ liệu của bạn. Ví dụ, nếu bạn xây dựng một ứng dụng để bán các băng
video, bạn có thể mong đợi một người dùng truy vấn đến tất cả các băng video có
một từ khoá nào đó trong phần tiêu đề và do một người cụ thể làm đạo diễn. Vì
điều này, bạn chắc chắn muốn các tài liệu XML mô tả băng video có chứa tiêu đề
của băng video và tên đạo diễn của nó. Mặt khác, với ứng dụng cụ thể này, bạn có
thể không muốn hỗ trợ một truy vấn cho tất cả các băng video có một từ khoá cụ
thể trong tiêu đề và do một người sinh ở New York làm đạo diễn. Nói cách khác,
với ví dụ ứng dụng video, nếu bạn có thông tin chi tiết về đạo diễn (ngoài tên của
đạo diễn), thì thật tốt là xem xét việc giữ nó trong một tài liệu XML riêng biệt.
Hãy tưởng tượng một cơ sở dữ liệu có hai loại tài liệu XML liên kết, video-rec và
director-rec, cái trước mang thông tin chi tiết về các băng video bao gồm một trình
định danh director-rec, cái sau mang thông tin chi tiết về các đạo diễn. Truy vấn
với một bản ghi có một từ khóa trong tiêu đề và một đạo diễn sinh ở New York là
một truy vấn phải thực hiện một phép toán nối để chọn các bản ghi. Như nói ở
trên, có lẽ là không tốt để hỗ trợ cho loại truy vấn này vì nó còn hơn một truy vấn
khai phá-dữ liệu, không thực sự là loại truy vấn mà hầu hết những người dùng
đang duyệt web một loại cửa hàng video trực tuyến. Tuy nhiên, trừ khi bạn có các
lý do cụ thể để di chuyển các thông tin chi tiết về đạo diễn tới một loại tài liệu
riêng biệt, bạn nên giữ nó trong tài liệu video-rec.
Mặc dù trong một cơ sở dữ liệu XML nguyên gốc thì chưa bao giờ có hiệu quả
nếu thực hiện một phép toán nối để chọn các bản ghi, thường rất tốt nếu tìm nạp
dữ liệu từ nhiều loại tài liệu XML khi chuyển đổi dữ liệu từ các kết quả tìm kiếm.
Cửa hàng video mà tôi đã mô tả có thể đưa ra các kết quả một cách dễ dàng và có
hiệu quả bao gồm nơi sinh của đạo diễn, dù cần đến vị trí yêu cầu tìm nạp dữ liệu
từ một tài liệu không thuộc các kết quả tìm kiếm ban đầu. Các hoạt động cần thiết
để lắp ghép các kết quả theo cách này bị hạn chế trong một vài bản ghi mà ứng
dụng đó đã chọn và nó lên kế hoạch để hiển thị các bản ghi đó; đó là tính toán và
các yêu cầu bộ nhớ là không đáng kể so với những gì cần thiết để kết nối nhiều

loại tài liệu trong một truy vấn tìm kiếm chung.


Sử dụng các tên phần tử duy nhất
Các phần tử duy nhất là các phần tử luôn luôn tham chiếu đến một phần tử tương
đương trong một tài liệu XML. Các phần tử không duy nhất là các phần tử có thể
xuất hiện ở bất cứ đâu trong tài liệu XML và cần phải đặt trước một đường dẫn có
nghĩa. Ví dụ, nếu một tài liệu XML có chứa 10 loại nút hoàn toàn khác nhau và
mỗi loại bao gồm một phần tử ngày làm phần tử con cháu, thì phần tử ngày là một
tên của phần tử không duy nhất. Việc sử dụng các tên phần tử không duy nhất có
thể cản trở khả năng của bạn để đánh giá hoặc mô tả một số lựa chọn thay thế
XQuery hoặc XPath cho việc định vị dữ liệu của bạn. Ví dụ, các tên phần tử không
duy nhất có thể khiến bạn không đánh giá đúng mã thực hiện tìm kiếm chỉ mục ít
hơn. Ngoài ra, các tên phần tử không duy nhất có thể thu nhận các cách hỗ trợ mới
nổi cho các kết quả tìm kiếm nhiều nhánh.
Những phần sau sẽ đưa ra các ví dụ về các loại tối ưu hóa mà bạn có thể hỗ trợ
bằng cách thay đổi thiết kế của một tài liệu giống như trong Liệt kê 1 để cho nó sử
dụng các tên phần tử khác nhau.

Liệt kê 1. Tài liệu cơ bản với các tên phần tử không duy nhất

#+BEGIN_SRC nxml-mode
<class-info>
<school>Lusher Elementary School</school>
<grade>10</grade>
<teachers>
<teacher>
<name>
<first>Carol</first>
<last>Osborne</last>

</name>
</teacher>
<teacher>
<name>
<first>Dan</first>
<last>Silver</last>
</name>
</teacher>
</teachers>
<students>
<student>
<name>
<first>Barrie</first>
<last>Stoff</last>
</name>
</student>
<student>
<name>
<first>Andrew</first>
<last>Silver</last>
</name>
</student>
<student>
<name>
<first>Larry</first>
<last>Cracchiolo</last>
</name>
</student>
<student>
<name>

<first>Richard</first>
<last>Hughes</last>
</name>
</student>
<student>
<name>
<first>Bruce</first>
<last>Silver</last>
</name>
</student>
.
.
.
</students>
</class-info>
#+END_SRC

Thực hiện tìm kiếm chỉ mục ít hơn
Để có được những cái tên đầu tiên của các sinh viên có họ là Silver, bạn có thể sử
dụng một biểu thức XPath như trong Liệt kê 2.

Liệt kê 2. Biểu thức Xpath tìm họ Silver

: /class-info/students/student/name[last = "Silver"]/first

Nếu bạn đã hạn chế dữ liệu để dữ liệu hiển thị trong một tài liệu duy nhất trong
Liệt kê 1, thì việc đánh giá biểu thức XPath trong Liệt kê 2 luôn luôn trả về kết
quả phù hợp trong Liệt kê 3.

Liệt kê 3. Kết quả của XPath

<first>Andrew</first>
<first>Bruce</first>

Nếu dữ liệu không được đánh chỉ mục, thì Liệt kê 2 luôn luôn là cách nhanh nhất
để nhận được các kết quả đó. Biểu thức này giới hạn số lượng các nhánh mà cơ sở
dữ liệu phải tìm kiếm để tìm các phần tử liên quan.
Tuy nhiên, nếu dữ liệu được đánh chỉ mục, thì tùy thuộc vào việc thực hiện cơ sở
dữ liệu cụ thể mà bạn sử dụng và miễn là bạn có một tập hợp dữ liệu rất lớn, một
biểu thức giống như biểu thức trong Liệt kê 4 thường có thể giải quyết nhanh hơn.

Liệt kê 4. Biểu thức Xpath để sử dụng khi dữ liệu được đánh chỉ mục

: //name[last = "Silver"]/first

Lý do của việc cải thiện tiềm năng là hệ thống phải xem xét các phần tử ít hơn
trong chỉ mục. Tuy nhiên, do thiết kế của tài liệu trong Liệt kê 1, trong đó sử dụng
các tên phần tử không duy nhất, nên XPath trong Liệt kê 4 trả về các kết quả
không đúng; các kết quả đó bao gồm tên của giáo viên, Dan. Thiết kế này ngăn
cản bạn khỏi mô tả các truy vấn sử dụng các chỉ mục ít hơn. Một thiết kế tốt hơn là
thay thế các tên phần tử không duy nhất trong Liệt kê 1 bằng các tên phần tử duy
nhất, như Liệt kê 5 mô tả.

Liệt kê 5. Thay thế các tên phần tử không duy nhất trong Liệt kê 1 bằng các
tên phần tử duy nhất

//teacher/name => //teacher/teacher-name
//teacher/name/first => //teacher/teacher-name/teacher-first
//teacher/name/last => //teach/teacher-name/teacher-last
//student/name => //student/student-name

//student/name/first => //student/student-name/student-first
//student/name/last => //student/student-name/student-last

Hỗ trợ các kết quả tìm kiếm nhiều nhánh
Mục tiêu của việc tìm kiếm nhiều nhánh là để hiển thị các liên kết cho phép người
dùng thu hẹp nhanh chóng và trực quan các kết quả tìm kiếm theo các trục khác
nhau. Trong một ứng dụng có hỗ trợ các kết quả tìm kiếm nhiều nhánh, một truy
vấn liệt kê tất cả các giáo viên trong cơ sở dữ liệu có thể trả về thông tin như thế
trong giao diện người dùng (xem Liệt kê 6).

Liệt kê 6. Tìm kiếm nhiều nhánh

•Tabor, Gavin
•Nance, Jamey
•Haas, Carlene
•Davies, Yesenia
•Singer, Lupe

Narrow your search:

•School

•Lusher Elementary School (35)
•Academy of the Sacred Heart (34)
•Isidore Newman School (32)
•Audubon Charter School (28)
•Benjamin Franklin Elementary Math-Science Magnet (25)

•Grades

•9 (5)
•10 (6)
•11 (6)
•12 (6)

Liệt kê 6 cung cấp hai nhánh: School (Trường) và Grades (Các lớp học). Mỗi
nhánh có bốn hoặc năm giá trị liên kết với một tìm kiếm để thu hẹp tìm kiếm gần
đây nhất. Bên cạnh mỗi giá trị nhánh là một số trong dấu ngoặc đơn, cho biết tổng
số giáo viên mà bạn sẽ kết thúc với số lượng đó nếu bạn nhấn vào liên kết đó. Các
kết quả tìm kiếm nhiều nhánh thường chỉ hiển thị một vài giá trị có thể cho từng
nhánh. Khi số lượng các giá trị riêng biệt cho một nhánh là nhỏ, như là trường hợp
của nhánh Grades, ứng dụng thường hiển thị tất cả các nhánh theo thứ tự trong đó
chúng có nghĩa nhất. Tuy nhiên, khi một nhánh bao gồm nhiều giá trị có thể, thì
ứng dụng đó thường chỉ hiển thị các giá trị sẽ trả về nhiều kết quả nhất và thường
hiển thị các giá trị đó theo thứ tự số lượng các kết quả giảm dần.
Một số cơ sở dữ liệu XML nguyên gốc đang kết hợp hỗ trợ cho các tìm kiếm
nhiều nhánh, nhưng chúng yêu cầu các chỉ mục đặc biệt để cung cấp hiệu năng tốt
nhất. Một thuật toán XQuery điển hình để thu thập các giá trị hiển thị cho một
nhánh nhanh chóng trở thành một nút cổ chai khi số lượng các bản ghi trong cơ sở
dữ liệu tăng lên và khi số lượng các giá trị có thể cho một nhánh tăng lên. Đối với
một cơ sở dữ liệu lớn có hàng nghìn giá trị nhánh, thì đúng là một thuật toán như
vậy không thể thực hiện được. Để cung cấp sức mạnh tìm kiếm nhiều nhánh, các
máy XML nguyên gốc cần có khả năng xây dựng các từ vựng từ các giá trị mà
một phần tử nhận trong cơ sở dữ liệu. Các từ vựng này có thể được triển khai thực
hiện từ các chỉ mục đặc biệt, lần lượt có thể yêu cầu các tên phần tử duy nhất.
Nếu bạn có một cơ sở dữ liệu XML nguyên gốc tương đối nhỏ không hỗ trợ tìm
kiếm nhiều nhánh và bạn cần phải viết mã riêng của mình để hỗ trợ chức năng như
vậy, bạn sẽ thấy tên phần tử duy nhất là cần thiết như thế nào đối với mã của bạn
cũng như chúng hướng tới mã hỗ trợ tìm kiếm nhiều nhánh đã tồn tại trong các cơ
sở dữ liệu cao cấp hơn.

Ước tính trước các giá trị
Ý định thêm dữ liệu dư thừa vào một tài liệu XML là ý định dị thường với một
người quản trị cơ sở dữ liệu quan hệ dày dạn. Tuy nhiên, khi mối quan tâm chính
của bạn là hiệu năng — ví dụ, khi bạn phải trả về các kết quả tìm kiếm nhiều
nhánh với các truy vấn chạy dựa vào hàng chục triệu bản ghi — việc ước tính
trước một số giá trị dựa trên dữ liệu hiện có trong tài liệu XML và sau đó thêm các
kết quả vào tài liệu XML có thể giúp cải thiện đáng kể các thời gian đáp ứng. Các
cơ sở dữ liệu XML nguyên gốc là tất cả về việc hy sinh bộ nhớ và chấp nhận dư
thừa để đổi lấy hiệu năng.
Giả sử bạn có một bộ các tài liệu XML siêu dữ liệu hình ảnh. Mỗi tài liệu trong
các tài liệu XML này có một hoặc nhiều phần tử trong các phần tử camera (máy
ảnh), device (thiết bị) và scanner (máy quét), tất cả lưu giữ thông tin về thiết bị đã
tạo nên hình ảnh. Phần tử device biểu diễn một nút phức tạp bao gồm một phần tử
với tên của thiết bị và một số các phần tử khác với thông tin bổ sung. Trong ví dụ
này, tất cả các phần tử device cần thiết trong các phần khác của ứng dụng và do đó
không thể bị loại bỏ. Ứng dụng này triển khai thực hiện các tìm kiếm nhiều nhánh
và đòi hỏi một nhánh có tên là scanning device (thiết bị quét) để chỉ ra tên của
thiết bị đã tạo nên hình ảnh.
Tương tự, các tài liệu siêu dữ liệu hình ảnh có các phần tử chiều cao và chiều
rộng, trừ khi ứng dụng đòi hỏi một nhánh gọi là size (kích thước), có thể bắt
nguồn dễ dàng từ các phần tử height (chiều cao) và width (chiều rộng).
Liệt kê 7 là một ví dụ.

Liệt kê 7. Ví dụ về tài liệu siêu dữ liệu hình ảnh đầu tiên

<image>
<id>123456789</id>
<date>2009-11-16T03:14:42</date>

<description>Eiffel Tower</description>
<device>
<device-name>Scanmelter 2000</device-name>
<device-resolution>300dpi</device-resolution>
<device-manufacturer>Scanners Inc.</device-manufacturer>
<service-tag>ASDFQWER</service-tag>
</device>
<width>1200</width>
<height>1024</height>
</image>

Liệt kê 8 là ví dụ thứ hai.

Liệt kê 8. Ví dụ về tài liệu siêu dữ liệu hình ảnh thứ hai

<image>
<id>123456788</id>
<date>2009-11-16T03:14:42</date>
<description>Empire State Building</description>
<scanner>Pixel Maker LS</scanner>
<width>800</width>
<height>600</height>
</image>

Bây giờ hãy hình dung một cơ sở dữ liệu có đủ các bản ghi này mà một truy vấn
về các hình ảnh đã nhận được vào 16.11.2009 trả về 5.000 hình ảnh. Trong số này,
ứng dụng hiển thị 30 hình ảnh. Khung nhìn các kết quả-tìm kiếm hiển thị các
nhánh khác nhau, bao gồm cả scanning device và size, cung cấp một danh sách
ngắn của các giá trị với mỗi nhánh. Các giá trị của nhánh scanning device bao gồm
Scanmelter 2000 (1202) và Pixel Maker LS (207). Các giá trị của nhánh size bao

gồm 1200x1024 (2302) và 800x600 (113).
Hãy nghĩ về đoạn mã mà bạn có thể viết để đáp ứng các yêu cầu này. Thật khá dễ
dàng để viết đoạn mã này, nhưng nó không mở rộng tốt do số lượng công việc mà
nó phải làm để đếm số lượng các bản ghi thỏa mãn truy vấn mà mỗi giá trị nhánh
đại diện. Có thể có hàng trăm các giá trị nhánh; đoạn mã này cần tính toán tổng số
kết quả cho mỗi một trong số chúng để xác định năm giá trị nhánh nào cần liệt kê
cho nhánh này. Tình hình xấu đi nhanh chóng với số lượng các bản ghi trong cơ sở
dữ liệu, với số nhánh mà ứng dụng của bạn đang hiển thị và với số các giá trị
nhánh có thể cho mỗi nhánh. Nếu ứng dụng của bạn đang hiển thị 50 nhánh và xử
lý hàng triệu bản ghi, thì bạn thực sự không có một tùy chọn nào cả, nhưng cần
ước tính trước các giá trị nhánh và đưa chúng vào trong bản ghi đó.
Các tài liệu XML trong Liệt kê 7 và Liệt kê 8 sẽ nhận hai phần tử mới: scanner-
name và size. Sự thay đổi đơn giản đó sẽ cho phép thực hiện với quy mô tốt hơn
nhiều.


Chuyển đổi dữ liệu theo các truy vấn của bạn
Một trong những điểm mạnh nhất của XQuery là khả năng cung cấp dữ liệu chính
xác khi người gọi cần nó. Nhưng điểm mạnh này lại có khả năng không được sử
dụng nhiều nhất. Thông thường, các kiến trúc sư bị cám dỗ để xử lý một cơ sở dữ
liệu XML nguyên gốc như là một dịch vụ Web XML tầng sau, trả về các tài liệu
XML hỗ trợ tầng trước để chuyển đổi và hoàn trả khi cần thiết.
Các nghiệp vụ đã sử dụng XQuery để lấy dữ liệu từ một cơ sở dữ liệu XML
nguyên gốc luôn nhanh chóng chỉ ra tất cả các lý do để trả về dữ liệu theo định
dạng XML và sau đó sử dụng XSLT (ví dụ) để chuyển đổi dữ liệu ở tầng trước.
Đây là một số trong các lý do phổ biến hơn cả:
 Chúng ta lập kế hoạch tạo ra các sản phẩm khác có sử dụng cùng một dữ
liệu cho các mục đích khác.
 Chúng ta có những người tầng trước đã biết sử dụng các ngôn ngữ XSLT,
Perl, PHP, JavaScript và Java™ như thế nào

 Chúng ta cần một SOA (kiến trúc hướng dịch vụ).
 Không ai trong chúng ta biết XQuery và chúng ta muốn hạn chế việc sử
dụng nó càng nhiều càng tốt.
 Chúng ta có một đường ống dẫn dữ liệu tại chỗ.
 XQuery trông có vẻ phức tạp.
 XQuery không thể thực hiện X.
Không có đủ lý do ở đây để bác bỏ từng câu lệnh trong số các câu lệnh này, nhưng
hãy ghi nhớ các điểm sau đây:
 Dữ liệu đã sẵn sàng để hoàn trả cho một trình duyệt thường là nhỏ hơn
nhiều so với dữ liệu ban đầu mà cơ sở dữ liệu lưu trữ.
 XQuery là dễ dàng hơn, mạnh hơn và ngắn gọn hơn XSLT, theo mọi tiêu
chuẩn.
 Việc chuyển đổi dữ liệu của bạn theo lối ra này nhanh hơn nhiều so với
việc chuyển đổi nó sau này khi sử dụng XSLT (hoặc hầu hết mọi thứ khác).
 Bạn có thể viết XQuery để cho các khách hàng có thể yêu cầu dữ liệu theo
các định dạng khác nhau.
 Mọi sự phức tạp của ứng dụng sẽ giảm đáng kể nếu mã giúp chuyển đổi dữ
liệu là gần giống với mã dùng trong dữ liệu và cả hai đều được viết bằng
ngôn ngữ giống nhau.
Điểm đầu tiên trong những điểm trên — về kích thước của dữ liệu được hoàn trả
so với kích thước của dữ liệu chưa chuyển đổi, ban đầu — cần được xem xét thêm
một chút. Hãy coi chừng các bản ghi XML lớn. Cố gắng tránh gửi các bản ghi đến
tầng trước để được chuyển đổi ở đó. Đưa khối dữ liệu nhỏ nhất có thể được lên
mạng thường có thể cải thiện đáng kể khả năng đáp ứng và khả năng mở rộng của
một ứng dụng. Và thông thường bạn muốn thực hiện một cách chính xác rằng:
Đưa khối dữ liệu nhỏ hơn lên mạng, khi bạn chuyển đổi các dữ liệu ở lối ra của nó
trong cơ sở dữ liệu.
Lý do thực sự mà các nghiệp vụ không tận dụng được toàn bộ sức mạnh của
XQuery là lo sợ về những thứ chưa được biết đến. Điều này là hoàn toàn dễ hiểu,
nhưng nếu bạn đã sử dụng một cơ sở dữ liệu XML nguyên gốc, thì việc sử dụng

toàn bộ các khả năng của nó sẽ chỉ làm cho mọi thứ kết thúc tốt hơn.


Mô tả sơ lược mã XQuery
Nói chung, việc mô tả sơ lược mã của bạn có nghĩa xác định lượng thời gian mà
máy tính cần dùng cho mỗi phần trong mã của bạn. Ý tưởng là xác định các phần
trong mã của bạn có thể có lợi nhất từ việc tối ưu hóa. Đây không nhất thiết phải là
các phần chạy chậm nhất; đôi khi, một đoạn mã đã là khá hiệu quả sẽ là một đoạn
mã mà bạn muốn tập trung vào nhiều nhất. Ví dụ, một đoạn mã có thể chạy trong
10 giây có thể tối ưu hóa khá dễ dàng để chạy trong chưa đầy một giây. Nếu mã
mà chỉ chạy một lần mỗi ngày, thì tốt hơn là dùng nỗ lực của bạn để nâng cao tốc
độ (thậm chí hết sức nhỏ) của một chức năng chạy 1.000.000 lần mỗi ngày.
Hầu hết các cơ sở dữ liệu XML nguyên gốc có các công cụ để kiểm tra so sánh
hoặc mô tả mã. Hãy sử dụng chúng. Đôi khi các công cụ này sẽ không đo hiệu
năng của một số đoạn mã cụ thể theo cách bạn muốn. Trong trường hợp đó, đừng
ngại tạo ra mã riêng của bạn để kiểm tra so sánh một quá trình. Không có gì sai
với việc chèn mã để đánh dấu và đo thời gian trong mô-đun XQuery của bạn, đặc
biệt là nếu bạn có thể bỏ qua việc kiểm tra so sánh mã trong sản xuất
Ngoài ra, vì XQuery là một ngôn ngữ lập trình chức năng, mỗi chức năng dựa vào
chính mình. Ở một mức cao hơn, chuỗi trả về của một hàm XQuery phụ thuộc
hoàn toàn vào các tham số mà bạn gọi hàm này với chúng. Vì thế thật dễ dàng hơn
là phát triển các bài thử nghiệm riêng lẻ và các bài thử nghiệm hiệu năng để đánh
giá các hàm XQuery hơn là phát triển các bài thử nghiệm cho các hàm theo các
ngôn ngữ lập trình theo thủ tục chuẩn như Java, Python, Perl, C và PHP. Bạn có
thể dễ dàng đặt thời gian cho các hàm trong mã XQuery của bạn với các quá trình
bên ngoài như là một kịch bản lệnh nhanh. Ví dụ, một kịch bản lệnh Emacs ngắn
và thông minh sẽ cho phép bạn chạy và đặt thời gian cho mã XQuery mà bạn đang
chỉnh sửa chỉ bằng cách đánh dấu mã và nhấn một tổ hợp phím. Kịch bản lệnh này
có thể gửi mã tới máy chủ, có máy chủ đánh giá nó, sau đó trả về các kết quả tới
một bộ đệm mới có dấu thời gian-thực hiện.

Duy trì một danh sách tối ưu hóa
Duy trì một danh sách tối ưu hóa có tiềm năng để áp dụng cho nền tảng của bạn và
bao quát toàn bộ danh sách mỗi khi bạn cần cải thiện hiệu năng của ứng dụng.
Ngoài các việc tối ưu hóa mà bài viết này đã trình bày, tôi tiếp tục các mục sau
đây theo danh mục của tôi.
Biên dịch trước mã ở nơi có thể
Một số cơ sở dữ liệu XML nguyên gốc có khả năng biên dịch trước và phân tích
cú pháp mã XQuery. Đối với mã đang chạy thường xuyên trong một máy chủ, bạn
sẽ thấy các lợi ích định lượng về hiệu năng nếu bạn có thể đảm bảo rằng máy chủ
không phải phân tích cú pháp hay biên dịch mã khi đụng đến.
Mã dựa vào chỉ mục
Trong nhiều trường hợp, một cơ sở dữ liệu XML nguyên gốc có thể đánh giá một
biểu thức XPath và XQuery hoặc giải truy vấn trực tiếp từ các chỉ mục, mà không
bao giờ phải lấy ra một tài liệu. Bất kỳ ở đâu có thể, bạn nên cố gắng viết các truy
vấn để thực hiện điều này. Hãy tìm một tùy chọn cơ sở dữ liệu hay tùy chọn hàm-
tìm kiếm cho phép việc tìm kiếm của bạn lấy ra các kết quả của nó trực tiếp từ các
chỉ mục và tránh bất kỳ việc lọc theo điều kiện xác nhận hợp lệ để có các kết quả.
Việc lấy các kết quả từ chỉ mục mà không cần lọc có các hạn chế riêng của nó.
Bạn phải cẩn thận nếu các nút mà bạn đang tìm kiếm không phải là các nút cấp
cao nhất (hoặc các gốc của đoạn). Hãy sẵn sàng để hiểu các kết quả, có thể bao
gồm các nút mà việc tìm kiếm có lọc sẽ không đưa vào.
Xem xét các phần mở rộng XQuery
Hầu hết các cơ sở dữ liệu XML nguyên gốc cung cấp các phần mở rộng XQuery
được thiết kế để chạy nhanh. Khi bạn ra khỏi những qui định chặt chẽ của
XQuery, ứng dụng của bạn trở nên bị ràng buộc nhiều hơn vào một sản phẩm cụ
thể, nhưng trong thực tế, trong sản xuất, khi xử lý một lượng lớn dữ liệu, chắc bạn
muốn xem xét các lợi thế của các phần mở rộng hiệu năng. Tính di động thường đi
kèm với một mức giá.

Hiểu biết về các khu rừng, các cây và các kết hợp
Một số cơ sở dữ liệu XML nguyên gốc giữ dữ liệu của chúng theo định dạng nhị
phân trong các khu rừng (các thư mục), có chứa nhiều cây (các tệp). Các bản ghi
mới thường lưu vào các cây mới. Hệ thống (hoặc một quản trị viên) kết hợp các
cây theo định kỳ để cải thiện hiệu năng — nếu các cây trong một khu rừng ít hơn,
thì thời gian đáp ứng truy vấn tốt hơn. Nhưng bạn không muốn các khu rừng phát
triển quá lớn. Khi bạn tối ưu hệ thống của bạn, hãy điều tra kích thước tối ưu lớn
nhất cho các khu rừng và số lượng cây lớn nhất mà bạn muốn trước khi bạn bắt
đầu (hoặc cấu hình hệ thống để bắt đầu) kết hợp.
Vì vậy, các tải dữ liệu kích hoạt các kết hợp. Và các kết hợp có thể đưa một hệ
thống đang hoạt động xuống gần giới hạn của các khả năng thông qua của nó. Khi
có thể, bạn nên lập biểu cho các tải dữ liệu và các kết hợp xảy ra khi tải của hệ
thống ở mức tối thiểu của nó. Các tải dữ liệu có tác động nhỏ hơn nhiều về hiệu
năng so với các kết hợp. Nếu các tải dữ liệu của bạn chạy trong các khoảng thời
gian dài, thì nên xem xét chỉ cấm các kết hợp trong lúc tải cao nhất.


Tóm tắt
Các cơ sở dữ liệu XML nguyên gốc hiện đang là các trang web mạnh mẽ hỗ trợ
các tìm kiếm phức tạp dựa vào các cơ sở dữ liệu có hàng chục triệu bản ghi. Trong
điều kiện thích hợp, với một số ứng dụng, các cơ sở dữ liệu có thể cung cấp cho
các tổ chức các lợi thế cạnh tranh đáng kể so với những người đến sau. Nhưng
cũng giống như bất kỳ công nghệ cơ sở dữ liệu khác, các cơ sở dữ liệu XML
nguyên gốc sẽ cung cấp nhiều lợi ích nhất cho những ai hiểu rõ cách tối ưu hóa hệ
thống của họ về tính hiệu quả và khả năng đáp ứng.

Mục lục

 Các cơ sở dữ liệu XQuery và cơ sở dữ liệu XML nguyên gốc
 Tránh tiêu chuẩn hóa

 Sử dụng các tên phần tử duy nhất
 Ước tính trước các giá trị
 Chuyển đổi dữ liệu theo các truy vấn của bạn
 Mô tả sơ lược mã XQuery
 Duy trì một danh sách tối ưu hóa
 Tóm tắt