Пагинация страниц: архитектура

Вроде, сделал пагинацию. На файлах. Можно изменить максимальный размер файлов пагинации, тогда, при записи очередного сообщения, вначале будет пере-пагинация, т.е. файлы с сообщениями будут, возможно, сформированы заново, а потом в последний файл будет добавлено сообщение. Т.е. можно управлять "динамически" максимальным размером файлов. Ну, и т.д.
Но, вот вопрос. О счетчике общего количества сообщений. Он у меня - только в последнем файле (т.е. там, где содержатся последние сообщения). Понятно, что при добавлении очередного сообщения он будет увеличен на 1. При удалении - уменьшен на 1. Здесь все без проблем.
НО: как быть, если сообщение будет удалено не из последнего файла пагинации, а из ЛЮБОГО? Пока вижу такие возможные варианты:
1. При каждом удалении сообщения обязательно корректировать счетчик сообщений (а это - лишняя операция с последним файлом пагинации, т.е. доп. нагрузка на сервер). Впрочем, удаление старых сообщений (из предыдущих файлов пагинации) делается не столь часто...
2. Реализовать счетчик сообщений в дополнительном (маленьком) подключаемом файле. Но, это - лишний файл в файловой системе севера для КАЖДОЙ страницы, у которой имеются файлы пагинации с сообщениями. Как-то тоже - такое себе решение... Хотя, если эти файлы будут храниться где-то в отдельном каталоге - может, почему бы и нет?...
3. Хранить количество сообщений не только в последнем, но и во всех файлах пагинации для соответствующей страницы (в каком-нибудь теге). Но, это еще хуже, чем п.1, 2, т.к. при очередном добавлении/удалении сообщения придется вносить изменения не только в последний, но и во все файлы пагинации (ну, или, для экономии, применить аналогию метода кворума при репликации, только в рамках одного сервера).
4. Создать нечто типа "базы данных" (может, даже на MySQL) по всем веб-страницам сервера и "проиндексировать" их, в том числе, по количеству сообщений. Т.е. расширенный аналог п.2. Правда, при этом придется каждый раз при добавлении/удалении сообщений вносить изменения в этот файл, а он, конечно, будет достаточно большим. Т.е. гораздо хуже по производительности, чем п.1, 2.
А какой еще м.б. вариант?

Добавлено через 14 минут
Мне кажется, способы по п.1, 2 будут наиболее производительными при текущей работе с сообщениями (добавить/исправить/удалить). Но, способ по п.4 - более функционален, т.к. в одном файле будет храниться вся управляющая информация по всем вебстраницам. А это удобно, например, при выводе всех сообщений одного или группы пользователей, при управлении ими. А если по п.2 - это придется просматривать ВСЕ файлы с сообщениями (ибо пользователь мог оставить сообщение где угодно, где сможет). Это - ОЧЕНЬ затратно.

Добавлено через 28 минут
Например, пусть есть условные 30.000 страниц на сервере. Соответственно, на каждую из них, в среднем, 3 условных файла пагинации с сообщениями. Объем каждого из них, например, не более 100 кБ.
В итоге, оставляли сообщения 10.000 пользователей. По каждому пользователю хранится информация (ник, пароль, т.д.) в общем объеме не более 1 кБ.
Общий объем файла управляющей информации (по п.4) составит не более 10.000*1 = 10.000 кБ = 10 МБ.

Если же по п.1, 2, то при выводе всех сообщений одного пользователя придется, в общем случае, просматривать 30.000*3 = 90.000 файлов пагинации. Объем данных, среди которых придется искать то, что относится к конкретному пользователю, составит до
90.000*100 = 9000.000 кБ.
На это потратится очень много времени. Т.е., похоже, п.1,2 - нереальны для мало-мальски серьезного сайта. Быстрее просмотреть 10 МБ в ОДНОМ файле, чем 9 ГБ, да еще в разных.

Добавлено через 1 час 6 минут

Сообщение от Htext не более 1 кБ

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

Добавлено через 28 минут
Т.е. выходит, что п.3, 4 - слишком затратны, а выигрыша в дополнительной функциональности не дают.
Из п.1, 2 в среднем наиболее быстрый - это п.1. С учетом того, что удаление старых сообщений происходит достаточно редко.
Если иного варианта не будет, пожалуй, на нем.

0

Сообщение от sad67man топовые сайты построены исключительно на файлах для высокой производительности

Вполне возможно. Ибо SSI.

0

Сообщение от Htext Или пишем в кэш и записываем в файлы (тоже периодически).

СУБД это программа. БД = файлы.

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

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

В одиночку вы не сможете разработать хорошее функциональное универсальное решение. Но опыт получите бесценный.

Добавлено через 2 минуты

Сообщение от Htext Вполне возможно. Ибо SSI.

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

У нас nginx - и в качестве балансировщика нагрузки (ну точнее несколько nginx-серверов), и статику он отдает, и архивы он же отдает (он умеет их на лету формировать). Ну а для всего остального - Apache и PHP.

0

Сообщение от liris Если у вас статичный сайт

Статико-динамический. Т.е. чтение, выдача браузеру готовых страниц осуществляется в основном в "почти статическом" режиме, без РНР вообще. Т.е. суть именно в этом. Почему файлы.
А вот для уточнения контента на странице - там включается в работу РНР (например, для работы с сообщениями). Или если нужно сделать статистику, карту сайта, отправка оповещений, административные функции, т.д. - тоже РНР.

Добавлено через 9 минут

Сообщение от liris Если у вас файлы структурированы и есть некоторый программный код, который управляет этой структурой

Именно так. Архитектура есть, да. Возможно, неидеальная.

Сообщение от liris полный бред для 90% задач

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

Сообщение от liris В одиночку вы не сможете разработать хорошее функциональное универсальное решение

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

0

Сообщение от Htext Статико-динамический. Т.е. чтение, выдача браузеру готовых страниц осуществляется в основном в "почти статическом" режиме, без РНР вообще.

Это как? Почти не бывает. Или nginx выдает сразу в виде статического файла который читает прямо с диска, или проксирует на модуль php и уже после обработки выдает в браузер.

0

Сообщение от Htext Статико-динамический

Нельзя быть "немножко беременной". Это называется динамический сайт.

Сообщение от Htext Если это - обычный сайт, типа этого форума, к примеру.

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

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

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

Сообщение от Htext Но, я по крайней мере не допущу серьезных багов-уязвимостей (точнее, наверное, не допущу...). Наслышан об уязвимостях БД раньше, лет 10 назад. О стенаниях владельцев сайтов на предмет взломов их сайтов...

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

0

Сообщение от liris Нельзя быть "немножко беременной". Это называется динамический сайт.

Файловый кэш с "прямым доступом" или просто гибрид, в котором какие-то страницы являются статическими в прямом смысле слова.

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

1

Сообщение от estic Файловый кэш с "прямым доступом"

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

0

Сообщение от liris В крупных проектах такие страницы почти всегда есть.

Можно пример?

0

Сообщение от estic Можно пример?

Легко. Допустим у нас интернет-магазин. В нем все страницы динамические. Но есть несколько "справочных" страниц (контакты, доставка, оплата, гарантия, лицензионное соглашение и т.д.). Их можно смело делать статическими (многие CMS умеют это делать "из коробки" или плагинами).

Формируем статическую html-страницу. В настройках веб-сервера (например для Apache можно создать правило в .htaccess) прописываем, что при обращении к странице /help/payment или /help/warranty - отдаем эти страницы (не запуская php-интерпретатор, не подключаясь к БД и т.д.).

0

Сообщение от liris Легко. Допустим у нас интернет-магазин.

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

0

Сообщение от liris Формируем статическую html-страницу.

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

0

Сообщение от estic они выносятся на отдельный хост

Зачем?

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

0

Сообщение от POSE Я у себя делаю что-то похожее.

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

Добавлено через 7 минут

Сообщение от liris Зачем?

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

2

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

Да? Надо попробовать. Что-то я не подумал об этом. Читать с помощью file_get_contents ?

Добавлено через 14 минут
estic, спасибо за совет. Я уже сбегал и проверил на сайте
Конечно, изменений в скорости я не заметил, но доверюсь тебе.

0

Сообщение от POSE Читать с помощью file_get_contents ?

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

Добавлено через 5 минут

Сообщение от POSE Конечно, изменений в скорости я не заметил, но доверюсь тебе.

Я бы удивился, если бы заметили. Но все равно не нужно динамически компилировать echo 'data', когда можно загрузить файл и сделать echo $data.

1

Сообщение от estic не нужно динамически компилировать echo 'data', когда можно загрузить файл и сделать echo $data.

Понятно. Просто как-то не подумал об этом. Сделал... работает... и забыл. Еще раз спасибо.

0