欢迎大家赞助一杯啤酒🍺 我们准备了下酒菜:Formal mathematics/Isabelle/ML, Formal verification/Coq/ACL2, C++/F#/Lisp
Memlink
(→开发者) |
(→开发者) |
||
第43行: | 第43行: | ||
==开发者== | ==开发者== | ||
− | [[Memlink/developer| | + | [[Memlink/developer|Memlink开发者相关文档]] |
==用户== | ==用户== |
2010年11月13日 (六) 01:43的最后版本
Memlink是一个高性能、持久化、分布式的Key-list/queue数据引擎。正如名称中的memlink所示,所有数据都建构在内存中,保证了系统的高性能(大约是redis几倍),同时使用了redo-log技术保证数据的持久化。Memlink还支持主从复制、读写分离、List过滤操作等功能。
目录 |
[编辑] 特点
- 内存数据引擎,性能极为高效
- List块链结构,精简内存,优化查找效率
- Node数据项可定义,支持多种过滤操作
- 支持redo-log,数据持久化,非Cache模式
- 分布式,主从同步
[编辑] 与Redis区别
redis同样也提供key-list 存储功能,memlink与redis区别有:
- redis比较消耗内存。每个存储节点,在不支持vm的情况下要额外消耗12字节内存,在支持vm的情况下,每个节点额外消耗24字节内存。对于存储上亿条数据来说,额外消耗的内存太大。
- redis redo-log不够完善。redis redo-log机制:每隔一段时间同步磁盘(此期间重启就好丢失数据);追加log方式,会使log文件越来越大,而且性能不够优化。
- 主从同步不完善。如果从节点因为网络原因丢失了部分同步数据,需要重新完全获取一份主节点的所有数据。在大数据量的情况下,不太合适。
- 网络处理主事件循环只有一个线程,不能很好的利用多核;同时读写没有分离,没有进行写优先处理。
- list节点没有mask表,不能进行一些属性过滤。
memlink主要对上述特点进行了改进。
[编辑] 为什么会有Memlink?
对于大型论坛服务,比如百度贴吧、天涯论坛,日均发帖量过百万,日均PV过亿,日积月累下来的帖子数量可能几十亿。这么大的一个论坛服务,海量数据的存储、访问是一个非常有挑战性的技术难题。
中小规模的论坛通常使用mysql/sql server作为后端存储,当数据量膨胀时,比如一个版面有百万、千万级别主贴,一个主贴下有数百万回复,此时使用SQL语句select … order by … limit … ,性能可想而知。
大型论坛中的数据可以抽象为如下几类数据结构:
- 版面信息、主帖信息、回帖信息等。这是Key-Value结构的数据类型,比如主贴id对应主贴的信息(标题、发帖时间、作者等等),回帖id对应回贴的信息(回复内容、回复时间、回复者等等)。
- 版面的主贴列表,主贴列表可按发表时间或者回复时间排序;主贴下的回复列表,等等。这种数据类型是key-list数据类型,而且list是可排序的。
- 其他周边数据。比如斑竹、会员等,由于数据量较小、逻辑关系较复杂,可以使用sql系统存储。比如检索数据,由检索系统承担。等等。
对于Key-Value系统,市面上有较多选择,它们的数据容量大小从数百万到上百亿不等,性能、功能也各有差异,由于讨论KV系统的文章很多,再次不赘述。
对于Key-list系统,市面上可选择的余地就非常小,加之线上工业级别的要求,因而就诞生出了memlink系统。
[编辑] 支持语言
[编辑] 开发者
[编辑] 用户
目前Memlink应用于天涯来吧、天涯论坛系统。
[编辑] 未来
Memlink是专注于key => list\Queue对象的存储系统,所以它内存使用更精简、性能更高效。Key => list\Queue系统作为Key => value另一种形式补充,为高性能海量数据的Web应用提供了新的选择。
[编辑] 链接
<discussion>characters_max=300</discussion>