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

Question

Я ищу самый быстрый / самый эффективный способ поиска, если данное имя пользователя доступно из набора десятков миллионов имен пользователей. В данный момент я использую обычный запрос MySQL SELECT, который запускает каждое нажатие клавиши, но я не доволен производительностью. Я использую индексирование, разбиение и т. Д., И я знаю, что MySQL можно оптимизировать, чтобы он был очень быстрым, но я также знаю, что есть лучшие решения.

Итак, какой самый быстрый поиск по имени пользователя:

• Команда Redis EXISTS
• Elasticsearch
• Что-то еще

Пример: как Gmail выполняет поиск по миллиардам адресов электронной почты при регистрации. Как это делает Facebook? Я предполагаю, что они не просто запускают SQL-запрос.

Я ищу практическое решение для приложения PHP.

Сейчас я просто использую очень простой выбор:

SELECT username FROM users WHERE username = $username LIMIT 1

Столбец имени пользователя имеет уникальный индекс

Answer 1

Я согласен, что вы должны попытаться вставить все это в оперативную память (например, Redis).

Но если вы не хотите идти до конца, я делаю следующее: сохраняйте список где-то медленно (например,S3 или база данных SQL).Затем создайте фильтр Блума (там есть материал в Википедии, и есть отличный модуль Redis, который вы можете использовать - https://oss.redislabs.com/redisbloom) из этого списка.

Теперь, BF говорит, что никогда не даст вамложный отрицательный результат, чтобы вы могли эффективно проверить, доступно ли имя пользователя. Однако иногда BF сообщает имя пользователя как недоступное (ложный положительный результат), и вы решаете, можете ли вы жить с этим.

Answer 2

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

Давайте предположим, как гигантская компания обращается к любому имени пользователя среди миллиардов:

Есть служба, вероятно написанная на C, даже не C ++

Развертывается в кластере Unix или Linux

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

Служба загружает все данные (обычно имя пользователя и пароль) в память

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

Когда для данных требуется вызов (в нашем случае), существует 2 (минимум) асинхронных вызова для двух копий средства проверки работоспособности (во избежание задержек в обслуживании), когда основная служба активна

Когда любая проверка работоспособности отвечает нормально, происходит звонок в главную службу (проверки), и проверяется или нет запрашиваемое имя пользователя и / или пароль.

Затем вызывающий абонент непрерывно отвечает в ответ.

В заключение, любое решение, максимально приближенное к этому, работает быстро. Память 'db', такая как redis, как упомянуто выше, несколько близка - значит, достаточно близка, учитывая различия. Если колоссальная компания получает производительность 10, а простой веб-сайт - 8-9, используя аналогичные методы, следуя тем же принципам, с затратами, скорректированными на размер каждой компании, то я считаю, что это удачный выбор.

Answer 3

Загрузка списка в ассоциативный массив. Проверьте наличие ключа. Готово. «Десятки миллионов» в наши дни не так много данных. Он помещается в оперативной памяти.

Если у вас мало памяти и вы не возражаете против астрономически малой вероятности ложного срабатывания, вы можете использовать хэш SHA2-256 вместо полного значения. Это только 40 байтов в шестнадцатеричном формате, 20 байтов в необработанном виде. Проверка, был ли проиндексирован хеш-ключ, тривиален, даже O (1) время во многих случаях.

Помните, что это актуально, только если вы имеете дело с пиковыми нагрузками, превышающими 1000 запросов в секунду. Не преждевременно оптимизируйте это. Большинство баз данных могут выполнять тестирование имени пользователя практически за нулевое время, это даже не сложно, и выполнение тысячи тестов в секунду не сломает ваш сервер.

Если у вас есть проблема измеримой производительности , то вы всегда можете изучить варианты индексирования. MySQL поддерживает разные типы индексов : BTREE или HASH. Они работают по-разному.