Mengapa basis data tidak memiliki indeks teks lengkap yang bagus

Mengapa tidak ada sistem RDBMS utama seperti MySQL, SQL Server, Oracle, dll. Yang memiliki dukungan pengindeksan teks lengkap yang baik?

Saya menyadari bahwa sebagian besar database mendukung indeks teks lengkap sampai taraf tertentu, tetapi biasanya lebih lambat, dan dengan serangkaian fitur yang lebih kecil. Tampaknya setiap kali Anda menginginkan indeks teks lengkap yang benar-benar bagus, Anda harus keluar dari database dan menggunakan sesuatu seperti Lucene / Solr atau Sphinx.

Mengapa teknologi di mesin pencari teks lengkap ini tidak sepenuhnya terintegrasi ke dalam mesin basis data? Ada banyak masalah dengan menjaga data di sistem lain seperti Lucence, termasuk menjaga data tetap mutakhir, dan ketidakmampuan untuk menggabungkan hasil dengan tabel lain. Adakah alasan teknologi spesifik mengapa kedua teknologi ini tidak dapat diintegrasikan?

Jawaban singkatnya adalah karena pencarian teks hampir tidak memiliki kesamaan dengan bagaimana database tradisional dirancang dan digunakan. Seseorang yang ace dalam membuat / menggunakan RDBMS seperti domba yang disembelih ketika mereka mendekati pengambilan teks untuk pertama kalinya.

(Maaf untuk jawaban panjangnya, tapi aku sakit di tempat tidur hari ini dan aku tidak punya hal lain untuk dilakukan.)

Berikut ini dapat dengan mudah berada di bawah TL; DR, tetapi jika Anda punya waktu dan minat, yang berikut adalah bagian dari jawaban yang lebih panjang. Catatan: Saya berbicara tentang penerapan sistem pencarian informasi komersial mulai tahun 1986. Kami sukses secara teknis, tetapi gagal dalam pemasaran.

Melakukan IR (Pengambilan Informasi) dengan benar mengharuskan Anda mulai dengan memikirkan apa yang Anda cari dan bagaimana Anda akan menemukannya menggunakan mekanisme kueri Anda. Hal ini mungkin terdengar mudah, tetapi itu adalah sesuatu tapi mudah. Berikut adalah beberapa hal yang harus Anda putuskan sebelum Anda mulai memindai dokumen (atau bidang) Anda.

1. Apakah kasus penting? Apakah DoD sama dengan dod? Bagaimana dengan "nyala api" dan "FLAME" (cologne berdasarkan Burger King Whopper (ya, sungguh)).
2. Token apa yang akan Anda indeks? Anda jelas ingin mengindeks "ayah". Anda mungkin ingin mengindeks "daddy123". Apakah Anda ingin mengindeks "123"? "12.3"? "192.168.1.1"?
3. Bagaimana Anda menghadapi hal-hal seperti tanda hubung? Contoh yang agak ketinggalan zaman adalah "basis data", "basis data", dan "basis data", yang semuanya digunakan secara bersamaan pada tahun 1986.
4. Jika bahasa permintaan Anda mendukung konsep "Temukan A dalam kalimat yang sama dengan B", bagaimana Anda menentukan jeda kalimat? Meskipun '?' dan '!' cukup mudah, itu adalah menyebalkan. Pikirkan tentang hal-hal seperti "Tuan", "2.", "dll.", Dll.
5. Apakah Anda akan mendukung stemming? Jika demikian, seberapa hati-hati Anda untuk tidak secara tidak sengaja mengubah POS (Bagian Bicara)? Misalnya "kucing" dapat berakar ke "kucing", tetapi "kerai" mungkin atau mungkin tidak berakar pada "kebutaan". Jika itu adalah kata kerja ("Dia membutakan saya") maka Anda dapat membendung, tetapi jika itu adalah kata benda ("Saya suka kerai Anda) Anda tidak bisa (atau setidaknya tidak seharusnya). Stemming sangat menggoda, tetapi itu adalah rawa dari Orde Pertama.
6. Bahasa apa yang akan Anda dukung? Apa yang berhasil dalam bahasa Inggris dapat gagal dalam waktu yang lama baik dalam bahasa Prancis atau Jerman, meskipun anehnya itu akan cenderung berhasil untuk Jepang dalam representasi Hepburn Romanji .

Dan daftarnya terus bertambah.

Maka kita harus memikirkan bahasa permintaan kita. Mungkin terlihat bahwa jika semua yang Anda dukung adalah Boolean sederhana maka itu harus mudah, tetapi satu hal yang cukup banyak disepakati secara universal adalah bahwa Boolean murni menghisap teks. Misalnya, Anda akan memerlukan operator tambahan untuk menentukan pemesanan dan jarak, dan anak laki-laki, oh, anak laki-laki itu pernah membuat hidup lebih rumit. Anda juga perlu tahu bagian apa yang sedang Anda geluti - judul, tajuk, badan, dll. - yang mengarah ke segala macam kesenangan parsing khusus koleksi. Tetapi sekarang tidak lagi cukup untuk hanya memiliki daftar token yang terjadi dalam dokumen, Anda harus tahu di manadalam dokumen itu terjadi. Ini menghasilkan sebuah tupel alamat (docID, sectionID, para-in-section, kalimat-dalam-para, kata-dalam-kalimat). Secara efisien menyimpan dan mencari informasi ini dapat memperoleh koleksi non-mainan.

Lalu ada struktur sebenarnya dari penyimpanan data Anda. Sistem teks biasanya diimplementasikan sebagai "inversi penuh" dari dokumen. Berapa banyak indeks yang dimiliki oleh rata-rata DB? 10? 50? 500? Di IR tidak jarang memiliki 5.000.000 atau lebih indeks, satu untuk setiap token yang terpisah. Dan token apa pun yang diberikan dapat memiliki 1 instance (mis. "Narfle" atau "garthok") atau 10.000.000 instance (mis. "The"). Ini berarti bahwa seluruh metode Anda untuk membuat dan memperbarui indeks harus secepat kilat atau Anda akan tenggelam ke dalam rawa. Dan Anda masih memiliki banyak masalah lain yang dilakukan oleh DB tradisional: manajemen ruang disk, pemulihan kerusakan, snapshot yang koheren dari sistem yang sedang berjalan, dll., Dll.

Akhirnya ada peringkat hasil. Hasil yang tidak di-set yang ditetapkan dari kueri Boolean terhadap koleksi besar tidak berguna bagi manusia. Mungkin bermanfaat untuk suatu program, tetapi bukan itu yang saya hadapi. Meskipun sistem kami menerapkan Boolean, nilai jual kami adalah bahwa kami adalah sistem pertama yang tersedia secara komersial untuk mendukung pencarian kesamaan , berdasarkan Cosine Coefficient . Matematika dan logika jenis pencarian ini (pada dasarnya produk titik yang dinormalisasi dari vektor kueri terhadap jutaan vektor dokumen) memerlukan pendekatan yang sangat berbeda untuk representasi dan penyimpanan data daripada Boolean - jelas bukan sesuatu yang tersedia di DB rata-rata Anda.

Semua ini (dan lebih banyak lagi) adalah alasan "pencarian teks" dan "database" hampir tidak termasuk dalam kalimat yang sama. Saya pikir Anda akan lebih baik memilih database yang baik untuk kebutuhan "normal" Anda, dan kemudian menggunakan sistem IR eksternal untuk mengindeks / mencari "dokumen" di DB utama Anda.

Oracle memiliki kemampuan pencarian teks lengkap yang cukup canggih sebagai bagian dari Oracle Text dan telah memilikinya selama lebih dari satu dekade. SQL Server 2008 juga mendukung pencarian teks lengkap . Jadi saya tidak yakin bahwa premis dari pertanyaan Anda benar.

Jika pertanyaan Anda benar-benar sejalan, "mengapa kita tidak melakukan lebih banyak pencarian teks lengkap dalam database daripada di tingkat menengah", ada beberapa faktor. Pengembang basis data umumnya ingin menyimpan data yang dinormalkan bukan data yang tidak terstruktur atau semi-terstruktur. Jadi mereka umumnya lebih suka merancang sistem yang mem-parsing data yang masuk ke bidang yang dapat dicari terpisah daripada mendukung pencarian teks lengkap. Pengembang aplikasi juga cenderung tidak ingin menyimpan data tidak terstruktur atau semi-terstruktur dalam bidang CLOB / BLOB dalam database karena mereka melihatnya lebih mudah untuk menyimpan data pada sistem file dan tidak ingin database menjadi terlalu besar. Saya bukan penggemar argumen ini, tapi ini argumen yang umum. Akibatnya, kebanyakan orang berakhir dengan data yang mereka miliki. d ingin melakukan pencarian teks lengkap tentang hidup di luar database sehingga perlu diindeks di luar database. Jika bahkan sebagian kecil dari data Anda tinggal di luar database, memiliki indeks tingkat menengah itu menjadi solusi yang jauh lebih enak.

Jika Anda menyimpan data Anda yang tidak terstruktur dan semi-terstruktur di Oracle, saya akan menempatkan Oracle Text fitur-untuk-fitur dengan salah satu solusi pengindeksan teks lengkap mandiri.

Saya tidak pernah memiliki banyak masalah dengan FTS di PG.

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

Yang mengatakan, itu bukan sphinx atau lucene, atau apa pun. Saya pikir ada beberapa alasan utama (beberapa ditunjukkan di atas). Saya pikir satu-satunya yang mereka lewatkan adalah faktor biaya.

FTS tidak gratis. Dibutuhkan sumber daya memori, cpu dan disk untuk mencari. Database biasanya memiliki cukup banyak pekerjaan yang terlibat tanpa melakukan FTS. Menskalakan basis data 1 yang melakukan FTS dan penyimpanan data terstruktur biasanya menyakitkan. Melakukan penskalaan hal-hal yang terpisah (lucene / sphinx / apa pun) dan Menskalakan basis data biasanya kurang menyakitkan.

Sebagian besar ada di sekitar ukuran, dan apa kebutuhan Anda. Mencoba untuk membangun sesuatu seperti Google (atau pencarian web luas) dengan FTS atau Oracle Text dari PG sedang mencari masalah.

Saya menggunakan fitur FTS PG dalam lingkungan produksi, tetapi saya menyimpan barang yang ingin saya cari cukup kecil / terbatas. Saya tidak mencari dokumen kata, saya mencari seluruh catatan (kombinasi baris DB). Misalnya salah satu fungsi pencarian kami adalah mencari orang. Dalam DB kami, kami ingin menyimpan nama mereka di tempat yang terpisah (first_name, last_name, dll). Plus banyak orang yang memiliki lebih dari 1 nama (saya tahu ini mungkin terdengar gila, tetapi itu benar-benar benar). Ditambah banyak orang yang menginginkan umlaut mereka dan apa yang bukan karakter non-ascii dalam nama mereka dihormati (katakan ketika dicetak pada cek mereka), tetapi tidak ada yang akan ingat bagaimana mengetikkan umlaut untuk menemukan orang itu, jadi kami membiarkan Anda mencari baik dengan atau tanpa dan biasanya menemukan orang yang Anda inginkan.

Bahkan dengan banyak nama, dan penyimpanan ascii polos dan UTF-8, kami tidak berbicara tentang BANYAK ruang pencarian DAN datanya sudah ada di DB (di mana tempatnya), jadi melakukannya di dalam DB membuat TONS masuk akal .

Tetapi mendorong 1 juta kata dokumen HR ke dalam DB hanya untuk menggunakan FTS pada mereka tidak masuk akal. Mereka sudah file pada filesystem, dan filesystem melakukan pekerjaan yang lebih baik daripada DB dapat menjaga data yang aman dan waras, jadi mari kita gunakan Lucene, atau sphinx atau apa pun untuk mencari data itu.

Gunakan alat yang tepat untuk pekerjaan itu! Tetapi untuk mengatakan bahwa DB tidak memiliki FTS tidak benar, tetapi use case yang saya percaya berbeda.

Sebagian besar aplikasi database tidak perlu pencarian teks lengkap.

Jika itu dibangun di dalamnya masih akan menghadapi masalah yang sama dengan pengindeks eksternal, Anda hanya akan membayar untuk itu (dalam waktu / ruang / biaya / kompleksitas) apakah Anda membutuhkannya atau tidak.

Pencarian teks lengkap bukan poin dari sistem manajemen basis data relasional . Heck, ada banyak lubang di bagian relasional. (Apakah Anda membaca buku Chris Date?)