MongoDB 条件查询和排序

MongoDB 条件查询和排序,第1张

查询的基本格式是 dbcollectionfind({条件}) ,其中条件是可选的,类似于 MySQL 的 WHERE 条件一样。示例如下:

可以使用 $and 、 $or 和 $not 来设置组合条件。

例如下面的 users 数据集:

我们查找 nickname 是岛上码农和且性别是 male :

查找分数是90或76分的用户:

查找性别不是 male 的用户和查找分数高于80分用户:

其中 $eq 为相等条件, $lt 为小于条件。

条件可以嵌套使用,例如 or 嵌套,表示 (a || b) && (c || d) ,格式如下:

在 MongoDB 提供了如下比较 *** 作符,比较 *** 作符的格式为 {key: {$op: value}} :

in 查询的格式和比较 *** 作符类似,只是对应的值是数组,即

例如,需要查找分数为90,76的用户:

in 查询也可以和其他条件组合,如and 查询:

find 方法会将所有匹配条件的数据查找出来,因此对于数据集很大的时候会导致速度很慢且产生大量的 磁盘 I/O,如果确定数据只有1条的时候可以使用 findOne ,如果要限制查询条数可以使用 limit 或 skip 。 limit 是查询到指定数量后的结果就返回,而 skip 是跳过前面指定数量的结果。

排序使用格式如下:

其中1表示升序,-1表示降序,例如我们需要以分数降序排序:

本篇介绍了 MongoDB 的条件查询 *** 作,限制返回条数和排序。可以看到,MongoDB 的 *** 作虽然语法和 SQL 不同,但是都有对应的功能辅助查询,对于查询来说也是十分便捷的。

List<BasicDBObject> result = new ArrayList<BasicDBObject>();

if (tableNamelength() > 0) {

if (cursor == null) {

coll = dbgetCollection(tableName);

cursor = collfind()skip(skipNum)limit(num);

}

while (cursorhasNext()) {

BasicDBObject o = (BasicDBObject) cursornext();

resultadd(o);

}

}

但是调用出现了问题:

我这样查,

List<BasicDBObject> list1 = mongoDaoqueryWithNum(LuceneTesttableName, 100,100);

List<BasicDBObject> list2 = mongoDaoqueryWithNum(LuceneTesttableName, 200,100);

Systemoutprint("--结束,共" + list1size() + "条---" + "--");

Systemoutprintln(list2size());

MongoDB 中的关系可以是:

MongoDB 聚合管道(Aggregation Pipeline)

使用聚合管道可以对集合中的文档进行变换和组合。

管道 *** 作符

$project 修改文档的结构,可以用来重命名、增加或删除文档中的字段。

$match 用于过滤文档。用法类似于 find() 方法中的参数。

$limit 用来限制MongoDB聚合管道返回的文档数

$skip 在聚合管道中跳过指定数量的文档,并返回余下的文档。

$sort 将输入文档排序后输出

$group 将集合中的文档进行分组,可用于统计结果

$lookup 可以引用其他集合的数据(表关联查询)

创建数据

一、简述一下MongoDB的应用场景

mongodb 支持副本集、索引、自动分片,可以保证较高的性能和可用性。

更高的写入负载

默认情况下,MongoDB 更侧重高数据写入性能,而非事务安全,MongoDB 很适合业务系统中有大量 “低价值” 数据的场景。但是应当避免在高事务安全性的系统中使用 MongoDB,除非能从架构设计上保证事务安全。

高可用性

MongoDB 的复副集 (Master-Slave) 配置非常简洁方便,此外,MongoDB 可以快速响应的处理单节点故障,自动、安全地完成故障转移。这些特性使得 MongoDB 能在一个相对不稳定(如云主机)的环境中,保持高可用性。

数据量很大或者未来会变得很大

依赖数据库 (MySQL) 自身的特性,完成数据的扩展是较困难的事,在 MySQL 中,当一个单达表到 5-10GB 时会出现明显的性能降级,此时需要通过数据的水平和垂直拆分、库的拆分完成扩展,使用 MySQL 通常需要借助驱动层或代理层完成这类需求。而 MongoDB 内建了多种数据分片的特性,可以很好地适应大数据量的需求。

基于位置的数据查询

MongoDB 支持二维空间索引,因此可以快速及精确地从指定位置获取数据。

表结构不明确

在一些传统 RDBMS 中,增加一个字段会锁住整个数据库 / 表,或者在执行一个重负载的请求时会明显造成其它请求的性能降级。通常发生在数据表大于 1G 的时候(当大于 1TB 时更甚)。 因 MongoDB 是文档型数据库,为非结构货的文档增加一个新字段是很快速的 *** 作,并且不会影响到已有数据。另外一个好处当业务数据发生变化时,是将不再需要由 DBA 修改表结构。

二、数据库设计经验,为什么进行分表?分库?一般多少数据量开始分表?分库?分库分表的目的?

1、为什么要分表

当一张表的数据达到几百万时,你查询一次所花的时间会变多,如果有联合查询的话,有可能会死在那儿了。分表的目的就在于此,减小数据库的负担,缩短查询时间。日常开发中我们经常会遇到大表的情况,所谓的大表是指存储了百万级乃至千万级条记录的表。这样的表过于庞大,导致数据库在查询和插入的时候耗时太长,性能低下,如果涉及联合查询的情况,性能会更加糟糕。

分表和表分区的目的就是减少数据库的负担,提高数据库的效率,通常点来讲就是提高表的增删改查效率。数据库中的数据量不一定是可控的,在未进行分库分表的情况下,随着时间和业务的发展,库中的表会越来越多,表中的数据量也会越来越大,相应地,数据 *** 作,增删改查的开销也会越来越大;另外,由于无法进行分布式式部署,而一台服务器的资源(CPU、磁盘、内存、IO 等)是有限的,最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。

2、分表的方案

做 mysql 集群,有人会问 mysql 集群,根分表有什么关系吗?虽然它不是实际意义上的分表,但是它启到了分表的作用,做集群的意义是什么呢?为一个数据库减轻负担,说白了就是减少 sql 排队队列中的 sql 的数量,举个例子:有 10 个 sql 请求,如果放在一个数据库服务器的排队队列中,他要等很长时间,如果把这 10 个 sql 请求,分配到 5 个数据库服务器的排队队列中,一个数据库服务器的队列中只有 2 个,这样等待时间是不是大大的缩短了呢?

linux mysql proxy 的安装,配置,以及读写分离

mysql replication 互为主从的安装及配置,以及数据同步

优点:扩展性好,没有多个分表后的复杂 *** 作(php 代码)

缺点:单个表的数据量还是没有变,一次 *** 作所花的时间还是那么多,硬件开销大。

三、简述一下数据库主从复制,读写分离

什么是主从复制

主从复制,是用来建立一个和主数据库完全一样的数据库环境,称为从数据库;

主从复制的原理:

1数据库有个bin-log二进制文件,记录了所有的sql语句。

2只需要把主数据库的bin-log文件中的sql语句复制。

3让其从数据的relay-log重做日志文件中再执行一次这些sql语句即可。

主从复制的作用

1做数据的热备份,作为后备数据库,主数据库服务器故障后,可切换到从数据库继续工作,避免数据丢失。

2架构的扩展。业务量越来越大,I/O访问频率过高,单机无法满足,此时做多库的存储,降低磁盘I/O访问频率,提高单机的I/O性能

3主从复制是读写分离的基础,使数据库能制成更大 的并发。例如子报表中,由于部署报表的sql语句十分慢,导致锁表,影响前台的服务。如果前台服务使用master,报表使用slave,那么报表sql将不会造成前台所,保证了前台的访问速度。

主从复制的几种方式:

1同步复制:所谓的同步复制,意思是master的变化,必须等待slave-1,slave-2,…,slave-n完成后才能返回。

2异步复制:如同AJAX请求一样。master只需要完成自己的数据库 *** 作即可。至于slaves是否收到二进制日志,是否完成 *** 作,不用关心。MYSQL的默认设置。

3半同步复制:master只保证slaves中的一个 *** 作成功,就返回,其他slave不管。

这个功能,是由google为MYSQL引入的。

关于读写分离

在完成主从复制时,由于slave是需要同步master的。所以对于insert/delete/update这些更新数据库的 *** 作,应该在master中完成。而select的查询 *** 作,则落下到slave中。

以上就是关于MongoDB 条件查询和排序全部的内容,包括:MongoDB 条件查询和排序、java中的mongoDB怎么分页,要代码,数据量较大、mongoDB表与表的关系及聚合管道查询等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!

欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/web/9312981.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-04-27
下一篇 2023-04-27

发表评论

登录后才能评论

评论列表(0条)

保存