Сделайте уникальный индекс (шардинг) по username, тогда запрос будет к конкретному шарду в котором это имя (есть или должно быть). И при добавлении не нужно будет проверять, т.к. дубль имени не запишется (будет ошибка).
Можно попробовать sphinxsearch (или эластик), он ищет с сортировкой по релевантности, т.е. сверху будут наибольшие пересечения ключей, но он может сильно задуматься если там много пересечений.
Либо попробовать сделать обратный индекс с сортировпнными сайтами, за один проход вычислять пересечение по сайту, все сайты раскидать по нодам, результат скидывать в БД для сортировки.
Можно взять MongoDB, плюсы такие:
* При большой нагрузке или объеме можно будет данные разлить по шардингу. Это так же может помочь сэкономить, например можно вместо одного сервера DO за $480 можно взять 24 минимальных виртуалки за $120, + будет больше ядер и трафика.
* Можно хранить доп. параметры, теги, (атрибутивную информацию) и прочее вместе с файлом, таким образом тайл и все с ним связанное будет в одном блоке данных, в отличие от применения *sql. Это хорошо для производительности, т.к. меньше индексов и меньше обращений к ФС.
* Можно сделать доп. индексы
* Можно использовать гео-индексы, выборка тайлов по радиусу и т.п.
* Так же для данной задачи (вполне возможно) достаточно атомарных комитов, они лучше по производительности чем полноценные транзакции.
Обычно удобнее что-б ключи были фиксированные - не нужно гадать/перебирать, что-б получить значение.
Проблема может возникнуть если вы в будущем добавите ещё по стране в каждый элемент или т.п.
Памяти это (почти) не сэкономит. Проблем с хранением не возникнет.
Если расширять не планируется и хорошо подходит под текущие запросы, то никаких проблем.
Ещё можно сделать ssh тунель в одну команду, я так иногда автоматические дампы с удаленного сервера делаю.
Так же можно настроить openvpn или т.п.
Эти способы лучше по безопасности и удобнее если у клиента динамический ip.
PS: В mongodb не рекомендуют использовать авторизацию по логину+паролю.
В будущем потребуется хранить и редактировать огромные объёмы информации
На счет объемов, у вас наверняка для книг будут картинки (постеры), дак вот они могут занимать большую часть хранилища (+ большую часть расхода), я работал с одним книжным сайтом - на каждую книгу с отзывами (~4kb) есть несколько картинок (~120kb), т.е. ~97% (от книг) это картинки.
Зависит от использования, например если отзывы будут выводится на странице книги и больше с ними ничего не будет происходить, то их удобно сделать вложенными, + экономия на запросах, одним запросом будет доставаться книга и отзывы.
А вот авторов лучше (можно) в отдельную коллекцию, т.к. их данные будут изменятся (имя, фотка, описание, теги?), Хотя если эти изменения очень редкие или вовсе нет, то можно сделать вложенными, при этом будет больший расход диска, но экономия на запросах.