注意:我做了一些重新格式化和添加了一些额外的信息。
请看看这个:Question_Answer
我想问一下——对于DSE 5.0和即将到来的变化，在今年的C*峰会上提到了5.1和5.2，同样的建议会有用吗?
平台必须始终可用。(Cassandra)
数据必须是可搜索的。(SOLR/Lucene)
平台必须提供分析/数据仓库/BI等(Graph/Spark)
多亏了DSE，所有这些都可以在一个产品中实现!谢谢DataStax!
但是我们存储的数据量和事务计数非常有限。
我们的规范是应用程序内的100个并发会话——当然，这甚至不能转化为100个并发DB请求/操作。
在大多数情况下，我们的应用程序类似于日常的企业CRUD应用程序。
虽然不荒谬，但AWS实例并不是完全免费的。
对我们来说，为每个工作负载拥有一个单独的集群(具有足够的复制以实现持续可用性)将是一个成本问题。
虽然我理解，但概念验证可以提供一些帮助——但没有真正的工作负载/真正的用户——通过服务/应用程序——只有"生产"系统和流氓用户才能真正提供洞察力。最好的方法是"加载"功能测试。
简而言之，从平台的角度来看，我们有点被困在这里。
我们最初的想法是:
2个地理隔离数据中心
每个DC 2个机架
每个机架2个节点
3
local_quorum
如果我们发现遇到了性能问题，我们可以向外扩展——在最初的2个机架上添加一个额外的机架或额外的节点。
至于v节点或代币的数量，我们不知道。
DSE Search的文档说v节点增加了30%的开销，所以听起来你不应该使用v节点，但在文档中的一个表中它也说使用16或32。怎么可能两者都有呢?
如果我们可以成功地在单个节点上运行所有工作负载(我们的需求确实是最小的)，我们是使用v -node(16或32)运行还是运行单个令牌?
最后，还有其他选择吗?
您是否可以在同一个数据中心拥有具有不同工作负载的节点?在哪里为特定工作负载设置具有RAM/CPU需求的单个节点?
假设每个数据中心有4个节点(仅作为起始点-我们不知道是否可以在单个节点上成功运行Search/或Spark)
节点1:Just Cassandra
节点2:Cassandra和Search
节点3:Cassandra and Graph
节点4:Cassandra和Spark
如果搜索需要64GB内存，那就这样吧……但卡桑德拉唯一节点只需要8或16个节点就可以工作。
因此，我们可以满足每个工作负载类型的CPU和内存，但仍然只有一个DC。(我们将有2个冗余-但实际上它是一个单独的DC安装:镜像)
提前感谢你的帮助。
Vnodes为搜索解决方案的分散-收集部分增加了额外的开销。在一些基准指数中，这一比例高达30%。由于动态扩展的好处，一些客户愿意忍受这种开销，并希望使用vnodes。
如果你已经或正在计划一个小型集群——并且不需要动态扩展它——那么我绝对建议你坚持使用单个令牌。这种方法隐藏的好处是，你的修理也会稍微快一些。这有助于搜索，因为你正在阅读相当于CL.ONE。
可以在同一个数据中心上运行所有功能(搜索、分析和现在的图形)，但你会发现开销增加了。您将需要具有更多内存和cpu资源的更大节点来应对处理负载。我可能会从128gb的内存开始，然后从那里开始。我想如果你的负荷真的很轻，你可能会少用一些。与所有事情一样，在您打算运行的规模上进行基准测试是关键。
顺便说一句，我不完全清楚你对RF的意图。假设有2个节点，RF=3。我猜这只是措辞，但如果不是-值得注意的是，您希望至少有与RF一样多的节点以获得最佳覆盖!