Silm

Шардинг и репликация
Вертикальный шардинг
Горизонтальный шардинг

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

При сомнениях в ответственном проекте надо отдавать предпочтение более знакомому инструменту. При сомнениях в фановом проекте - менее знакомому.

Можно использовать сразу 2 субд в одном проекте.

GROUP BY album_id

Очередь нужна, чтобы вы или могли более равномерно использовать ресурсы (ресурсоемкие задачи выполнять не одновременно, а последовательно), либо чтобы могли из веб интерфейса создать задачу и не дожидаясь ее завершения продолжить работу с сайтом.

Вам надо смотреть что у вас и почему не выдерживает. Скорее всего ресурсов просто маловато для такой операции. Может вы нерационально их используете. Посмотрите, вдруг у вас утечка памяти происходит в PHP.

Если по данным нужны выборки и/или поиск, то их не стоит хранить в сериализованном виде.
Сериализация может подойти, когда данные типа объект или массив нужно только хранить и выводить.

"автоматически преобразовывать в теги html"
Что и в какие теги вы хотите преобразовать?

При выводе можно добавить к символу переноса строки \n тег переноса строки <br> для этого есть php функция nl2br() php.net/function.nl2br

Другим языком, так можно отобразить переносы строк в тексте.
Вам что то еще надо?

От PHP требуется грамотное использование. Защита от ddos реализуется совершенно на другом уровне. А этот скрипт принципиально не поможет ибо ddos он на то и ddos, что с разных IP идет. Даже напротив, с этим скриптом быстрее ляжете.

У вас либо хостер совсем плох, либо вы что то накодили кривое.

Для начала надо выяснить из за чего именно падает сайт. Где узкое место, откуда нагрузка. Если не нравится Узбекистанский хостинг, возьмите другой.

И почему вас вообще беспокоит ddos? Не похоже что у вас какой то коммерчески или конкурентный проект, который был бы смысл ддосить.

Лучше всего использовать готовые системы для управлениями аутентификацией, ролями, авторизацией, правами..
https://cartalyst.com/manual/sentry/2.1
Если к вашему велосипеду возможно что-то прикрутить...

В целом у вас подход правильный. В БД храним роли, права. В коде определяем есть ли право на действие. Чтобы не было постоянных запросов к БД кешируем в память (Memcached/Redis).

Главное чтоб реализация не оказалась дырявой.

Возьмите пробный период у нескольких хостеров. Поставьте свое приложение. Проведите нагрузочное тестирование.

Вот так обычно узнают "какую посещаемость выдержит такой чат на среднестатистическом хостинге".

А вы пробовали сперва изучить язык на котором хотите писать?

Я вам даже ссылку дам: php.net/manual/ru/language.functions.php

Через 5 минут чтения наступит просветление, попробуйте в следующей раз начать с этого

Сделайте var_dump($_POST) и увидите своими глазами что у вас приходит из селекта.

Придет значение атрибута value выбранного option, лежать будет в $_POST под индексом с именем указанным в атрибуте name тега select. Селект должен быть ассоциирован с отправляемой формой.

Это значение добавляется в БД ровно так же как любое другое.

<b>символ</b>
А эта строка представляет какую то опасность для БД? Она абсолютно для нее безопасна.
Почитайте про SQL-inject.

Да в общем то любой популярный специализированный магазинный движок с необходимыми модулями подойдет. Сравните сами, с чем вам приятнее работать. 10-15к товаров этож мало.

Во-первых: PDO

Во-вторых: Выведи SQL запрос, который получается в итоге, на экран, посмотри что в нем получается. Если ничего подозрительного выполни его вручную, посмотри на результат.

В-третьих:

mysqli_query($CONNECT, "UPDATE vacancies SET  title = $_POST[title], preview = $_POST[preview], content = $_POST[content], regdate = NIW() WHERE id=$_POST[id]");

значения для полей строкового типа должны быть в кавычках, вместо NIW() должно быть NOW()