Quantcast
Channel: 后端技术 by Tim Yang » data
Browsing all 14 articles
Browse latest View live

Image may be NSFW.
Clik here to view.

MemcacheDB, Tokyo Tyrant, Redis performance test

I had tested the following key-value store for set() and get() MemcacheDB, use memcached client protocol. Tokyo Tyrant (Tokyo Cabinet), use memcached client protocol Redis, use JRedis Java client 1....

View Article



Image may be NSFW.
Clik here to view.

Memcached数据被踢(evictions>0)现象分析

很多同学可能熟知Memcached的LRU淘汰算法,它是在slab内部进行的,如果所有空间都被slabs分配,即使另外一个slab里面有空位,仍然存在踢数据可能。你可以把slab理解为教室,如果你的教室满了,即使别的教室有空位你的教室也只能踢人才能进人。...

View Article

Friendfeed的MySQL key/value存储

这是一篇2009年初的资料How FriendFeed uses MySQL to store schema-less data,相信大部分人已经看过了。如Fenng的中文介绍FriendFeed 使用 MySQL 的经验。本文从不同的角度再补充下。作者几个月前也曾经在广州技术沙龙作过一次Key value store漫谈的演讲,许多参会人员对key...

View Article

Image may be NSFW.
Clik here to view.

Dynamo一个缺陷的架构设计(译)

在云计算的时代,Dynamo可以说是一本实现分布式存储的红宝书,借鉴Dynamo实现的产品如雨后春笋般冒出。前段时间本人曾在Twitter上戏称 这年头,如果一个号称有“海量数据”的互联网公司,不做一个自己的Dynamo, 出去都不好意思跟人打招呼 (http://twitter.com/xmpp/status/8023241449)...

View Article

多IDC的数据分布设计(二)

在前文《多IDC的数据分布设计(一)》中介绍了多IDC数据一致性的几种实现原理,遗憾的是,目前虽然有不少分布式产品,但几乎都没有开源的产品专门针对IDC来优化。本文从实践的角度分析各种方法优缺点。 背景资料 Latency差异 Jeff Dean提到不同数据访问方式latency差异 Numbers Everyone Should Know L1 cache reference...

View Article


Twitter停用Cassandra原因分析

Twitter在其7.9一篇官方技术博客Cassandra at Twitter Today提到暂停使用Cassandra来代替MySQL存储feed的计划,这是Twitter一个重要的架构策略调整,因为之前Twitter一直是业界Cassandra方向的领头羊。 For now, we’re not working on using Cassandra as a store for Tweets....

View Article

Redis几个认识误区

前几天微博发生了一起大的系统故障,很多技术的朋友都比较关心,其中的原因不会超出James Hamilton在On Designing and Deploying Internet-Scale Service(1)概括的那几个范围,James第一条经验“Design for failure”是所有互联网架构成功的一个关键。互联网系统的工程理论其实非常简单,James...

View Article

Redis容量及使用规划

在使用Redis过程中,我们发现了不少Redis不同于Memcached,也不同于MySQL的特征。 (本文主要讨论Redis未启用VM支持情况) 1. Schema MySQL: 需事先设计 Memcached: 无需设计 Redis: 小型系统可以不用,但是如果要合理的规划及使用Redis,需要事先进行类似如下一些规划 数据项: value保存的内容是什么,如用户资料 Redis数据类型:...

View Article


Redis新的存储模式diskstore

Redis作者antirez是一个非常勤奋的开发者,在Redis性能已经非常惊人的情况下持续不断开发新的特性,比如从新的cluster源代码看到,作者已经把Dynamo及Paxos一些核心的思想考虑进去并进行了一些简洁的实现。相比其它产品如Memcached则几年没什么大变化,在Web...

View Article


Image may be NSFW.
Clik here to view.

Cassandra代替Redis?

最近用Cassandra的又逐渐多了,除了之前的360案例,在月初的QCon Shanghai 2013 篱笆网也介绍了其使用案例。而这篇百万用户时尚分享网站feed系统扩展实践文章则提到了Fashiolista和Instagram从Redis迁移到Cassandra的案例。考虑到到目前仍然有不少网友在讨论Redis的用法问题,Redis是一个数据库、内存、还是Key value...

View Article

Image may be NSFW.
Clik here to view.

分布式缓存的一起问题

背景说明 分布式缓存中为了可用性及高性能的考虑,可以使用如下一种master/slave设计模式。 图中的proxy是逻辑的概念,可以是基于client的包装实现,也可以是独立的proxy服务,但本文大部分是指独立的服务。几个主要的问题说明如下。 为什么cache要使用两个集群((master/slave)来存放?...

View Article

Image may be NSFW.
Clik here to view.

为什么超长列表数据的翻页技术实现复杂

今天讨论了一个传统的问题,问题本身比较简单,就是针对key-list类型的数据,如何优化方案做到性能与成本的tradeoff。Key-list在用户类型的产品中非常普遍,如一个用户的好友关系 {“uid”:{1,2,3,4,5}},表示uid包含有5个好友;一条微博下面的评论id列表{“weibo_id”: {comment_id1, comment_id2……}},一个用户发表的微博id列表等。...

View Article

Image may be NSFW.
Clik here to view.

Feed消息队列架构分析

最近一两年,大部分系统的数据流由基于日志的离线处理方式转变成实时的流式处理方式,并逐渐形成几种通用的使用方式,以下介绍微博的消息队列体系。 当前的主要消息队列分成如图3部分: 1、feed信息流主流程处理,图中中间的流程,通过相关MQ...

View Article


Image may be NSFW.
Clik here to view.

为什么超长列表数据的翻页技术实现复杂(二)

上文为什么超长列表数据的翻页技术实现复杂提到了超长列表翻页技术设计上一些问题,今天讨论下部分解决思路。 前新浪同事 @pi1ot 最近在程序员杂志发表的一篇文章《门户级UGC系统的技术进化路线》也是超长列表的一个经典案例,在正式展开思路之前,我们也不妨了解一下此文所说新浪评论系统的演进思路。 从文中看到几个版本的列表翻页实现方案 3.0版...

View Article
Browsing all 14 articles
Browse latest View live


Latest Images