легка індексація документів для обробки менш ніж 250 тис. потенційних записів

Нещодавно я опинився, що розбирався над обмеженнями механізмів індексації документів. Я розробляв невеликий веб-сайт, який потребував досить надійних пошукових можливостей, але через їхні апаратні обмеження я не міг розгорнути рішення, пов'язане з люценом (наприклад, Solr або ElasticSearch, як я зазвичай), щоб вирішити цю потребу.

І навіть тоді, коли мені потрібно було обслуговувати деякі складні дані та обчислення, що вимагали великої кількості баз даних, мені не потрібно було обробляти понад 250 000 потенційних записів. Розгортання цілого екземпляра Solr або ES просто для вирішення цього питання здавалося марним.

Після того, як я подумав про це, це здається досить великою проблемою. Більшість людей обробляють вимоги пошуку виключно з SQL. Вони просто виконують запити SQL для своїх даних, і це все. Їх пошукові можливості також виявляються жахливими.

• Пошук у повнотекстовому підстановковому пошуку в деяких системах може бути дуже повільним у деяких системах (зокрема спільних хостах) і перервати вашу базу даних, особливо якщо у вас складні запити та багато приєднань.

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

• Брак функцій, як правило, присутній у повнотекстових двигунах.

Бази даних мали таку саму проблему, що потрібно розгорнути як сервер, і тоді з'явився SQLite, і ми раптом змогли розгорнути базу даних, яка міститься в одному файлі. Мій Googling нічого не дав - дивуйтеся, чи існує щось подібне для повнотекстової індексації / пошуку.

Які чинники слід враховувати, приймаючи рішення про те, чи застосовувати легку індексацію документів (наприклад, як це пояснено у відповідях на інше запитання ) чи продовжувати використовувати SQL у цих ситуаціях?

Ви знаєте, я повинен сказати, що варто використовувати Redis.

• Використовуйте ідею контексту . Важко було б піти в глибину, не знаючи більше про документи. Часто можна помітити багато речей із заголовків документів. Профілювання кожного документа є основним першим кроком, як і сканування веб-сторінок.

• Зробіть підрахунок кожного документа слів у словнику ключових слів. Слідкуйте за кількістю популярності кожного слова для загального проекту. Додайте більше ітератора для цього рахунку, якщо вам вдасться виявити високу релевантність у документі чи наборі.
  
  Перше, що це робиться - це надати вам всеосяжний список слів у всьому наборі. Все, що НЕ знайдено в цьому списку, автоматично повертає "немає результатів". Я б запропонував класифікувати результати нижче нижчих на 5-20% популярності (при запуску пошукового запиту за індексом) також просто сказати, що результатів немає ».

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

• Щоб піти далі, починайте зберігати довідкові дані, які групують посилання / ref / pointer / index / незалежно від двох або більше документів та набір ключових слів або фраз. В основному ви отримуєте накачане хмара тегів.

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

• Чим більше способів можна розділити свої дані та зберегти групи, пов'язані одна з одною, у фактичному використанні, тим краще.

• Підключіть ймовірність коректності, відстежуючи кожен раз, коли користувач натискає на результат, який не є першою трійкою. Отримайте вдосконалення виявлення фрази, переглядаючи пошукові запити користувачів, які не давали ідеальних результатів. Примушуйте ваші запити ставати відносно пошукових запитів клієнтів.

• Чи потрібно стежити за оновленнями документів? Chronjobs / скрипт оболонки або заплановані завдання / пакетний сценарій можуть допомогти. Існують різні варіанти планування та сценаріїв, хоча очевидно.

• Витрачайте диск, набирайте швидкість, втрачайте складність. Збережіть кілька дерев своїх документів та / або дерев посилань на документи. Шукайте лише по деревах, для яких були виконані критерії, або принаймні віддайте перевагу їм, щоб швидше отримати результат у більшості випадків.

• Створіть власний легкий двигун перестановки або знайдіть той, який використовує швидке виявлення символів та відсутність регулярних виразів. Або просто за допомогою декількох годин за допомогою регулярного вираження, але тут буде помітна різниця в продуктивності для достатнього пошуку.

• Так багато речей.

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