Здравствуйте! Планируется каталог. К стандартным таблицам ModX, будут добавлены примерно 30 дополнительных. Общее количество записей в этих таблицах будет примерно 5 миллионов. В запросах выборок максимум одновременно будут участвовать 5 таблиц. Основные обращения к БД будут по выборке данных. Вся база будет загружена отдельно. Еще будет одна таблица, отдельно от ModXовской системв в ней будут соотношения «фирма» — «штука с каталога». Фирмы планирую хранить в стандартных документах ModX. Итого, на сайте будет только пару страниц, основная работа будет выполняться поисковиком в сторонних таблицах, в файлах будут представлены только фирмы, количество 100-200 штук приблизительно. Вопросы следующие:
1. Как лучше организовать поиск в сторонних таблицах? Простым SQL или xPDO?
2. Сторонние таблицы промэтить, на случай дальнейшей вставки, или промэпить только те которые будут использоваться сейчас?
3. Если использовать xPDO то через итератор, наверное, лучше?
4. Если страниц не много стоит ли использовать шаблонизатор Смарти?
5. Поиск лучше писать как сниппет или реализовывать как процессор?
если, как я понял, 5 млн связанных ресурсов планируется, то тут даже битрикс ляжет при выборке, тут скорее всего надо в сторону nosql типа elastic search копать, пол года назат ребята в минске на митапе говорили, что смогли modx к elastic-y привязать, правда про ЧПУ придется забыть. Смарти поможет в случие нагруженного шаблона (когда там много чанков в которых еще и сниппеты есть), т.к. он код шаблона напрямую в php перемалывает в обход медленного парсера modx, xpdo при такой нагрузке ляжет, впрочем как и обычные sql запросы. Да и сам представь какая будет нагрузка если ты «тяжелый» запрос с join-ами по всем 5 таблицам выполнишь? А если 30 человек примерно в одно время его выполнят? тут DDOS атака рядом не стояла, даже VDS ляжет.
то тут даже битрикс ляжет при выборке
А что, битрикс с каких-то пор считается высоконагруженной платформой? Если что, он жрет гораздо больше, чем MODX. Не зря для него на том же таймвебе специальный тарифный план есть с повышенными теххарактеристиками. Это во-первых. А во-вторых, при чем тут вообще платформа, если речь о пользовательских таблицах, пользовательских данных и пользовательских запросах? И с чего вы взяли, что обязательно все должно развалиться? Если что, мускул давно уже многие миллионы записей тянет. На том же новостном портале (который я недавно разработал) одних только индекс-записей для морфологического поиска более 11 000 000 строк, не считая 75 000+ статей и всяких связанных с ними записей. Это еще при том, что сервер довольно-таки средненький (4 core 8 GB). А тут по всем таблицам всего 5 000 000 записей. Откуда такой испуг? Не надо предположений. Такие неуверенные предположения хуже молчания.
И далее идем по списку…
Смарти поможет в случие нагруженного шаблона (когда там много чанков в которых еще и сниппеты есть)
Не буду это утверждение опровергать. Но при чем тут вообще Смарти и 5 000 000 записей? Да хоть 500 млн, или наоборот всего 500 записей. Смарти-то что с того? Это шаблонизация, а не работа с БД. Его тут в данном контексте вообще не имеет смысла обсуждать.
xpdo при такой нагрузке ляжет,
Опять-таки, при чем тут xPDO? И в каком именно месте ляжет? Понятно дело, что getCollection() многих тысяч записей делать не надо, но xPDO этим не ограничивается, getCollection() здесь вполне можно и не юзать. Да и на 10 000 записей getCollection() может развалиться, не говоря уже о миллионах записей. Но это, если и с 10 000 записей не умеете обращаться, так за миллионы точно браться не стОит.
впрочем как и обычные sql запросы
Учите SQL-запросы, и все у вас получится, может быть. Индексы и правильно составленные запросы рулят.
Да и сам представь какая будет нагрузка если ты «тяжелый» запрос с join-ами по всем 5 таблицам выполнишь?
А вы не юзайте «тяжелые джоины». Настройте нормально индексы, и лучше парные первичные/вторичные. И будет вам счастье.
А если 30 человек примерно в одно время его выполнят? тут DDOS атака рядом не стояла, даже VDS ляжет.
Делать все нормально надо, и работать будет ОК.
Насчет базы данных, то пока однозначно MySQL. С таким объемом она справиться на ура. C nosql не так все просто, один очень крупный белорусский портал с посещением примерно в 1 000 000 пользователь в сутки, на кеширование использует mongodb и хлебонул с ней горя. Я подумываю для выборок использовать xPDO, а для вставок(там их будет не много) чистый sql. Насчет смарти я имел ввиду чисто с практической точки зрения использования для себя. TV параметров предполагается использовать по минимуму, стандартных modx полей в шаблоне тоже не много будет. Просто сам факт, что можно отказаться от многих сторонних сниппетов и это все быстрее делать в шаблоне, не дает голове покоя.
Я подумываю для выборок использовать xPDO
xPDO на уровне выборки формирует только SQL-запрос. Сам же запрос выполняет СУБД. Это важно помнить. Многие этого не знают или забывают.
, а для вставок(там их будет не много) чистый sql.
А вам в любом случае придется юзать чистый SQL :). xPDO не умеет формировать запросы на вставку, как это не печально. Вот смотрите xPDOObject::save(). Как видите, там чистый INSERT INTO… А xPDOQuery::command() поддерживает только SELECT|UPDATE|DELETE.
Просто сам факт, что можно отказаться от многих сторонних сниппетов и это все быстрее делать в шаблоне, не дает голове покоя.
На самом деле от очень многих… А расширение шаблонов — это вообще просто мегафича, освоив которую, уже никогда от нее не откажешься.
xPDO на уровне выборки формирует только SQL-запрос. Сам же запрос выполняет СУБД. Это важно помнить.
Это я понимаю, просто для упрощения работы использовать xPDO.
На самом деле от очень многих… А расширение шаблонов — это вообще просто мегафича, освоив которую, уже никогда от нее не откажешься.
Вот я и посматриваю в эту сторону, это более «вкусно» выглядит по использованию ModX + ускоряет работу, уменьшает нагрузку и с таким подходом даже практически отпадает желание смотреть на фреймворки
и с таким подходом даже практически отпадает желание смотреть на фреймворки
MODX — это тоже фреймворк. Так, на минуточку :)
MODX — это тоже фреймворк. Так, на минуточку :
Сморозил я. Имел в виду, что его можно использовать наравне с «чистыми» фреймворками в нагруженных системах.
Не все так просто. Но в целом много для чего его можно использовать.