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

Вроде, сделал пагинацию. На файлах. Можно изменить максимальный размер файлов пагинации, тогда, при записи очередного сообщения, вначале будет пере-пагинация, т.е. файлы с сообщениями будут, возможно, сформированы заново, а потом в последний файл будет добавлено сообщение. Т.е. можно управлять "динамически" максимальным размером файлов. Ну, и т.д.
Но, вот вопрос. О счетчике общего количества сообщений. Он у меня - только в последнем файле (т.е. там, где содержатся последние сообщения). Понятно, что при добавлении очередного сообщения он будет увеличен на 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 если нужно деактивировать (убрать из выдачи) по каким-либо условиям элеметы

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

Сообщение от sad67man добавить сортировку + фильтры

путем работы с файлами, как обычно. Правда, это будет долгая операция....... Т.е. если для админа (и т.п.) - это еще ладно. Но, если для всех - это будет, конечно, кошмар.

Эх... вот недавно один мой знакомый (точнее, теперь уже родственник) по-быстрому создал, для интереса, аналогичную БД - на 50 тыс. строк, 3 столбца. И, как estic (и как я на файлах) добавил 4-й. В итоге, вместо моих 0,5 сек. он получил 0,002 сек (5 миллисекунды). Правда, у него компьютер, конечно, побыстрее, чем мой. И он, похоже, добавлял одинаковые значения, а не как я - разные. Но, тем не менее - у него получилось быстрее почти на ДВА порядка.
В итоге я сильно задумался...

Мне вот что любопытно: добавление 4-го столбца в аналогичную БД с 30 тыс. строк - сколько времени займет? Если на обычном домашнем компьютере, который без особых наворотов.
Вот что я меня по тем трем способам получилось:

Миниатюры

 

0

И, кстати, у него получилось не 1...2 МБ (файл), как у меня, а 5 МБ (БД). Т.е. объем данных выше в 2 с лишним раза. Понимаю, ерунда.

0

Сообщение от Htext вместо моих 0,5 сек. он получил 0,002 сек (5 миллисекунды).

Ух, наконец-то(!) я нашел разгадку этому парадоксу: https://skillbox.ru/media/code... emennosti/
Я ведь везде запускал этот скрипт в РНР 5.3. А у знакомого - то ли 7, то ли 8. Да еще жесткий диск скоростной.
А база данных - в C#, а не в РНР. PostGre.
Как раз примерно на порядок-два и должно работать быстрее, чем у меня.

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

0

Сообщение от Htext Я ведь везде запускал этот скрипт в РНР 5.3. А у знакомого - то ли 7, то ли 8. Да еще жесткий диск скоростной.

софт и железо - влияет на работу. это матчасть. это знают те, кто от разработки софта далеки.

Сообщение от Htext А база данных - в C#, а не в РНР. PostGre.

с# 6/7 и php 7.4+ - между ними разницы сейчас особо нет (в плане скорости запросов и прочего).
помимо постгре, есть и другие базы, не хуже, а скоро даже и лучше будут.

0

Сообщение от Htext А я уж было СОВСЕМ огорчился и начал усиленно думать о том, что разработка файлах - это "устарело" и "медленно".

На мой взгляд у вас не показательное тестирование. Вот к примеру сравнивали скорость вставки. А у вас есть есть индексы, ключи, взаимосвязи, транзакции в вашем решении?

А есть БД заточенные на скорость вставки, если не ошибаюсь ClickHouse, если ее взять?

Между тем в большинстве проектов только вставка (без индексов и прочего) - не не самая популярная задача.

1

Сообщение от Htext Оказывается, совсем не в этом дело))

Если вам приятно так думать, то пожалуйста

Конечно, мультипликативный эффект никто не отменял, но и от основных принципов построения современных сайтов/сервисов никто отказываться не собирается

0

Как люди не тешатся, лишь бы БД не использовать

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

Но это всё будет далеко от скоростных БД.

Добавлено через 1 минуту
В общем по итогу, использовать файловую систему для хранения данных, которые подлежат постоянному обновлению - изменению, добавлению, сортировки - анализу и так далее. УЖАСНАЯ ИДЕЯ.

1

Сообщение от xkkx В общем по итогу, использовать файловую систему для хранения данных, которые подлежат постоянному обновлению - изменению, добавлению, сортировки - анализу и так далее. УЖАСНАЯ ИДЕЯ.

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

0

Сообщение от POSE Вроде движок Википедии так устроен.

Одно дело когда ты редактируешь html страницу в редакторе. Другое, когда ты неструктурированные файлы используешь в качестве БД

Сообщение от POSE Проще и удобнее при скроллинге подгружать новые данные, используя аякс.

Автор темы заявит что он будет грузить файл file_get_contents и использовать substr что бы достигнуть нужной позиции

0

Сообщение от xkkx Автор темы заявит что он будет грузить файл file_get_contents и использовать substr что бы достигнуть нужной позиции

Серьезно? Я честно говоря прочитал только заголовок. Лень читать длинные описания. Но, если действительно так - могу посоветовать только удачи. Она ему понадобится

0

Сообщение от POSE А от пагинации страниц я уже давно отказался.

Да вот вроде и гугл тоже от нее не в восторге. Я тоже немного сомневаюсь, на самом деле.

Сообщение от xkkx неструктурированные файлы

Похоже, Вы не в курсе дела.

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

Сообщение от estic от основных принципов построения современных сайтов/сервисов никто отказываться не собирается

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

0

Сообщение от Htext Похоже, Вы не в курсе дела.

Какого дела ? Бить массивы через implode и писать в файл ? Потом его читая через file засоряя всю оперативную память)))

У вас сервер быстро упадёт от нехватки оперативной памяти

Добавлено через 40 секунд

Сообщение от Htext производительность не намного хуже.

Отвратительная производительность, которая убьёт сервер очень быстро

Добавлено через 43 секунды

Сообщение от Htext С БД было бы несколько хуже.

Не придумывайте

0

Сообщение от Htext Лишь говорю, что на файлах можно получить производительность не намного хуже.

Возможно. Но для этого стоит очень и очень постараться. Люди которые занимались разработками СУБД продумали всё за нас. Ты же не будешь утверждать, что команды этих программистов некомпетентны? Лично я уверен, что не сделаю лучше, чем они. Поэтому буду пользоваться результатом их труда... тем более это бесплатно

0

Htext, Производительность тут ни причем - это просто плохое решение. Вам уже писали, что если нужна производительность то можно использовать кэширование (хоть на тех же файлах), либо noSql решения поверх СУБД.

0

Любая БД так или иначе представляет собой файл. Но вы тут дискутируете о производительности, а ведь она - не главное. Хоть и важное.
Если вам нужно просто сохранить N строк (или тысяч строк) текста - можно и в файлы писать. Если очень хочется.

СУБД создавались, потому что нужны были механизмы, обеспечивающие бОльшую функциональность. А именно - структурирование данных. Многопользовательский режим. Механизмы блокировок. Транзакции. Обеспечение целостности данных. И т.д.

Если ТСу всё это не нужно, а файлы полностью покрывают его задачи - ничего плохого в этом решении нет. Более того, именно при написании велосипедов мы часто получаем новый опыт.
При этом, советуя свой велосипед другим людям, будьте готовы, что ваше решение бренда "Made of shit and sticks" может оказаться неконкурентоспособным.
Ну а если при этом другие решения вы не рассматриваете не потому, что считаете свою реализацию лучше, а просто потому что не умеете ими пользоваться - фу таким быть.

1

Сообщение от Htext Я ведь не пытаюсь никого убедить в этом. Лишь говорю, что на файлах можно получить производительность не намного хуже

Да можно. Но это будет за счет жесткого ограничения функционала

1

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

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

На мой взгляд, тут есть некий перекос. ТС тратит уйму времени казалось бы на банальную задачу, при этом искусственно вводит множество ограничений, усложняя поддержку приложения (по сути делая ее бесполезной), аргументируя тем, что сохраняет некие затраты на ресурсы. И тут встает вопрос, если заказчик не в состоянии оплатить среднинький хостинг для поддержки СУБД, то что можно говорить об оплате труда программиста?

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

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

1

Сообщение от sad67man По предыдущим темам прослеживается

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

Если нужна производительность - это точно не про файлы. Самые быстрые решения используют буферы в ОЗУ, потому что даже запись в СУБД слишком медленная.
Как пример - счетчик просмотров страницы на highload-ресурсе. Он может обновляться несколько десятков (или сотен) раз в секунду. На тысячах страниц одновременно (разные счетчики на каждой). Если это всё писать в файлы - мы положим сервер за минуту. Если писать в СУБД - потеряем половину просмотров (из-за довольно большого времени записи), ну либо также выстроим огромную очередь запросов и положим сервер. Поэтому пишем в кеш и записываем в СУБД с некоторой периодичностью порционно.

0

Сообщение от liris Самые быстрые решения используют буферы в ОЗУ

Но ведь это надо много ОЗУ. При большой нагрузке на сайт - очень много.
Потом, вроде, буферизация в РНР включена по умолчанию?

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

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

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

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

Сообщение от liris Он может обновляться несколько десятков (или сотен) раз в секунду. На тысячах страниц одновременно (разные счетчики на каждой).

Хм... но это уже DOS-атака получается. До нескольких миллионов запросов в секунду...
Тут уж неважно, файлы, СУБД или т.п. - сервер просто не в состоянии будет принимать все запросы.
Да и нет необходимости столь часто обновлять счетчик(и). Раз в пару секунд от каждой страницы, уж не чаще.
Другое дело, если это - интерактивные действия пользователя в режиме реального времени (типа онлайн-игр). Но, там РНР уже, по-моему, слабо поможет. Там надо будет С++, java...

Сообщение от liris Поэтому пишем в кеш и записываем в СУБД

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

0

Сообщение от Htext Но ведь это надо много ОЗУ

Сравните стоимость одного часа работы квалифицированного программиста и стоимость одного гигабайта ОЗУ. Это раз.
Во-вторых вам не нужно складывать всю БД в озу. Вы храните лишь отдельные значения. Как правило довольно небольшие.
Если говорить о счетчике просмотров - насколько он тяжелый? Давайте возьмем 64 байта. Очень тяжелый. Не будем ограничиваться 32 байтами.

Допустим вместе с ним мы будем хранить указатель на ячейку, куда его надо записать. Допустим еще 64 байта. Ну и может быть какую-то служебную информацию. Например таймкод. Что-то еще. Пусть будет еще 128 байт.
Итого получаем 256 байт на один запрос (думаю что я взял сильно с запасом).
В одном гигабайте можно уместить - 4 * 1024 * 1024 = 4 194 304 записей. Как по мне - довольно недорого.

Сейчас в обычных (гражданских, не серверных) SSD можно встретить DRAM-буфер (по сути ОЗУ) на 512Мб. Который работает примерно по схожему принципу (быстро пишем данные в буфер, а потом плавно и медленно перезаписываем их в постоянное хранилище).

Сообщение от Htext Т.е. чтение уже готовых страниц.

Именно так это и реализуется. Если у вас статичный сайт - вы создаете статичные страницы, и настраиваете веб-сервер таким образом, чтобы он их отдавал, вообще не обращаясь ни к php, ни к БД. Это очень быстро и не создает нагрузку на сервер.

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

0