эффективное автозаполнение на стороне сервера - PullRequest
Новая
       16

эффективное автозаполнение на стороне сервера

8 голосов
/ 08 января 2010

Прежде всего, все, что я знаю:

Преждевременная оптимизация - корень всего зла

Но я думаю, что неправильное автозаполнение действительно может взорвать ваш сайт.

Я хотел бы знать, существуют ли какие-либо библиотеки, которые могут эффективно выполнять автозаполнение (на стороне сервера), которые предпочтительно могут помещаться в ОЗУ (для лучшей производительности). Таким образом, нет автозаполнения javascript в браузере (yui / jquery / dojo). Я думаю, что есть достаточно темы об этом на stackoverflow. Но я не смог найти хорошую ветку об этом в stackoverflow (возможно, выглядел не достаточно хорошо).

Например, автозаполнение имен: 

names:[alfred, miathe, .., ..]

Что я могу придумать:

  • простой SQL, например: SELECT name FROM users WHERE name LIKE al%.
    • Я думаю, что эта реализация взорвется множеством одновременно работающих пользователей или большим набором данных, но, возможно, я ошибаюсь, поэтому числа (которые можно обработать) были бы классными.
  • Используя что-то вроде терминов solr, например: http://localhost:8983/solr/terms?terms.fl=name&terms.sort=index&terms.prefix=al&wt=json&omitHeader=true.
    • Я не знаю производительности этого, поэтому, пожалуйста, скажите пользователям с большими сайтами.
  • Может быть, что-то вроде восстановления памяти , на котором я также не тестировал производительность.
  • Я также читал в этой теме о том, как реализовать это в Java (Lucene и некоторые библиотеки, созданные Shilad)

Что я хотел бы услышать, так это то, что сайты используют реализацию, и цифры того, насколько хорошо он может справиться с нагрузкой, предпочтительнее:

  • Ссылка на реализацию или код.
  • числа, до которых вы знаете, что оно может масштабироваться.
  • Было бы неплохо, если бы он мог быть принят через http или сокеты.

Большое спасибо,
Альфред

Ответы [ 3 ]

10 голосов
/ 21 января 2010

Оптимизация для автозаполнения

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

LIKE-запросы не будут слишком сильно напрягать вашу базу данных, если вы проводите время, используя EXPLAIN или профилировщик, чтобы показать вам, как оптимизатор запросов планирует выполнить ваш запрос.

Некоторые основы, которые следует иметь в виду:

  • Индексы: убедитесь, что у вас настроены индексы. (Да, во многих случаях LIKE использует индексы. На myitforum есть отличная статья на эту тему. Производительность SQL - индексы и предложение LIKE ).

  • Объединения: убедитесь, что ваши СОЕДИНЕНИЯ на месте и оптимизированы планировщиком запросов. SQL Server Profiler может помочь с этим. Ищите полный индекс или полное сканирование таблицы

Автозаполнение подмножеств

Автозаполнение запросов является особым случаем, в котором они обычно работают как всегда уменьшающиеся подмножества.

  • 'name' LIKE 'a%' (может вернуть 10000 записей)
  • 'name' LIKE 'al% '(может вернуть 500 записей)
  • 'name' LIKE 'ala%' (может вернуть 75 записей)
  • 'name' LIKE 'alan%' (может вернуть 20 записей)

Если вы возвращаете весь набор результатов для запроса 1, то нет необходимости снова обращаться к базе данных для следующих наборов результатов, поскольку они являются подмножеством вашего исходного запроса.

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

6 голосов
/ 21 января 2010

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

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

  • Используйте простой SQL, например, например: SELECT name FROM users WHERE name LIKE al%., но используйте TOP 100, чтобы ограничить количество результатов.
  • Кэшировать результаты и вести список терминов, которые кэшируются
  • Когда приходит новый запрос, сначала проверьте в списке, есть ли у вас термин (или часть термина в кеше).
  • Имейте в виду, что ваши кэшированные результаты ограничены, некоторые из них могут понадобиться для выполнения SQL-запроса, если термин остается действительным в конце результата (я имею в виду действительный, если последний результат соответствует термину.

Надеюсь, это поможет.

1 голос
/ 27 января 2010

Использование SQL и компонента терминов Solr на самом деле не сравнение. По своей сути они решают проблему таким же образом, создав индекс, а затем просто вызывая его.

То, что я хотел бы знать, это «то, что вы пытаетесь выполнить автоматически».

В конечном счете, самый простой и надежный способ масштабирования системы - это найти простое решение, а затем просто масштабировать систему путем репликации данных. Попытки кешировать вызовы или предсказать результаты только усложняют ситуацию и не доходят до сути проблемы (т. Е. Вы можете до сих пор их обрабатывать, например, если каждый запрос пропускает кеш).

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

...