一個數(shù)據(jù)庫設計的難題

問題比較復雜，盡可能簡化描述

比如一個存儲文章的數(shù)據(jù)表，數(shù)據(jù)存儲用的是mongodb

1、有不確定列，比如點擊率、內(nèi)容、標題、回復、用戶uid，利的數(shù)目不確定，可能十幾個，也可能上百個?？赡茉黾?，也可能減少，是動態(tài)的。

2、每個列存儲的數(shù)目不確定，比如回復這個字段，可能有上百萬，也有可能只有1個。

3、每個字段需要能存儲版本。比如內(nèi)容這個字段，可能存在多個版本，版本1、版本2、版本3。版本數(shù)目多少不確定。

我是這樣設計的

1、數(shù)據(jù)表：data。存儲文章的基本信息。比如文章添加時間，文章發(fā)布狀態(tài)等。
2、字段表：field。存儲具體的字段內(nèi)容，比如回復、內(nèi)容、標題。
3、還有一個數(shù)據(jù)表：version。存儲版本。每個版本的具體內(nèi)容依然存儲在 field 里面

目前的問題：

1、存儲是沒問題的。比如我查詢一篇文章的回復、內(nèi)容，都能查詢。
2、性能有問題。比如分頁，一頁列出25條。每條需要在列表列出一些數(shù)據(jù)給用戶。比如標題、內(nèi)容、時間等等。大概7個字段。加起來就是：25*7=174個查詢，查詢花費了10秒左右。
如果解決這個問題，可能需要把這些數(shù)據(jù)提前寫入一份放到data表。也就是反范式。比如這樣：

field:{
    title:'標題',
    content:'內(nèi)容',
}

存放這么一些冗余數(shù)據(jù)到data表里面。

3、搜索的問題。感覺還是存在一些功能的局限和性能問題。

目前整體來說，感覺設計很復雜，代碼寫得很累，問題層出不窮。
不知道數(shù)據(jù)庫設計問題還是說mongodb不適合存儲這樣的數(shù)據(jù)。
如果是你，你會怎么設計這個數(shù)據(jù)庫呢