Порівняння повнотекстової пошукової системи - Lucene, Sphinx, Postgresql, MySQL?


312

Я будую сайт Django і шукаю пошукову систему.

Кілька кандидатів:

  • Lucene / Lucene з компасом / Solr

  • Сфінкс

  • Постгреш вбудований повнотекстовий пошук

  • Повний текстовий пошук MySQl

Критерії відбору:

  • релевантність результатів та рейтинг
  • швидкість пошуку та індексації
  • простота використання та простота інтеграції з Django
  • вимоги до ресурсів - сайт розміщуватиметься на VPS , тому в ідеалі пошуковій системі не потрібно багато оперативної пам’яті та процесора
  • масштабованість
  • додаткові функції, такі як "ти мав на увазі?", пов'язані пошуки тощо

Кожен, хто мав досвід роботи з пошуковими системами вище, або іншими двигунами, які не в списку - я хотів би почути вашу думку.

EDIT: Що стосується потреб в індексації, оскільки користувачі продовжують вводити дані на сайт, ці дані потрібно індексувати постійно. Це не повинно бути в режимі реального часу, але в ідеалі нові дані відображатимуться в індексі із затримкою не більше 15 - 30 хвилин


26
2 ¢: Повний текст та транзакції MySQL є (в даний час) взаємовиключними. Для повнотекстових індексів MySQL потрібен тип таблиці MyISAM, який не підтримує транзакції. (На відміну від типу таблиці InnoDB, яка підтримує транзакції, але не повнотекстові індекси.)
Carl G

2
Повний текст PostgreSQL, Tsearch не підтримує пошук фрази. Однак він є у списку TODO sai.msu.su/~megera/wiki/FTS_Todo .
Гнанам

1
Кожен, хто дивиться на це Джанго, повинен перевірити додаток для сіна. haystacksearch.org
Keyo


24
@CarlG, просто для всіх. MySQL 5.6+ має повну підтримку пошуку тексту за допомогою двигуна
innodb

Відповіді:


167

Приємно бачити, як хтось лунав у Люцені - тому що я про це не знаю.

Сфінкс, з іншого боку, я знаю досить добре, тож давайте подивимось, чи можу я допомогти.

  • Рейтинг за релевантністю результатів є типовим. Ви можете налаштувати власне сортування за вашим бажанням та надати конкретним полям більш високу вагу.
  • Швидкість індексації надшвидка, тому що вона спілкується безпосередньо з базою даних. Будь-яка повільність виникне від складних SQL-запитів та неіндексованих зовнішніх ключів та інших подібних проблем. Я ніколи не помічав жодної повільності в пошуку.
  • Я хлопець з Rails, тому я не маю уявлення, як легко реалізуватися з Django. Існує API Python, який постачається разом із джерелом Sphinx.
  • Демон служби пошуку (searchd) досить низький у використанні пам'яті - і ви можете встановити обмеження на те, скільки також використовує процес індексатора.
  • Масштабованість - це те, де мої знання є більш схематичними - але досить просто скопіювати індексні файли на кілька машин та запустити кілька пошукових демонів. Загальне враження, яке я отримую від інших, полягає в тому, що це досить чортово добре під великим навантаженням, тому масштабування його на кількох машинах - це не те, з чим потрібно боротися.
  • Немає підтримки "зробив-ти-маєш на увазі" тощо - хоча це можна зробити з іншими інструментами досить легко. Сфінкс має основні слова, хоча використовує словники, тому "водіння" та "диск" (наприклад) вважатимуться однаковими при пошуку.
  • Сфінкс не дозволяє частково оновлювати індекс для польових даних. Загальний підхід до цього полягає у підтримці індексу дельти з усіма останніми змінами та повторному індексуванні після кожної зміни (і ці нові результати з’являються протягом секунди чи двох). Через малу кількість даних це може зайняти лічені секунди. Вам все одно доведеться регулярно індексувати основний набір даних (хоча наскільки регулярно залежить від нестабільності ваших даних - щодня? Щогодини?). Швидкі показники швидкості індексації утримують це все досить безболісно.

Я не знаю, наскільки це застосовно до вашої ситуації, але Еван Вівер порівняв декілька загальних варіантів пошуку Rails (Сфінкс, Феррет (порт Люцена для Рубі) та Солр), запустивши деякі орієнтири. Можливо, може бути корисним.

Я не пронизував глибини повнотекстового пошуку MySQL, але знаю, що він не конкурує з високою швидкістю або з особливими можливостями зі Сфінксом, Люценом або Солром.


Сфінкс дозволяє оновлювати окремі атрибути елементів у поточних індексах, але не видаляти / оновлювати повні записи.
Xorlev

sphinx RT дозволяє робити часткові оновлення / видалення. вона знаходиться на ранній стадії, але вже [майже] працює. sphinxsearch.com/wiki/doku.php?id=rt_tutorial
pQd

4
Ось відповідь на Солр, що є гарною парою на цю відповідь на Сфінксі
Нова Олександрія

Ніщо не може відповідати Сфінксу за швидкістю, тому, якщо швидкість є вашою проблемою номер один, то Сфінкс - це варіант для досягнення. Хороший пост
twigg

Sphinx 2.3.2 Beta тепер має функцію "CALL SUGGEST", яку можна використовувати для реалізації "Ви мали на увазі?" sphinxsearch.com/docs/devel.html#sphinxql-call-suggest
K

82

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

Ось тут найбільша перешкода: особисто я думаю, що інтегрувати Lucene у свій проект непросто . Звичайно, це не надто важко налаштувати його, щоб ви могли зробити якийсь основний пошук, але якщо ви хочете отримати максимальну користь від цього, з оптимальною продуктивністю, то вам точно потрібна хороша книга про Люцен.

Що стосується вимог до процесора та оперативної пам’яті, то пошук у Lucene не надто ставить перед вашим процесором, хоча індексує ваші дані, хоча ви робите це не надто часто (можливо, один чи два рази на день), так що це не так багато перешкод.

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


10
Порівняно зі сфінксом, люцесія надто повільна і громіздка. Я використовував обидва у своєму проекті, і я нарешті дотримувався сфінкса. Lucence знаходиться в java, і це вимагає набагато більше процесора та оперативної пам’яті, ніж у Sphinx.
Пхіо Аркар Лвін

25
Я маю тут не погодитися. Lucene блискавично Якщо ви будуєте правильний показник. Ви в основному можете виконати розширений запит над мільйонами записів всього за пару мілісекунд. Вам просто потрібно знати, що ви робите. А Люсен знаходиться в Яві ... твоя справа? Також є порт .NET, Lucene.NET btw.
Razzie

15
але ви чітко заявили, що не використовуєте сфінкса, а v3sson використовує обидва.
user508546

20
як ви можете стверджувати, що продуктивність луцена не має собі рівних у тому ж реченні, яке ви заявляєте, що ви не використовували сфінкса?
user508546

22
Дійсні запитання. Я ніколи не говорив, що Люцен швидший за Сфінкса, я згадував, що Люцен проти повнотекстового пошуку в базі даних є неперевершеним. І воно є. Про це немає жодного питання. Луцен заснований на перевернутому індексі. Зараз я не знаю Сфінкса, як згадувалося раніше, але якщо він також використовує перевернутий індекс або подібний метод індексації, то, можливо, вони однаково працюють. Заявлення про те, що Лучен, порівняно зі Сфінксом, був би "надто повільним та об'ємним", не ґрунтується на фактах. Особливо не тоді, коли кажуть лише, що Lucene знаходиться в «Java», що є просто смішною проблемою з точки зору продуктивності.
Razzie

60

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

Відповідь за посиланням нижче деталізує кілька речей про Сфінкса, який також стосується Solr. Порівняння повнотекстової пошукової системи - Lucene, Sphinx, Postgresql, MySQL?

Solr також пропонує такі додаткові функції:

  1. Підтримує реплікацію
  2. Кілька ядер (вважайте їх окремими базами даних із власною конфігурацією та власними індексами)
  3. Булеві пошуки
  4. Виділення ключових слів (досить просто це зробити в коді програми, якщо у вас є регулярний фукс; проте, чому б не дозволити спеціалізованому інструменту зробити кращу роботу для вас)
  5. Оновіть індекс через XML або розмежений файл
  6. Спілкуйтеся з сервером пошуку через HTTP (він може навіть повернути Json, Native PHP / Ruby / Python)
  7. PDF, Індексація документів Word
  8. Динамічні поля
  9. Грані
  10. Сукупні поля
  11. Зупиніть слова, синоніми тощо.
  12. Більше подібного ...
  13. Індексуйте безпосередньо з бази даних за допомогою спеціальних запитів
  14. Авто-пропозиція
  15. Автоматичне прогрівання кешу
  16. Швидке індексування (порівняйте з часом індексації повнотекстового пошуку MySQL) - Lucene використовує бінарний перевернутий формат індексу.
  17. Підвищення (спеціальні правила для підвищення актуальності певного ключового слова чи фрази тощо)
  18. Польові пошукові запити (якщо користувач пошуку знає поле, яке він / вона хоче шукати, вони звужують їх пошук, ввівши поле, потім значення і ТОЛЬКО це поле шукається, а не все - набагато кращий досвід користувача)

До речі, є тонни більше функцій; однак я перерахував лише ті функції, які я фактично використовував у виробництві. BTW, поза скринькою, MySQL підтримує №1, №3 та №11 (обмежено) у списку вище. Щодо функцій, які ви шукаєте, реляційна база даних не збирається її скорочувати. Я би усунув їх відразу.

Крім того, ще одна перевага полягає в тому, що Solr (ну, Lucene насправді) - це база даних документів (наприклад, NoSQL), тому багато переваг будь-якої іншої бази даних документів може бути реалізовано за допомогою Solr. Іншими словами, ви можете використовувати його для більш ніж просто пошуку (тобто продуктивності). Будьте творчі з цим :)


Сфінкс теж про підтримку реплікації Кілька ядер Булеві пошуки Виділення ключових слів Оновлення індексу через XML -розділений файл - PDF, індексація Word-документа (через xml) Фасетки Зупинка слів, синонімів тощо. Індексуйте безпосередньо з бази даних із спеціальними запитами Авто-пропозиція швидкого індексація Підвищення польових пошуків Про динамічні поля Агрегативні поля Кеш Автонагрівання Я просто не знаю
Moosh

58

Apache Solr


Окрім відповіді на запити ОП, дозвольте передати деяку інформацію про Apache Solr від простого вступу до детальної установки та впровадження .

Просте вступ


Кожен, хто мав досвід роботи з пошуковими системами вище, або іншими двигунами, які не в списку - я хотів би почути вашу думку.

Solr не слід використовувати для вирішення проблем у режимі реального часу. Для пошукових систем Solr - це дуже велика гра та працює бездоганно .

Solr відмінно працює у веб-додатках із високим трафіком ( я десь прочитав, що це не підходить для цього, але я створюю резервну копію цього твердження ). Він використовує оперативну пам’ять, а не процесор.

  • релевантність результатів та рейтинг

Підштовхування допомагає ранжувати ваші результати показують на вершині. Скажімо, ви намагаєтеся знайти ім'я джон в полях FirstName і LastName , і ви хочете , щоб доречність в ПгвЬИате поле, то вам необхідно збільшити вгору ПгвЬИате поле , як показано.

http://localhost:8983/solr/collection1/select?q=firstname:john^2&lastname:john

Як ви можете бачити, Firstname поле збільшив з 2 бали.

Детальніше про SolrRelevancy

  • швидкість пошуку та індексації

Швидкість неймовірно швидка і з цим не йде ніяких компромісів. Причина, що я переїхав у Солр .

Що стосується швидкості індексації, Solr також може обробляти JOINS з таблиць вашої бази даних. Більш високий і складний ПРИЄДНУЮТЬ впливає на швидкість індексації. Однак величезна конфігурація оперативної пам'яті може легко вирішити цю ситуацію.

Чим вище оперативна пам'ять, тим швидше швидкість індексації Solr.

  • простота використання та простота інтеграції з Django

Ніколи не намагалися інтегрувати Солра і Джанго , однак ви можете досягти цього з Haystack . Я знайшов цікаву статтю про ту саму, і ось цей github для цього.

  • вимоги до ресурсів - сайт розміщуватиметься на VPS, тому в ідеалі пошуковій системі не потрібно багато оперативної пам’яті та процесора

Solr розмножується на оперативній пам’яті, тому, якщо оперативна пам’ять висока, вам не доведеться турбуватися про Solr .

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

  • масштабованість

Solr високо масштабований. Погляньте на SolrCloud . Деякі ключові особливості цього.

  • Шардери (або шардинг - це концепція розподілу індексу серед кількох машин, скажімо, якщо ваш індекс виріс занадто великий)
  • Балансування навантаження (якщо Solrj використовується з хмарою Solr, він автоматично бере на себе балансування навантаження за допомогою механізму Round-Robin)
  • Розподілений пошук
  • Висока доступність
  • додаткові функції, такі як "ти мав на увазі?", пов'язані пошуки тощо

Для вищевказаного сценарію ви можете використовувати SpellCheckComponent , упакований у Solr . Є багато інших функцій, SnowballPorterFilterFactory допомагає отримати записи, якщо ви введете книги замість книги , вам будуть представлені результати, пов'язані з книгою .


Ця відповідь широко зосереджена на Apache Solr & MySQL . Джанго поза сферою.

Припускаючи, що ви перебуваєте в середовищі LINUX, ви можете перейти до цієї статті далі. (моя була версія Ubuntu 14.04)

Детальний монтаж

Починаємо

Завантажити Apache Solr з тут . Це буде версія 4.8.1 . Ви можете завантажити нові версії, я вважав це стабільним.

Завантаживши архів, витягніть його в папку на ваш вибір. Скажіть .. Downloadsабо що завгодно .. Так буде виглядатиDownloads/solr-4.8.1/

За Вашим підказкою .. Перейдіть до каталогу

shankar@shankar-lenovo: cd Downloads/solr-4.8.1

Тож тепер ви тут ..

shankar@shankar-lenovo: ~/Downloads/solr-4.8.1$

Запустіть сервер додатків Jetty

Jetty доступний у папці з прикладами solr-4.8.1каталогу, тому перейдіть до нього та запустіть сервер додатків Jetty.

shankar@shankar-lenovo:~/Downloads/solr-4.8.1/example$ java -jar start.jar

Тепер не закривайте термінал, мінімізуйте його і нехай він залишається осторонь.

(Порада: Використовуйте & після start.jar, щоб сервер Jetty запускався у фоновому режимі)

Щоб перевірити, чи успішно працює Apache Solr , відвідайте цю URL-адресу в браузері.http: // localhost: 8983 / солр

Запуск Jetty на користувальницькому порту

Він працює за портом 8983 за замовчуванням. Ви можете змінити порт або тут, або безпосередньо всередині jetty.xmlфайлу.

java -Djetty.port=9091 -jar start.jar

Завантажте JConnector

Цей файл JAR діє як міст між MySQL та JDBC. Завантажте незалежну версію платформи тут

Завантаживши її, вийміть папку та скопіюйте mysql-connector-java-5.1.31-bin.jarта вставте її у каталог lib .

shankar@shankar-lenovo:~/Downloads/solr-4.8.1/contrib/dataimporthandler/lib

Створення таблиці MySQL для підключення до Apache Solr

Щоб використовувати Solr у використанні, вам потрібно мати кілька таблиць і даних для пошуку. Для цього ми будемо використовувати MySQL для створення таблиці та натискання деяких випадкових імен, і тоді ми можемо використовувати Solr для підключення до MySQL та індексувати цю таблицю та її записи.

1.Структура таблиці

CREATE TABLE test_solr_mysql
 (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT,
  name VARCHAR(45) NULL,
  created TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id)
 );

2.Зарахуйте вищевказану таблицю

INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jean');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jack');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jason');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Vego');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Grunt');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jasper');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Fred');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Jenna');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Rebecca');
INSERT INTO `test_solr_mysql` (`name`) VALUES ('Roland');

Потрапляння всередину ядра та додавання директив lib

1.Navigate до

shankar@shankar-lenovo: ~/Downloads/solr-4.8.1/example/solr/collection1/conf

2.Модифікація solrconfig.xml

Додайте ці два директиви до цього файлу ..

  <lib dir="../../../contrib/dataimporthandler/lib/" regex=".*\.jar" />
  <lib dir="../../../dist/" regex="solr-dataimporthandler-\d.*\.jar" />

Тепер додайте DIH (обробник імпорту даних)

<requestHandler name="/dataimport" 
  class="org.apache.solr.handler.dataimport.DataImportHandler" >
    <lst name="defaults">
      <str name="config">db-data-config.xml</str>
    </lst>
</requestHandler>

3.Створіть файл db-data-config.xml

Якщо файл існує, тоді ігноруйте, додайте ці рядки до цього файлу. Як ви бачите перший рядок, вам потрібно надати облікові дані вашої бази даних MySQL . Ім'я бази даних, ім'я користувача та пароль.

<dataConfig>
    <dataSource type="JdbcDataSource" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/yourdbname" user="dbuser" password="dbpass"/>
    <document>
   <entity name="test_solr" query="select CONCAT('test_solr-',id) as rid,name from test_solr_mysql WHERE '${dataimporter.request.clean}' != 'false'
      OR `created` > '${dataimporter.last_index_time}'" >
    <field name="id" column="rid" />
    <field name="solr_name" column="name" />
    </entity>
   </document>
</dataConfig>

(Порада. Ви можете мати будь-яку кількість сутностей, але стежте за ідентифікаційним полем, якщо вони однакові, то індексація буде пропущена.)

4.Змініть файл schema.xml

Додайте це до схеми.xml, як показано ..

<uniqueKey>id</uniqueKey>
<field name="solr_name" type="string" indexed="true" stored="true" />

Впровадження

Індексація

Ось де справжня справа. Вам потрібно зробити індексацію даних від MySQL до Solr в порядку замовлення для використання Solr-запитів.

Крок 1: Перейдіть на панель адміністратора Solr

Натисніть URL-адресу http: // localhost: 8983 / solr у своєму браузері. Екран відкриється так.

Це основна панель адміністрації Apache Solr

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

Крок 2: Перевірте свої журнали

Гаразд, тепер ви тут, оскільки, можливо, є багато жовтих повідомлень (ПОПЕРЕДЖЕННЯ). Переконайтеся, що у вас немає повідомлень про помилки, позначених червоним кольором. Раніше в нашій конфігурації ми додавали запит вибору в наш db-data-config.xml , скажімо, якщо в цьому запиті були помилки, він би відображався тут.

Це розділ реєстрації вашого двигуна Apache Solr

Чудово, помилок немає. Нам добре їхати. Виберемо колекцію1 зі списку, як зображено, і виберемо Dataimport

Крок 3: DIH (обробник імпорту даних)

Використовуючи DIH, ви підключитесь до MySQL з Solr через файл конфігурації db-data-config.xml з інтерфейсу Solr та отримаєте 10 записів із бази даних, що індексується на Solr .

Для цього виберіть повний імпорт та перевірте параметри Очистити та ввести . Тепер натисніть Виконати як показано.

Також ви можете використовувати прямий запит із повним імпортом, як цей.

http://localhost:8983/solr/collection1/dataimport?command=full-import&commit=true

Обробник імпорту даних

Після того, як ви натиснули Виконати , Solr починає індексувати записи, якщо були якісь помилки, він би сказав, що індексація не вдалася, і вам потрібно повернутися до розділу « Журнал», щоб побачити, що пішло не так.

Якщо припустити, що з цією конфігурацією немає помилок, і якщо індексація успішно завершена., Ви отримаєте це повідомлення.

Індексація успіху

Крок 4: Запуск Solr запитів

Здається, що все пройшло добре, тепер ви можете використовувати Solr Queries для запиту даних, які були індексовані. Клацніть Запит зліва та натисніть Виконати кнопку внизу.

Ви побачите індексовані записи, як показано.

Відповідний запит Solr для переліку всіх записів є

http://localhost:8983/solr/collection1/select?q=*:*&wt=json&indent=true

Індексовані дані

Ну, там іде всі 10 індексованих записів. Скажімо, нам потрібні лише імена, починаючи з Ja , в цьому випадку вам потрібно націлити ім'я стовпця solr_name, Отже, ваш запит буде таким.

http://localhost:8983/solr/collection1/select?q=solr_name:Ja*&wt=json&indent=true

Дані JSON, починаючи з Ja *

Ось так ви пишете Solr Queries. Щоб прочитати більше про це, перегляньте цю прекрасну статтю .


3
@Downvoter, не соромтесь коментувати чи редагувати цю відповідь, і міркування про зниження голосу допоможуть і іншим.
Шанкар Дамодаран

4
це одне з найбільш всеосяжних і добре організованих постів, які я бачив на SO. Дивовижна робота.
вироджений

28

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

Але у нього немає зручних пошукових операторів, таких як + або AND (використовує & |!), І я не в захваті від того, як це працює на їхньому сайті документації. У фрагментах результатів він містить напівжирність термінів відповідності, але алгоритм, що відповідає умовам, для термінів відповідності не є великим. Крім того, якщо ви хочете індексувати rtf, PDF, MS Office, ви повинні знайти та інтегрувати конвертер файлового формату.

ОТОХ, це набагато краще, ніж пошук тексту MySQL, який навіть не вказує слова з трьох літер або менше. Це за замовчуванням для пошуку MediaWiki, і я дійсно думаю, що це не корисно для кінцевих користувачів: http://www.searchtools.com/analysis/mediawiki-search/

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

для SHAILI - SOLR включає в себе бібліотеку кодів люценівського пошуку і має компоненти, які будуть приємною автономною пошуковою системою.


1
Я вважаю, що в повнотекстовому пошуку PostgreSQL ви посилаєтесь Tsearch. Але Цесар не підтримує пошук фрази. Це все ще є у їхньому списку TODO sai.msu.su/~megera/wiki/FTS_Todo .
Гнанам

1
Щойно зробили купу тестування на повнотекстовому пошуку Postgres 9.0; був розчарований, виявивши, що текст французькою мовою не відповідає, якщо користувач забуде отримати всі акценти правильно. Відповідність словоформ є невід'ємною - наприклад, англійською мовою "сказати" не відповідає тексту, що містить "сказав". В цілому досить вражаючий, хоча для інтегрованої функції на всіх тестованих мовах (en, fr, ru).
Роман Старков

9
@romkyns: вам потрібно встановити словник непристойних, щоб викреслити їх.
Дені де Бернарді

2
"OTOH, це набагато краще, ніж пошук тексту MySQL, який навіть не вказує слова з трьох літер або менше." Це не вбудоване обмеження MySQL - це все, що ви встановили у конфігураційному файлі. Якщо ви хочете проіндексувати однолітерні слова, просто змініть одне значення в конфігу.
Canuck

1
Турбує те, що люди порівнюють бази даних, які ще не вивчили повністю. MySQL МОЖУТЬ індексувати слова з трьома символами або меншими - ви просто повинні їх правильно налаштувати.
TheCarver

22

Просто два мої центи на це дуже давнє запитання. Настійно рекомендую поглянути на ElasticSearch .

Elasticsearch - це сервер пошуку, заснований на Lucene. Він надає повнотекстовий пошуковий механізм, що підтримує багатосторонніх даних, з RESTful веб-інтерфейсом та документами JSON без схем. Elasticsearch розроблений на Java і випускається як відкритий код на умовах ліцензії Apache.

Перевагами перед іншими двигунами FTS (повнотекстовий пошук) є:

  • RESTful інтерфейс
  • Краща масштабованість
  • Велика громада
  • Побудовано розробниками Lucene
  • Докладна документація
  • Доступно багато бібліотек з відкритим кодом (включаючи Django)

Ми використовуємо цю пошукову систему в нашому проекті і дуже задоволені нею.


10

SearchTools-Avi сказав: "Пошук тексту в MySQL, який не вказує навіть слова з трьох літер або менше".

FYI, довжина хвилини повного тексту MySQL може регулюватися, оскільки принаймні MySQL 5.0. Прості інструкції Google "mysql fulltext min length".

При цьому, повний текст MySQL має обмеження: для одного він оновлюється повільно, коли ви досягнете мільйона записів або близько того, ...


2

Я б додав mnoGoSearch до списку. Надзвичайно ефективне і гнучке рішення, яке працює як Google: індексатор отримує дані з кількох сайтів, ви можете використовувати основні критерії або вигадувати власні гачки, щоб мати максимальну якість пошуку. Крім того, він може отримувати дані безпосередньо з бази даних.

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

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

Оскільки ви використовуєте рамку Django, ви можете використовувати або PHP-клієнт посередині, або знайти рішення в Python, я побачив деякі статті .

І, звичайно, mnoGoSearch є відкритим кодом, GNU GPL.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.