Я большой поклонник простых решений и поэтому предпочитаю - для простых задач - плоское хранилище файлов. Реляционная БД с ее возможностями индексирования совсем не поможет вам с произвольными шаблонами регулярных выражений, а кэширование файловой системы в любом случае гарантирует, что этот довольно маленький файл находится в памяти. Я бы пошел по плоскому файлу + perl route.
Edit: (taking your new information into account) Если на самом деле речь идет только о поиске подстроки в одном известном атрибуте, то использование полнотекстового индекса (который предоставляет БД) поможет вам немного (в зависимости от типа применяемого индекса) и может обеспечить легкий и достаточно быстрое решение, которое соответствует вашим требованиям. Конечно, вы можете самостоятельно реализовать индекс в файловой системе, например, используя вариацию Suffix Tree , которую трудно победить по скорости.
Тем не менее, я бы пошел по пути простого файла (и если он соответствует вашей цели, посмотрите на awk), потому что, если бы вы начали его реализовывать, вы бы уже закончили;) Далее я подозреваю, что количество пользователей, о которых вы говорите, не заставит систему почувствовать разницу (ваш процессор все равно будет скучать большую часть времени).
Если вы не уверены, просто попробуйте! Внедрите это решение regex + perl, если вы знаете perl, вам потребуется несколько минут, зацикливайтесь 100 раз и измеряйте с помощью time. Если это достаточно быстро, используйте его, если нет, рассмотрите другое решение. Вы должны иметь в виду, что ваши 50 000 уникальных линий на самом деле невелики с точки зрения современных вычислений. (сравните с этим: Оптимизация индексации таблиц Mysql для запросов на подстроки )
НТН,
александр