MongoDB 中我们经常会接触到一个自动生成的字段:"_id",类型为ObjectId. 之前我们使用MySQL等关系型数据库时,主键都是设置成自增的.但在分布式环境下,这种方法就不可行了,会产生冲突.为此,mongodb采用了一个称之为ObjectId的类型来做主键.ObjectId是一个12字节的 BSON 类型字符串.按照字节顺序,一次代表: 4字节:UNIX时间戳 3字节:表示运行MongoDB的机器 2字节:表示生成此_id的进程 3字节:由一个随机数开始的计数器生成的值

近期对两个应用进行改造,在上线过程中出现一系列问题(其中一部分是由于ObjectId误区导致的) 先来了解下ObjectId: TimeStamp 前 4位是一个unix的时间戳,是一个int类别,我们将上面的例子中的objectid的前4位进行提取"4df2dcec",然后再将他们安装十六进制 专为十进制:"1307761900",这个数字就是一个时间戳,为了让效果更佳明显,我们将这个时间戳转换成我们习惯的时间格式(精确到秒) $ date -d '1970-01

一.ObjectId的组成首先通过终端命令行,向mongodb的collection中插入一条不带“_id”的记录.然后,通过查询刚插入的数据,发现自动生成了一个objectId“5e4fa350b636f733a15d6f62”这个24位的字符串,虽然看起来很长,也很难理解,但实际上它是由一组十六进制的字符构成,每个字节两位的十六进制数字,总共用了12字节的存储空间.相比MYSQL int类型的4个字节,MongoDB确实多出了很多字节.不过按照现在的存储设备,多出来的字节应该不会成为什么瓶颈

ObjectId 由12个字节组成,其中组成如下: a 4-byte timestamp value, representing the ObjectId's creation, measured in seconds since the Unix epoch a 5-byte random value a 3-byte incrementing counter, initialized to a random value 前4个字节为以秒为单位的时间戳 中间5个字节为随机字符串 最后3个字节是

MongoDB默认使用_id字段作为主键,类型为ObjectId.ObjectId的生成有一定的规则,详情可以查看这篇文章 - MongoDB深究之ObjectId.如果你在写入数据库的时候忘记写入创建时间,不用担心,完全可以通过_id字段的值来还原当时的时间.看下面的mongodb script脚本: db.getCollection('fees').find({}).forEach(function(item){ var _str = item._id.toString().substr(1

ObjectId 基本操作增删改查 增: insert 介绍: mongodb存储的是文档,. 文档是json格式的对象. 语法: db.collectionName.insert(document); 1: 增加单篇文档 db.collectionName.insert({title:’nice day’}); db.person.insert({“name”:”yxl”,”age”:26}) 2: 增加单个文档,并指定_id db.collectionName.insert({_id:8,a

mongodb中"_id"下面有个ObjectId类型的数据,想通过这个数据把整个对像删除,费了半天劲终于搞定费话少说上代码 module.exports = function (req, res) { var dbCollection = req.app.db.collection('alarm.user'); var doc = {}; if (req.query) { doc = req.query; } var BSON = require('mongodb').BSONPur

用mongoose驱动保存数据,如果_id没有定义,那么在save的时候,mongoose驱动会自己生成一个_id.那么如果需要手动生成可以用mongoose.Types.ObjectId()方法. var mongoose = require('mongoose'); var id = mongoose.Types.ObjectId(); 这样就能手动生成id了.

An ObjectId is a 12-byte unique identifier consisting of: a 4-byte value representing the seconds since the Unix epoch, a 3-byte machine identifier, a 2-byte process id, and a 3-byte counter, starting with a random value. 由于前 4 个 byte 表示时间,所以 ObjectI

 http://blog.haohtml.com/archives/10678   MongoDB ObjectId的优化  

前面有写使用自己的mvc 序列化工具即jsonNetResult.我这里结合之前写的jsonNetResult来做一个Json序列化工具,而且序列化ObjectId成一个字符串.详细代码例如以下 using System; using System.IO; using System.Text; using System.Web.Mvc; using Aft.Build.Common; using Newtonsoft.Json; using Newtonsoft.Json.Serializati

在分布式系统中,有一些场景需要使用全局唯一 ID ,可以和业务场景有关,比如支付流水号,也可以和业务场景无关,比如分库分表后需要有一个全局唯一 ID,或者用作事务版本号.分布式链路追踪等等,好的全局唯一 ID 需要具备这些特点: 全局唯一:这是最基本的要求,不能重复: 递增:有些特殊场景是必须递增的,比如事务版本号,后面生成的 ID 一定要大于前面的 ID :有些场景递增比不递增要好,因为递增有利于数据库索引的性能: 高可用:如果是生成唯一 ID 的系统或服务,那么一定会有大量的调用,那么保证其

概述 > db.col.find() { , } { , } { , } { , } 每个文档中都有一个“_id”,她是一个12字节的BSON类型数据,格式如下 56c56dd4ca446fab71e4c38a 前4个字节表示时间戳 接下来的3个字节是机器标识码 紧接的两个字节由进程id组成(PID) 最后三个字节是随机数 MongoDB存储的文档必须有一个的“_id”键,这个键值可以是任意类型,默认的是ObjectId类型对象. 文档的“_id”是唯一的,以确保集合中的文档被唯一标识. Mon

ObjectId是"_id"的默认类型.它设计成轻量型的,不同的机器都能用全局唯一的同种方法方便地生成它. 这是MongoDB采用ObjectId,而不是其他比较常规的做法(比如自动增加的主键)的主要原因,因为在多个 服务器上同步自动增加主键值既费力还费时.MongoDB从一开始就设计用来作为分布式数据库,处理多个节 点是一个核心要求.后面会讲到ObjectId类型在分片环境中容易生成得多. ObjectId使用12字节的存储空间,每个字节两位十六进制数字,是一个24位的字符串.由于看

在Tp5中使用mongodb 使用自定义ObjectId时报错:Cannot use object of type MongoDB\\BSON\\ObjectID as array 查询源码发现在topthink/think-mongo/src/Builder.php中发现 它原来的parseData方法这样写的: protected function parseData($data, $options) { if (empty($data)) { return []; } $result =

一.简介 从官网 https://www.mongodb.com/download-center?jmp=nav#community 下载相应平台及版本的 mongodb,解压后的 bin 文件夹中有多个可执行文件,其中 mongod 是服务程序, mongo 是客户端程序. 通过执行 mongod 即可运行起 mongodb 服务,默认使用端口是 27017,同时 mongodb 还会启动一个 HTTP 服务(获取数据库管理信息),该 HTTP 服务的端口号默认比 mongodb 服务的端口号

4 管理 Mongodb Manual阅读笔记:CH2 Mongodb CRUD 操作Mongodb Manual阅读笔记:CH3 数据模型(Data Models)Mongodb Manual阅读笔记:CH4 管理Mongodb Manual阅读笔记:CH5 安全性Mongodb Manual阅读笔记:CH6 聚合Mongodb Manual阅读笔记:CH7 索引Mongodb Manual阅读笔记:CH8 复制集Mongodb Manual阅读笔记:CH9 Sharding 4 管理 4.1

3数据模型(Data Models) Mongodb Manual阅读笔记:CH2 Mongodb CRUD 操作Mongodb Manual阅读笔记:CH3 数据模型(Data Models)Mongodb Manual阅读笔记:CH4 管理Mongodb Manual阅读笔记:CH5 安全性Mongodb Manual阅读笔记:CH6 聚合Mongodb Manual阅读笔记:CH7 索引Mongodb Manual阅读笔记:CH8 复制集Mongodb Manual阅读笔记:CH9 Sha

最近开始学习Mongodb方面的东西.. 看到有很多博主都说MongoDB的第三方驱动 Samus 对Linq的支持比较好..能够降低学习的成本..所以就想从这里开始.. 但是弊端在我学习了一半的时候才发现..很严重..Samus驱动对数据库的操作没有返回值..增删改都没有..只有查询有结果.. 这在很多时候都不能允许的..因为我们必须知道这一步是否操作成功才能够安全的进入下一步.. 不过我还是硬着头皮写完了一套增删改查的工具方法..在这里共享一下..也作为一个记录.. 至于具体放在什么地方使用

数据在分片时,典型的是分库分表,就有一个全局ID生成的问题.单纯的生成全局ID并不是什么难题,但是生成的ID通常要满足分片的一些要求:   1 不能有单点故障.   2 以时间为序,或者ID里包含时间.这样一是可以少一个索引,二是冷热数据容易分离.   3 可以控制ShardingId.比如某一个用户的文章要放在同一个分片内,这样查询效率高,修改也容易.   4 不要太长,最好64bit.使用long比较好操作,如果是96bit,那就要各种移位相当的不方便,还有可能有些组件不能支持这么大的ID.

ID即标示符,在某个搜索域内能唯一标示其中某个对象.在关系型数据库中每个表都需要定义一个主键来唯一标示一条记录.为了方便一般都会使用一个auto_increment属性的整形数做为ID.因为数据库本身能保证这个数是在这个表范围内一直累加的,所以任何两条记录不会有相同的ID值,包括已经删除的记录.可是一旦表大到一定程度,要跨机器分表的时候,那么就不能再依靠这个auto_increment字段唯一表示一条记录了.因为此时的搜索域已经扩大到多个机器,而每台机器的auto_increment都是独立增长