ModX и несколько миллионов ресурсов
Привет! Подскажите, ModX подходит для нескольких миллионов ресурсов (или minishop-товаров)? Знаете ли примеры ModX-сайтов с таким количеством ресурсов/товаров?
Комментарии: 17
Авторизуйтесь или зарегистрируйтесь, чтобы оставлять комментарии.
Наверное будут проблемы с таблицами в бд.
В общем, на ресурсах с такими объёмами далеко не уедешь. Тут либо создавать свою альтернативу ресурсам, либо использовать другие технологии вообще.
Очень жаль, что на родненький ModX нельзя рассчитывать. С SeoFilter вообще, наверное, не откроется?..
Разделение на разных категорий по разным сайтам с разными БД (site.ru/cat1/, site.ru/cat2/) будет одним из вариантов решений?
Но, думается, что хранить в родной таблице страницы не выйдет…
seoFilter думается сам застрелится еще на этапе установки)
Из базы вытаскиваются только уникальные значения, если на миллион ресурсов — значений уникальны штук 100, то ничего страшного.
А если миллион — то да, застрелится))
Но если отказаться от стандартных ресурсов Modx, вынести товары в отдельную таблицу — тогда взлетит.
Надо продумать свою таблицу с товарами так, чтобы все поля были оптимизированными и адаптированными под ваши нужды. Чтобы не было ни одного лишнего поля. Зато чтобы все опции товаров были в той же таблице (чтобы не делать отдельный запрос в другую таблицу на фронте).
После этого можно конечно сгенерировать модель таблицы, но работать с ней практически не прийдётся, каждый запрос нужно будет оптимизировать по-максимому. Для этого пишешь свои сниппеты для работы с твоей таблицей, где выполняешь чистый SQL-код, по этому образцу.
Вообще при таких объёмах, каждый запрос нужно будет оптимизировать. Выигрывать миллисекунды прийдётся и за счёт Fenoma и файловых элементов.
В итоге, в админке мы имеем только основные страницы и категории, а все миллионы товаров в своей таблице оптимизированной по-максимому. Админка будет работать шустро, а для управления товарами из своей таблицы можно будет сделать отдельную заточенную админку, в закрытом разделе сайта.
Ну и конечно же сервер должен соответствовать объёмам, на обычном хостинге это не запустится, лучше арендовать сервер.
Но если сильно надо, то можно.
1. перейти на минишоп- там тв можно в опции-они работают быстрее, но большинство для ms2 модулей — платные и все равно 1 шт =объект поэтому сильно быстрей не будет, но будет сильно дороже :)
2. оптимизировать модх движок.
— самое простое — выкинуть id и индекс из таблицы тв значений — она там не нужна и сделать индекс по value(10), сразу будет на 3-7% быстрее.
— доп.поля хранить не в тв. а добавлять столбцы к таблице ресурсов- своими ф-ями, будет что-то вроде минишопа. Но поля в осн. таблице поддерживаются всеми. есть минусы: типы: число/строка и знач. по умолч=0.
Но можно списки писать строками [raz,dva,tri] — и можно их сортировать и фильтровать, но это не очень удобно.
— переписать пол движка модх- заменить одиночные процедуры — массовыми, например создание товара — аргумент не массив ключ-значение, а массив массивов — сразу по 100-500-1000 шт- и она там внутри пишет одним запросом или через сохраненные sql процедуры, а не 1000-3000 запросов как сейчас — это очень сильно ускорит, но надо будет переписывать почти все модули чтобы они это поддерживали — это дорого. Этим вобще проф. разработчики движка должны заниматься, а не одиночные фрилансеры-любители, у меня это есть частично. Если надо, то могу продать/научить/проконсультировать, пишите в личку.
Есть еще битрикс, опенкарт, престашоп- там можно больше хранить, но нет кастомизации как в модх, что-то свое там сделать очень тяжело и лучше юзать стандартные шаблоны и модули, ну немножко можно дизайн поправить, но сильно там что-то поменять будет трудно, долго и дорого.
Из того, что падает и невозможно использовать:
1. mSearch2 — первый камень в огород Наумкина. Но и его понять можно — предусмотреть идеальный вариант для всех сайтов задача непосильная.
2. pdoPage — катастрофа астрономических масштабов. Постраничная навигация тоже делается своими силами. Всему виной передача всех id в дочерний сниппет.
3. Стандартная постраничная навигация в товарной админке сжирает RAM. но частично работоспособна.
Из серьёзных ограничений:
1. msProducts нужно запускать аккуратно, хорошо подбирая для него параметры.
2. Максимум 1 TV, максимум 1 свойство у товаров miniShop2 (если оно есть у всех товаров). Всё из-за особенностей таблиц БД.
3. Успех запуска pdoMenu сильно зависит от дерева категорий.
Очевидно, что регулярный импорт такой кучи товаров тоже нужно продумывать своими силами, чтобы избежать дублей, особенно если поставщиков тоара много, обновляются они когда попало и как попало.
Время генерации страницы каталога в среднем около 3 секунд, что для автомобилистов вполне терпимо.
Тот самый пример.
В итоге был выбор: или искать спеца под нужный фреймворк или немного допилить уже известный движок. Второе оказалось проще.
Любой сайт нужно обслуживать, если это не визитка на чистом HTML.