Cơ sở dữ liệu XML nguyên gốc và XQuery
Bài đăng này đã không được cập nhật trong 8 năm
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.
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á.
Tham khảo : http://www.ibm.com/developerworks/
All rights reserved
