include в php большого файла

БД однозначно. В ней и мильены записей держи, нагрузки не будет существенной, нежели в файле держать

Снипеты от видео и файлы на серверах от этого видео я храню в БД... А вот стоп-лист я не догадался сразу в БД писать, да я как то не ожидал что их будет столько много...

Виктор Горняков, спасибо за совет!

А я не любитель подключать лишние БД или вообще БД без острой на то необходимости.

Я бы просто немного поменял логику хранения в файлах в зависимости от примерного предполагаемого количества таких id, сделав, например, хранение всех id, начинающихся (заканчивающихся) на 25, в файле с именем 25s.dat. Ну Вы поняли, количество необходимых элементов для поиска и объём загружаемого файла уменьшаются в 100 раз примерно (можно и в 1000, да хоть в 100 000). Вроде способ тупой, "в лоб", но у меня так много чего работает моментально, без БД, используя минимум памяти.

Зачем?

Это дело времени. Когда сайт разрастается до крупных масштабов - порой поздно переделывать, лучше на начальном этапе БД создать. Это чисто моё мнение.

Да, это тоже вариант отсортировать айдишники по первому символу и распихать по разным файлам, я как то использовал нечто подобное, но там проще было только цифры в айдишнике. Спасибо!

Ну я например знаю подобный сайт с 10м посещалки в сутки... Значит это кому то надо!

Зависит от того, как именно вы проверяете наличие нужной записи в файле.

Зачастую файл заметно лучше БД. Иногда лучше SQLite, иногда - реляционная СУБД, а иногда и не реляционная.

Один из худших, но распространенных в мире PHP способов - зачитать файл в память, заполнить строками условный массив и искать по этому массиву.

Трафика море

Например? Применительно к задаче? При хранении большого обьема данных, при необходимости быстрого доступа, например по индексу, чем?

Я наверное не понял, Имеешь ввиду что SQLlite  не реляционная?

Когда? Как-то все ответы не подтверждены.

Например, если ТС будет хранить данные в NoSQL DB like MongoDB, он получит самый быстрый доступ по хэшу обьекта, остальные способы не сравнятся. Но проиграют по памяти

Про преимущества файлов.

В стартпосте речь идёт о YouTube. Мне приходилось писать утилиту для работы с его API. Для работы с ним характерны большие объемы данных и низкая финансовая прибыльность. Заказчики подобных проектов зачастую не готовы и не умеют работать с БД, которые уже на старте проекта достигают размеров в районе 200-300 Гб. Не могут ни сделать бэкап ни развернуть его.
С текстовым файловым хранилищем, особенно партиционированным, всё намного проще. Повредить его сложно. Восстановить легко. Протестировать или модифицировать легко. Получается аналог portable софта, работать с которым может человек без подготовки.

В моём тезисе про SQLite и альтернативы не было противопоставления. Придирка ни о чём. 

Mongo многим приходит в голову, когда нужно быстро искать по чему-то вроде ID и хранить привязанную к каждой такой записи неопределенную кучу разнородных данных. Для YT это может быть актуально. А может и не быть. Зависит от потребностей и планов бизнеса.

Конкретно для случая ОПа, до сотни миллионов записей я для начала попробовал бы сделать именно партиционированные текстовые файлы. Например, по двум первым "буквам" ID, если он гарантированно ASCII буквенно-цифровой. Искал бы построчным чтением с брейком в случае нахождения строки. С хорошим объемом RAM файлы будут в кеше ОС и всё должно быть быстро. А писал бы обычным для Unix 'my str' >> /target/file.txt.

Но всё нужно тестировать. И для  конкретно этой задачи тестирование альтернатив не выглядит проблемой. Для проверки эффективности каждого подхода должно хватить не более сотни строк кода.

Про подтверждение ответов. 

Это вообще к чему? Я тут не кандидатскую защищаю, а развлекаюсь на форуме. Как захотел, так и написал. Не нравится - напиши лучше 👍