Як швидко шукати дуже великий список рядків / записів у базі даних

У мене є така проблема: у мене є база даних, що містить понад 2 мільйони записів. У кожному записі є рядкове поле X, і я хочу відобразити список записів, для якого поле X містить певний рядок. Кожен запис має розмір близько 500 байт.

Щоб зробити це більш конкретним: у графічному інтерфейсі моєї програми у мене є текстове поле, куди я можу ввести рядок. Над текстовим полем я маю таблицю із відображенням (перший N, наприклад 100) записів, які відповідають рядку в текстовому полі. Коли я набираю або видаляю один символ у текстовому полі, вміст таблиці повинен бути оновлений на льоту.

Цікаво, чи існує ефективний спосіб зробити це за допомогою відповідних індексних структур та / або кешування. Як було пояснено вище, я хочу лише показати перші N елементів, які відповідають запиту. Тому для N досить малих, це не повинно бути великим питанням завантаження відповідних елементів із бази даних. Крім того, кешування елементів в основній пам'яті може зробити пошук швидшим.

Я думаю, що головна проблема полягає в тому, як швидко знайти відповідні елементи, враховуючи рядок шаблону. Чи можу я покластися на деякі засоби СУБД, чи потрібно самостійно будувати індекс пам'яті? Будь-які ідеї?

EDIT

Я провів перший експеримент. Я розділив записи на різні текстові файли (максимум 200 записів на файл) і розмістив файли в різних каталогах (я використовував вміст одного поля даних для визначення дерева каталогу). У кінцевому підсумку я маю близько 50000 файлів у приблизно 40000 каталогах. Потім я запустив Lucene, щоб індексувати файли. Пошук рядка за допомогою демо-програми Lucene досить швидкий. Розщеплення та індексація зайняли кілька хвилин: це для мене цілком прийнятно, оскільки це статичний набір даних, який я хочу запитувати.

Наступним кроком є ​​інтеграція Lucene в основну програму та використання звернень, повернутих Lucene, для завантаження відповідних записів у основну пам'ять.

Замість того, щоб розміщувати свої дані всередині БД, ви можете зберігати їх як набір документів (текстові файли) окремо і зберігати посилання (шлях / URL тощо) у БД.

Це важливо, оскільки запит SQL за дизайном буде дуже повільним як у пошуку підрядків, так і в пошуку.

Тепер ваша проблема сформульована як необхідність пошуку текстових файлів, що містять набір рядків. Тут є дві можливості.

1. Збіг підрядків Якщо текстові краплі - це одне слово або слово (без пробілів), і вам потрібно шукати в ньому довільну підрядку. У таких випадках потрібно проаналізувати кожен файл, щоб знайти найкращі можливі файли, які відповідають. Один використовує такі алгоритми, як алгоритм Boyer Moor. Детальніше дивіться у цьому та цьому . Це також рівнозначно grep - тому що grep використовує подібні речі всередині. Але ви все одно можете зробити принаймні 100+ греп (найгірший випадок 2 мільйони) перед поверненням.

2. Індексований пошук. Тут ви припускаєте, що текст містить набір слів, а пошук обмежений фіксованою довжиною слова. У цьому випадку документ індексується за всіма можливими зустрічами слів. Це часто називається "Повний текст пошуку". Існує кількість алгоритмів для цього та кількість проектів з відкритим кодом, які можна використовувати безпосередньо. Багато з них, а також підтримка дикого пошуку карти, приблизний пошук і т.д. , як зазначено нижче:
   а. Apache Lucene: http://lucene.apache.org/java/docs/index.html
   b. OpenFTS: http://openfts.sourceforge.net/
   c. Сфінкс http://sphinxsearch.com/

Швидше за все, якщо вам потрібні "фіксовані слова" як запити, підхід два буде дуже швидким та ефективним.

Ви шукаєте технологію повнотекстової індексації. Більшість RDBMS мають якісь вбудовані можливості, які можуть працювати тут, або ви можете використовувати щось на зразок Lucene, якщо хочете отримати більш фантазії та / або просто запустити його в пам'яті.

Ви розглядали трійку ? В основному ви будуєте дерево, використовуючи загальні префікси, тому всі слова, які починаються з однакових літер, - це діти одного і того ж вузла. Якщо ви збираєтесь підтримувати відповідність у будь-якій підрядці, то вам доведеться генерувати якийсь перестановлений індекс і будувати з цього свій трійник. Однак це може призвести до того, що ваші вимоги щодо зберігання можуть закінчитися.

Я хотів би додати відповідь Уайата Барнетта, що рішення RDBMS з повнотекстовим індексуванням у відповідному стовпчику буде працювати, але якщо ви хочете використовувати локальний кеш попередньо отриманих записів, тоді вам потрібно скласти план використання цих кешованих записів. на вашу користь.

Один із варіантів - зібрати унікальні ідентифікатори цих записів, які ви НАЙКРАЙНО не бажаєте отримувати з запиту та включати їх, можливо, в a NOT INчи a NOT EXISTS.

Хоча слово обережності, використання NOT INабо, NOT EXISTSяк правило, не є дешевим, і МОЖЕ негативно впливати на ефективність запиту або план запитів, залежно від того, який механізм бази даних ви використовуєте. Запустіть план пояснення щодо остаточного запиту, щоб переконатися, що всі ваші індекси на постраждалих стовпцях використовуються

Також не завадить порівняти ефективність між двома підходами, щоб побачити, що швидше. Ви можете бути здивовані, дізнавшись, що підтримка локального кешу та явна фільтрація запитів із запиту може мати гірші показники, ніж тонко налаштований запит, який отримує всі записи.

Про всяк випадок, коли ви його пропустили. Якщо ви використовуєте Lucene для своєї бази даних замість текстового пошуку, що підтримується в DB, ​​вам доведеться бути дуже обережними під час внесення змін до своєї БД. Як ви переконаєтесь у тому, що ви можете мати атомність, коли вам доведеться вносити зміни як у БД, так і на зовнішні ресурси (Lucene)? Так, це можна зробити, але роботи буде багато.

Коротше кажучи, ви втрачаєте підтримку транзакцій БД, якщо помістити Lucene у свою схему даних.

Ви розглядали сфінкса? http://sphinxsearch.com, якщо ви можете скористатись стороннім інструментом, це було б ідеально для того, що ви намагаєтесь досягти, його набагато ефективніше при повнотекстовому пошуку, ніж будь-які RDBMS, якими я особисто користувався.

Дещо дивно, що жодна з відповідей не представляла термін "перевернутий індекс" , технологію, що лежить в основі всіх рішень, аналогічних Apache Lucene та ін.

Перевернутий індекс - це зіставлення від слів до документів ("інвертований індекс рівня" запису) або навіть точних розташувань слів у документі ("інвертований індекс на рівні слів").

І ІЛИ АБО логічні операції є тривіальними для реалізації. Якщо у вас є точні місця розташування слів, можна шукати суміжні слова, таким чином роблячись можливим пошук фрази.

Отже, подумайте про індекс, що містить (слово, файл, місцезнаходження) кортежі. Якщо у вас є напр. ("Перевернутий", "foo.txt", 123), ви просто перевіряєте, чи ("індекс", "foo.txt", 124) є частиною індексу для пошуку повної фрази "перевернутий індекс" .

Хоча я не рекомендую вам повторно реалізувати повнотекстову пошукову систему з нуля, корисно знати, як працюють такі технології, як Apache Lucene.

Отже, моя рекомендація - дізнатися, як працюють перевернуті індекси та вибрати технологію, використовуючи їх, наприклад Apache Lucene. Тоді ви, принаймні, добре розумієте, що можна зробити, а що не можна зробити.