Как лучше организовать выборку

если, как я понял, 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 — это тоже фреймворк. Так, на минуточку : Сморозил я. Имел в виду, что его можно использовать наравне с «чистыми» фреймворками в нагруженных системах.

Не все так просто. Но в целом много для чего его можно использовать.