Роботы роботами, но в любом случае они не сотнями приходят на сайт одновременно.
И держать типовую нагрузку ботов - нормальное свойство нормального движка.
Даже на слабом железе и малоподходящем движке - это решается.
Это решается через кэширование и throttling
Количество страниц - не важно. Понятно, что чем больше страниц, то тем дольше боты будут ходить по сайту.
Но отдавать страницы по запросу - это штатный функционал сайта, то за ради чего он вообще сделан.
Поэтому сайт должен штатно выдерживать как 10 секундное посещение ботами, так и 5 часовое.
Хотя, владельцы ботов не позволяют своим робото-ресурсам так долго возится с одним сайтом. У них и другие задачи в очереди есть.
И боты не запрашивают по миллиарду страниц одномоментно. Они делают это последовательно.
Дело не в движках, а в умение ваших программистов ими пользоваться.
Это те люди и должны вам сказать какой движок лучше, - которые будут его внедрять.
Ну вот скажу я вам, что я бы делал на Tarantool. Который сам был бы в этой схеме и application server и сам и СУБД и код backend был бы в нем же.
Вам стало от этого легче?
Нет волшебного движка, который просто так решит вашу проблему просто самим фактом своего существования.
Это все кто-то должен установить и настроить. Кто-то разбирающийся в том, что он делает.
Вам лучше задать вопрос тем конкретным людям, что будут этим заниматься.---------- Добавлено 11.10.2018 в 14:15 ----------
Ну это же неправильный подход.
В конечном итоге, нам всем нужен поисковый трафик.
А тут вы намерено затрудняете работу поисковым системам.
Понятно, что вам оставшегося трафика хватает.
Но разве не хотите большего?
Проблема вовсе не там.
Если вы уже сделали кэширование, если у вас уже есть шардинг - пора искать узкие места в движке.
Сначала выполняете профилирование, смотрите какая нагрузка, сколько времени генерится страница.
И если даже одна страница отдается за 0,5 секунд, то это уже плохо и миллиарды не при чем.
Далее смотрите что именно тормозит в движке. То ли это работа БД, то ли это захлебывается оперативка, то ли процессора не хватает.
Если затык в СУБД - то обратите внимание - у вас не SSD
Если затык в процессоре - то проверьте, все ли ядра загружены и обратите внимание - у вас всего 4 ядра.
И т.д.
В целом нельзя поставить диагноз по фотографии.
Нужно конкретно работать с конкретно вашим проектом и смотреть конкретно ваши узкие места.
Это не взаимоисключающие понятия.
Плагин может давать команду на рассылку внешнему сервису.
Вот о чем речь - сейчас поисковики очень жестоки по части спамеров.
И прямая рассылка на сколько-нибудь значительное число адресов - забанит вас в почтовиках.
Через внешние сервисы это сделать будет куда как безопаснее. Больше гарантия, что письма все же дайдут до адресата. Во исполнение этого специализированные сервисы рассылки определенные требования к рассылкам предъявляют.
Будете ли вы вручную в эти сервисы выгружать файл с адресами и нажимать вручную кнопку "Начать рассылку" или сайт это будет делать автоматически - другой вопрос.---------- Добавлено 11.10.2018 в 13:54 ----------
Этого недостаточно.
Нужно еще выполнять оперативную отписку.
Если на вас будут жаловаться - и DKIM/SPF не поможет.
Не только в этом дело.
Никто не будет оказывать услуги саппорта за копейки. Человеческий труд - дорог по сравнению с трудом "железа".
Полагаю, топикстартер хочет качества и недорого.
Пусть наймет своего админа на почасовку - дело-то.
Саппорт все равно не сможет оказывать услуги существенно дешевле наемного внешнего админа.
За счет знакомства со средой, за счет навыков постоянно однотипной работы - может и будет дешевле.
Но отнюдь не те копейки, что, полагаю, ожидает топикстартер.
Если даже есть лишние 2-3 тыс. рублей в месяц на еще 2 сервера, то не факт, что есть лишние 100-200 тыс. на специалиста который переделает программное обеспечение, чтобы корректно в кластере отрабатывало, нормально репликации делались.
Цифры условны.
Я к тому, что стоимость аренды железа по сравнению со стоимостью создания создания программного обеспечения, живущего в кластере - разные порядки цен.
А еще индексы посчитать забыли.
Чего именно вы хотите? Боитесь, что база данных не выдержит? Лимиты очень велики:
https://dev.mysql.com/doc/refman/8.0/en/table-size-limit.html
https://dev.mysql.com/doc/refman/8.0/en/innodb-restrictions.html---------- Добавлено 11.10.2018 в 01:51 ----------
Если это виртуалка, то просто тариф смените по мере того как место закончится.
Если это "железный" сервер - покупать сразу с запасом, дорого. Но его все равно переезжать придется. Жить на одном железе сервере 10 лет - стремновато. Диски уж точно понадобится менять.---------- Добавлено 11.10.2018 в 01:53 ----------
Там не такая зависимость:
https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html#data-types-storage-reqs-strings
Они будут преспокойно лежать себе в базе данных. А базе данных - все равно. Пусть хоть там миллиард лежит статей.
Обычному пользователю-человеку нужна одна статья на секунды или даже минуты.
База данных отдаст эту одну статью быстро (индексы же есть).
А миллиарды лежащих в базе данных статей будут так же спокойно лежать.
Нагрузка определяется не количеством статей (индексы же есть), а сложностью логики обработки запроса. Если один запрос будет проходить через миллиард плагинов, то другое дело.
TDP - это же длительное пиковое (а кратковременный пик там вообще до 400 Вт https://www.tomshardware.com/reviews/overclock-core-i7,2268-10.html )
В полусне, в коем прибывают 98% веб-серверов - он мало потребляет.
Если в облаке, то точка отказа один сервер - это нормально.
От задачи зависит.
Есть задачи хорошо распараллеливаемые - больше ядер будет целесообразнее.
Есть задачи плохо распараллеливаемые - меньше ядер, но выше частота будет целесообразнее.
Типа этого?
:)
Почему вы считаете, что если вы лично не знакомы с теми людьми, то они все сплошь на подбор - эксперты?
Эффект - "за морем рай земной" и "нет пророка в своем отечестве"?
"Эксперты" пишут, чтобы их читали. Ресурсам нужны читатели.
Целевые тесты на надежность сами по себе - тупость. Эти устройства ориентированы на долгосрочное использование. И что там показал за считанные дни один тестируемый экземпляр - не показатель, не тот профиль нагрузки.
Куда как более показательны результаты статистических наблюдений типа отчетов Backbaze. Такие на коленке "эксперты" не нарисуют.
https://www.backblaze.com/blog/hard-drive-stats-for-q1-2018/
К сожалению, это только по HDD.
У кого и откуда подобная серьезная статистика по NVMe?
Долговременные и массовые наблюдения?
