Я буду комментировать только на стороне базы данных:
При нормальной СУБД нагрузка чтения / записи для БД 50/50 сделает репликацию «дорогой» с точки зрения накладных расходов. Почти во всех случаях простое решение отработки отказа обходится дешевле, чем реализация репликации активной / активной настройки БД. Как с точки зрения администрирования / обслуживания, так и стоимости лицензирования (если применимо).
Поскольку ваши данные «в основном денормализованы и нереляционные», вы можете взглянуть на HBase , который является реализацией OSS Google Bigtable , системы баз данных на основе столбцов ключ / значение , HBase снова построен поверх Hadoop , который является реализацией OSS Google GFS .
Какое решение выбрать, зависит от ожидаемого увеличения емкости, когда Hadoop предназначен для масштабирования до потенциально тысяч узлов, но также должно работать и на гораздо меньшем.
Я управлял активными / активными реплицированными БД, БД с одной записью / множеством чтений и простыми отказоустойчивыми кластерами. Выход за пределы простого отказоустойчивого кластера открывает новое измерение потенциальных проблем, которые вы никогда не увидите при настройке отказоустойчивости.
Если вы собираетесь использовать традиционную СУБД SQL, я бы предложил относительно «железный» сервер с большим объемом памяти и сделал бы его отказоустойчивым кластером. Если ваш коэффициент записи уменьшается, вы можете использовать отказоустойчивый кластер записи и ферму серверов только для чтения.
Ответ кроется в деталях. Ваш процессор приложения или I / O связаны? Вам потребуется терабайт памяти или всего несколько ГБ?