Мне нужен каталог с ссылками всякими замутить.
т.е. куча страничек без картинок и прочей медиа.
Но проблема в том, что ссылок 2-3 млн.
И с разбивкой по категориям. Тоже гдето 0,5 ляма.
Сразу огрочу.
был вордпрес. были плагины. все дела.
импортнул категории - вордпрес умер.
Ну т.е. он не может поднять такой разрез.
Смотрю на легкие CMS(которые флат-файл).
есть тут Аноны, кто сталкивался?
(смотрел и выбирал тут https://cmsguide.info/directory/light
всё - говно или неудобное или ппц или вырвиглазный дезигн.)
Есть ли что, что может потянуть 3 ляма записей в разрезе полуляма категорий?
Или эта уйня только для портфолио и прочей мелкой хуйни? (да у меня вроде тоже мелкая хуйня, но ее много)_
Памажите. Посоветуйте.
И вроде как (не уверен) где-то они хвастались что можно реализовывать огромные многостраничные сайты. Попробуй. Отпиши о результате.
Анон(ы), объясните, что значит flat-file?
Почитал немного, понял только то, что данные хранятся не в базе, а на диске в текстовых файлах. А какие это профиты дает? Это гибрид статик-сайт-генератора типа джекила, только с мородой для редактирования? Или как?
>>138263 (OP)
>ссылок 2-3 млн с разбивкой по категориям гдето 0,5 ляма.
>импортнул категории - вордпрес умер
А что значит умер? И в каком виде вообще у тебя хранится информация? И в каком виде ты хочешь каталогизировать 500кк категорий? Они вообще плоские или древовидные? Если древовидные, то сколько на верхнем уровне, какой уровень вложенности?
(Просто вообще неск.млн это не очень большой объем, проблема либо в том как хранится и какие индексы проставлены, либо в том как делаются выборки.)
>что значит flat-file
Ну это значить что у тебя нет:
1) БД, ибо file
2) Разбивки контента по каким-то хитрым алгоритмам, ибо flat.
Ну т.е. контент твоих страниц абсолютно прозрачно отражает структуру твоего сайта. Для сравнения - зайди в БД сложной системы типа Drupal и попробуй пойми из каких частей собирается конкретная страница - немного охуеешь с непривычки.
А что оно умеет?
Просто в базе как правило таблица=тип контента (товар, статья, вотэвар), со свойствами. Есть свойства = есть фильтрация.
А тут я могу себе представить только либо хранение статей по подпапкам. Либо, если оно умеет больше, то должно быть эти файлы будут в хитрых форматах со всяким вспомогательным службеным стафом в еще одних файлах.
У статик-сайт-генераторов есть для этого относительно стандартизированная yaml-нотация в md-файдах и подобие БД в yaml-файлах.
>А что оно умеет?
>есть для этого относительно стандартизированная yaml-нотация в md-файдах и подобие БД в yaml-файлах
Ну вот тоже самое тот же Grav и умеет, там можно организовать стандартную категоризацию любого уровня с нуля, без заранее предопределенных страт деления контента.
Насколько оно быстро будет для реально сложносоподчиненных типов материалов? Тут вопросики - надо пробовать и тискать.
Но в целом мне очень понравилось что создатели Grav не стали изобретать коня и сразу пошли по пути того самого Drupal - где как известно можно категоризировать что угодно на свете - даже небо, даже Аллаха.
Плюс уже начали посматривать в сторону кастомных материалов - а это ещё одна киллер-фича при выборе CMS. Т.е. мы получаем мини-CMS без обвеса всяким дерьмом, но где искаропки упор на полностью кастомную структуру и типы материалов.
Так что всё что надо - смотреть на скорость работы. Чем тебе и советую заняться - изготовь стендик, нагенери (если ещё нет) тестовую массу контента да и прогони всю эту радость. Тем более для flat-file не нужно хитрого кода - обычный парсер-преобразователь накидай на PHP да и для каждого двигла перегони свои мильёны статей.
Благодарю, анон. Да, это интересно. Жаль нет времени посмотреть толком.
А эта задача, что ты решаешь - это твой проект или для дяди и поэтому ты в дедлайне?
>данные хранятся не в базе, а на диске в текстовых файлах. А какие это профиты
Это тебя избавит от огромных запросов в БД (а они в Вордпрессе будут всегда), цени
У нее были слишком большие запросы...
— Привет.
— Привет.
— Как там ваши дела с Наташей? Еще не поженились?
— Нет, мы расстались.
— А что случилось?
— Мне надоело, у нее были слишком большие запросы.
— Например какие?
— Ну например 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;
Я не знаю, ты может быть отвечаешь на вопрос "почему тормознутый вордпресс", но не на вопрос "в чем концептуальное преимущество флэт-файловых CMS".
У меня к сожалению так и не было времени с ними разобраться. Пока что я так понял, что это SSG + веб-морда для редактирования файлов. ЕСЛИ это так, то профиты:
- Деревянность: сайт = файлы-страницы, как в старые добрые времена. Доп.эффект - простота.
- Нетребовательность к хостингу.
- Скорость за счет раздачи статики (если это реально SSG, а не динамический рендер md-файлов).
Минусы (опять же, ЕСЛИ это так):
- Сайт реально статический. Поиск если возможен, то ограниченный. Фильтрация если возможна, то за счет параллельной классификации, которая требует преререндера альтернативной струтктуры сайта (грубо говоря если у статьи проставлены теги, то для каждого тега будет сгенерена отдельная папка с копиями/ссылками соотв. страниц). О динамических функциях типа каталога с фильтрацией и сортировкой речи не идет. А если вдруг такое есть, то это перебор файлов php-скриптом, который всосет даже у вордпрессной БД.
Но это моя догадка, повторюсь: хуй знает, что это такое на самом деле. Потому и спросил. Пока что мне никто ничего толком сказать не может кроме "нет БД".
Дело тут не в CMS, а в БАЗЕ ДАННЫХ. Нужно было брать NoSQL базу данных, которая может держать любое количество данных, без шардинга. Flat file цмс - это полный бред, поскольку генерация такого объёма файлов будет занимать целую вечность. И надо будет каждый раз пересобирать этот сайт, что неудобно.
А в чем разница c NoSQL когда речь о плоской таблице (тем более без шардинга)?