i**d
发帖数: 357 | 1 我删文是觉得和你argue这个问题很没有意义。
fanout或者不fanout和你有什么db没有本质关系。你doc-based和无非就是节约写的
cost而牺牲读。你写不用fanout，你读需要fanout了。这个和你的读写qps的pattern有
关。还是那句话，规模大了以后都会出现问题。至于会出现什么问题，我觉得你可以去
看看twitter VP的一个关于fanout的talk。这种问题其实不是一句话两句话可以说清楚
的。一直争论下去只是耽误你我的时间，不如花点时间来好好学习一下这些公司的架构
，来充实自己。 |
|
I***a
发帖数: 704 | 2 这个是详细的tco时序报告: PIN_C20的cell delay和interconnect delay 怎么分别是2
.103 ns 和8.358 ns ？为什么这么大？thanks.
Info: tco from clock "CLK" to destination pin "S[23]" through register "S[23
]~reg0" is 14.204 ns
Info: + Longest clock path from clock "CLK" to source register is 3.644
ns
Info: 1: + IC(0.000 ns) + CELL(0.904 ns) = 0.904 ns; Loc. = PIN_Y37;
Fanout = 1; CLK Node = 'CLK'
Info: 2: + IC(0.360 ns) + CELL(0.000 ns) = 1.264 ns; Loc. = CLKCTRL_
G3; Fanout = 104; COMB Node = 'CLK~clkctrl'
... 阅读全帖 |
|
n****e
发帖数: 678 | 3 这道题是说每个node的fanout是 <= 2吗？
即使fanout <= 2, (p1, p2)也有多种可能啊，如何定义这两个paths。
感觉题目没说清楚 |
|
i**d
发帖数: 357 | 4 很简单的一个问题，lady gaga更新了一条tweet，怎么样能够及时显示到所有follower
的首页上？这本质上是个高fanout数据更新的问题。你可以tweak你的后端数据存储和
你的数据pipeline，决定是在读还是写的时候做fanout。和你用php, jsp, Xsp没有任
何关系。 |
|
w**z
发帖数: 8232 | 5 real time chatting 不是很懂，我们用open sourced, 很是蛋疼。connection 有时就
断了， 还会丢包。不知道有啥好的开源软件。
feed 我们用Cassandra, news 发生的时候， 就fanout ，写入Cassandra. 至于 news
item要不要denormalize, 看具体情况。 如果一个user 有很多 friends, 你可能要选
择性的fanout,， 要不系统压力太大。 |
|
o********s
发帖数: 66 | 6 我来试试：
1.Vds？channel width？fanout？是不是应该是inverter的速度？
2. 应该是工艺能做到的最小沟道宽度。
3. no idea
4. n type? 因为电子迁移率更高? |
|
s******c
发帖数: 1920 | 7 ladygaga 是所有社交网络的噩梦。
社交网络的workload一般读写比都大于9：1，所以应该是写时fanout吧？
follower |
|
x**********a
发帖数: 1372 | 8 一个典型的system design fanout的failure scenario啊。 |
|
w**z
发帖数: 8232 | 9 fanout 一般都是在写的时候做的。 immutable 确实是关键。如果能把 post 做到能改
的就太牛了。
timeline都是做成immutable, 这才是scalability的关键。朋友圈帖子在前，删朋
友在
间。 |
|
a*****a
发帖数: 438 | 10 set fanout=n, only use insertion as example:
if the data being inserted is the n(1-x) member of the leaf,
it's time to split? |
|
|
n**x
发帖数: 25 | 12
try put some 0402 SMD decoupling capacitors on the back of your PCB, if you
BGA IC uses some vias to fanout. |
|
