Tại sao cơ sở dữ liệu không có chỉ mục toàn văn tốt

Tại sao không có bất kỳ hệ thống RDBMS chính nào như MySQL, SQL Server, Oracle, v.v. có hỗ trợ lập chỉ mục toàn văn tốt?

Tôi nhận ra rằng hầu hết các cơ sở dữ liệu hỗ trợ các chỉ mục văn bản đầy đủ ở một mức độ nào đó, nhưng chúng thường chậm hơn và với một bộ tính năng nhỏ hơn. Dường như mỗi khi bạn muốn có một chỉ mục văn bản đầy đủ thực sự tốt, bạn phải ra ngoài cơ sở dữ liệu và sử dụng một cái gì đó như Lucene / Solr hoặc Sphinx.

Tại sao công nghệ trong các công cụ tìm kiếm toàn văn này không được tích hợp hoàn toàn vào công cụ cơ sở dữ liệu? Có rất nhiều vấn đề với việc giữ dữ liệu trong một hệ thống khác như Lucence, bao gồm việc giữ dữ liệu cập nhật và không thể tham gia kết quả với các bảng khác. Có một lý do công nghệ cụ thể tại sao hai công nghệ này không thể được tích hợp?

Câu trả lời ngắn gọn là vì truy xuất văn bản hầu như không có gì giống với cách cơ sở dữ liệu truyền thống được thiết kế và sử dụng. Một người nào đó là một át chủ bài trong việc tạo / sử dụng RDBMS giống như một con cừu để giết thịt khi họ tiếp cận truy xuất văn bản lần đầu tiên.

(Xin lỗi vì câu trả lời dài, nhưng hôm nay tôi bị ốm và tôi không có gì khác để làm.)

Những điều sau đây có thể dễ dàng xuất hiện dưới TL; DR, nhưng nếu bạn có thời gian và sự quan tâm, thì phần tiếp theo là một phần của câu trả lời dài hơn. Lưu ý: Tôi đang nói đến việc đã triển khai một hệ thống truy xuất thông tin thương mại bắt đầu từ năm 1986. Chúng tôi đã thành công về mặt kỹ thuật, nhưng là một thị trường thất bại.

Thực hiện IR (Truy xuất thông tin) đúng cách yêu cầu bạn bắt đầu bằng cách suy nghĩ về những gì bạn đang tìm kiếm và cách bạn sẽ tìm thấy nó bằng cơ chế truy vấn của mình. Điều này nghe có vẻ dễ dàng, nhưng nó là bất cứ điều gì nhưng dễ dàng. Đây chỉ là một số trong những điều bạn sẽ phải quyết định trước khi bạn bắt đầu quét tài liệu (hoặc các trường) của mình.

1. Có vấn đề gì không? DoD có giống như tơ hồng không? Làm thế nào về "ngọn lửa" và "FLAME" (một loại nước hoa dựa trên Burger King Whopper (vâng, thực sự)).
2. Những loại mã thông báo nào bạn sẽ lập chỉ mục? Bạn rõ ràng muốn lập chỉ mục "cha". Bạn có thể muốn lập chỉ mục "Daddy123". Bạn có muốn lập chỉ mục "123" không? "12.3"? "192.168.1.1"?
3. Làm thế nào để bạn đối phó với những thứ như gạch nối? Một ví dụ hơi lỗi thời là "cơ sở dữ liệu", "cơ sở dữ liệu" và "cơ sở dữ liệu", tất cả đều được sử dụng đồng thời vào năm 1986.
4. Nếu ngôn ngữ truy vấn của bạn hỗ trợ khái niệm "Tìm A trong cùng một câu với B", làm thế nào để bạn xác định ngắt câu? Mặc du '?' và '!' là đủ dễ dàng, những '. là một bitch. Hãy suy nghĩ về những thứ như "Mr.", "2.", "vv", v.v.
5. Bạn sẽ hỗ trợ xuất phát? Nếu vậy, bạn sẽ cẩn thận đến mức nào để không vô tình thay đổi POS (Phần của bài phát biểu)? Ví dụ: "mèo" có thể bắt nguồn từ "mèo", nhưng "rèm" có thể hoặc không bắt nguồn từ "mù". Nếu đó là một động từ ("Anh ấy làm tôi mù") thì bạn có thể bắt nguồn, nhưng nếu đó là một danh từ ("Tôi thích rèm của bạn) thì bạn không thể (hoặc ít nhất là không nên). là một đầm lầy của Đệ nhất.
6. Những ngôn ngữ bạn sẽ hỗ trợ? Những gì hoạt động bằng tiếng Anh có thể thất bại thời gian lớn bằng tiếng Pháp hoặc tiếng Đức, mặc dù thật kỳ lạ, nó sẽ có xu hướng hoạt động tốt cho tiếng Nhật trong đại diện Hepburn Romanji .

Và danh sách cứ tiếp tục dài.

Sau đó, chúng tôi phải suy nghĩ về ngôn ngữ truy vấn của chúng tôi. Nó có vẻ rằng nếu tất cả các bạn sẽ hỗ trợ rất đơn giản Boolean sau đó nó sẽ được dễ dàng, nhưng một trong những điều đó là khá nhiều phổ biến thoả thuận là tinh khiết Boolean hút cho văn bản. Ví dụ, bạn sẽ cần các toán tử bổ sung để chỉ định thứ tự và khoảng cách, và cậu bé, ồ, cậu bé làm điều đó khiến cuộc sống trở nên phức tạp hơn. Bạn cũng cần biết bạn đang ở phần nào - tiêu đề, tiêu đề, nội dung, v.v. - dẫn đến tất cả các loại phân tích cú pháp cụ thể của bộ sưu tập. Nhưng bây giờ không còn đủ để chỉ có một danh sách các mã thông báo xuất hiện trong tài liệu, bạn phải biết nơitrong tài liệu họ xảy ra. Điều này dẫn đến một bộ địa chỉ của (docID, partID, para-in-part, câu-in-para, word-in-ver). Lưu trữ và tìm kiếm hiệu quả thông tin này có thể có được sở trường cho một bộ sưu tập phi đồ chơi.

Sau đó là cấu trúc thực tế của cửa hàng dữ liệu của bạn. Các hệ thống văn bản thường được thực hiện dưới dạng "đảo ngược hoàn toàn" các tài liệu. DB trung bình có bao nhiêu chỉ số? 10? 50? 500? Trong IR, không có gì lạ khi có 5.000.000 chỉ mục trở lên , mỗi chỉ số cho một mã thông báo riêng biệt. Và bất kỳ mã thông báo cụ thể nào cũng có thể có 1 phiên bản (ví dụ: "narfle" hoặc "garthok") hoặc 10.000.000 phiên bản (ví dụ: "the"). Điều này có nghĩa là toàn bộ phương pháp tạo và cập nhật các chỉ mục của bạn phải nhanh như chớp hoặc bạn sẽ chìm vào đầm lầy. Và bạn vẫn còn nhiều vấn đề khác mà DB truyền thống mắc phải: quản lý không gian đĩa, phục hồi sự cố, ảnh chụp nhanh mạch lạc từ một hệ thống đang chạy, v.v., v.v.

Cuối cùng là kết quả xếp hạng. Một kết quả không được đặt ra từ một truy vấn Boolean đối với một bộ sưu tập lớn là vô ích đối với con người. Nó có thể hữu ích cho một chương trình, nhưng đó không phải là điều tôi đang giải quyết. Mặc dù hệ thống của chúng tôi đã triển khai Boolean, điểm bán hàng của chúng tôi là chúng tôi là hệ thống thương mại đầu tiên hỗ trợ tìm kiếm sự tương tự , dựa trên Hệ số Cosine . Toán học và logic của loại tìm kiếm này (về cơ bản là một sản phẩm chấm được chuẩn hóa của vectơ truy vấn so với hàng triệu vectơ tài liệu) yêu cầu các cách tiếp cận khác nhau để biểu diễn và lưu trữ dữ liệu so với Boolean - chắc chắn không phải là thứ có sẵn trong DB trung bình của bạn.

Tất cả điều này (và hơn thế nữa) là lý do tại sao "truy xuất văn bản" và "cơ sở dữ liệu" gần như không thuộc cùng một câu. Tôi nghĩ rằng bạn nên chọn một cơ sở dữ liệu tốt cho nhu cầu "bình thường" của mình, sau đó sử dụng hệ thống IR bên ngoài để lập chỉ mục / tìm kiếm "tài liệu" trong DB chính của bạn.

Oracle có các khả năng tìm kiếm văn bản đầy đủ khá tinh vi như một phần của Văn bản Oracle và đã có được điều đó trong hơn một thập kỷ. SQL Server 2008 cũng hỗ trợ tìm kiếm toàn văn . Vì vậy, tôi không chắc rằng tiền đề của câu hỏi của bạn là chính xác.

Nếu câu hỏi của bạn thực sự nhiều hơn theo dòng "tại sao chúng ta không thực hiện tìm kiếm toàn văn bản hơn trong cơ sở dữ liệu thay vì ở tầng giữa", có một vài yếu tố. Các nhà phát triển cơ sở dữ liệu thường muốn lưu trữ dữ liệu chuẩn hóa không phải là dữ liệu phi cấu trúc hoặc bán cấu trúc. Vì vậy, họ thường thích thiết kế các hệ thống phân tích dữ liệu đến thành các trường có thể tìm kiếm riêng biệt hơn là hỗ trợ tìm kiếm toàn văn. Các nhà phát triển ứng dụng cũng có xu hướng không muốn lưu trữ dữ liệu phi cấu trúc hoặc bán cấu trúc trong các trường CLOB / BLOB trong cơ sở dữ liệu vì họ xem việc lưu trữ dữ liệu trên hệ thống tệp dễ dàng hơn và không muốn cơ sở dữ liệu quá lớn. Tôi không phải là người hâm mộ của cuộc tranh luận này, nhưng đó là một vấn đề phổ biến. Kết quả là, hầu hết mọi người kết thúc với dữ liệu họ ' d muốn thực hiện tìm kiếm toàn văn bản khi sống bên ngoài cơ sở dữ liệu vì vậy nó cần được lập chỉ mục bên ngoài cơ sở dữ liệu. Nếu thậm chí một phần nhỏ hợp lý của dữ liệu của bạn nằm ngoài cơ sở dữ liệu, có chỉ mục tầng giữa thì nó trở thành một giải pháp hợp lý hơn nhiều.

Nếu bạn lưu trữ dữ liệu phi cấu trúc và bán cấu trúc của mình trong Oracle, tôi sẽ đặt Oracle Text lên tính năng cho tính năng với bất kỳ giải pháp lập chỉ mục toàn văn bản độc lập nào.

Tôi chưa bao giờ gặp nhiều vấn đề với FTS trong PG.

http://www.postgresql.org/docs/civerse/static/textsearch.html

Điều đó nói rằng, nó không phải là nhân sư hoặc lucene, hoặc bất cứ điều gì. Tôi nghĩ rằng có một vài lý do chính (một số chỉ ra ở trên). Tôi nghĩ rằng người duy nhất họ bỏ lỡ sẽ là yếu tố chi phí.

FTS không miễn phí. Nó cần bộ nhớ, cpu và tài nguyên đĩa để tìm kiếm. Cơ sở dữ liệu thường có đủ công việc liên quan mà không cần thực hiện FTS. Thu nhỏ 1 cơ sở dữ liệu thực hiện FTS và lưu trữ dữ liệu có cấu trúc thường gây đau đớn. Thu nhỏ những thứ riêng biệt (lucene / nhân sư / bất cứ thứ gì) và Thu nhỏ cơ sở dữ liệu thường ít gây đau đớn hơn.

Chủ yếu là xung quanh kích thước, và nhu cầu của bạn là gì. Cố gắng xây dựng một cái gì đó như Google (hoặc tìm kiếm trên web rộng) bằng FTS của PG hoặc Oracle Text đang gặp rắc rối.

Tôi sử dụng các tính năng FTS của PG trong môi trường sản xuất, nhưng tôi giữ những thứ tôi muốn tìm kiếm khá nhỏ / hạn chế. Tôi không tìm kiếm tài liệu từ, tôi đang tìm kiếm toàn bộ hồ sơ (kết hợp các hàng DB). Chẳng hạn, một trong những chức năng tìm kiếm của chúng tôi là tìm kiếm người. Trong DB của chúng tôi, chúng tôi muốn lưu trữ tên của họ ở những nơi riêng biệt (First_name, last_name, v.v.). Thêm vào đó, nhiều người có nhiều hơn 1 tên (tôi biết nghe có vẻ điên rồ, nhưng nó hoàn toàn đúng). Ngoài ra, nhiều người muốn có ô của họ và những ký tự không phải là ascii trong tên của họ được tôn trọng (nói khi được in trên séc của họ), nhưng không ai nhớ cách gõ ô để tìm người, vì vậy chúng tôi cho phép bạn tìm kiếm bằng hoặc không có và thường tìm người bạn muốn.

Ngay cả với nhiều tên và lưu trữ ascii và UTF-8 đơn giản, chúng ta không nói về RẤT NHIỀU không gian tìm kiếm VÀ dữ liệu đã có trong DB (nơi nó thuộc về), do đó, việc thực hiện trong DB có ý nghĩa .

Nhưng việc đẩy 1 triệu tài liệu từ của HR vào DB chỉ để sử dụng FTS cho chúng không có ý nghĩa gì. Chúng đã là các tệp trên hệ thống tệp và hệ thống tệp thực hiện công việc tốt hơn DB có thể giữ dữ liệu đó an toàn và lành mạnh, vì vậy hãy sử dụng Lucene, hoặc nhân sư hoặc bất cứ thứ gì để tìm kiếm dữ liệu đó.

Sử dụng các công cụ thích hợp cho công việc! Nhưng để nói rằng DB không có FTS thì không đúng, nhưng trường hợp sử dụng tôi tin là khác.

Hầu hết các ứng dụng của cơ sở dữ liệu không cần tìm kiếm toàn văn.

Nếu nó được xây dựng trong nó vẫn sẽ phải đối mặt với các vấn đề tương tự như một người lập chỉ mục bên ngoài, bạn sẽ chỉ phải trả tiền cho nó (theo thời gian / không gian / chi phí / độ phức tạp) cho dù bạn có cần hay không.

Tìm kiếm toàn văn không phải là điểm của một hệ thống quản lý cơ sở dữ liệu quan hệ. Heck, có rất nhiều lỗ hổng trong phần quan hệ. (Bạn đã đọc cuốn sách của Chris Date chưa?)