d*******r
发帖数: 3299 | 1 最近在研究 memory database，做 queuing， cache 和 简单查询。
Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
大牛们有无推荐? |
g*****g
发帖数: 34805 | 2 你到底需要那些特性？只是cache的话memcached, 相似的还有Riak.
【在 d*******r 的大作中提到】
: 最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
: 大牛们有无推荐?
|
y***y
发帖数: 224 | 3 数据关系比较复杂的话用什么最好？ 或者应该上graph database？ |
d*******r
发帖数: 3299 | 4 就是把实时采集到的用户端数据，基本都放在内存(过了几秒以上的，persisent到硬盘
)，然后用内存database里的数据，做一些非常实时的计算 (要支持比较复杂的查询)。
具体的需求还在完善。但是我想要一个快的，而且强大的 memory database, 这样后续
开发方便。
看了 Redis 的表现能力，觉得很爽。就是不支持 Cluster scale out.
Riak 用的人很少吧。我怕查不到资料和经验。难道 Riak 有 Redis 一样高性能的的内
存数据库功能，persistent 做得还比 Redis 好很多？我知道 Riak scale out 不错的。
【在 g*****g 的大作中提到】
: 你到底需要那些特性？只是cache的话memcached, 相似的还有Riak.
|
g*****g
发帖数: 34805 | 5 Maybe Elastic Search is your answer.
的。
【在 d*******r 的大作中提到】
: 就是把实时采集到的用户端数据，基本都放在内存(过了几秒以上的，persisent到硬盘
: )，然后用内存database里的数据，做一些非常实时的计算 (要支持比较复杂的查询)。
: 具体的需求还在完善。但是我想要一个快的，而且强大的 memory database, 这样后续
: 开发方便。
: 看了 Redis 的表现能力，觉得很爽。就是不支持 Cluster scale out.
: Riak 用的人很少吧。我怕查不到资料和经验。难道 Riak 有 Redis 一样高性能的的内
: 存数据库功能，persistent 做得还比 Redis 好很多？我知道 Riak scale out 不错的。
|
d*******r
发帖数: 3299 | 6 看了下ElasticSearch介绍，用起来像 NoSQL DB 的搜索存储servce? 看样子是主要提
供很强的 RESTful search API.
我觉得我主要是要快，search 的功能要不到 ElasticSearch 那么强。
我想从end端用户采集信息-->存到我们server上的内存DB-->viewer端检索出部分出来
represent
viewer端是些 interactive的charts,
e.g. http://code.shutterstock.com/rickshaw/examples/extensions.html
实际的charts比这个复杂，很多charts还要联动，支持real time的随便调整参数
整个过程 (end端->server端->viewer端) 延迟我想控制在 ms 级别，最多不超过 1s.
所以我主要是想快, 我都打算所有通信用 JSON over TCP, 不用 HTTP 了。
end 端 是我们自己的 app，可以不用 HTTP 提交数据。
viewer端(e.g. browser) 和中间 server 的通信，我打算用 websocket.
【在 g*****g 的大作中提到】
: Maybe Elastic Search is your answer.
:
: 的。
|
g*****g
发帖数: 34805 | 7 高并发的我比较熟，要保证延迟的实时系统我不会，不想误导你。
【在 d*******r 的大作中提到】
: 看了下ElasticSearch介绍，用起来像 NoSQL DB 的搜索存储servce? 看样子是主要提
: 供很强的 RESTful search API.
: 我觉得我主要是要快，search 的功能要不到 ElasticSearch 那么强。
: 我想从end端用户采集信息-->存到我们server上的内存DB-->viewer端检索出部分出来
: represent
: viewer端是些 interactive的charts,
: e.g. http://code.shutterstock.com/rickshaw/examples/extensions.html
: 实际的charts比这个复杂，很多charts还要联动，支持real time的随便调整参数
: 整个过程 (end端->server端->viewer端) 延迟我想控制在 ms 级别，最多不超过 1s.
: 所以我主要是想快, 我都打算所有通信用 JSON over TCP, 不用 HTTP 了。
|
a***n
发帖数: 538 | 8 MongoDB吧，快的时候不到1ms。查询很方便。就是偶尔会卡住，不过也不会超过1s的吧。 |
N********n
发帖数: 8363 | 9
你的数据量真大到要用CLUSTER CACHE了？还有你的数据之间COUPLING是高
还是低？高的话就不那么容易SCALE OUT了，除非你在STALENESS上让步。
【在 d*******r 的大作中提到】
: 最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
: 大牛们有无推荐?
|
g****r
发帖数: 1589 | 10 you can do your own client side hashing with Redis
【在 d*******r 的大作中提到】
: 最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
: 大牛们有无推荐?
|
|
|
d*******r
发帖数: 3299 | 11 是的，上头一定要求要能随便 scale out
我数据之间 COUPLING 很低，基本是些实时的client端的 performance metrics.
【在 N********n 的大作中提到】
:
: 你的数据量真大到要用CLUSTER CACHE了？还有你的数据之间COUPLING是高
: 还是低？高的话就不那么容易SCALE OUT了，除非你在STALENESS上让步。
|
d*******r
发帖数: 3299 | 12 这样只解决了 client side 写到 Redis 的 load balancing 的问题吧，相当于让
clients 随机均衡地写各个 Redis nodes。回头我要在这些各自独立的 Redis nodes上
做各种querying还是不方便。
【在 g****r 的大作中提到】
: you can do your own client side hashing with Redis
|
d*******r
发帖数: 3299 | 13 你用MongoDB cluster 做过大系统吗，说说经验
吧。
【在 a***n 的大作中提到】
: MongoDB吧，快的时候不到1ms。查询很方便。就是偶尔会卡住，不过也不会超过1s的吧。
|
a***n
发帖数: 538 | 14 很久以前用过，大概100M个doc，1TB左右的数据吧, 没什么不好的单机可以达到4，5k/
s的query吧。就是不怎么稳定。
primary死掉以后也不是立即elect，有时候干脆变成只读的了，不过我觉得这也可能是
配置问题吧，DBA是个什么都不懂的烙印。
【在 d*******r 的大作中提到】
: 你用MongoDB cluster 做过大系统吗，说说经验
:
: 吧。
|
d*******r
发帖数: 3299 | 15 几年前？现在应该改进不少吧。
尼玛 MongoDB 也要 DBA? 不是 dev 一并做了吗
5k/
【在 a***n 的大作中提到】
: 很久以前用过，大概100M个doc，1TB左右的数据吧, 没什么不好的单机可以达到4，5k/
: s的query吧。就是不怎么稳定。
: primary死掉以后也不是立即elect，有时候干脆变成只读的了，不过我觉得这也可能是
: 配置问题吧，DBA是个什么都不懂的烙印。
|
a***n
发帖数: 538 | 16 1年前吧。
【在 d*******r 的大作中提到】
: 几年前？现在应该改进不少吧。
: 尼玛 MongoDB 也要 DBA? 不是 dev 一并做了吗
:
: 5k/
|
d*******r
发帖数: 3299 | 17 请问你说的快的时候不到1ms，是在在你们 Mongo cluster上读写吗？
你们 cluster 规模大概有多少？还是一个 powerful 的单机 server?
吧。
【在 a***n 的大作中提到】
: MongoDB吧，快的时候不到1ms。查询很方便。就是偶尔会卡住，不过也不会超过1s的吧。
|
a***n
发帖数: 538 | 18 好像有5个吧。不过mongodb有replicate和master/slave两种模式，再shard，很不好用。
【在 d*******r 的大作中提到】
: 请问你说的快的时候不到1ms，是在在你们 Mongo cluster上读写吗？
: 你们 cluster 规模大概有多少？还是一个 powerful 的单机 server?
:
: 吧。
|
d*******r
发帖数: 3299 | 19 这个具体怎么讲
用。
【在 a***n 的大作中提到】
: 好像有5个吧。不过mongodb有replicate和master/slave两种模式，再shard，很不好用。
|
a***n
发帖数: 538 | 20 我觉得设计的人开始没有设计成能做很大的cluster。不过大数据我也没有什么经验。
【在 d*******r 的大作中提到】
: 这个具体怎么讲
:
: 用。
|
|
|
d*******r
发帖数: 3299 | 21 依然没有... 尼玛没有人怒了自己去写一个吗 ... |
v***e
发帖数: 2108 | 22 couchbase = cluster + memcached + couchdb + xdcr
used by many enterprise customers, this is exactly what you want
【在 d*******r 的大作中提到】
: 最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
: 大牛们有无推荐?
|
d*******r
发帖数: 3299 | 23 这个公司现在有好几个产品，看着好乱不敢用
它这个使用者是怎么算的
http://www.couchbase.com/company
【在 v***e 的大作中提到】
: couchbase = cluster + memcached + couchdb + xdcr
: used by many enterprise customers, this is exactly what you want
|
v***e
发帖数: 2108 | 24 正派产品就一个，Couchbase Server，我们一直用
scalability比mongo好太多，还有mongo没有的
cross-datacenter replication（XDCR）和UI
get/set performance比cassandra强，因为是围绕
memcached 写的。
这些应该都是paid customer吧，不想花钱就用community
version好了，功能和enterprise version一样
当然，具体还要看你的需要
【在 d*******r 的大作中提到】
: 这个公司现在有好几个产品，看着好乱不敢用
: 它这个使用者是怎么算的
: http://www.couchbase.com/company
|
d*******r
发帖数: 3299 | 25 那你说的 community version 比 enterprise version 差在哪里？
memcached 是已经集成进 Couchbase Server了，还是 Couchbase Server 自己用
Erlang 实现了一个类似 memcached 的服务？
好不容易发现个用 Erlang 系的... 满版只有 C/C++ VS Java 有木有...
所以顺便问下，你们用 Rabbitmq 吗？这货如何?
【在 v***e 的大作中提到】
: 正派产品就一个，Couchbase Server，我们一直用
: scalability比mongo好太多，还有mongo没有的
: cross-datacenter replication（XDCR）和UI
: get/set performance比cassandra强，因为是围绕
: memcached 写的。
: 这些应该都是paid customer吧，不想花钱就用community
: version好了，功能和enterprise version一样
: 当然，具体还要看你的需要
|
p*****2
发帖数: 21240 | 26
message queue我还没研究过。大牛研究一下给个summary？
【在 d*******r 的大作中提到】
: 那你说的 community version 比 enterprise version 差在哪里？
: memcached 是已经集成进 Couchbase Server了，还是 Couchbase Server 自己用
: Erlang 实现了一个类似 memcached 的服务？
: 好不容易发现个用 Erlang 系的... 满版只有 C/C++ VS Java 有木有...
: 所以顺便问下，你们用 Rabbitmq 吗？这货如何?
|
d*******r
发帖数: 3299 | 27 同研究中... 好像 Rabbitmq 功能挺强的
最近在琢磨能不能组些 vert.x 节点，简单写点东西，就当 message services 用了
【在 p*****2 的大作中提到】
:
: message queue我还没研究过。大牛研究一下给个summary？
|
p*****2
发帖数: 21240 | 28
我感觉这个是个好选择
https://github.com/ptaoussanis/carmine
【在 d*******r 的大作中提到】
: 同研究中... 好像 Rabbitmq 功能挺强的
: 最近在琢磨能不能组些 vert.x 节点，简单写点东西，就当 message services 用了
|
v***e
发帖数: 2108 | 29
到目前为止没差，一样的。当然enterprise license有support
不过将来就不知道了
是的，Couchbase Server的caching layer就是memcached + persistence，
是一个C/C++ process，当然加了很多改进，但还是兼容memcached binary protocol
很多enterprise user 用couchbase构建很大的cluster，但是developer里面，
couchbase用的就比mongdo少。
Erlang不太可能写memcached，不是用来干这个的。
Couchbase Server架构里面除了memcached，是还有一大块Erlang process
不过是用来做cluster management和couchdb的
好像用的，具体不太清楚。
【在 d*******r 的大作中提到】
: 那你说的 community version 比 enterprise version 差在哪里？
: memcached 是已经集成进 Couchbase Server了，还是 Couchbase Server 自己用
: Erlang 实现了一个类似 memcached 的服务？
: 好不容易发现个用 Erlang 系的... 满版只有 C/C++ VS Java 有木有...
: 所以顺便问下，你们用 Rabbitmq 吗？这货如何?
|
g*******o
发帖数: 156 | 30 或者0MQ ? 或者netty里面的mq?
【在 d*******r 的大作中提到】
: 同研究中... 好像 Rabbitmq 功能挺强的
: 最近在琢磨能不能组些 vert.x 节点，简单写点东西，就当 message services 用了
|
|
|
d*******r
发帖数: 3299 | 31 这些都太底层了，
zeromq 有核心离开了，搞了个 www.crossroads.io
vert.x 是 build 在 netty 上的，直接用更方便
【在 g*******o 的大作中提到】
: 或者0MQ ? 或者netty里面的mq?
|
d*******r
发帖数: 3299 | 32 赞详细解释
【在 v***e 的大作中提到】
:
: 到目前为止没差，一样的。当然enterprise license有support
: 不过将来就不知道了
: 是的，Couchbase Server的caching layer就是memcached + persistence，
: 是一个C/C++ process，当然加了很多改进，但还是兼容memcached binary protocol
: 很多enterprise user 用couchbase构建很大的cluster，但是developer里面，
: couchbase用的就比mongdo少。
: Erlang不太可能写memcached，不是用来干这个的。
: Couchbase Server架构里面除了memcached，是还有一大块Erlang process
: 不过是用来做cluster management和couchdb的
|
d*******r
发帖数: 3299 | 33 展开说说？还是只是因为是 Clojure 的 Redis msq queue?
【在 p*****2 的大作中提到】
:
: 我感觉这个是个好选择
: https://github.com/ptaoussanis/carmine
|
p*****2
发帖数: 21240 | 34
用redis做queue更方便了。
不过你要用vert的话，直接用它的mb酸了。
【在 d*******r 的大作中提到】
: 展开说说？还是只是因为是 Clojure 的 Redis msq queue?
|
d*******r
发帖数: 3299 | 35 我看了下，vert.x message bus 貌似还是太简单，只有基本功能，
如果要把很多 messages 扔到到一个分布式内存 DB 中，然后还要支持很快的自定义的
查询读写，貌似 "Redis Cluster" 之类的最好，但是丫还处于难产的"开发中"阶段
【在 p*****2 的大作中提到】
:
: 用redis做queue更方便了。
: 不过你要用vert的话，直接用它的mb酸了。
|
p*****2
发帖数: 21240 | 36
你需要什么样的concurrency呀？
【在 d*******r 的大作中提到】
: 我看了下，vert.x message bus 貌似还是太简单，只有基本功能，
: 如果要把很多 messages 扔到到一个分布式内存 DB 中，然后还要支持很快的自定义的
: 查询读写，貌似 "Redis Cluster" 之类的最好，但是丫还处于难产的"开发中"阶段
|
d*******r
发帖数: 3299 | 37 回二爷，
前面说了延迟需求，
我们视频直播，平时没多少人看，就是直播时候concurrent users多，上头要求峰值时
候大概要支持end端的 50M concurrent users' clients 同时提交 metrics 数据(但愿
达不到这个...)，每人每10~30sec 发一个包含metrics 数据的 message到我们server
上的内存DB，每个 message 大概 1K bytes 大小。所以至少是 50M*1K/30sec = 1.
7Gbytes/sec 数据。我虽然有networking背景，但是没有写过这种大并发实时app，不
知道这样直接估计对不对。 |
p*****2
发帖数: 21240 | 38
server
大牛不考虑一下storm呀？
【在 d*******r 的大作中提到】
: 回二爷，
: 前面说了延迟需求，
: 我们视频直播，平时没多少人看，就是直播时候concurrent users多，上头要求峰值时
: 候大概要支持end端的 50M concurrent users' clients 同时提交 metrics 数据(但愿
: 达不到这个...)，每人每10~30sec 发一个包含metrics 数据的 message到我们server
: 上的内存DB，每个 message 大概 1K bytes 大小。所以至少是 50M*1K/30sec = 1.
: 7Gbytes/sec 数据。我虽然有networking背景，但是没有写过这种大并发实时app，不
: 知道这样直接估计对不对。
|
g*******o
发帖数: 156 | 39 听起来storm+kafka可能适合啊～～
kafka的batch模式throughput大概2台小vm可以handle 20k/sec messages.如果换成更
强大的vm应该能handle更多。
server
【在 d*******r 的大作中提到】
: 回二爷，
: 前面说了延迟需求，
: 我们视频直播，平时没多少人看，就是直播时候concurrent users多，上头要求峰值时
: 候大概要支持end端的 50M concurrent users' clients 同时提交 metrics 数据(但愿
: 达不到这个...)，每人每10~30sec 发一个包含metrics 数据的 message到我们server
: 上的内存DB，每个 message 大概 1K bytes 大小。所以至少是 50M*1K/30sec = 1.
: 7Gbytes/sec 数据。我虽然有networking背景，但是没有写过这种大并发实时app，不
: 知道这样直接估计对不对。
|
T*U
发帖数: 22634 | 40 hekaton
【在 d*******r 的大作中提到】
: 最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
: 大牛们有无推荐?
|
|
|
a***n
发帖数: 538 | 41 好像很难用啊，我的同事扯这个大半年了，也没有看见做出什么像样的东西来。
【在 p*****2 的大作中提到】
:
: server
: 大牛不考虑一下storm呀？
|
g*******o
发帖数: 156 | 42 用clojure就出的很快了～～
不过在guarantees data processing处理大量数据流的时候，对network latency很敏
感。
【在 a***n 的大作中提到】
: 好像很难用啊，我的同事扯这个大半年了，也没有看见做出什么像样的东西来。
|
p*****2
发帖数: 21240 | 43
其实storm真的算是易用了。这个zhaoce大牛可以证明.
【在 a***n 的大作中提到】
: 好像很难用啊，我的同事扯这个大半年了，也没有看见做出什么像样的东西来。
|
z****e
发帖数: 54598 | 44 i agree
but for some people
who dont have too much experiences in using 3rd party tools
i dont think it would be easy for them
【在 p*****2 的大作中提到】
:
: 其实storm真的算是易用了。这个zhaoce大牛可以证明.
|
z****e
发帖数: 54598 | 45 spark spark
【在 g*******o 的大作中提到】
: 听起来storm+kafka可能适合啊～～
: kafka的batch模式throughput大概2台小vm可以handle 20k/sec messages.如果换成更
: 强大的vm应该能handle更多。
:
: server
|
a***n
发帖数: 538 | 46 据说不是实时的？
【在 z****e 的大作中提到】
: spark spark
|
q*c
发帖数: 9453 | 47 就是因为这样不错那样不错，所以 cluster 搞不定。
transaction 可不容易。
【在 d*******r 的大作中提到】
: 最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。
: 大牛们有无推荐?
|
p*****2
发帖数: 21240 | 48
大牛说的是。我觉得也是这么个问题
【在 q*c 的大作中提到】
: 就是因为这样不错那样不错，所以 cluster 搞不定。
: transaction 可不容易。
|
d*******r
发帖数: 3299 | 49 之前琢磨过 kafka+storm, 后来觉得这俩东西性价比不高，就是 (能用他们干的事情)/
(学习试错成本) 不太划算。
就拿 kafka 来说，你想写点复杂点的 query 咋办? 貌似听goodbug说最近 v0.8 才真
正支持分布式的？觉得还不如把数据存在某种 NoSQL DB 里面算了，要是追求存取速度
，就搞 Redis+硬盘DB 这种组合。storm 处理的问题就更 specific 了，而且要用
Clojure 我还是怕组里的人吃不消。
【在 g*******o 的大作中提到】
: 用clojure就出的很快了～～
: 不过在guarantees data processing处理大量数据流的时候，对network latency很敏
: 感。
|
d*******r
发帖数: 3299 | 50 大牛说的是，难道不能牺牲点一致性
【在 q*c 的大作中提到】
: 就是因为这样不错那样不错，所以 cluster 搞不定。
: transaction 可不容易。
|
|
|
d*******r
发帖数: 3299 | 51 这是神马高科技?
【在 T*U 的大作中提到】
: hekaton
|
z****e
发帖数: 54598 | 52 我打算vert.x试用一段时间后
如果没问题，以后就替换掉storm这些
就用一个vert.x好了
)/
【在 d*******r 的大作中提到】
: 之前琢磨过 kafka+storm, 后来觉得这俩东西性价比不高，就是 (能用他们干的事情)/
: (学习试错成本) 不太划算。
: 就拿 kafka 来说，你想写点复杂点的 query 咋办? 貌似听goodbug说最近 v0.8 才真
: 正支持分布式的？觉得还不如把数据存在某种 NoSQL DB 里面算了，要是追求存取速度
: ，就搞 Redis+硬盘DB 这种组合。storm 处理的问题就更 specific 了，而且要用
: Clojure 我还是怕组里的人吃不消。
|
z****e
发帖数: 54598 | 53 tim以前就是做mq的
【在 d*******r 的大作中提到】
: 同研究中... 好像 Rabbitmq 功能挺强的
: 最近在琢磨能不能组些 vert.x 节点，简单写点东西，就当 message services 用了
|
z****e
发帖数: 54598 | 54 哇，感觉你这个跟netflix的很接近
都是做流式数据的，问问古德霸他们吧
server
【在 d*******r 的大作中提到】
: 回二爷，
: 前面说了延迟需求，
: 我们视频直播，平时没多少人看，就是直播时候concurrent users多，上头要求峰值时
: 候大概要支持end端的 50M concurrent users' clients 同时提交 metrics 数据(但愿
: 达不到这个...)，每人每10~30sec 发一个包含metrics 数据的 message到我们server
: 上的内存DB，每个 message 大概 1K bytes 大小。所以至少是 50M*1K/30sec = 1.
: 7Gbytes/sec 数据。我虽然有networking背景，但是没有写过这种大并发实时app，不
: 知道这样直接估计对不对。
|
z****e
发帖数: 54598 | 55 你要是不怕牺牲一致性的话
那就上cassandra？
这个高并发估计问题不大，文档也多
不过你们视频直播这种我没试过
如果不怕麻烦的话，c*和storm准备两套方案
最后看看表现如何，这个要测试一下才行
感觉akka也行啊，卡卡
【在 d*******r 的大作中提到】
: 大牛说的是，难道不能牺牲点一致性
|
z****e
发帖数: 54598 | 56 恩，好像是，会顿，不适合看视频这种领域
【在 a***n 的大作中提到】
: 据说不是实时的？
|
z****e
发帖数: 54598 | 57 想了下，c*不合适，还是storm吧
要么就是内存数据库，redis貌似不错得样子
你自己写一点cluster得功能也没那么难了
反正你们只是查，没有大面积的改写数据which适用于c*
所以你有两套方案，内存数据库vs流式处理
也就是redis/mongo vs storm这些
storm不需要你用clojure，除非有bug
否则你不用clojure也没啥大不了的
如果真怕，用jstorm吧，淘宝的人做的
建议你做两套，然后看看表现如何
哪个好留哪个
看了下redis，感觉真不错
观后感是
写内存计数器的eq简直是降到了零点以下
整个一负数 |
z****e
发帖数: 54598 | 58 vert.x有一个流式媒体的module
基本上功能直接对应storm
然后tim以前就是做mq的
但是我没试过这样效果如何
不能保证 |
d*******r
发帖数: 3299 | 59 我觉得我的处理数据的逻辑其实挺简单的，重点在快速存取，支持一些复杂的querying，
可能上 MongoDB + Redis 就行了，回头 MongoDB 扛不住写，再琢磨下 C*.
【在 z****e 的大作中提到】
: 想了下，c*不合适，还是storm吧
: 要么就是内存数据库，redis貌似不错得样子
: 你自己写一点cluster得功能也没那么难了
: 反正你们只是查，没有大面积的改写数据which适用于c*
: 所以你有两套方案，内存数据库vs流式处理
: 也就是redis/mongo vs storm这些
: storm不需要你用clojure，除非有bug
: 否则你不用clojure也没啥大不了的
: 如果真怕，用jstorm吧，淘宝的人做的
: 建议你做两套，然后看看表现如何
|
z****e
发帖数: 54598 | 60 如果只是mongodb抗不住的话
你换一个couchdb试试
couchdb vs mongodb
like
cassandra vs hbase
querying，
【在 d*******r 的大作中提到】
: 我觉得我的处理数据的逻辑其实挺简单的，重点在快速存取，支持一些复杂的querying，
: 可能上 MongoDB + Redis 就行了，回头 MongoDB 扛不住写，再琢磨下 C*.
|
|
|
d*******r
发帖数: 3299 | 61 我其实没懂这个类比，为啥呢
【在 z****e 的大作中提到】
: 如果只是mongodb抗不住的话
: 你换一个couchdb试试
: couchdb vs mongodb
: like
: cassandra vs hbase
:
: querying，
|
z****e
发帖数: 54598 | 62 couchdb&c* - a+p
mongodb&h* - c+p
【在 d*******r 的大作中提到】
: 我其实没懂这个类比，为啥呢
|
d*******r
发帖数: 3299 | 63 多谢~~
【在 z****e 的大作中提到】
: couchdb&c* - a+p
: mongodb&h* - c+p
|
z****e
发帖数: 54598 | 64 couchdb 就是 mongodb的ap版本
大部分原理跟mongodb类似
但就是不强调一致性，而强调availability |
v***e
发帖数: 2108 | 65 Couchbase，not CouchDB
【在 z****e 的大作中提到】
: couchdb 就是 mongodb的ap版本
: 大部分原理跟mongodb类似
: 但就是不强调一致性，而强调availability
|
d*******r
发帖数: 3299 | |
z****e
发帖数: 54598 | 67 no
couchbase是商用产品
couchdb是apache的开源产品
别搞错了
couchbase类似couchdb+redis这样
他们自己有一个memcache的东西
所以如果搂主只是mongodb不顶用
换成couchdb可能就可以了
【在 v***e 的大作中提到】
: Couchbase，not CouchDB
|
v***e
发帖数: 2108 | 68 CouchDB根本不是楼主需要的那种。
我认为你根本不知道你在说什么。
【在 z****e 的大作中提到】
: no
: couchbase是商用产品
: couchdb是apache的开源产品
: 别搞错了
: couchbase类似couchdb+redis这样
: 他们自己有一个memcache的东西
: 所以如果搂主只是mongodb不顶用
: 换成couchdb可能就可以了
|
z****e
发帖数: 54598 | 69 看图
搂主都用了redis+mongodb了
现在是mongodb撑不住
换个couchdb就好了，牺牲一下一致性
你用couchbase反而有重叠
【在 v***e 的大作中提到】
: CouchDB根本不是楼主需要的那种。
: 我认为你根本不知道你在说什么。
|
v***e
发帖数: 2108 | 70 正以为楼主需要的是redis+mongo之类的，所以couchdb
根本不是楼主需要的，而couchbase才是
couchdb是distributed datastore，全Erlang，不能提供楼主要求
的high performance caching 和 in-memory operation,
Couchbase 是memcached (caching) + Couchdb （只用在persisted db layer)
+ cluster + XDCR
Couchdb在商业上并不成功，只有Cloudant之类的还在围绕it开发，而Couchbase
是和Mongo，Cassandra一起的NoSQL DB market 三驾马车
楼主原帖 “最近在研究 memory database，做 queuing， cache 和 简单查询。
Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。”
【在 z****e 的大作中提到】
: 看图
: 搂主都用了redis+mongodb了
: 现在是mongodb撑不住
: 换个couchdb就好了，牺牲一下一致性
: 你用couchbase反而有重叠
|
|
|
d*******r
发帖数: 3299 | 71 再次感谢详细解答！之前就一直没搞懂 couchdb 公司那几个产品的关系。
【在 v***e 的大作中提到】
: 正以为楼主需要的是redis+mongo之类的，所以couchdb
: 根本不是楼主需要的，而couchbase才是
: couchdb是distributed datastore，全Erlang，不能提供楼主要求
: 的high performance caching 和 in-memory operation,
: Couchbase 是memcached (caching) + Couchdb （只用在persisted db layer)
: + cluster + XDCR
: Couchdb在商业上并不成功，只有Cloudant之类的还在围绕it开发，而Couchbase
: 是和Mongo，Cassandra一起的NoSQL DB market 三驾马车
: 楼主原帖 “最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。”
|
z****e
发帖数: 54598 | 72 我知道你的意思了
你要用couchbase整个替换掉mongodb+redis
我说的是，如果只是mongodb顶不住的话
换成couchdb就好了，并没有打算替换掉redis，还照用
couchdb从某种意义上说只是couchbase的子集
当然略有不同，这样做的好处是可以继续保留有redis
而不用被couchbase给捆绑住手脚
http://www.couchbase.com/couchbase-vs-couchdb
【在 v***e 的大作中提到】
: 正以为楼主需要的是redis+mongo之类的，所以couchdb
: 根本不是楼主需要的，而couchbase才是
: couchdb是distributed datastore，全Erlang，不能提供楼主要求
: 的high performance caching 和 in-memory operation,
: Couchbase 是memcached (caching) + Couchdb （只用在persisted db layer)
: + cluster + XDCR
: Couchdb在商业上并不成功，只有Cloudant之类的还在围绕it开发，而Couchbase
: 是和Mongo，Cassandra一起的NoSQL DB market 三驾马车
: 楼主原帖 “最近在研究 memory database，做 queuing， cache 和 简单查询。
: Redis 看着真心不错，还支持 transaction, 丫的就是 cluster 模式还没搞出来。”
|
c******o
发帖数: 1277 | 73 spark-Streaming 是实时的。
据说比storm 快
【在 a***n 的大作中提到】
: 据说不是实时的？
|
