我现在需要在资源非常有限的系统上部署一个基于容器化的Nebula的应用系统，能够分配给Nebula的资源可能只有1~2个核、1~2GB内存，这种场景下只有使用纯粹的单节点部署的Nebula才能做到，请问Nebula支持纯粹的单节点部署吗？如果能支持，和多节点分布式部署相比，除了失去数据高可用特性以外，还有别的性能和功能损失吗？
看起来没有什么功能损失
我感觉就放不了几个数据就挂了。2GB啊。。。。
basketballplayer那个估计能跑，多了基本要挂。
我现在只跑了metad、graphd、storaged各一个共3个容器，nebula很不错，纯单点也能跑起来。
空库时内存占用也还好，340MB左右。
但灌了点basketballplayer的数据，建了两个索引，内存占用就上升到了1.5GB左右。
主要是storaged和metad增加得厉害，用pmap看进程的vma变化，多了很多8MB和1MB的匿名vma。
计划灌几组不同数量级的数据，看看内存占用的变化曲线，希望会收敛于实际数据量的某个倍数。
要不把 RocksDB 的Block Cache改小一些？
请教 您测试这个的目的是？
这个灌数据看内存占用的测试是为了确认在我们预计的最大图数据量的边界条件下，Nebula的内存占用不会超过预留给Nebula的内存容量。
整个测试的目的是为了评估确定能否在我们的产品中集成Nebula图数据库，为我们的上层应用提供图数据的存储和计算服务。
16GB是测试用的最低条件。
标准96GB用于生产。
2GB怎么都是不够的。
我们不是做web服务的，我们是做自己的软件产品卖给客户。我们的图数据比较小，主要就是客户网络的拓扑图等，点边总规模不超過10万，应该用不了那么多内存。
我们知道Nebula是为大规模分布式图数据库设计的，可能并不太适合我们的应用。但我们非常欣赏Nebula的架构、商业模式和服务，非常愿意进入和依赖Nebula生态系统，和Nebula共成长。
如果当前确实用不了，也希望Nebula未来能够推出能够在资源有限系统中运行的单机版本，让更多的用户能够用上Nebula。
从您的需求来看 更像是一种嵌入式的数据库
是的，有合适的帮忙推荐下～～
其实 Nebula 挺合适的 再次感谢您的支持 
我也相信现在Nebula是能够应用到资源有限系统中的，但可能需要精细的配置和调优，也可能需要很局部的代码改动，都不会太难。因为我感觉Nebula的架构设计得比较好，能够适应这种应用场景，不需要大的改动。
那你直接用tinkergraph算了
neo4j也有library版本的。或者jgrapht也行
nebula-Java支持嵌入式的方式运行吗。类似于neo4j的
GraphDatabaseService graphDb = new GraphDatabaseFactory().newEmbeddedDatabase(dbPath);
graphDb.execute(cypherContent, param);