Tìm kiếm hiệu quả không phân biệt dạng chữ với pureXML DB2

Chia sẻ: Nguyen Nhi | Ngày: | Loại File: PDF | Số trang:11

Thêm vào BST

Báo xấu

72
lượt xem 3
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Tìm kiếm và sắp xếp dữ liệu XML theo cách không phân biệt dạng chữ Matthias Nicola, Chuyên gia về hiệu năng CSDL, IBM Silicon Valley Laboratory Tóm tắt: Các giá trị của các phần tử và các thuộc tính XML, theo định nghĩa, là phân biệt dạng chữ. Ví dụ, nếu bạn tìm kiếm các phần tử cho giá trị "Paris", bạn sẽ không tìm thấy "PARIS" hoặc "paris".

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Tìm kiếm hiệu quả không phân biệt dạng chữ với pureXML DB2

Tìm kiếm hiệu quả không phân biệt dạng chữ với pureXML DB2 Tìm kiếm và sắp xếp dữ liệu XML theo cách không phân biệt dạng chữ Matthias Nicola, Chuyên gia về hiệu năng CSDL, IBM Silicon Valley Laboratory Tóm tắt: Các giá trị của các phần tử và các thuộc tính XML, theo định nghĩa, là phân biệt dạng chữ. Ví dụ, nếu bạn tìm kiếm các phần tử cho giá trị "Paris", bạn sẽ không tìm thấy "PARIS" hoặc "paris". Điều này có thể được giải quyết bằng các hàm XQuery như fn:upper-case(), nhưng hiệu năng sẽ không phải luôn luôn tối ưu do việc sử dụng các hàm như vậy cản trở việc sử dụng các chỉ số XML. Bài viết này giải thích cách tạo ra một cơ sở dữ liệu không phân biệt dạng chữ khi sử dụng DB2® pureXML™ và hành vi hay xảy ra trong truy vấn XML và các chỉ mục XML Mục lục Case-insensitive search with upper/lower case functions  Creating a case-insensitive database in DB2  Query XML data in a case-insensitive database  Performance  Summary 
Tìm kiếm không phân biệt dạng chữ với các hàm chữ hoa và chữ thường Ví dụ sau sẽ cho bạn một sự hiểu biết rõ ràng hơn về tìm kiếm không phân biệt dạng chữ. Liệt kê 1 định nghĩa một bảng có một cột số nguyên (INTEGER) và một cột XML và chèn 7 hàng vào trong bảng đó. Mỗi hàng có chứa một tài liệu khách hàng nhỏ có chứa một phần tử XML . Các giá trị trong phần tử này khác nhau về chữ hoa và chữ thường. Một số giá trị tất cả là chữ hoa, một số giá trị tất cả là chữ thường và một số trường hợp trộn lẫn ("ký tự chữ hoa đầu tiên"). Điều này có thể xảy ra khi dữ liệu này đã đến từ một loạt các ứng dụng có sử dụng các quy tắc khác nhau để nhập vào dữ liệu chữ hoa và chữ thường. Liệt kê 1. Bảng và dữ liệu mẫu CREATE TABLE customer (id INTEGER, xmldoc XML); INSERT INTO customer (id, xmldoc) VALUES (1,'PARIS'), (2,'Tokyo'), (3,'tokyo'), (4,'PARIS'),
(5,'paris'), (6,'Delhi'), (7,'Paris'); Một ứng dụng truy vấn các tài liệu XML này để tìm kiếm các khách hàng với một thành phố cụ thể hầu như đòi hỏi tìm kiếm không phân biệt dạng chữ. Ví dụ, bạn có thể muốn tìm tất cả các khách hàng ở Paris và hy vọng sẽ lấy ra hàng 1, 4, 5 và 7. Tuy nhiên, nếu bạn tìm kiếm giá trị "Paris", thì chỉ có hàng 7 được trả về. Để tóm lấy tất cả bốn hàng mà bạn cần, bạn có thể sử dụng hàm XQuery fn:upper- case() để biến đổi các giá trị phần tử thành phố thành dạng chữ hoa và so sánh chúng với ""PARIS". Điều này được chỉ ra trong truy vấn trong Liệt kê 2 nó trả về tất cả bốn khách hàng ở Paris. Liệt kê 2. Chọn các khách hàng ở Paris SELECT id, XMLCAST( XMLQUERY( '$XMLDOC/Customer/city') AS VARCHAR(15)) AS city FROM customer WHERE XMLEXISTS('$XMLDOC/Customer[fn:upper-case(city) = "PARIS"]');
Nếu truy vấn của bạn sử dụng một dấu tham số cho giá trị t ìm kiếm, rồi tham số này cũng sẽ được biến đổi sang dạng chữ hoa. Điều này được thể hiện trong Liệt kê 3. Dấu tham số ("?") được gõ vào là VARCHAR(15) và được chuyển vào vị từ XQuery như là biến "c". Liệt kê 3. Chọn các khách hàng khi sử dụng một dấu tham số SELECT id, XMLCAST( XMLQUERY( '$XMLDOC/Customer/city') AS VARCHAR(15)) AS city FROM customer WHERE XMLEXISTS('$XMLDOC/Customer[fn:upper-case(city) = fn:upper- case($c)]' PASSING CAST(? AS VARCHAR(15)) AS "c"); Hình 1 cho thấy kết quả đầu ra của các truy vấn thí dụ ở trên.
Hình 1. Kết quả của truy vấn thí dụ Tất cả điều này thực hiện tốt nếu bạn đang truy vấn chỉ một số lượng nhỏ dữ liệu hoặc nếu các truy vấn của bạn cũng chứa các vị từ chọn như là vị từ dạng chữ hoa được áp dụng chỉ cho một tập kết quả trung gian nhỏ. Vấn đề là vị từ có hàm fn:upper-case() ngăn cản sử dụng các chỉ mục XML trong DB2. Do đó, cách tiếp cận này không thích hợp với số lượng lớn dữ liệu. Để tránh việc sử dụng hàm fn:upper-case() và lợi dụng các lợi ích của các chỉ mục XML, cần thiết tạo ra một cơ sở dữ liệu không phân biệt dạng chữ. Tạo một cơ sở dữ liệu không phân biệt dạng chữ trong DB2 DB2 hỗ trợ phép đối chiếu Unicode nhận biết-cục bộ kể từ Phiên bản 9.5 Bản sửa lỗi 1. Điều này cho phép bạn bỏ qua dạng chữ và/hoặc các dấu. Để tạo một cơ sở dữ liệu không phân biệt dạng chữ cho tất cả các phép so sánh chuỗi, cần thiết sử dụng đối chiếu UCA500R1 như trong Liệt kê 4. Liệt kê 4. Tạo một cơ sở dữ liệu không phân biệt dạng chữ
CREATE DATABASE testdb USING CODESET UTF-8 TERRITORY US COLLATE USING UCA500R1_LEN_S2; Điều chuỗi UCA500R1_LEN_S2 có nghĩa chính xác gì? UCA500R1 UCA500R1 xác định rằng Unicode Collation Algorithm (UCA –Thuật toán phép đối chiếu Unicode) mặc định dựa trên phiên bản 5.0.0 chuẩn Unicode được sử dụng trong cơ sở dữ liệu này. Do UCA mặc định không thể kiểm soát đối chiếu chuỗi của mỗi ngôn ngữ được Unicode hỗ trợ cùng một lúc, việc bố trí các ký tự có thể được tùy chỉnh bằng cách sử dụng các thuộc tính tùy chọn. Các thuộc tính này được phân tách bằng một dấu gạch dưới (_). Từ khóa UCA500R1 cùng với các thuộc tính bất kỳ tạo nên một tên đối chiếu UCA. Tên đối chiếu được sử dụng trong Liệt kê 4 chứa hai thuộc tính: LEN và S2. LEN là của L (ngôn ngữ) và EN (mã ngôn ngữ ISO 639-1 cho tiếng Anh). Thuộc tính thứ hai S2 xác định mức độ mạnh mà nó quyết định có tính đến hay không dạng chữ hay trọng âm khi sắp xếp hoặc so sánh các chuỗi. Trong Liệt kê 4 mức độ mạnh 2 được sử dụng để cho "PARIS" và "paris" là như nhau. Sau đây là các ví dụ về các giá trị khác có thể có: UCA500R1_LEN_S1 sẽ đối chiếu "cliche" = "Cliche" = "cliché"  UCA500R1_LEN_S2 sẽ đối chiếu "cliche" = "Cliche" < "cliché"  UCA500R1_LEN_S3 sẽ đối chiếu "cliche" < "Cliche" < "cliché" 
Có thể tìm thấy trong Trung tâm Thông tin DB2 (xem Tài nguyên) một danh sách tất cả các cách kết hợp có khả năng để sử dụng như một tên đối chiếu UCA. Truy vấn dữ liệu XML trong cơ sở dữ liệu không phân biệt dạng chữ Do cơ sở dữ liệu đã được tạo ra bằng cách sử dụng tên đối chiếu UCA500R1 với mức độ mạnh 2, các truy vấn trước đó bây giờ có thể được viết đơn giản như khi tất cả các dữ liệu thực sự sẽ là chữ hoa, mà không dùng hàm fn:upper-case() (Liệt kê 5). Nó thậm chí không quan trọng cho dù chuỗi tìm kiếm là "Paris" hoặc "PARIS" hoặc sự kết hợp nào khác của chữ hoa hay chữ thường. Liệt kê 5. Chọn các khách hàng ở Paris SELECT id, XMLCAST( XMLQUERY( '$XMLDOC/Customer/city') AS VARCHAR(15)) AS city FROM customer WHERE XMLEXISTS('$XMLDOC/Customer[city = "PARIS"]');
Hình 2. Kết quả truy vấn thí dụ Nếu bạn thêm một mệnh đề ORDER BY để sắp xếp theo giá trị thành phố được trích ra, tập kết quả vẫn duy trì như nhau: PARIS, paris và Paris được coi như là cùng giá trị. Để truy vấn dữ liệu này một cách hiệu quả, đặc biệt là nếu số hàng trong bảng lớn, bạn nên tạo một chỉ mục XML trên XPath là /Customer/city, như Liệt kê 6 cho thấy: Liệt kê 6. Tạo một chỉ mục XML CREATE INDEX customer_lang_idx ON test (xmldoc) GENERATE KEY USING XMLPATTERN '/Customer/city' AS SQL VARCHAR(15); giải thích truy vấn (bằng Visual Explain hoặc db2exfmt), bạn thấy rằng chỉ số được sử dụng để tìm kiếm không phân biệt dạng chữ:
Hình 3. Kế hoạch giải thích để truy vấn tất cả các khách hàng ở Paris trong một cơ sở dữ liệu không phân biệt dạng chữ Mặt hạn chế tiềm ẩn của cách tiếp cận đã mô tả trong phần này là tất cả các dữ liệu trong tất cả các cột trong tất cả các bảng trong toàn thể cơ sở dữ liệu được xử lý theo cách không phân biệt dạng chữ. Không thể hạn chế không phân biệt dạng chữ cho các bảng hay các cột cụ thể. Đó là tất cả hoặc không. Lưu ý rằng không phân biệt dạng chữ chỉ áp dụng cho các giá trị phần tử và thuộc tính, chứ không phải tên thẻ của chúng. Các thẻ và biểu thức đường dẫn XML vẫn
còn phân biệt dạng chữ. Ví dụ, hai biểu thức XPath là /Customer/city (chữ "c" viết thường) và /Customer/City (chữ "C" viết hoa) là khác nhau. Cái sau sẽ không tìm thấy bất kỳ phần tử nào trong dữ liệu mẫu của chúng tôi bởi vì các phần tử trong dữ liệu mẫu của chúng tôi được viết theo chữ thường. Hiệu năng Sử dụng một phép đối chiếu tùy chỉnh cho cơ sở dữ liệu có thể tác động đến hiệu năng truy vấn do số lượng của lần khớp các chuỗi có thể sẽ tăng lên khi bạn chọn một giá trị thiết lập UCA lỏng hơn. Nói cách khác, các phép so sánh chuỗi có thể tốn kém hơn trong cơ sở dữ liệu không phân biệt dạng chữ. Để kiểm tra sự khác biệt hiệu năng giữa các truy vấn các cơ sở dữ liệu phân biệt dạng chữ và không phân biệt dạng chữ, chúng tôi đã tạo ra một cơ sở dữ liệu thông thường (phân biệt dạng chữ) và một cơ sở dữ liệu không phân biệt dạng chữ. Chúng tôi đưa vào 20.000 tài liệu CustAcc từ khung chuẩn TPoX và đo một loạt các truy vấn trong cả hai cơ sở dữ liệu. Đối với các truy vấn chỉ có một số hàng nhỏ đến trung bình, sự khác biệt hiệu năng giữa hai cơ sở dữ liệu kiểm tra không đáng kể. Chúng tôi đã thấy một sự khác biệt lớn hơn đối với các truy vấn có một số lượng lớn các hàng, chẳng hạn như một hoạt động quét bảng qua tất cả 20.000 tài liệu XML so với phép so sánh chuỗi trên mỗi tài liệu. Các truy vấn như vậy đã lâu hơn 5% đến 8% trong cơ sở dữ liệu không phân biệt dạng chữ. Một chi phí nhỏ phải trả cho t ìm kiếm phân biệt dạng chữ. Tóm tắt Có một số phương pháp để tìm kiếm dữ liệu DB2 theo cách không phân biệt dạng chữ như việc sử dụng các cột đã tạo ra (xem Tài nguyên). Trong khi các phương pháp này có thể làm việc tốt với dữ liệu quan hệ, nhưng chúng không phù hợp với truy vấn dữ liệu XML. Việc tạo ra một cơ sở dữ liệu với đối chiếu Unicode tùy
chỉnh là cách tốt nhất để đạt được xử lý dữ liệu XML không phân biệt dạng chữ. Điều này làm cho mọi sự so sánh giá trị chuỗi trong cơ sở dữ liệu là không phân biệt dạng chữ và cho phép sử dụng các chỉ mục XML và các chỉ số quan hệ như bình thường. Chi phí hoạt động của việc tăng các mẫu tìm kiếm (liên quan đến dạng chữ hoặc dấu) đã chứng tỏ là rất thấp.