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

3

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

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

Ваш Ответ

4   ответа
3

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

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

Error: User Rate Limit Exceeded omg
Error: User Rate Limit Exceeded
Error: User Rate Limit Exceededpagetracer.com/2008/02/15/…Error: User Rate Limit Exceededwhatstheplot.com/blog/tag/lucene
Error: User Rate Limit Exceeded omg
Error: User Rate Limit Exceeded
3

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

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

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

0

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

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

Error: User Rate Limit Exceeded
10

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

  • MySQL FULLTEXT

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

  • PostgreSQL fulltext

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

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

  • Xapian : I tested this, there are also Lucene and Sphinx which have good reputation.

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

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

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

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

Похожие вопросы