inselfox

От DDOS защититься можно неиспользованием PHP во фронтальной инстанции. Если один сервер - полное кэширование результатов в оперативной памяти.
От XSS и SQL-инъекций (кстати, по сути одно и то же, второе без первого врятли возможно) поможет защититься грамотное распределение прав на сервере. - Если интересно, могу дать консультацию. Но, скорее всего вы так не сделаете! В 95% случаев, сколько сайтов я настраивал на дедиках/vps, web-мастеры возвращают свои разрешающие все и везде права. Им, видете ли, неудобно устанавливать жумловские/вордпресовские плагины прям из админки.
Если же разрешить изменения всех файлов только пользователем ftp (то есть, запретить это делать вебсерверу), и разрешить делать только заранее заданные выборки из БД, то можно не бояться за безопасность по этим вопросам. Даже если у злоумышленника что и получится подобрать, все равно сделать он ничего не сможет. - Ни тебе шелл залить, ни базу пользователей угнать.
Но современные движки сделаны для очень ленивых пользователей, они сами формируют структуру своих файлов. Тебе надо то лишь просто залить версию дистра в корень сайта - остальное сделают скрипты, они же оставят себе права на изменеия файловой структуры для дальнейшего удобного использования. Ставишь плагины от третьих разработчиков - они тоже хотят постоянно что-то записывать в файловую структуру, их разработчики вообще не предусматривают варианты работы, когда на изменение ФС нет доступа, хорошо если выводят сообщение о том, чтобы web-мастер выдал разрешение...
Я не могу назвать этот факт никаким другим определением как долбо..бизм.

Не хочется ругаться, но вопрос очень бессвязный и в нем перемешаны реальные проблемы с нелепыми фантазиями.

И проблема тут не в незнании как работать с большими базами данных, а в неумении работать с БД в целом.

Про идею "всем индекс не поставишь" надо сразу забыть. Там где индекс нужен, он должен стоять без вариантов. Другое дело что тупо натыкать индексов по всем полям, по которым идёт поиск - это тоже глупость. Индекс в запросе может использоваться только один, и индексы по второму-третьему полю уже будут бесполезны. Надо анализировать запросы и, возможно, делать составные индексы.

Детсадовский запрос вида like '%...%' - это отдельный ужас. Надо смотреть на полнотекстовый поиск. А лучше вообще его избегать. На крайний случай использовать внешние поисковые сервисы типа эластика. И только не говори что этот лайк у тебя идёт по полю типа джейсон или "через запятую"

Но самый конечно кошмар - это select distinct для фильтров. То есть неумение проектировать бд на самом базовом уровне, непонимание самых начальных принципов реляционных бд, нормализации. Вот с этих принципов и надо начать. В потом уже хвататься за большие объемы. Очевидно, что поля по которым ты собрался делать "distinct" - это должны быть отдельные таблицы, от которых в основной таблице будет просто id. поле размером в 4 байта.

Непонятно, откуда взялись фантазии про гигабайтные индексы, кстати. Большая часть полей в нормальной бд - это не больше десятка байт. То есть индекс - это десятки мегабайт, а не "гигабайты".

В общем, куда лучше бы смотрелись здесь не абстрактные рассуждения про большие объёмы, а конкретный запрос, который "отваливается". С обязательным результатом EXPLAIN

А ответ на абстрактный вопрос "как работать с большими объемами" очень простой: точно так же, как с небольшими. Реляционные бд изначально проектировались под большие размеры. То есть надо просто уметь работать с бд. Читать про реляционную модель, нормализацию, индексы, оптимизацию запросов.

Конкретно для грида надо смотреть в сторону Эластика/Сфинкса. В смысле чтобы не только для полнотекстового поиска, а чтобы все фильтры, которые есть выборке, были забиты в поисковый индекс. И все выборки - через поисковый сервис, а не через прямой запрос к базе