摘要:
参考了以下资源和 memcached-1.2.5的源代码,画了一个memcached模型图,作为下面资源的补充。 slab内存模型的优点(减少碎片,速度快)和缺点(有空间浪费)下面的链接里面都有讲,Tim也没有什么新观点,就不重复了。 参考资源: Current memcached memory management: http://lists.danga.com/pipermail/memc... 阅读全文
摘要:
Performance compare: Tim http://hi.baidu.com/jabber/blog/category/Memcached memcached 1.2.0 MySQL 5.0.26 with MEMORY (heap) engine 记录数:50万~100万条 单机,client 从另外一台机访问 数据:单条 0.1K左右 memcached set/get... 阅读全文
摘要:
基本上用MySQL 5.0, 操作系统则是Linux的天下,开发语言用php,python,java,c++,另外facebook还用erlang的
MySQL对DBA的需求较小,程序员就是dba
facebook平均每个db server有20个数据库 阅读全文
摘要:
MySQL分表实现上百万上千万记录分布存储的批量查询设计模式
Tim http://hi.baidu.com/jabber/blog/category/Mysql
我们知道可以将一个海量记录的 MySQL 大表根据主键、时间字段,条件字段等分成若干个表甚至保存在若干服务器中。
唯一的问题就是跨服务器批量查询麻烦,只能通过应用程序来解决。谈谈在Java中的解决思路。其他语言原理类似。 阅读全文
摘要:
在大型的应用中,我们经常碰到MySQL的表数据需要无限扩充的情形。我们通常有以下一些解决方案,但是现成的方案都不是完美的。
比如,
MySQL master/slave: 只适合大量读的情形,未必适合海量数据。
MySQL cluster: 提供的可能不是大家想要那种功能。
MySQL proxy: MySQL master/slave配合
MySQL 5.1 partition: 只是将一个表存储上逻辑分开,部分改善了性能,但是可扩展性仍然是问题。
MySQL 按应用逻辑分表和分数据库,通过程序来决定数据存放的表,目前很多公司都是这么做的。它的主要问题是跨区查询,可参考Tim以前的文章MySQL分表实现上百万上千万记录分布存储的批量查询设计模式 阅读全文