Ефективна модель бази даних для зберігання даних, індексованих n-грамами

Я працюю над додатком, який вимагає створення дуже великої бази даних з n-грамів, які існують у великому текстовому корпусі.

Мені потрібні три ефективні типи операцій: пошук та вставка, індексовані самим n-грамом, і запит для всіх n-грамів, які містять суб-n-грам.

Мені це здається, що база даних повинна бути гігантським деревом документів, і бази даних документів, наприклад Монго, повинні вміти виконувати цю роботу добре, але я ніколи не використовував їх у масштабах.

Знаючи формат питань Stack Exchange, я хотів би пояснити, що я не прошу пропозицій щодо конкретних технологій, а про тип бази даних, який я повинен шукати, щоб реалізувати щось подібне в масштабі.

Дивіться Lucene NGramTokenizer

Ви впевнені, що не можете просто використовувати люценові або подібні методи індексації?

Інвертовані індекси будуть зберігати n-грам лише один раз, тоді лише ідентифікатори документа, що містять ngram; вони не зберігають це як надмірно необроблений текст.

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

В основному для цього завдання ви можете ефективно використовувати будь-яку базу даних SQL з хорошою підтримкою індексів на основі дерева B + (MySQL підійде вам просто ідеально).

Створіть 3 таблиці:

1. Таблиця документів, стовпці: id / документ
2. N-грамова таблиця: n_gram_id / n_gram
3. Картографування між n-грамами та документами: document_id / n_gram_id

Створіть індекси на N-грамовій таблиці / рядку n_gram та Mapping table / n_gram_id, а також первинні ключі за замовчуванням добре індексуються.

Ваші операції будуть ефективними:

1. Вставка документа: просто витягніть всі n-грами та вставте в таблицю документів та таблицю N-грамів
2. Пошук у програмі буде швидким із підтримкою індексу
3. Запит на всі n-грами, які містять суб-n-грам: у 2 етапи - просто запит на основі індексу всіх n-грамів, які містять суб-n-грам з 2-ї таблиці. Потім - отримати всі відповідні документи для кожного з цих n-грамів.

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

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

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