Влад

1 миллион записей для современных СУБД и современных серверов - нагрузка ни о чем.
У меня миллиарды записей крутятся - и не тормозит.
Если тормозит, то что то вы не так спроектировали.

Гуглите - правильная индексация базы данных.
А для очень больших нагрузок (не объем, не количество данных, а количество запросов, количество пользователей) - шардинг.

Еще вот тут полезняк:
https://habrahabr.ru/post/113298/
Про Tarantool можете не читать. Вам не надо.
А вот в начале - про правильное использование MySQL.

UPD:
Правильный выбор VPS????
У меня на 200 рублевом VPS с небольшим запасом 5000 запросов в секунду обрабатывается.
Все дело в правильном проектировании/реализации всего хозяйства - БД, индексы, запросы, обработка запросов.

UPD:

1) Сколько места будет занимать база с 1 млн подобных записей?

Берешь размер одной записи (суммируешь среднюю длина фамилии, имени, название города и пр.) умножаешь на миллион и умножаешь на 3.

А зачем ты хочешь в БД хранить фотографию? Это не типовая задача для БД.
Может, ты имел ввиду ссылку?

2) Насколько тяжёлые будут запросы к выборке из такой большой базы? Если база увеличится до 10 млн, то и длительность/тяжесть запросов пропорционально в 10 раз увеличится?

Никому не нужны все твои миллионы. Как правило.

Запросы будут выполняться за разумное время только к небольшой части БД.

Чтобы производительно не падала, чтобы не было Full Scan - нужны индексы. Правильные. Делаешь их на основании того, какие у тебя условия во where.

Выше - это про поиск.

А вот передача данных - это да.
Если тебе надо передать 100 записей или 100 000 записей, то, очевидно, что будет дольше. Но это уже не проблема БД. Тебе нужно постараться максимальное количество информации в одном-единственном запросе получать. А все остальное - уже не задача БД.

3) На какие параметры стоит обратить внимание при выборе хостинга/vps/vds под такую базу?

VDS современный, как правило, легко масштабируется вверх. Берешь самый дешевый. Если не хватает - увеличиваешь тариф. Перезагружаешь. Получаешь больше ресурсов.

Сейчас бы понять, откуда у вас переменные состоящие из двух слов, которые разделены пробелом.
А не работает, ибо получается селектор вида #word1 word2 (то есть элемент word 2 внутри айдишника word1), ну и соответственно ничего подобное querySelector и не находит.

Там используют этот плагин: masonry.desandro.com

DOM-элементы загружаются сверху-вниз, это касается и head с body (сначала head, т.к. он выше).
Если расположить свой script ниже элемента shortstory, то он будет работать. Иначе - только с ready и т.п. (это событие специально отслеживает, когда все элементы загружены).

Пока элемент #shortstory не будет создан, ваше $("#shortstory") не сработает. Поэтому код заворачивают в $(document).ready(), чтобы он начинал выполняться только после формирования элементов на странице.

Шансов восстановить удалённую таблицу обычно мало, а перезатёртую - практически нет.

Есть пара иногда работающих практик:

Восстановление через файловую систему:
Некоторое время после удаления таблицы, она может оставаться на жёстком диске.

Нужно как можно скорее предотвратить дальнейшую запись на диск: остановить MySQL, отмонтировать раздел с базой данных и примонтировать его в режиме read-only, или в принципе снять образ диска (не копию файлов) и исследовать его только в режиме read-only.

Затем можно исследовать раздел с базой на наличие удалённых таблиц/баз с помощью общих инструментов, вроде extundelete, или специализированных, вроде undrop-for-innodb.

Восстановление через binlog:
Можно попытаться восстановить все запросы (CREATE TABLE, INSERT и т.д.) к базе за весь настроенный срок существования binlog.
Если нужные данные в движок были добавлены в пределах этого срока, вы сможете восстановить их полностью. Если нет - только те данные, что попали в срок жизни binlog.