Os bancos de dados orientados a documentos foram desenvolvidos para serem a próxima geração de bancos de dados e basicamente substituir completamente os bancos de dados relacionais?
Não. Bancos de dados orientados a documentos (como MongoDB) são muito bons no tipo de tarefas que normalmente vemos em sites modernos (pesquisas rápidas de itens individuais ou pequenos conjuntos de itens).
Mas eles fazem algumas grandes trocas com sistemas relacionais. Sem coisas como conformidade com ACID, eles não poderão substituir certos RDBMS. E se você observar sistemas como o MongoDB, a falta de conformidade com o ACID é um grande motivo para ser tão rápido.
É possível que os projetos sejam melhores usando um banco de dados orientado a documentos e um banco de dados relacional lado a lado para vários dados que são mais adequados para um ou outro?
Sim. Na verdade, estou executando um site de produção muito grande que usa ambos. O sistema foi iniciado no MySQL, mas migramos parte dele para o MongoDB, b/c precisamos de um armazenamento de valor-chave e o MySQL simplesmente não é muito bom em encontrar um item em 150 milhões de registros.
Se os bancos de dados orientados a documentos não pretendem substituir os bancos de dados relacionais, alguém tem um exemplo de estrutura de banco de dados que seria absolutamente melhor em um banco de dados relacional (ou vice-versa)?
Bancos de dados orientados a documentos são ótimos dados de armazenamento que são facilmente contidos em relacionamentos "chave-valor" e simples e lineares "pai-filho". Exemplos simples aqui são coisas como Blogs e Wikis.
No entanto, bancos de dados relacionais ainda tem uma forte vantagem em coisas como relatórios, que tendem a ser "baseados em conjuntos".
Honestamente, posso ver um mundo onde a maioria dos dados é "manipulada" pelo banco de dados orientado a documentos, mas onde o relatório é feito em um banco de dados relacional que é atualizado por trabalhos de redução de mapa.
