Насколько быстрее Postgres, чем MYSQL при полнотекстовом поиске?

Question

Я был пользователем MYSQL, никогда не пробовал Postgres.

Но у MYSQL узкое место при полнотекстовом поиске, когда набор данных огромен.

Answer 1

Несколько лет назад я провел тесты для больших наборов данных и обнаружил, что:

• MySQL FULLTEXT

работает довольно медленно.Другим недостатком является то, что он навязывает вам MyISAM, что создает много проблем.Кроме того, обновления индекса происходят довольно медленно, когда индекс достигает определенного размера: при вставке новой строки существенная часть индекса создается заново, иногда несколько сотен мегабайт индекса перезаписываются просто для вставки сообщения на форуме.Другими словами, это нормально для небольшого форума с несколькими МБ постов, но есть причина, по которой Википедия не использует его ...

• Полный текст PostgreSQL

Это примерно в 10-100 раз быстрее, чем полный текст MySQL, намного мощнее, суть быстро при вставках / обновлениях, никаких проблем с блокировками, другими словами, это вполне приличное решение.

Однако поиск замедляется, когданабор данных больше чем RAM из-за MVCC, postgres должен проверить видимость строк, нажав на кучу.Обратите внимание, что это может измениться в будущей версии.Если ваш запрос возвращает 10 строк, нет проблем.Однако, если вы хотите выбрать WHERE (полнотекстовый запрос) ORDER BY date LIMIT 10 и полный текст соответствует 10.000 строк, это может быть довольно медленным.Все еще быстрее, чем MySQL, но не той производительности, которую вы хотели бы.

• Xapian: Я проверял это, есть также Lucene и Sphinx, которые имеют хорошую репутацию.

Xapian делаетне должны соответствовать тем же ограничениям, что и база данных, поэтому она может сделать намного больше оптимизаций.Например, это модель параллелизма с несколькими записывающими устройствами для одного записывающего устройства, поэтому вам потребуется какая-то очередь обновлений для обновления индекса в фоновом режиме.Он также имеет свой собственный формат на диске.В результате он невероятно быстр, даже когда набор данных намного больше, чем ОЗУ, и особенно для сложных запросов, сопоставляющих множество строк с сортировками и возвращающих только самые релевантные.

Индекс огроментоже, вероятно, содержит много дублирующихся вещей.Следствием этого является то, что ему не нужно искать, чтобы извлечь материал.

В основном, когда Postgres начал атаковать стену IO-seek, MySQL был давно мертв, а Xapian продолжал быстро гореть.

Но он не так хорошо интегрирован в базу данных, так что это больше работы для использования.Это того стоит, если у вас огромный набор данных.Если это ваш случай, попробуйте, это удивительно.Если ваш набор данных помещается в ОЗУ, postgres будет работать с меньшими хлопотами.Также, если вы хотите объединить полнотекстовые запросы и запросы к базе данных, интеграция становится важной.

Answer 2

Хотя маловероятно, что в Postgres вы найдете существенное преимущество по сравнению с mysql, если не повредит протестировать. Тем не менее, ваша основная проблема, полнотекстовый поиск, лучше решать с помощью чего-то вроде Sphinx или Lucene . Я использовал Sphinx на работе и обнаружил, что он значительно превосходит встроенный полнотекстовый поиск mysql. Это также довольно легко интегрировать в существующие системы.

также см. php mysql полнотекстовый поиск: lucene, sphinx или? мой оригинальный вопрос (включая ссылки) о различных параметрах полнотекстового поиска

Answer 3

Как уже упоминалось ранее, он сильно отличается между наборами данных, рабочей нагрузкой и тем, как вы ее настраиваете.

Например, полнотекстовые индексы на основе GIN очень быстры для поиска, но очень медленны для вставки / обновления. Индексы на основе GIST медленнее для поиска (но все еще довольно быстро), но намного быстрее для вставки / обновления.

Если у вас нет необходимости в функциональности базы данных, я бы, вероятно, также посмотрел на sphinx или lucene для необработанной производительности. Наибольшим преимуществом интегрированного полнотекстового поиска в PostgreSQL является то, что он просто интегрирован. Имеет поддержку транзакций. Поддержка восстановления. Поддержка снимков. Все те вещи, которые имеют жизненно важное значение для базы данных. Но если вам не нужна функциональность db, решение, которое отбрасывает эти требования, скорее всего, быстрее.

Answer 4

Вы знаете, что есть только один ответ на это; и вам просто нужно попробовать это с вашим собственным набором данных.

Лично я был бы удивлен, если есть существенная разница, я подозреваю, что производительность такого рода вещей ограничена пропускной способностью ввода-вывода.