Как быстрее выбрать изображения из БД (mysql php)?

Question

[Traney]

Проектирую движок аукциона. (высоконагруженную систему)
Имеем 2 таблицы Лот и Изображения. На одном лоте может быть до 10 изображений.

Как быстрее будет и менее ресурсоемко для сервера:

1. Связь Один ко многим. Лот -< Изображения.

В таблице Лота есть поля: Ид., Название, описание, цена...
В таблице Изображения: Ид., Ид.Лота, путь...

2. Связь не принципиальна

В таблице Лота: Ид., Название, описание, цена, строка с Ид. Изображений ('1001, 1002,..')
В таблице Изображений Ид., путь.

Вопрос: Быстрее делать выборку через JOIN с двух таблиц. Или средствами php делать выборку id-шников изображений. и потом брать из таблицы их (без JOIN).

Допустим: в базе 100 000 лотов и 500 000 изображений.
и при 50 000 000 лотов и 100 000 000 изображений.

Можете кидать ссылки на статьи. Можете советовать другие варианты. Но должно летать!
Заранее спасибо!

Answer 1

[_ _]

Отличные советы вам дал человек в очках. Храните изображения в базе, доставайте их оттуда скриптом, из скрипта отдавайте! Зачем нам реверс-прокси, энджиниксы всякие.
А по поводу вашего вопроса - самое правильное, это взять PostgreSQL, где есть типизированный массив в качестве типа столбца.
А если без него, то я бы сериализовал массив имен файлов и пихал их в поле типа text, потому что:
- вероятней всего вы не будете использовать одно изображение в нескольких лотах
- вы не будете выполнять поиск по названиям файлов изображений
В этом случае вы избавлены от накладного запроса в БД для получения изображений - получили запись, десериализовали массив имен и все, можете отдавать.

Comments

[Александр Литвинов]

@AMar4enko В вашем решении есть ряд проблем. 1) Файлы не подчиняются удалению. 2) Файлы не подчиняются локализации транзакции 3) Файлы не подчиняются операции отката 4) Файлы не подчиняются инструментам резервного копирования базы данных. 5) Файлы не подчиняются правам доступа SQL 6) Файлы не являются типами данных SQL. Для хайлоада мое решение не годится, но для ряда типовых проектов оно может быть лучшим. Собственно как я и написал. Ваше решение тоже есть в той книге, в разделе анти-паттернов.

[_ _]

Оно не годится никуда вообще. Это выхолощенный академический пример. Если нужна права доступа, удаление, версионирование, локализация - хранятся индентификаторы, сами файлы с метаданными в отдельной таблице.
Если вы считаете, что подвергать резервному копированию 100 Гб базу с картинками внутри, вместо 1 Гб данных + инкрементальный бэкап статических файлов через rsync, то мне вас жаль, правда.
Ну и напоследок, раскажите мне, как вы с вашими картинками будете организовывать кластер базы данных, таская туда сюда эти картинки.

[Александр Литвинов]

@AMar4enko У меня такое ощущение, что из всего ответа вы прочитали лишь два слова "Хранить BLOB". Все поднятые вами проблемы решаются и в ответе есть ссылки. (Не на всех проектах есть такие проблемы или будут) И не нужно доставать картинки через скрипты.. Смотрите в сторону специализированного Storage Engine и как пример FILESTREAM. Думаю ваше решение было бы лучше, если добавить User-Defined Functions для контроля целостности, но вероятно будут проблемы с поддержкой.

Answer 2

[Андрей]

Небольшой лайфхак - вам надо шардить картиночки, иначе при 100М картинок в одной папочке произойдет что-то очень плохое. Поэтому вижу такой вариант - делаете структуру папок примерно как:

images/
            001/
                   <id лота нач. на 001>/
                                                     все картинки лота
            002/
                   <id лота нач. на 002>/
                                                     все картинки лота

Тогда вы сможете по id лота получить все картиночки, вообще не дергая БД. Ну и сможете со временем изменить схему шардирования. Сможете даже разнести картинки по разным серверам, если понадобится, то есть получите горизонтально масштабируемую архитектуру.

Comments

[Magnum72]

И небольшое дополнение к вышесказанному: В таблице лотов сделать бинарное поле в котором отмечать какие картинки прикреплены к лоту, т. е. например есть 2 типа картинки: фас, профиль, храним бинарную маску 11 если обе картинки присутствуют, либо храним 01 в случае картинки профиля. Это позволит лишний раз не проверять наличие файла на диске.

Answer 3

[Виталий Желтяков]

Все данные пишите в одну таблицу (да, будет большая таблица с кучей полей). Изображения храните в виде файлов с именами в виде id. Это бесспорно самый быстрый вариант

Answer 4

[Сергей]

Правильно понял, что вам нужно вывести на странице несколько лотов с картинками?
Храните в 2-х таблицах и выбирайте 2-мя запросами, 2-й с id IN (...).
В postgresql могли бы использовать array_agg + JOIN и выбирать всё одним запросом. Но тут тоже лучше бенчмаркать что лучше - 2 запроса или один, но с JOIN и аггрегацией.

Answer 5

[Андрей Ежгуров]

Быстрее всего будет работать вариант, когда имена файлов изображений хранятся непосредственно в таблице "лот" - чтобы JOIN вообще не было. Будет ли это 10 полей типа VARCHAR, или одно поле, хранящее сериализованный массив - не принципиально.

Но хранить, разумеется, надо именно имена файлов, а не сами файлы.

@kaasius прав в том, что картинки надо раскидывать по множеству папок. Но должно быть 2 уровня папок, а не один и в механизме распределения он ошибается. Раскидывать надо не по id, а случайным образом. Например, взять md5(uniqid($id_лота, true)) и первые 3 символа использовать в качестве имени папки, а следующие 3 - в качестве имени подпапки. Получится что-то вроде /images/48e/da3/имя_файла.