Из flat-file в итоге пришел к Grav. Так как принцип архитектуры понятен, код понятен тоже.

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

>>268
Анон(ы), объясните, что значит flat-file?
Почитал немного, понял только то, что данные хранятся не в базе, а на диске в текстовых файлах. А какие это профиты дает? Это гибрид статик-сайт-генератора типа джекила, только с мородой для редактирования? Или как?

>>263 (OP)

>ссылок 2-3 млн с разбивкой по категориям гдето 0,5 ляма.

>импортнул категории - вордпрес умер

А что значит умер? И в каком виде вообще у тебя хранится информация? И в каком виде ты хочешь каталогизировать 500кк категорий? Они вообще плоские или древовидные? Если древовидные, то сколько на верхнем уровне, какой уровень вложенности?
(Просто вообще неск.млн это не очень большой объем, проблема либо в том как хранится и какие индексы проставлены, либо в том как делаются выборки.)

>>280

>что значит flat-file

Ну это значить что у тебя нет:

1) БД, ибо file

2) Разбивки контента по каким-то хитрым алгоритмам, ибо flat.

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

>>300
А что оно умеет?
Просто в базе как правило таблица=тип контента (товар, статья, вотэвар), со свойствами. Есть свойства = есть фильтрация.
А тут я могу себе представить только либо хранение статей по подпапкам. Либо, если оно умеет больше, то должно быть эти файлы будут в хитрых форматах со всяким вспомогательным службеным стафом в еще одних файлах.
У статик-сайт-генераторов есть для этого относительно стандартизированная yaml-нотация в md-файдах и подобие БД в yaml-файлах.

>>301

>А что оно умеет?

>есть для этого относительно стандартизированная yaml-нотация в md-файдах и подобие БД в yaml-файлах

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

Насколько оно быстро будет для реально сложносоподчиненных типов материалов? Тут вопросики - надо пробовать и тискать.

Но в целом мне очень понравилось что создатели Grav не стали изобретать коня и сразу пошли по пути того самого Drupal - где как известно можно категоризировать что угодно на свете - даже небо, даже Аллаха.

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

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

>>302
Благодарю, анон. Да, это интересно. Жаль нет времени посмотреть толком.

>>303
А эта задача, что ты решаешь - это твой проект или для дяди и поэтому ты в дедлайне?

>>280

>данные хранятся не в базе, а на диске в текстовых файлах. А какие это профиты

Это тебя избавит от огромных запросов в БД (а они в Вордпрессе будут всегда), цени

У нее были слишком большие запросы...
— Привет.
— Привет.
— Как там ваши дела с Наташей? Еще не поженились?
— Нет, мы расстались.
— А что случилось?
— Мне надоело, у нее были слишком большие запросы.
— Например какие?
— Ну например update instance inner join (select group.id as group_id, (select message.id from message inner join thread on thread.id = message.thread_id where location_id = @location_id and language_id = @language_id and concat(group_key, '.') like concat(group.`key`, '.%') order by message.created desc limit 1) as last_message_id, (select count(*) from thread where location_id = @location_id and language_id = @language_id and concat(group_key, '.') like concat(group.`key`, '.%')) as thread_count, (select if(sum(thread.message_count) is null, 0, sum(thread.message_count)) from thread where location_id = @location_id and language_id = @language_id and concat(group_key, '.') like concat(group.`key`, '.%')) as message_count from group where @group_key like concat(`key`, '.%')) as statistics on statistics.group_id = instance.group_id set instance.message_id = statistics.last_message_id, instance.thread_count = statistics.thread_count, instance.message_count = statistics.message_count where instance.location_id = @location_id and instance.language_id = @language_id;

>>263 (OP)
Дело тут не в CMS, а в БАЗЕ ДАННЫХ. Нужно было брать NoSQL базу данных, которая может держать любое количество данных, без шардинга. Flat file цмс - это полный бред, поскольку генерация такого объёма файлов будет занимать целую вечность. И надо будет каждый раз пересобирать этот сайт, что неудобно.