卡桑德拉 vs 里亚克

发布于 2024-08-18 12:36:16 字数 1431 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

再可℃爱ぅ一点好了 2024-08-25 12:36:16

您可能知道,它们在架构上都受到 Dynamo 的强烈影响(最终一致、无单点故障等)。两者都超越了 Dynamo,提供了“比纯 K/V 更丰富”的数据模型——在 Cassandra 的例子中,提供了一种类似 Bigtable 的 ColumnFamily 模式,在 Riak 的例子中,提供了一种面向文档的模式。我见过理智的人两者都选择。

我认为支持 Cassandra 的点包括

有利于 Riak 的点包括

  • map/reduce 支持盒子

/Cassandra dev,fwiw

As you probably know, they are both architecturally strongly influenced by Dynamo (eventually consistent, no single points of failure, etc). Both also go beyond Dynamo in providing a "richer than pure K/V" data model -- in Cassandra's case, providing a Bigtable-like ColumnFamily mode, in Riak's, a Document-oriented one. I have seen sane people choose both.

I believe points that favor Cassandra include

Points that favor Riak include

  • map/reduce support out of the box

/Cassandra dev, fwiw

最冷一天 2024-08-25 12:36:16

使用

  • Riak 由Mozilla 基金会
  • Ask.com 赞助列表
  • Comcast
  • 花旗集团
  • Bet365

我认为它们都通过了可信参考客户/用户的测试。

Cassandra 看起来更加成熟,目前在基准测试中表现更好。随着集群的增长,Riak 似乎更容易添加节点。

Riak is used by

  • Mozilla Foundation
  • Ask.com sponsored listings
  • Comcast
  • Citigroup
  • Bet365

I think they both pass the test of credible reference customers/users.

Cassandra seems more mature, and is currently doing better in benchmarks. Riak seems easier to add a node to as your cluster grows.

失去的东西太少 2024-08-25 12:36:16

使用和下载是不同的。最好能得到参考资料。

也许可以进行私人对话,分享 Riak 在这些公司的参考资料?不确定如何使用 Cassandra 实现这一目标,但有一个支持 Cassandra 的公司社区似乎是一个不错的起点。由于 Cassandra 开发中可能有社区参与者,因此这可能是一个非常合理的起点。

我想听听 Riak 对最近客户满意的大型部署的回答。

我还想查看每个产品的路线图。在我看来,Cassandra 比 Riak 更容易追踪(http://wiki.apache.org/cassandra/),因为 Cassandra 的 wiki 讨论了限制以及未来可能会发生变化的事情,但两者都没有很好地概述未来。我可以理解开源社区的含义……也许……但我不能理解我必须付费的产品。

Use and download are different. Best to get references.

Perhaps a private conversation could be had where Riak references in these companies could be shared? Not sure how to get such with Cassandra, but there is a community of companies that support Cassandra that seem like a good place to start. As these probably have community participants in Cassandra development, it may be a REALLY reasonable place to start.

I would like to hear Riak's answer to recent and large deployments where customers are happy.

I also would like to see the roadmap for each product. Cassandra is a bit easier to track (http://wiki.apache.org/cassandra/) than Riak in my view as Cassandra's wiki discusses limitations and things that are probably going to change going forward, but neither outline futures well. I could understand that of an open source community ... perhaps ... but I cannot for a product for which I must pay.

执手闯天涯 2024-08-25 12:36:16

我还建议研究 Cloudant,它具有非常好的功能分层。看起来它也正在将阿帕奇土地上其他地方的能力发挥出来。 CouchDB 是 Cloudant 所基于的 Apache 平台。但是,当谈到 Cloudant 的发展方向时,Lucene 的索引似乎只是冰山一角。创建和管理索引是一个非常系统的过程,是一种数据管道,可以使用其他 Apache 社区资产编写脚本。 AND 功能(例如 NLP)也可以通过 Lucene 间接添加,或者直接添加到持久保存的内容中。

很高兴看到拟议的 Cloudant 路线图,特别是因为该团队可以挖掘 Apache 社区的财富并将其集成到 Cloudant 中。如果没有其他原因,这种情况可能存在,因为 Cloudant 收入模型中有一个运营组件需要它。

另一个令人感兴趣的领域...Cloudant 的定价模型...很明显,他们的收入模型不是基于软件,而是围绕服务。这非常有吸引力,而且似乎也与 Cassandra 周围的生态系统一致。我不知道 Basho 的人们是否已经赢得了足够多的 nosql 社区......从他们的网站或产品的任何嗡嗡声中看不到这样的情况。

我喜欢这个 Cloudant 网页 (https://cloudant.com/the-data-layer/)。我很惊讶地看到嵌入式 Erlang 功能...我不知道 CouchDB 是用 Erlang 编写的,因为这对我在 Apache 社区来说似乎很不寻常(我的无知); CouchDB 似乎比我所知道的(现在)用 Erlang 编写的其他 nosql 产品更老。无论他们采取什么策略,他们至少将 Amazon EC2 和 Microsoft Azure 视为托管合作伙伴,这表明他们对 Microsoft 和!Microsoft 世界的赞赏 - 如果正确认识到这些类型的数据的中间件价值潜力(超越缓存或哈希表应用程序),所有这些都非常重要商店可以有。

最后,虽然我不太了解董事会,但安迪·帕尔默的指导看起来很有价值。他可以为一个可能被不公平地贴上非结构化数据 KVP 哈希表标签的世界(通过 VoltDB)带来一些关于结构化数据的指导。人们正在认识到围绕 nosql“数据库”的结构和生态系统的需求...见证 Google 在 Spanner 方面的努力...KVP/小结构/对搜索能力的需求促使 Google 在 Spanner 领域进行投资。虽然我们可能都不需要像 Spanner 这样的东西,但我们可能确实需要这些 nosql 数据库中改进且强大的“企业”管理和互操作性功能,以便合理地将它们合并到现代云架构中。所需的结构可以来自于互操作性的便利性和功能的丰富性。它还可以来自支持将非结构化数据转换为结构化数据的新功能(例如索引、使用 NLP 创建 KVP blob 内部事物的结构化和解析渲染,以及许多其他事物,如果放入路线图并发布,可以吸引并扩大用户群)。 Cloudant 看起来成功的机会很大...我会仔细研究它...

看看我对 CouchDB 的发现...

CouchDB 附带了一套功能,例如即时文档转换和实时更改通知,使 Web 应用程序开发变得轻而易举。它甚至还配备了易于使用的网络管理控制台。您猜对了,直接从 CouchDB 提供服务!我们非常关心分布式扩展。 CouchDB 具有高可用性和分区容忍性,但最终也是一致的。我们非常关心您的数据。 CouchDB 具有容错存储引擎,将数据的安全性放在第一位。

I also would suggest research of Cloudant, which has what appears to be a very nice layering of capabilities. It also looks like it is bringing to bear the capabilities elsewhere in Apache land. CouchDB is the Apache platform on which Cloudant is based. BUT the indexing with Lucene seems but the tip of the iceberg when it comes to where Cloudant could go. Creating and managing an index is a very systematic process, a kind of data pipeline, that could be scripted using other Apache community assets. AND capabilities like NLP also could be added through Lucene indirectly, or maybe directly into what is persisted.

It would be nice to see a proposed Cloudant roadmap, especially since the team could mine the riches of the Apache community and integrate such into Cloudant. Such probably exists as there is an operational component to the Cloudant revenue model that will require it, if for no other reason.

Another area of interest ... Cloudant's pricing model ... it is clear their revenue model is not based on software, but around service. That is quite attractive, and it seems consistent with the ecosystem surrounding Cassandra too. I don't know if the Basho folks have won over enough of the nosql community as yet ... don't see such from any buzz around their web site or product.

I like this Cloudant web page (https://cloudant.com/the-data-layer/). I was surprised to see the embedded Erlang capability ... I did not know CouchDB was written in Erlang as this seems unusual to me in the Apache community (my ignorance); CouchDB appears to be older than other nosql products I know (now) to be written in Erlang. Whatever their strategy, they at least count Amazon EC2 and Microsoft Azure as hosting partners, indicating an appreciation of Microsoft and !Microsoft worlds - all very important if properly recognizing the middleware value potential (beyond cache or hash table applications) that these types of data stores could have.

Finally, while I don't know the board well, Andy Palmer's guidance looks like it will be valuable. He can bring some guidance vis-a-vis structured data (through VoltDB) to a world that rightly or wrongly may be unfairly branded as KVP hash tables of unstructured data. The need for structure and ecosystem surrounding nosql "databases" is being recognized ... witness Google's efforts with Spanner ... KVP/little structure/need for search-ability motivated Google's investment in the Spanner space. While we all may not need something like Spanner, we probably do need an improving and robust "enterprise" management and interoperability capability in these nosql databases to make it reasonable to incorporate them into modern cloud architectures. The needed structure can come from ease of interoperability and functional richness. It can also come from new capabilities that support conversion of unstructured data to structured data (e.g. indexes, use of NLP to create structured and parsed renderings of things inside of a KVP blob, and plenty of other things that, if put into a roadmap and published, could entice and grow a user base). Cloudant looks like it has a good chance of success ... I will take a closer look at it ...

And look what I found about CouchDB ...

CouchDB comes with a suite of features, such as on-the-fly document transformation and real-time change notifications, that makes web app development a breeze. It even comes with an easy to use web administration console. You guessed it, served up directly out of CouchDB! We care a lot about distributed scaling. CouchDB is highly available and partition tolerant, but is also eventually consistent. And we care a lot about your data. CouchDB has a fault-tolerant storage engine that puts the safety of your data first.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文