| Twitter | Del.icio.us | Comments (25) | | Edit

Comments Powered by Disqus

留言评论 | Comments (25)

也反应一点,他们的监控做得不够,在问题出现之前,应该在监控的时候,会有反应的。

谢谢分享

要做到未雨绸缪 提前规划
所谓 无远虑 有近忧
谢谢分享

今天的确是个值得庆祝和纪念的日子。

很好的案例,值得关注一下,使用新技术最大的风险就是如何能在突发情况下得的解决方案。

现在好像还不能访问

亚马逊云计算部门有个DBA伙计,刚上班两个月,就在圣诞节加班两个通宵. 外面看着风光, 里面辛苦呀.

新东家的全部服务器跑在Amazon上,包括测试环境。目前略知一二 :p

好像还不能访问

跟五月份Reddit在Cassandra上遇到的情况差不多,平时没有注意到性能瓶颈,等到发现再去补救已经无力回天,越增加节点越糟糕。分布式Key-Value数据库好像都没有太好的办法对付这种情况。
http://blog.reddit.com/2010/05/reddits-may-2010-state-of-servers.html

我来学习了。

Foursquare 2.0版上线:多项功能得到调整... 【搜狐IT消息】北京时间9月21日消息,据Techcrunch科技网站报道,美国地理位置社交网站Foursquare已于20日宣布推出2.0版

这么长时间?真恐怖&!@

请教:
能不能实现一种数据库表做堆栈用,或者说,实现固定记录数的表,比如固定100条记录,数据表满时,如果再插入,那么第一条记录自动删除,依次类推。

程序可以实现,问题是性能问题不能确定,现在想到一个办法是定期删除过期记录(手动或计划任务),但感觉不是很爽,有没有爽的办法。还有是自增ID问题,假如记录数过多,自增ID也会超过最大值,从而导致错误,现在想到的办法是定期更新表结构,即删除自增ID列,再重新创建此列。请问下还有没有别的办法?

仔细看了10gen的邮件,MongoDB把数据文件mmap到virtual memory,依赖os paging去完成disk读写——这也太省事了!
市面上数据库有几个不是自己管理内存和I/O的?对MongoDB的印象大打折扣了

MongoDB性能不过如此,到跟宕机并没有直接关系吧?

很切实际,面对现实有点无奈。另外问一下,实习生招聘这么快就结束了,难道我没机会了?

DB简单一点,就需要监控用点心。

关于Foursqure宕机,这里也有一篇文章值得看看 Troubles with Sharding - What can we learn from the Foursquare Incident? http://highscalability.com/blog/2010/10/15/troubles-with-sharding-what-can-we-learn-from-the-foursquare.html

都不记得Foursquare什么时候无法访问的了

个人认为,对特定应用如SNS来说,NoSQL是趋势。相关的支持技术、管理人员都会逐步跟上。foursquare这次事件,对其自身是坏事(其实也不完全),对其他公司包括正在用和考虑用的,都是好事。

不是在升级么?无比的nosql

太专业,看不懂。都是DBA的活。
4SQ在国内用GPRS速度不给力,不过优点是可以认识更多的同城好友。

这是为什么?

关于本文

这篇文章由 Fenng 于 October 8, 2010 12:37 PM 发布.

上一篇:从 C10K 到 C500K.

下一篇:说说校园招聘这事儿.

回到 首页 查看最近发表的文章或者查看所有 归档文章.