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

По этому небольшому пункту напомню, что энтропию ID в данной задаче обеспечивает YouTube. Зато моя "хеш-функция" позволяет сразу понять в каком файле искать нужный ID при необходимости.

Если смотреть не по конкретной задаче, а с академическим интересом, у вас много исследовательских мыслей. Однако многие из них напоминают задачи, уже решенные создателями файловых систем. Вероятно, вернувшись к решению с несколькими тысячами "обычных" текстовых файлов, мы почти не потеряем в производительности. Зато не будет привязки к конкретной реализации ФС, в плане ожидаемого поведения.

При использовании необычных решений есть вероятность столкнуться с багами самих файловых систем. Например, лучшая, на мой взляд, из файловыйх систем общего назначения, ext4 может показывать необычное поведение при высокой вложенности каталогов и/или при наличии порядка ста тысяч-миллиона файлов в одном каталоге. Возможно, это описано мануалах или спецификации, но нужен эксперт по ФС, а это редкость. Хотя формально там и " Unlimited number of subdirectories" и "Max n of files 4billions".

Для бизнеса, связанного с социальными медиа, обычная картина - отсутствие как самого IT-отдела, так и опыта и даже желания связываться с "большим IT".

Представьте медиапродюсера среднего уровня, которому нужна система с данными по YouTube. Гигабайтов на 200. Он хочет периодически смотреть там статистику, аналитику, прогнозы, тренды и что-то еще по своим интересам.

Что он хочет получить - три сервера с приложением (бэкенд/фронтенд), БД, slave-БД?
Срок изготовления - полгода. Стоимость условно USD 85.990 и еще USD 15.000 на поддержку в будущем. 
Где он ничего не сможет сделать сам, кроме пользования интерфейсом.

Либо приложение на одном сервере, с использованием файлового хранилища.
С веб-интерфейсом либо тонким клиентом. Быстро работающее. Срок изготовления 5-7 дней.
С возможностью лёгкого и быстрого полного бэкапа zip-архива либо scp/rsync-ом (если умеет), либо через тонкий клиент.
С возможностью развернуть самому с помощью пошаговой инструкции на двух листах А4, выполнить которую проще, чем собрать мини-набор Lego. Или через тонкий клиент (дороже).
Стоимостью в 5-7k USD, а в некоторых странах намного дешевле, если найдется подходящий фрилансер.

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

SSD в сервере нужен. Более того, обычно нужен RAID-0. Это не слишком дорого.

А бэкап базы MySQL в случаях если нет slave и данных много, я бы рекомендовал делать по частям, по одной или несколько таблиц.

Del pls. Невнимательно прочитал один из ответов.

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

Хранение данных - Однозначно PostgreSQL.  Она соответствует принципам ACID, но позволяет гибко к ним относиться, в частности I-solation доктрина - я  могу отступить и позволить чтение  данных во время записи. Но в данном случае это неважно. Для надежности - настраивается репликация, которая и бэкап и масштабирование одновременно.

Бэкенд - скорее всего это будет FastApi приложение, полностью RESTful, что бы не было в дальнейшем проблем с расширением. Ну и конечно же помним про принципы SOLID -  именно для этого. 

На фронте  -  скорее всего React, хотя на старте можно прикрутить шаблонизатор Jinja2 прямо в FastApi и не заморачиваться особо, 

Что мы получим:

Простое АПИ, легко масштабируемое. Мне не нужно заморачиваться с созданием файловой системы и ее целостностью. Изначально делаю дизайн базы данных. Любое изменение обеспечено миграциями, я люблю Alembic, но тут кому что, хоть руками пиши. Заходел заказчик добавить какую-то инфу в базу или новую выборку - никаких проблем.

Теперь переходим к главному пункту споров - как это все легко будет разворачиваться и поддерживаться? 

Я Все ваши эти ваши VPS/VDS считаю пережитком прошлого. Облака - наше все. В моем случае это будет Амазон, конечно же. собрать инфраструктуру - ну наверное полдня с нуля, а потом все это добавляется в terraform и не нужно быть девопсом высокгого класса, чтоб это развернуть. Достаточно получить креды и стартануть локально скрипт башевский - инструкция на страницу! 

А при желании разобраться - что проще чем читать YML- файл? Это всяко легче чем выолнять линуксовые команды. Вот пример кода, который поднимет базу, уверен что даже тот кто это счас прочитает впервые, поймет что там происходит.

resource "aws_db_instance" "fastapi-db" {
  allocated_storage    = 5
  storage_type         = "gp2"
  instance_class       = "db.t3.micro"
  identifier           = "fastapi-db"
  engine               = "postgres"
  engine_version       = "14"
  parameter_group_name = "default.postgres14"

  username = var.db_username
  password = var.db_password
  db_name = "postgres"

  vpc_security_group_ids = [aws_security_group.sg-postgres.id]
  publicly_accessible    = true # Only for testing!
  skip_final_snapshot    = true
}

Никаких пошаговых инструкций не будет, кроме как получить креды. Все разворачивание полностью  автоматическое. Репозиторий из гитхаба и CI/CD.

Все это собрать будет однозначно быстрее для меня возни с файловой системой.  По цене - точно не дороже. 

Если бы не намечающаяся на сегодня пьянка с друзьями - к понедельнику бы выкатил бы POC, через неделю MVP.

Даже интересно стало - за сколько бы я такое реализовал.

Так что не вижу никаких преимуществ ни по одному из пунктов решения с файловой системой. Особенно на миллионах записей

всё-таки Гленливет победил меня вчера :)

Так я и не претендую на оригинальность. Например, эта идея отлично отражена в реализации модуля nginx proxy_cache_path. Там вложенность, вроде, ограничена 3-мя уровнями.

Странное заявление. Какие еще два просмотра в час?
Мой основной профиль - приложения от сотни RPS или автономных операций с вычислениями.

В последнее время меня удивляют типичные реакции людей в интернете. Какое-то тотальное недоверие всех ко всем.

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

Разве что хотелось бы видеть конструктивные комментарии по сути вопроса, а не оценочные предположения.

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

Вот еще аи сюда приплетем:

База данных с master-slave имеет ряд преимуществ перед файловой базой в упрощенном поиске по айди:

• Производительность: база данных с master-slave может обеспечить более высокую производительность при большом количестве запросов, поскольку чтение данных может выполняться одновременно с нескольких серверов.
• Надежность: база данных с master-slave более надежна, чем файловая база, поскольку данные хранятся на нескольких серверах. В случае отказа одного сервера данные все равно будут доступны.
• Масштабируемость: база данных с master-slave легко масштабируется, поскольку можно добавлять дополнительные серверы по мере необходимости.

Файловая база в упрощенном поиске по айди имеет ряд преимуществ перед базой данных с master-slave:

• Простота: файловая база в упрощенном поиске по айди проще в настройке и управлении, чем база данных с master-slave.
• Стоимость: файловая база в упрощенном поиске по айди может быть дешевле, чем база данных с master-slave, поскольку не требует специального оборудования или программного обеспечения.

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

Конечно, я тоже использую СУБД и понимаю их преимущества.

Выше по треду - рассуждения по сути вопроса ОПа, на тему могут ли хранилища данных на базе текстовых файлов работать быстро. И основной вывод - да, могут работать быстро. Для хранения и поиска YouTubeID скорее всего подойдут. Видел подобное в парсерах для хранения ID обработанных записей.

Не могу остановиться, так заинтересовался этой темой. По итогу написал себе скрипт, который делает поиск по файлу значений. Конечно все условно, поставил следующие лимиты. Адрес - 5-ти значное число. Храниться в 

в файле значения неотсортированы. Пример скрипта на пайтона -

import os
import random
import time
from functools import wraps


def timer(func):
    """ Return calc time of execution wrapped function"""
    @wraps(func)
    def wrapper(self, *args, **kwargs):
        start = time.time()
        result = func(self, *args, **kwargs)
        print(f"Execution time: {time.time() - start}")
        return result
    return wrapper


class SimpleFinder:

    def __init__(self):
        pass

    def add_ip(self):
        name = random.randint(40000, 49999)
        # name = 49342
        print(f"Function started. got Ip: {name}")
        file_name = self.get_filename(name)
        if self._if_exist(file_name):
            # print(f"File {file_name} exists")
            self.add_butch(file_name, name)
        else:
            # print(f"File {file_name} does not exists")
            self.create_butch(file_name, name)
    
    def get_filename(self, name):
        first_name = str(int(name / 10000))
        return "".join((first_name, "0000"))
    
    def _if_exist(self, filename):
        files_list = (os.listdir("file_finder/storage"))
        if filename in files_list:
            return True
        return False
    
    def create_butch(self, file_name, name):
        with open(f"file_finder/storage/{file_name}", "w+") as f:
            f.write(str(name))
            f.write(" ")

    def add_butch(self, file_name, name):
        with open(f"file_finder/storage/{file_name}", "a+") as f:
            f.write(str(name))
            f.write(" ")

    @timer
    def find_ip(self, name):
        filename = self.get_filename(name)
        if filename:
            print(f"Found file {filename} for checking ip {name}")
            with open(f"file_finder/storage/{filename}") as f:
                data_ip = f.read()
                if data_ip:
                    ip_list = data_ip.split(' ')
                    print(f"Count of records: {len(ip_list)}")
                    if str(name) in ip_list:
                        print(f"This ip({name}) was blocked for download")
                        return
        print(f"This ip({name}) can be download!!!")


if __name__ == "__main__":

    # res = SimpleFinder()
    # res.add_ip()
    print(timer.__doc__)
    print("="*120)
    print("Start script")
    # for i in range(100000):
    #     res = SimpleFinder()
    #     res.add_ip()
    # SimpleFinder().add_ip()
    res = SimpleFinder().find_ip(49342)

Результат выполнения для поиска по файлу с примерно полмиллиона записей:

Start script
Found file 40000 for checking ip 49342
Count of records: 433209
This ip(49342) was blocked for download
Execution time: 0.04430103302001953

Это локально, без всяких HTTP запросов, на 4-х ядерном core i5 10gen 16RAM
Мне кажется, сопоставимо со скоростью запроса в БД. Может и имеет место быть такой подход