5 млн файлов JSON или DB?

Question

[just_dev]

Привет, комьюнити! Прошу ваших мнений по вопросу.

Дано: пишу API которое при обращении к метому /get_user_data/ должно возвращать JSON с данными по пользователю. Важно - данные не изменяются, то есть требуется только их прочитать и вернуть, никаких запросов на запись\удаление\изменение.

Всего около 5 млн записей.

Варианты:
1) хранить в DB вида id | json_string_data
2) залить на CDN 5 млн JSON и читать их, динамически меняя урл ../data/{id}.json

Вопрос: что будет быстрее\менее ресурсоёмко по нагрузке?

Уточнения:
1) данные не критичны с т.ч. безопасности если вдруг кто-то получит доступ ко всей папке.
2) на CDN отключен листинг фалов и чтобы найти папку вида ../g7G47yqhry&h/data/.. надо ооочень постараться.
3) почему не давать просто прямую ссылку на JSON и не пилить API - конечный пользователь не должен знать источник данных + авторизация, которая осуществляется на стороне того сервиса который будет обращаться к API, т.е. некое разграничение прав доступа всё же реализуется но не на стороне API.

Спасибо за ваши мнения и помощь!

Comments

[Everything_is_bad]

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

Answer 1

[Rsa97]

Если по записям нет никакого поиска и всегда точно известно (вычислимо) имя файла, то база данных не нужна. Заливка на CDN тоже не имеет смысла, поскольку ваш API будет на одном сервере, а не разбросан по миру. Проще всего в этом случае хранить все файлы локально на API-сервере.

Comments

[Сергей П]

Добавлю, что для реализации такого на файлах достаточно чистого nginx. Если сервер на ssd, то всё будет быстро и без CDN

[just_dev]

Сергей П, спасибо, а можно в двух словах про реализацию на чистом nginx?

[just_dev]

Rsa97, спасибо за ответ.

[VoidVolker]

just_dev https://docs.nginx.com/nginx/admin-guide/web-serve...

[Олег]

Сергей П,@Rsa97,@VoidVolker
Тут только один момент. Сама файловая система сдохнуть может. Папку с милионом файлов даже команда ls открывает часами.
Раскладывать файлы нужно гдето по тысяче в подпапке.
Пусть имя json файла это UUID (0-9a-f)
16 в 4ой степени = 2в16 должно хватить с запасом
Так что по первым 3-4 буквам создаем дерево хранения

[Rsa97]

Олег, Ну, это достаточно стандартно. Для UUID можно по первым символам

/00/0D/55/47/000D5547-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json

[Олег]

Rsa97, но вопрошавший скорее не в курсе проблемы большого числа файлов. самый Очевидный момент не озвучен был.

[just_dev]

Олег, совершенно верно, спасибо что указали на этот существеный аспект.

[Сергей П]

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

[Олег]

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

[Сергей П]

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

Answer 2

[Everything_is_not_so_bad]

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

данные не изменяются

а через год-два так же?
Если "обойтись" файлами и CDN, то все данные пользователей могут утечь в интернет и быть проиндексированы поисковиками.
Если будет реализовано через файлы, то есть высокий шанс того, что файлы будут скачивать в обход систем авторизации. Так что на свой страх и риск.

5 млн файлов

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

Comments

[just_dev]

Спасибо за подробный комментарий.

Answer 3

[mayton2019]

Файловая система - самый дешевый способ хранения инфы. Если других требований нет - почему бы и нет?

Comments

[Валентин Бируля]

А редис тут не вариант?

[mayton2019]

Валентин Бируля, редис скорее всего будет дороже по суммарной стоимости владения. Это инстанс. Занимает память. И его надо хостить и оплачивать. Тарификация идет даже в состоянии покоя. Задача неактивна а вы все равно платите.

[fasvik]

mayton2019, редис можно запускать локально на сервере. Мне казалось что это самый популярный вариант запуска, разве нет?

[mayton2019]

fasvik, у Редиса и у файловой системы типа S3/BlobStorage есть матрица фич. И мы не можем провести объективное сравнение этих двух вещей. Здесь нет лучше или хуже. Здесь есть число фич, слева и справа и некое экспертное решение на основе максимального соотвествия.