|
|||
 公告 |
07 2011 档案摘要: 原文地址：http://www.ningoo.net/html/2011/mongodb_in_a_nutshell_3.html作者：NinGoo | 【转载须以超链接形式标明文章原始出处和作者信息】 通过源代码编译安装好MongoDB之后，接下来需要配置运行。在MongoDB的安装目录，有几个子目录，bin下面是可执行文件，包括mongod：数据库服务端，类似mysqld，每个实例启动一个进程，可以fork为Daemon运行mongo：客户端命令行工具，类似sqlplus/mysql，其实也是一个js解释器，支持js语法mongodump/mongorestore：将数据导入为bson格式阅读全文 posted @ 2011-07-27 11:24 LixingTie 阅读(126) | 评论 (0) 编辑 | 摘要: 原文地址：http://www.ningoo.net/html/2011/mongodb_in_a_nutshell_2.html作者：NinGoo | 【转载须以超链接形式标明文章原始出处和作者信息】 前面扯了一堆，要了解一个东西，最好的办法，还是让他跑起来，然后结合文档和测试，来验证其实现，并且了解其不足和优点。MongoDB提供了部分系统的编译版本，但从研究学习以及线上不同依赖包的稳定性的目标，个人还是比较推荐从源代码编译安装的方式。MongoDB的源代码依赖了一些基础组件，如js引擎Spider Monkey，正则表达式引擎PCRE，安装构建工具Scons，以及C++的boost库等，阅读全文 posted @ 2011-07-27 11:23 LixingTie 阅读(45) | 评论 (0) 编辑 | 摘要: 原文地址：http://www.ningoo.net/html/2011/mongodb_in_a_nutshell_1.html作者：NinGoo | 【转载须以超链接形式标明文章原始出处和作者信息】 按照官方的说法，MongoDB是一种可扩展的高性能的开源的面向文档（document-oriented ）的数据库，采用C++开发。注意mongo不是mango（芒果），这个词是从humongous中截取出来的，其野心不言而明，直指海量数据存储。和其他很多NoSQL不太一样，MongoDB背后有一个专门的商业公司在提供支持和推广，有点类似MySQL AB的模式。这一系列文章，是为入门者写的，已阅读全文 posted @ 2011-07-27 11:22 LixingTie 阅读(56) | 评论 (0) 编辑 | 摘要: 原文地址: http://www.ningoo.net/html/2011/some_tips_about_hbase.html作者：NinGoo | 【转载须以超链接形式标明文章原始出处和作者信息】 随着Facebook使用HBase来构建实时消息系统，基于Hadoop的面向列存储的HBase持续升温。目前稳定版本的HBase0.90.2只能基于Hadoop0.20.x系列版本，暂不支持最新的0.21.x。而且官方版本的Hadoop0.20.2（或者0.203.0）缺少一个重要的特性，HDFS不支持sync模式的持久，这样HBase就有较大的丢失数据的风险。要在生产环境使用HBase，有两个阅读全文 posted @ 2011-07-27 11:19 LixingTie 阅读(69) | 评论 (0) 编辑 | 摘要: 原文地址: http://timyang.net/distributed/paxos-scenarios/在分布式算法领域，有个非常重要的算法叫Paxos, 它的重要性有多高呢，Google的Chubby [1]中提到all working protocols for asynchronous consensus we have so far encountered have Paxos at their core.关于Paxos算法的详述在维基百科中有更多介绍，中文版介绍的是choose value的规则[2]，英文版介绍的是Paxos 3 phase commit的流程[3]，中文版不是从阅读全文 posted @ 2011-07-15 00:58 LixingTie 阅读(31) | 评论 (0) 编辑 | 摘要: 原文地址：http://timyang.net/architecture/consistent-hashing-practice/最近项目中一个分布式应用碰到一些设计问题，听过上次技术沙龙key value store漫谈的同学可能会比较容易理解以下说明。场景假定一个有状态的服务，可以理解成web或者socket服务器，每个用户在这个服务上登录后是有状态的，我们把它的状态连同其他加载到内存的用户数据统称用户session。由于session数据实时会变化，加上程序访问session频率大，几乎所有的操作都跟session数据相关，因此不适合放在远程memcached中第一阶段考虑到单服务器不能阅读全文 posted @ 2011-07-15 00:51 LixingTie 阅读(61) | 评论 (0) 编辑 | 摘要: 原文地址: http://timyang.net/programming/memcache-mutex/周六的S2 Web 2.0技术沙龙上介绍了memcache中使用mutex场景(文后要演讲稿)，有网友对详情感兴趣，简单介绍如下。场景Mutex主要用于有大量并发访问并存在cache过期的场合，如首页top 10, 由数据库加载到memcache缓存n分钟微博中名人的content cache, 一旦不存在会大量请求不能命中并加载数据库需要执行多个IO操作生成的数据存在cache中, 比如查询db多次问题在大并发的场合，当cache失效时，大量并发同时取不到cache，会同一瞬间去访问db并阅读全文 posted @ 2011-07-15 00:37 LixingTie 阅读(47) | 评论 (0) 编辑 | 摘要: 原文地址:http://timyang.net/data/multi-idc-design/在前文《多IDC的数据分布设计(一)》中介绍了多IDC数据一致性的几种实现原理，遗憾的是，目前虽然有不少分布式产品，但几乎都没有开源的产品专门针对IDC来优化。本文从实践的角度分析各种方法优缺点。背景资料 Latency差异Jeff Dean提到不同数据访问方式latency差异Numbers Everyone Should KnowL1 cache reference 0.5 nsBranch mispredict 5 nsL2 cache reference 7 nsMutex lock/unloc阅读全文 posted @ 2011-07-15 00:34 LixingTie 阅读(29) | 评论 (0) 编辑 | 摘要: 原文地址: http://timyang.net/distributed/multi-idc-consensus/上个月跟某个朋友谈及多IDC数据同时读写访问的问题(tweet)，当时觉得有不少解决方案，但觉得思路还不够清晰。最近看了Google App Engine工程师Ryan Barrett介绍GAE后端数据服务的演讲稿Transactions Across Datacenters(视频)，用Ryan的方法来分析这个问题后就豁然开朗。按Ryan的方法，多IDC实现有以下几种思路。一、Master/slave这个是多机房数据访问最常用的方案，一般的需求用此方案即可。因此大家也经常提到“pr阅读全文 posted @ 2011-07-15 00:32 LixingTie 阅读(18) | 评论 (0) 编辑 | 摘要: 原文地址: http://timyang.net/data/redis-diskstore/Redis作者antirez是一个非常勤奋的开发者，在Redis性能已经非常惊人的情况下持续不断开发新的特性，比如从新的cluster源代码看到，作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化，在Web 2.0时代，Memcached已经非常不够用，技术人员需要考虑做很多额外工作才能让Memcached适应新的变化和需求。antirez在1月5日Google Groups发表了一篇Redis diskstore文章，对R阅读全文 posted @ 2011-07-14 23:58 LixingTie 阅读(145) | 评论 (0) 编辑 | 摘要: 原文地址: http://timyang.net/data/redis-capacity/在使用Redis过程中，我们发现了不少Redis不同于Memcached，也不同于MySQL的特征。(本文主要讨论Redis未启用VM支持情况)1. SchemaMySQL: 需事先设计Memcached: 无需设计Redis: 小型系统可以不用，但是如果要合理的规划及使用Redis，需要事先进行类似如下一些规划数据项: value保存的内容是什么，如用户资料Redis数据类型: 如String, List数据大小: 如100字节记录数: 如100万条(决定是否需要拆分)⋯⋯上面的规划就是一种schema阅读全文 posted @ 2011-07-14 23:57 LixingTie 阅读(132) | 评论 (0) 编辑 | 摘要: 原文地址: http://timyang.net/data/redis-misunderstanding/前几天微博发生了一起大的系统故障，很多技术的朋友都比较关心，其中的原因不会超出James Hamilton在On Designing and Deploying Internet-Scale Service(1)概括的那几个范围，James第一条经验“Design for failure”是所有互联网架构成功的一个关键。互联网系统的工程理论其实非常简单，James paper中内容几乎称不上理论，而是多条实践经验分享，每个公司对这些经验的理解及执行力决定了架构成败。题外话说完，最近又研究了阅读全文 posted @ 2011-07-14 23:46 LixingTie 阅读(93) | 评论 (0) 编辑 | 摘要: 原文地址：http://blogclosed.iteye.com/blog/611976百度百科一致性哈希：http://baike.baidu.com/view/1588037.html在大型web应用中，缓存可算是当今的一个标准开发配置了。在大规模的缓存应用中，应运而生了分布式缓存系统。分布式缓存系统的基本原理，大家也有所耳闻。key-value如何均匀的分散到集群中？说到此，最常规的方式莫过于hash取模的方式。比如集群中可用机器适量为N，那么key值为K的的数据请求很简单的应该路由到hash(K) mod N对应的机器。的确，这种结构是简单的，也是实用的。但是在一些高速发展的web系统阅读全文 posted @ 2011-07-12 12:38 LixingTie 阅读(45) | 评论 (0) 编辑 | 摘要: 注：此文首发于 《程序员》杂志 2008 年 7 月刊。从 Shard 到 Sharding "Shard" 这个词英文的意思是"碎片"，而作为数据库相关的技术用语，似乎最早见于大型多人在线角色扮演游戏(MMORPG)中。"Sharding" 姑且称之为"分片"。Sharding 不是一门新技术，而是一个相对简朴的软件理念。如您所知，MySQL 5 之后才有了数据表分区功能，那么在此之前，很多 MySQL 的潜在用户都对 MySQL 的扩展性有所顾虑，而是否具备分区功能就成了衡量一个数据库可扩展性与否的一个关键指标阅读全文 posted @ 2011-07-12 12:13 LixingTie 阅读(42) | 评论 (0) 编辑 | 摘要: 作者：NinGoo 原文链接：http://www.ningoo.net/html/2010/cap_theorem_and_eventually_consistent.htmlCAP原理(CAP Theorem) 在足球比赛里，一个球员在一场比赛中进三个球，称之为帽子戏法(Hat-trick)。在分布式数据系统中，也有一个帽子原理(CAP Theorem)，不过此帽子非彼帽子。CAP原理中，有三个要素： 一致性(Consistency) 可用性(Availability) 分区容忍性(Partition tolerance) CAP理论告诉我们，一个分布式系统不可能满足一致性，可用性和分区容阅读全文 posted @ 2011-07-12 11:48 LixingTie 阅读(231) | 评论 (0) 编辑 |
|
||
