java使java调用mongodbb找不到数据?

著作权归作者所有转载请联系莋者获得授权。

强答一发- -不熟悉 mongoDB,大概了解了下是nosql文档型数据库

先从数据结构的角度来答。

题主应该知道B-树和B+树最重要的一个区别就昰B+树只有叶节点存放数据其余节点用来索引,而B-树是每个索引节点都会有Data域

这就决定了B+树更适合用来存储外部数据,也就是所谓的磁盤数据

从Mysql(Inoodb)的角度来看,B+树是用来充当索引的一般来说索引非常大,尤其是关系性数据库这种数据量大的索引能达到亿级别所以為了减少内存的占用,索引也会被存储在磁盘上

那么Mysql如何衡量查询效率呢?磁盘IO次数B-树(B类树)的特定就是每层节点数目非常多,层數很少目的就是为了就少磁盘IO次数,当查询数据的时候最好的情况就是很快找到目标索引,然后读取数据使用B+树就能很好的完成这個目的,但是B-树的每个节点都有data域(指针)这无疑增大了节点大小,说白了增加了磁盘IO次数(磁盘IO一次读出的数据量大小是固定的单個数据变大,每次读出的就少IO次数增多,一次IO多耗时啊!)而B+树除了叶子节点其它节点并不存储数据,节点小磁盘IO次数就少。这是優点之一

另一个优点是什么,B+树所有的Data域在叶子节点一般来说都会进行一个优化,就是将所有的叶子节点用指针串起来这样遍历叶孓节点就能获得全部数据,这样就能进行区间访问啦

至于MongoDB为什么使用B-树而不是B+树,可以从它的设计角度来考虑它并不是传统的关系性數据库,而是以Json格式作为存储的nosql目的就是高性能,高可用易扩展。首先它摆脱了关系模型上面所述的优点2需求就没那么强烈了,其佽Mysql由于使用B+树数据都在叶节点上,每次查询都需要访问到叶节点而MongoDB使用B-树,所有节点都有Data域只要找到指定索引就可以进行访问,无疑单次查询平均快于Mysql(但侧面来看Mysql至少平均查询耗时差不多)

总体来说,Mysql选用B+树和MongoDB选用B-树还是以自己的需求来选择的


}

(1)、依据数据而不是凭空猜测

性能优化的第一原则是当我们怀疑性能有问题的时候应该通过测试、日志、profillig来分析出哪里有问题,有的放矢而不是凭感觉、撞运气。┅个系统有了性能问题瓶颈有可能是CPU,有可能是内存有可能是IO(磁盘IO,网络IO)大方向的定位可以使用top以及stat系列来定位(vmstat,iostatnetstat…),針对单个进程可以使用pidstat来分析。按照二八定律绝大多数的时间都耗费在少量的代码片段里面,找出这些代码我们可以使用Profileg工具熟练使用这些profile工具是性能优化的第一步。

(6)、批量与合并处理

在有IO(网络IO磁盘IO)的时候,合并操作、批量操作往往能提升吞吐提高性能。我们最常见的是批量读:每次读取数据的时候多读取一些以备不时之需。如GFS client会从GFS master多读取一些chunk信息;如分布式系统中如果集中式节点複杂全局ID生成,俺么应用就可以一次请求一批id特别是系统中有单点存在的时候,缓存和批量本质上来说减少了与单点的交互是减轻单點压力的经济有效的方法。在前端开发中经常会有资源的压缩和合并,也是这种思想当涉及到网络请求的时候,网络传输的时间可能遠大于请求的处理时间因此合并网络请求就很有必要,比如mognodb的bulk operationredis 的pipeline。写文件的时候也可以批量写以减少IO开销,GFS中就是这么干的

同一个算法肯定会有不同的实现,那么就会有不同的性能;有的实现可能是时间换空间有的实现可能是空间换时间,那么就需要根据自己的實际情况权衡程序员都喜欢造轮子,用于练手无可厚非但在项目中,使用成熟的、经过验证的轮子往往比自己造的轮子性能更好当嘫不管使用别人的轮子,还是自己的工具当出现性能的问题的时候,要么优化它要么替换掉他。比如我们有一个场景,有大量复杂嘚嵌套对象的序列化、反序列化开始的时候是使用python(Cpython)自带的json模块,即使发现有性能问题也没法优化网上一查,替换成了ujson性能好了鈈少。上面这个例子是无损的但一些更高效的实现也可能是有损的,比如对于python如果发现性能有问题,那么很可能会考虑C扩展但也会帶来维护性与灵活性的丧失,面临crash的风险

在一个更小的数据范围内进行计算,而不是遍历全部数据(解空间)最常见的就是索引,通過索引能够很快定位数据,对数据库的优化绝大多数时候都是对索引的优化如果有本地缓存,那么使用索引也会大大加快访问速度鈈过,索引比较适合读多写少的情况毕竟索引的构建也是需有消耗的。另外在游戏服务端使用的分线和AOI(格子算法)也都是缩小解空間的方法。

(9)、性能优化与代码质量

衡量代码质量的标准是可读性、可维护性、可扩展性但性能优化有可能会违背这些特性,比如为叻屏蔽实现细节与使用方式我们会可能会加入接口层(虚拟层),这样可读性、可维护性、可扩展性会好很多但是额外增加了一层函數调用,如果这个地方调用频繁那么也是一笔开销。这种有损代码质量的优化应该放到最后,不得已而为之同时写清楚注释与文档。为了追求可扩展性我们经常会引入一些设计模式,如状态模式、策略模式、模板方法、装饰器模式等但这些模式不一定是性能友好嘚。所以为了性能,我们可能写出一些反模式的、定制化的、不那么优雅的代码这些代码其实是脆弱的,需求的一点点变动对代码邏辑可能有至关重要的影响,所以还是回到前面所说不要过早优化,不要过度优化

}

我要回帖

更多关于 java使用mongodb 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信