Насколько быстры cms на файлах при большом количестве файлов?

Question

[Ivan Petrov]

Хочу сделать простую cms на json файлах. Каждый json файл это как бы отдельная запись в бд.

Насколько быстро php работает с файлами? Допустим у меня будет 10 000 или 100 000 файлов, и при выводе одной записи мне нужно будет найти один файл среди этих ста тысяч.

Насколько медленно / быстро это будет по сравнению с mysql?

Answer 1

[Sanes]

При таком кол-ве файлов это будет глупо.

Comments

[xmoonlight]

Почему глупо? Поясни.

[SagePtr]

xmoonlight, как минимум, отсуствие индексирования

[xmoonlight]

SagePtr, а где про это написано, что не будет или будет индексирование?

[SagePtr]

xmoonlight, вначале вопроса)
"Хочу сделать простую cms"
Велосипедить индексы на JSON-файлах - ну такое себе в плане простоты

[xmoonlight]

SagePtr, у меня есть база в текстовике 300к записей. По ней выборка с нужным ID-шником происходит со скоростью прямого чтения одной строки из файла. Т.к. указатель чтения сразу знает куда перемещаться.

Answer 2

[Кирилл Несмеянов]

1) Не забудьте, что все эти 10к файлов НЕ должны лежать в одной и той же директории, т.к. это сказывается на производительности а при превышении N лимита (влом гуглить циферку) всё наеб... поломается, короче. Я бы брал crc32 (самый быстрый алгоритм хеширования) от идентификатора, например "h87dg283" и складывал соответственно в "~/articles/h8/7d/g283.json".
2) При подобном хранилище поиск может быть осуществлён лишь по идентификатору записи. Т.е. что-то вроде "select * from articles where id = ?". Любые дальнейшие улучшения требуют больших накладных ресурсов. А реализация чего-то вроде поиска по записям будет физически невозможна (возможно, кончено, но писать такую шнягу придётся очень долго, а что-то вроде Sphinx к такому не прикрутить).

В остальном не вижу никаких особых проблем.

Answer 3

[xmoonlight]

Всё зависит от реализации структуры хранения и алгоритма поиска в этом хранилище.
Если всё сделать грамотно - это будет однозначно быстрее, чем mysql.
Но, это только разговор про чтение!
Пруф: Dokuwiki - работает без БД, на файловом хранилище.

Если Вам нужна модификация/выборка данных - лучше, всё-таки, использовать БД.

Comments

[Sanes]

MySQL всё же проще кешировать, нежели файлы.

[xmoonlight]

Sanes, зачем кешировать то, что не меняется?

[Sanes]

xmoonlight, прочитать из ОЗУ быстрее, чем с диска.

[xmoonlight]

Sanes, а какая разница при чтении из ОЗУ при работе с файлами или mysql?
Можно вообще смонтировать файловую структуру в ОЗУ при старте веб-сервера.
Что сложного-то здесь?

[Кирилл Несмеянов]

Sanes, а что если я скажу, что у MySQL есть драйвер таблиц, который хранит всё в памяти? Он так и называется, MEMORY =)

Кеширование на редисе/тарантуле нужно лишь для выборки нормализованных данных. Т.е. где с десяток всяких джоинов нужно со сложными запросами. А если же данных просто очень много, то обычно переходят на Elastic/Clickhouse/Hadoop в зависимости от задач. Из практики: Для примера, обычная выборка из MySQL по PK с одним GROUP BY на ~5-6 миллионов записей в кластере из 2х машин занимала ~17 секунд. Данные о посещаемости нескольких сайтов за один-два года. После переноса оных в ClickHouse скорость возросла до ~0.5 (одна машина), а повторный запрос уже ~0.1 (походу прогрев кеша). Так что стату можно было уже строить "на горячую", без промежуточной денормализации.

[Sanes]

Кирилл Несмеянов, к хранению в файлах как это относится?

[Кирилл Несмеянов]

Sanes, это просто оффтоп на тему "кеширование не нужно". А к хранению всего в файлах относится непосредственно мой ответ к статье.