Станислав Бодро́в

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

Не проще писать в файл? Это не шутка. Если только писать и практически не читать. Логи nginx легко могут лететь с такой скоростью.

подскажите пожалуйста как лучше организовать работу микросервисов

Это гооловная боль программистов. Задача девопс предоставить им среду исполнения и организовать сетевую связность. DDD и прочие шаблоны удел программистов.

Стоит ли разворачивать БД в докере, или лучше на хосте, или вообще на другой машине, почему, и какие могут быть подводные камни?

Тут многое зависит от проекта. Если это наколенный сайт, коих подавляющее большинство, можно сильно не заморачиваться и лепить всё на одном хосте. Но есть правило хорошего тона: разносить хранилище данных (СУБД) и среду обработки данных (обычно бэкенд). Потому что бэкенд может скалироваться горизонтально без особых проблем (но программисты и тут не дремлют), с базами такой номер далеко не всегда проходит. Второй момент: обновление кода (бекенда) не должно аффектить данные (СУБД). Но блин проклятые миграции, миграции, миграции.
Поэтому когда есть возможность разделай код и базы по разным хостам, чтобы спать спокойно. Когда совсем хреново с деньгами и бизнес трясётся за каждую копейку (собственно как всегда), смело лепи на одном хосте (но только не в одном контейнере, не уподобляйся некоторым отечественным компаниям в сфере безопасности). И не парься это совершенно не твоя забота. Ты работаешь с тем что есть.

Обе древние реляционные СУБД. Живы до сих пор, что на них написанно куча проектов ещё со времён апача, сайтов на перле и третьего Ишака. Диды разрабатывали под них, потом отцы писали под них, вот и вам под них писать.
Обычно под всякие ларавелы, симфони и прочие вордпресы ставят мускуль. Даже стек технологий образовался LAMP. Всё за себя говорит.
Если интересуют основные различия для общего развития, то:
у них разная модель обработки сетевых запросов. Но это важно только для системных архитекторов, которые строят огромные системы
у них разная модель хранения данных на физических устройствах. Это не должно волновать программиста.
разные алгоритмы работы планировщика (последствие разницы в обработке входящих запросов)
постгря версионник, про мускл не знаю

Есть ли четкое разделение между файловой системой и ДСУБД

Есть. Начинать надо с самого определения что такое СУБД, а что такое ФС.

является ли простой сетевой интерфейс к файловой системе (например, ftp сервер) - ДСУБД?

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

Если я перейду на mysql, она сможет обрабатывать ГИГАБАЙТЫ текста и быстро делать выборку? Или тоже зависнет?

Сможет. И не такое сможет. Предварительно главное его правильно настроить, затем нормальные запросы слать.

MySQL. Поживей будет и проще кластер работающий собрать.

Существуют ли базы данных которые поддерживают деревья?

LDAP очень хорошо работает с древовидными структурами данных.

Монго, конечно, быстро принимает записи, но работать потом по ней с выборками будет, наверное, очень проблематично

Ага-ага блокировки всякие.

какая из РСУБД в состоянии "принимать в себя" около 100тыс записей в сек?

Правильно настроенный MySQL. Повторяю, не MariaDB, а MySQL.
Ещё в версии 5.7 можно было сделать так чтобы он работал почти как NoSQL база.

Если сервис логгера будет писать в Монго, а некий переносчик раз в минуту будет все забирать из Монго и складировать в РСУБД, будет ли он успевать за минуту переносить все то, что будет накоплено в Монго, даже если брать большими блоками?

Так и не нашёл такой переносчик. Разве что самому писать.

Буду благодарен за любой совет/предложение по существу.

arangodb

Илья Космодемьянский рекомендует делать это вручную (отвечает в конце на вопросы).

каким образом в такой ситуации перевести все запросы на резервный сервер?

Распространённая практика - собирать кластер.