Поиск пользователей в БД, как эффективнее?

Question

[delletenebre]

Доброго времени суток. Есть таблица с ~5000 пользователей, нужно оптимизировать поиск по данным записям: пользователь вводит несколько символов и из БД динамически выгружается список совпадений. Наиболее близкий пример — Диалоги Хабра, поле «Введите имя пользователя».

Инструменты: MySQL, PHP.

В голову пришли два решения:

1) AJAX'ом отправлять по keyup (например) значение поля и делать запрос LIKE %%. Как по мне, это будет сильно напрягать MySQL;

2) Создать static переменную, в которую при первом обращении выгрузить все записи, и потом средствами PHP искать совпадения. Для PHP не сложно будет работать с таким массивом (повторюсь ~5000 записей + дополнительные поля, типа id и т.п.)?

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

Заранее спасибо.

Answer 1

[EugeneOZ]

Вы можете держать содержимое php-переменной всё время, пока юзер вводит данные? То есть у Вас PHP-запрос может висеть в памяти бесконечно долго? Такое редко бывает.
Я бы закэшировал в Redis и оттуда таскал. Есть long-polling — по long-polling, нет — по key-up. При добавлении юзера — обновлять кэш.

Comments

[subvillion]

Redis хорошее решение, но мне кажется, в данном случае, его функционал избыточен. По-моему достаточно традиционного memcache.

[EugeneOZ]

subvillion, Redis не заставляет использовать сразу весь его функционал и от memcached в простоте использования не отличается. В данном случае я не рискнул бы применять memcached, т.к. есть шанс упереться в лимит по размеру хранимого значения.

[delletenebre]

Спасибо, буду копать в эту сторону

[Tramvai]

Можно еще не просто по key-up, а через некоторый промежуток после key-up, если ничего далее пользователь не нажимает. Например, нажал пользователь 3 буквы и ждет, вот один запрос и генерировался, а не 3. Это снизит количество лишних запросов.

[delletenebre]

Tramvai, keyup был упомянут как обобщение. Согласен, нужна задержка, кстати, для этих целей мне подошёл TypeWatch.

Answer 2

[lightsgoout]

5000 записей это не много, обычного ajax-запроса и LIKE %% должно быть достаточно.

Comments

[WEBIVAN]

+1, 5000 это очень маленький объем. База его даже не заметит.
Но если уж очень хочется не грузить базу — отдайте все 5000 и обрабатывайте в JS на стороне пользователя.

[FilimoniC]

Мобильники скажут вам спасибо )

[delletenebre]

Да, согласен с Вами, но тут проблема не столько в производительности запросов, сколько в их количестве.

Answer 3

[Степан]

Почему бы не попробовать Sphinx?
Один раз настроил и будь там хоть 500к пользователей, sphinx довольно быстро справится с этим.

Answer 4

[Igor]

Кешируем данные в виде id:name в файл на диск. При запросе подгружаем файл и делаем поиск. Ноль запросов к БД. Кеш обновляем при добавлении нового пользователя или обновлении пользователя.

Comments

[Евгений]

сменить файлы на диске с удобным интерфейсом/доступом (бд) на просто файл где данные хранятся в куче?

Answer 5

[merlin-vrn]

Так готовые решения есть. Мы пробовали, работает на базе из как раз нескольких тысяч наименований (hardworm поправит меня, если я ошибаюсь). Использовали мы Ajax Autocomplete for jQuery.

Что касается запроса к таблице из ~5000 наименований — так то ни для какой базы не работа, при условии, что по соответствующему полю есть индекс.

Comments

[delletenebre]

Спасибо за ответы.

Я, наверное, неправильно выразился. Под «напрягом» MySQL имелось в виду количество запросов к БД, а не скорость их выполнения.

[merlin-vrn]

А какая разница, сколько их, если они выполняются быстро?

[Hint]

Индекс не используется на запросах LIKE %name%.

[merlin-vrn]

На LIKE name% используется. Что, в случае логинов, гораздо вероятнее.

Answer 6

[zednight]

А еще можно ajax + sphinx и полнотекстовый поиск и базу почти не грузит, но это уже радикальное решение :-)

Answer 7

[Roman Revin]

Преждевременная оптимизация — корень всех зол. © Кнут

Обычного запроса достаточно. Если у Вас вырастет нагрузка до такого размера, что БД будет падать от селекта, то тут уже включать кеширование.