Нагрузка на сервер. Что больше?

[Йода]

Atomic, умгу.

[Atomic]

НУ а что касается картинок - мой выбор, я прекрасно понимаю схему работы LAMP, но сделал такой финт в угоду удобства вставки, редактирования, удаления статей(контента).

[Йода]

Atomic, да я ж тебя жизни не учу, дружище
Каждый сходит с ума как умеет, включая меня.

[Alexey]

Чего-то вы все в одну кучу сбросили: картинки, каталог, статьи... Естественно, что такими темпами к общему мнению не прийти.

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

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

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

Вот и вся магия. Остальное - эксплуатирование этих двух принципов.

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


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

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

[ahsinis]

БД вообще-то еще "следит" за данными
Попробуйте на файлах транзакции и блокировки строк сделать.
Использование файлов или БД вообще-то зависит от поставленной задачи.

[Alexey]

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

[seocore]

Сообщение от Русская мафия

Что больше нагрузит сервер? Если я буду контент читать из файлов или из БД? И что во сколько раз лучше, примерно?(в 1.1 раза, в 2 раза, в 3, в 10, в 100)

все зависит от "криворукости" программера, а именно - если у тебя будет папка, в которой 90к мелких файликов, то это будет грузить сервер больше (при условии, что на сервере не SAS+SSD в качестве диска) ...

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

а вообще надо меньше обращаться к БД, хранить все часто используемое в кешах на диске, но при этом хорошо прорабатывать структуру папок, стараться не создавать более 1к файлов в папке, чтобы не создавать большие iowait'ы при чтении, т.е. делать папки /cache/s/sa/sape.txt...

и вообще много много тонкостей, можно еще вспомнить APC/xcache/eaccelerator/memcached, а связка memcached+nginx + php-скрипт по крону (генерируется index.html и складывается в memcached'ы разных машин кластера, откуда напрямую забирается nginx'ом) вообще не использует БД и файлики...

т.е. все зависит от конкретных задач

[Atomic]

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

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

[seocore]

Сообщение от Atomic

здесь позволю немного не согласиться, если картинки лежат в отдельной таблице и используется команда OPTIMIZE TABLE ..., то проблема фрагментации решается на ура

а кто спорит, только сколько отнимет OPTIMIZE TABLE ресурсов? - и как часто его делать? - а если в минуту идет по 100 INSERT'ов в эту таблицу, то разумно ли вообще делать

все зависит от конкретного случая

[Русская мафия]

Ух страсти бушуют))

Моя вина, не уточнил что мне нужно. Итак, имеем:

Есть много ГС, есть обычный хостинг. Нужно оптимизировать ГС, чтобы больше ГС влезло на один хостинг)) Влезло, это означает выдержать набеги сапы и поисковиков, посетителей нет.

Один сайт - 500 стр контента(текста)
К каждой статье есть 3 параметра - заголовок, краткий текст, полный текст.

Два варианта реализации:

1.
Эти данные храним в БД, в одной записе один заголовок, один крат. текст, один полный текст.
При обращении к странице обращаемся к данной записи и выводим всё.
2.
Эти данные храним в текстовых файлах.
Для одной статьи - файл с названием, файл с кратким текстом, файл с полным текстом(хотел всё это в один файл запихнуть, но пока это писал понял, что как я тогда на главной буду выводить 10 последних статей(название + крат. текст))
При обращении к странице выводим содержимое трёх файлов

Вобщем что создаст меньшую нагрузку?(нагрузку, на скорость обращения пофиг)

Пока это писал придумал вообще офигенный метод, так что если он прокатит, то это не нужно уже)))) Но всё равно подскажите плиз