PHP:Кол-во запросов к MySQL и оптимизация кода

[Summoner]

Сейчас делаю свой сайт и не могу определиться с вот такими вещами:

• 1. Какое нормальное кол-во запросов к БД? (В данный момент у меня от 10 до 18 запросов)
  2. Имеет ли смысл использовать использовать длинные запросы к БД (Если я буду использовать длинные запросы к БД тот кол-во запросов падает от 5 до 12 ) и будет ли от этого толк?
  3. Имеет ли смысл хранить изображение в БД (К примеру приватные фотографии)?
  4. Какое нормальное время генерирования страници?

Хотелось бы узнать какое нормальное кол-во запросво к MySQL...

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[zg]

1. Какое нормальное кол-во запросов к БД? (В данный момент у меня от 10 до 18 запросов)

от пяти до двадцати (но лучше в пределах пяти - десяти)

2. Имеет ли смысл использовать использовать длинные запросы к БД (Если я буду использовать длинные запросы к БД тот кол-во запросов падает от 5 до 12 ) и будет ли от этого толк?

имеет - многотабличные запросы (до трёх таблиц) при правильной расстановке индексов творят чудеса производительности

3. Имеет ли смысл хранить изображение в БД (К примеру приватные фотографии)?

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

4. Какое нормальное время генерирования страници?

для сайта в пределах сотых, для портала в предела десятых секунды.

Хотелось бы узнать какое нормальное кол-во запросво к MySQL...

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

[MAK]

3. Имеет ли смысл хранить изображение в БД (К примеру приватные фотографии)?

Если имеется ввиду в блобе вся фотка - то не имеет. Зачем гонять сквозь базу килобайты данных?
Обычно сами фотки хранят на диске, в базе только информация для составления пути, права доступа, высота/ширина, данные из exif'a и прочая хрень.

[zg]

в блобе вся фотка - то не имеет

если бы можно было напрямую передавать поток апачу, то пофигу. В PMA сделали такое, но вот оно пока не работает. Поэтому перед выводом изображения его нужно сначало передать в переменную пхп, а потом только апачу, а это офигенные расходы памяти (хотя в принципе по современным меркам не так уж и много).

[MAK]

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

[zg]

зачем?

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

[MAK]

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

в любом случе это файл. а файлу самое место в файловой системе. ))
Но вобщем, да, есть случаи, когда это необходимо. Например считать количество просмотров/скачиваний. Или закопать туда пиздилку сессии.

зы. я там кстати отписал тебе про морфологию, ты наверно не увидел
http://forum.lissyara.su/viewtopic.php? ... 46#p115266

[Alex Keda]

зачем?

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

кто мешает сохранять логику?
т.е. мона замутить субдиректории по именам разделов и т.п....

[zg]

т.е. мона замутить субдиректории по именам разделов и т.п....

если файл удалить, то удалится ли запись в базе данных?

[Alex Keda]

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

[zg]

в данном случае - идёт комплект из двух объектов - файл+запись в БД

-))) слишком много букоф для ответа "да" или "нет". Вопрос поставлен, на мой взгляд, прямо.

Если удалить файл, то удалится ли запись в базе данных?

[zg]

зы. я там кстати отписал тебе про морфологию, ты наверно не увидел
http://forum.lissyara.su/viewtopic.php? ... 46#p115266

гут, посмотрю, но попозже

[Alex Keda]

в данном случае - идёт комплект из двух объектов - файл+запись в БД

-))) слишком много букоф для ответа "да" или "нет". Вопрос поставлен, на мой взгляд, прямо.

Если удалить файл, то удалится ли запись в базе данных?

нет.
но вы пытаетесь разделить единое на два и манипулировать ими отдельно.
============
с таким же успехом я могу спросить - есть таблица с автоинкрементом.
при удалении последней записи автоинкремент уменьшиться на один?
нет?! значит запись удалилась не до конца. остались последствия от того что она была.
тут - тоже самое. просто вы смотрите через призму искажённой логики.

[zg]

при удалении последней записи автоинкремент уменьшиться на один?

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

но вы пытаетесь разделить единое на два и манипулировать ими отдельно.

есть разные уровни данных. И есть такое понятие как целостность. То есть, если мы храним вложения в виде файлов, а информацию о них в виде строк базы данных, то каждое вложение получется разделённое. И всякий раз при использовании нужно будет проводить проверку целостности - а есть ли файл, которому соотвествует запись в базе? И наоборот - если есть файл, то ему должна соотвествовать запись в базе. Если файл или запись отсутствуют, то такое вложение не имеет смысла. Это нужно понимать. Хранение же вложения целиком в базе позволяет избежать этих проблем.

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

[MAK]

Но однозначно говорить о том, что тот или иной метод плох нельзя.

+1
Файлы в базе хороши до того момента, пока проект живет на одной машине и не упирается в ее производительность. Как только он вырасает из этих границ - придется эти 2 сущности разнести. Моя позиция такая - если проект имет цель и возможность вырасти более 1 сервера - лучше их сразу разнести.
Кстати, а как быдет выглядеть дами базы с мильеном жопегов внутри? )) Он и не сожмется-то толком. )

[Alex Keda]

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

[zg]

Он и не сожмется-то толком. )

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

Что такое уровни - это абстрактные изолированные пространства. Вы наверное слышали про семь уровней моделей OSI. Так вот этот же принцип используется и в программироании.

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

Весь этот венегрет прежде чем реализовать, расписывают на бумаге, а потом на UML'е. Дак вот, хранением файлов обычно занимется драйвер, который работает на самом низком уровне логической модели и ему абсолютно пофигу где хранить файлы, как и почему. Один драйвер по средствам универсального интерфейса предлагает одно хранилище, второй дарйвер другое хранилище, третий третье ии т.д. А ядро, котрое работает только с интерфейсами понятия не имеет как именно драйвер извлекает файл и информацию о нём и где лежит сам файл. Поэтому

Как только он вырасает из этих границ - придется эти 2 сущности разнести.

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

Кстати, а как быдет выглядеть дами базы с мильеном жопегов внутри? )) Он и не сожмется-то толком. )

как обычно - таблицы, а в них строк, строки, строки...

[Alex Keda]

>>Как только он вырасает из этих границ - придется эти 2 сущности разнести.
>это не имеет никакого смысла, потому что как только база разростается до неимоверных размеров - это проблемы базы, а не драйвера и тем более не ядра. Потому что уровень другой.
верно. это проблемы проектировщика.

[MAK]

zg, для рядового проекта, коих 99%, те многа_букав, которые ты нарисовал, имеют собой целью программирования ради программирования.
если вы хотите научится рисовать диаграммы в UML'е, научится абстрагировать АПИ от реализации(драйверы) - то вперед, ищите приличный UML-редактор, проектируйте и пишите одновременно несколько драйверов. сроки реализации этой задачи умножте как минимум на 4, и расскажите об этом своему заказчику или начальнику.

[zg]

zg, для рядового проекта, коих 99%, те многа_букав, которые ты нарисовал, имеют собой целью программирования ради программирования.

я видел проекты, которые разрабатывались людьми без этих знаний. Честно скажу, зрелище печальное и вполне допускаю, что 99% наших проектов (именно наших, у забугорных с этим намного лучше) являют собой такое же тихое безумие.

сроки реализации этой задачи умножте как минимум на 4, и расскажите об этом своему заказчику или начальнику.

это неважно. При проектировании сроки могут и не огавариваться. А начальника нет, как и заказчика

если вы хотите научится рисовать диаграммы в UML'е, научится абстрагировать АПИ от реализации

целью является не это. Ты рассуждаешь с точки зрения разработчика, а надо с точки зрения проекта.

[MAK]

какой-то оффтоп пошел... ) либо автор понял что мы пытались донести, либо еще больше запутался.
я надеюсь на первое.

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

[zg]

какой-то оффтоп пошел... )

ну а как без него родимого? -))) иначе совсем скучно будет

призывая разработчика рассуждать с точки зрения проекта.

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

не успеешь сделать ты -- сделают другие

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

один из первых критериев в современном веб-проекте

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

[MAK]

давай вернемся к файлам.
я около 4х лет назад реализовал на группе сайтов хранение файлов в файловой системе, а всю остальную инфу о них в бд.
было сразу понятно, что проект не вырастет "из" сервера. да и не было такой нужды.
без долго-нудного проектирования, без раскрасок UML, без "драйверов"(давай их так назовем).
по сути была создана табличка, папка, и алгоритм айди_файла -> путь(и обратно). все.
сейчас их(фоток) около 10 тыщ. всего-то.
работа над сайтами кипела еще около 2х лет, в этой работе приняло участие как минимум 3 человека. ни один из них не жаловался на отсутствие документации, красивых схем и прочей "довеске" к коду. был только единождыписаный(какое слово!)) код, который выполнял свою функцию.
я считаю, что здесь было оправдано применение такой схемы.

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

[zg]

что это единственная возможность не грузить сервер лишними потугами

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

ни один из них не жаловался на отсутствие документации, красивых схем и прочей "довеске" к коду

ну а сами они много написали документации? или столько же? -)))

через базу, в переменную, и только потом веб-серверу

как я уже писал, через PMA можно передать поток из MySQL напрямую апачу. Это не проблема.

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

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

[MAK]

Цель в данном случае сохранить целостность базы, а не разгрузить сервер. Мощность серверов растёт с каждым годом, на неё можно не ориентироваться.

мой провайдер за несколько лет не поменял ни железки ни тарифы. ( так что ко мне это не относится.

как я уже писал, через PMA можно передать поток из MySQL напрямую апачу. Это не проблема.

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

Банально чтобы считать скачки/просмотры, нужно обрабатывать запрос самому.

ну это вот пожалуй единственная причина пропускать файло через опу. ) и то с помощью js(а он работает на 90 с чем-то % браузерах) можно обойти и эту ситуацию.

короче есть 2 зла. 1) следить за целостностью, и 2) хранить файлы в бд.
из них я выбираю 1. потому что
1. это не такая большая проблема, при правильно описанном алгоритме преобразования ойди_файла(здесь может быть и имя и что угодно) в путь на сервере и обратно.
2. статические файлы на ура отдаются легким шустрым веб-сервером, например nginx'ом.
3. не надо пропускать кучу данных через мясорубку.