Comments on: LightCloud的设计原理

By: Volcano

Volcano — Tue, 08 Mar 2011 03:19:36 +0000

@fjctlzy 谢谢提醒，我去看看怎么实现的

By: fjctlzy

fjctlzy — Tue, 08 Mar 2011 02:27:44 +0000

http://code.google.com/p/lightcloud-phpclient/
这个代码解决了当增加storage的时候，lookup会更新节点位置
当增加lookup的时候，也需要更新节点的位置。

By: Volcano

Volcano — Tue, 04 Jan 2011 14:33:18 +0000

1. 我从LightCloud的源码里没有找到数据迁移的动作，一般逻辑也就是直接根据hash算法直接从StorageNode寻找数据，如果没找到才从LookupRing寻找记录。
2. 最简的模型可以使用一组Lookup节点，但是扩充的时候会面临StorgeNode扩容时相同的问题
3. 没太明白
4. LookupRing的存在主要就是为了动态增加StorageNode，如果不考虑增加存储节点，当然不需要LookupRing

By: KnightE

KnightE — Tue, 28 Dec 2010 02:05:00 +0000

有几个疑问：
1.通过LookupRing来找到StorageNode上的数据后，是否需要对数据做一次迁移？把数据从旧的存储节点转移到新的存储节点，同时修改LookupNode中的指向？理论上是需要做的，否则在破坏节点的数据平衡，不过我粗粗算了下，需要6次操作才能完成。
2.LookupRing是否能简化成一组Lookup节点组？
3.Ketama比市面上常见的一致性哈希程序性能高很多，但貌似没有原生支持回溯映射列表，当然通过动态修改配置应该可以获得回溯列表。不过我看你代码里没有类似LightCloud回溯3个节点来反向匹配节点，这样LookupRing的扩展能力似乎就大大减弱？
4.其实我最疑惑的问题是，不管用什么一致性哈希算法，如果支持返回回溯列表，我总觉得LookupRing没有什么存在的必要。假设我能回溯一个key的N个节点，通过遍历这个列表同样能最大程度找到这个key对应的存储节点和值，通过LookupRing来实现，是否画蛇添足了？

LightCloud的资料好像不是很多，也没有去看他源码，能看到的都是本文一致的文章。有什么误解请指教。

By: amton

amton — Sun, 04 Jul 2010 08:48:11 +0000

http://code.google.com/p/lightcloud-phpclient/

By: Volcano

Volcano — Fri, 19 Mar 2010 00:33:37 +0000

NoSQL数据库可以在某些场合代替mysql，需要根据自己的实际情况考量。

python版的lightcloud在plurk的生产环境中已经使用很长时间，性能和负载占用的表现也不错。但是我写的litecloud还不算完善，不建议投入生产环境使用。

By: myDream

myDream — Thu, 18 Mar 2010 18:48:30 +0000

查询呢？上次看到有人说mysql这种关系型数据库可以很轻松组织数据，但是像lightcloud可行吗？并，这个可以直接投入生产环境使用吗？