mongodb数据迁移2种方式比较

尝试了2种方式对数据进行迁移,一种是rsync,直接拉取数据;另一种是使用mongodump/mongorestore

1.rsync
操作步骤:
1.2:
[mongodb]
path = /data1/mongodb/data
hosts allow = 192.168.1.0/24
read only = no
write only = no
1.3:
rsync -avz root@192.168.1.2::mongodb/dbname /data/mongodb-linux-x86_64-1.8.1/data/
chown -R mongodb:mongodb /data/mongodb-linux-x86_64-1.8.1/data/

使用时间:50分钟
到目标服务器数据:50G
优点:使用时间短
缺点:需要配置rsync,数据占用的空间大(数据原封不动的拉取过来,包括碎片)

2.mongodump/mongorestore
操作步骤:
mongodump:
/data/PRG/mongodb/bin/mongodump –host 192.168.1.2:27017 -d dbname -uuername -ppasswd -o /data/mongodb-linux-x86_64-1.8.1/data/ –directoryperdb
mongorestore:
/data/mongodb-linux-x86_64-1.8.1/bin/mongorestore –dbpath /data/mongodb-linux-x86_64-1.8.1/data/ –directoryperdb /data/dbname/
chown -R mongodb:mongodb /data/mongodb-linux-x86_64-1.8.1/data/

使用时间:35(mongodump)+90(mongorestore)
到目标服务器数据:20G(需要的空间大大减小,拉取过程中相当于做了一次碎片整理)
优点:迁移到新服务器的数据经过了整理,需要空间大大减小
缺点:需要时间长

数据迁移时需要停mongo进行操作,而2种方式各有优缺点,如果可以忽略操作时间内的数据的话,那么使用第2种方式会比较好(已经有不少例子因为碎片带来严重的后果)

MongoDB 1.8通过Journaling日志改善可靠性​

面向文档的数据库引擎MongoDB在3月16日发布了1.8版本。关键的变更包括新增Journaling日志、提升分片性能以及Shell的Tab​补全。​

Journaling日志通过预写式的Redo日志为MongoDB增加了额外的可靠性。开启该功能时,变更会先写入Journaling日志,​ 定期集中提交(目前是每100ms提交一次)​,然后在真实数据上进行这些变更。如果服务器安全关闭,日志会被清除。在服务器启动时,如果存在 Journaling日志​,则会进行回放。这保证了那些已写入,但在服务器崩溃前还没有回放的​日志能在用户连接前​被执行。​两次提交之间那 100ms的时间窗口​在未来的版本中有望被缩小。

MongoDB是​一种 NoSQL数据库​,不同于SQL Server这样的关系型数据库,MongoDB中数据的基本单位是文档。类似于JavaScript对象,文档中包含一系列带有类型的键值对​,这些类型可以是字符串、对象、数组、正则表达式和代码。​这些文档以​BSON格式存 储​,根据文档类型被分组到集合(类似于SQL Server里的表)中​。Schema的设计取决于哪些文档应该有自己的集合​,哪些应该被嵌入到其他集合中去。嵌入的文档就像类里的成员对象。在关系 型系统中,你会用一张表来存储订单,另一张外键的表来存储订单项。在MongoDB中,​针对同样的场景,推荐的做法是用一个集合来保存订单,每个订单中 保存一个订单项的数组,嵌入其中。​

水平扩展是通过​自动分片来 ​做的​,​它允许有序的集合数据分布。每个分片都是一组配置成Replica集的机器​,这意味着分片里的每台机器​都拥有分片数据的完整拷贝。​分片 中会自动进行故障转移。MongoDB会自动将查询引导到合适的分片上,因此应用程序并不需要了解哪个分片持有什么数据元素。​新的Replica集身份 认证功能允许Replica集的成员之间进行自动身份认证,其中使用了密钥文件和 –keyfile 选项。​

Covered索引和Sparse索引也是该版本中新增加的特性。​Covered索引允许​在索引本身里存储数据,而​Sparse索引则会排除掉不包含索引字段的文档。Covered索引在查询所请求的全部字段​都包含在Covered索引中时能提升性能,因为不再需要取出完整的文档记录。Sparse索引在所检索的字段并非经常出现在集合中时能提升性能。目前,Sparse索引只能有一个字段。​

在MongoDB的工具集中也有一些变化。mongostat 增加了​discover模式(–discover)​,它会自动从集群的节点中取回统计信息。​通过mongodump –oplogmongorestore –oplogReplay提供了高级事务日志转储和恢复​功能。​

欲更多地了解该版本中的新特性,请查看MongoDB 1.8 Webinar

查看英文原文:MongoDB 1.8 Improves Reliability with Journaling

 

MongoDB 1.8 版本发布

MongoDB 1.8.0版本发布了!最大的显著改变是增加了一个日志存储引擎,可以快速安全地恢复崩溃系统。还包括许多内部改进,极大地提高了效率。

MongoDB是一个基于分布式文件存储的数据库开源项目,由C++语言编写。旨在为WEB应用提供可护展的高性能数据存储解决方案。常用于高流量网站,在线游戏网站和搜索引擎的大规模数据管理和分类。

该版本主要新亮点:

* Journaling
* Sharding performance improvements
* Replica set enhancements, including support for authentication
* Spherical geo search
* Covered and sparse indexes
* B-tree index self-compaction
* New map/reduce options for incremental updates
* Tab completion in the shell
* mongostat –discover

详细更新日志: http://jira.mongodb.org/secure/IssueNavigator.jspa?requestId=10128

下载地址: http://www.mongodb.org/downloads

mongodb小结

用了一阵子mongodb,作一些小结,作为将来的参考。按照以往的习惯,先作一个总览,然后再挑出一些自己比较关注的几个点,作为珠玑,加以串联阐述。

mongodb由C++写就,其名字来自humongous这个单词的中间部分,从名字可见其野心所在就是海量数据的处理。关于它的一个最简洁描述为:scalable, high-performance, open source, schema-free, document-oriented database。我对于文档型数据库有一些个人的偏好,这种偏好是从半年前研究couchdb而来的,因为我觉得用它来描述一个具有个性化特征的实体对象正合适,比如网站上的用户或商品书籍之类的条目。

一些概念:

跟mysqld一样,一个mongod服务可以有建立多个数据库,每个数据库可以有多张表,这里的表名叫collection,每个collection可以存放多个文档(document),每个文档都以BSON(binary json)的形式存放于硬盘中。跟关系型数据库不一样的地方是,它是的以单文档为单位存储的,你可以任意给一个或一批文档新增或删除字段,而不会对其它文档造成影响,这就是所谓的schema-free,这也是文档型数据库最主要的优点。跟一般的key-value数据库不一样的是,它的value中存储了结构信息,所以你又可以像关系型数据库那样对某些域进行读写、统计等操作。可以说是兼备了key-value数据库的方便高效与关系型数据库的强大功能。

索引

跟关系型数据库类似,mongodb可以对某个字段建立索引,可以建立组合索引、唯一索引,也可以删除索引。当然建立索引就意味着增加空间开销,我的建议是,如果你能把一个文档作为一个对象的来考虑,在线上应用中,你通常只要对对象ID建立一个索引即可,根据ID取出对象某些数据放在memcache即可。如果是后台的分析需要,响应要求不高,查询非索引的字段即便直接扫表也费不了太多时间。如果还受不了,就再建一个索引得了。

默认情况下每个表都会有一个唯一索引:_id,如果插入数据时没有指定_id,服务会自动生成一个_id,为了充分利用已有索引,减少空间开销,最好是自己指定一个unique的key为_id,通常用对象的ID比较合适,比如商品的ID。

capped collection

capped collection是一种特殊的表,它的建表命令为:

db.createCollection("mycoll", {capped:true, size:100000})

允许在建表之初就指定一定的空间大小,接下来的插入操作会不断地按顺序APPEND数据在这个预分配好空间的文件中,如果已经超出空间大小,则回到文件头覆盖原来的数据继续插入。这种结构保证了插入和查询的高效性,它不允许删除单个记录,更新的也有限制:不能超过原有记录的大小。这种表效率很高,它适用于一些暂时保存数据的场合,比如网站中登录用户的session信息,又比如一些程序的监控日志,都是属于过了一定的时间就可以被覆盖的数据。

复制与分片

mongodb的复制架构跟mysql也很类似,除了包括master-slave构型和master-master构型之外,还有一个Replica pairs构型,这种构型在平常可以像master-slave那样工作,一但master出现问题,应用会自动了连接slave。要做复制也很简单,我自己使用过master-slave构型,只要在某一个服务启动时加上–master参数,而另一个服务加上–slave与–source参数,即可实现同步。

分片是个很头疼的问题,数据量大了肯定要分片,mysql下的分片正是成为无数DBA的噩梦。在mongodb下,文档数据库类似key-value数据库那样的易分布特性就显现出来了,无论构造分片服务,新增节点还是删除节点都非常容易实现。但mongodb在这方面做还不足够成熟,现在分片的工作还只做到alpha2版本(mongodb v1.1),估计还有很多问题要解决,所以只能期待,就不多说了。

性能

在我的使用场合下,千万级别的文档对象,近10G的数据,对有索引的ID的查询不会比mysql慢,而对非索引字段的查询,则是全面胜出。mysql实际无法胜任大数据量下任意字段的查询,而mongodb的查询性能实在让我惊讶。写入性能同样很令人满意,同样写入百万级别的数据,mongodb比我以前试用过的couchdb要快得多,基本10分钟以下可以解决。补上一句,观察过程中mongodb都远算不上是CPU杀手。

GridFS

gridfs是mongodb一个很有趣的类似文件系统的东西,它可以用一大块文件空间来存放大量的小文件,这个对于存储web2.0网站中常见的大量小文件(如大量的用户头像)特别有效。使用起来也很方便,基本上跟一般的文件系统类似。

用合适的数据库做适合的事情

mongodb的文档里提到的user case包括实时分析、logging、全文搜索,国内也有人使用mongodb来存储分析网站日志,但我认为mongodb用来处理有一定规模的网站日志其实并不合适,最主要的就是它占空间过于虚高,原来1G的日志数据它可以存成几个G,如此下去,一个硬盘也存不了几天的日志。另一方面,数据量大了肯定要考虑sharding,而mongodb的sharding到现在为止仍不太成熟。由于日志的不可更新性的,往往只需APPEND即可,又因为对日志的操作往往只集中于一两列,所以最合适作为日志分析的还是列存储型的数据库,特别是像infobright那样的为数据仓库而设计的列存储数据库。

由于mongodb不支持事务操作,所以事务要求严格的系统(如果银行系统)肯定不能用它。

mongodb占用空间过大的原因,在官方的FAQ中,提到有如下几个方面:

1、空间的预分配:为避免形成过多的硬盘碎片,mongodb每次空间不足时都会申请生成一大块的硬盘空间,而且申请的量从64M、128M、256M那样的指数递增,直到2G为单个文件的最大体积。随着数据量的增加,你可以在其数据目录里看到这些整块生成容量不断递增的文件。

2、字段名所占用的空间:为了保持每个记录内的结构信息用于查询,mongodb需要把每个字段的key-value都以BSON的形式存储,如果value域相对于key域并不大,比如存放数值型的数据,则数据的overhead是最大的。一种减少空间占用的方法是把字段名尽量取短一些,这样占用空间就小了,但这就要求在易读性与空间占用上作为权衡了。我曾建议作者把字段名作个index,每个字段名用一个字节表示,这样就不用担心字段名取多长了。但作者的担忧也不无道理,这种索引方式需要每次查询得到结果后把索引值跟原值作一个替换,再发送到客户端,这个替换也是挺耗费时间的。现在的实现算是拿空间来换取时间吧。

3、删除记录不释放空间:这很容易理解,为避免记录删除后的数据的大规模挪动,原记录空间不删除,只标记“已删除”即可,以后还可以重复利用。

4、可以定期运行db.repairDatabase()来整理记录,但这个过程会比较缓慢。

因为官方文档中对各方面的内容已经有很详细的叙述,所以我并没有再过多的引用原文与代码,只是结合自己的使用归纳一些心得,有兴趣的朋友不妨直接去翻文档中自己感兴趣的问题,超群的博客上有一个很好的入门介绍。

最后总结一句,文档型数据库有点像波粒二象性,总能在适当的时候表现出它作为关系型数据库或key-value数据库的优势来。

实战案例:

昨天我访问mongodb的python程序开始出错,经常抛出AssertionError异常,经查证只是master查询异常,slave正常,可判断为master的数据出了问题。

修复过程:

1、在master做db.repairDatabase(),不起作用;

2、停止slave的同步;

3、对slave作mongodump,备份数据;

4、对master作mongostore,把备份数据恢复,使用–drop参数可以先把原表删除。

5、恢复slave的同步。

 

在CentOS 5.4上安装CouchDB

CouchDB一种半结构化面向文档的分布式,高容错的数据库系统,具体的可以参见其网站上的文档,以及这里的一篇技术简介的翻译。CouchDB在Ubuntu下安装非常方便,只需要使用sudo apt-get install couchdb即可,我以为在CentOS中也会比较容易,没想到却遇到了比较多的问题。主要包括:

  1. CentOS的安装源里不包含CouchDB
  2. CouchDB需要Erlang的运行时支持,CentOS的安装源里也没有Erlang

OK,我们一步一步来搞定在CentOS下安装CouchDB。首先需要安装Erlang,却Erlang的官方网站下载源码,然后在本地编译安装:具体的脚本为:

   1: wget http://www.erlang.org/download/otp_src_R13B02-1.tar.gz
   2: tar–xzvf otp_src_R13B02-1.tar.gz
   3: cd otp_src_R13B02-1
   4: ./configure
   5: make && make install

中途有可能会遇到一些依赖的问题,比如缺少icu、ncurses、wxWindows等,前面几个大略都可以从yum时行安装,wxWindows可以不问,如果你之后不准备使用Erlang进行UI编程的话,这些也足够用了。

Erlang安装完成之后,测试一下在bash里erl和erlc能否使用,若能,则这一步就完成了。

接着是安装CouchDB,由于CouchDB里用到了JavaScript,所以其依赖于SpiderMonkey,需要先安装libmozjs这个库,步骤为:

   1: wget ftp://ftp.mozilla.org/pub/mozilla.org/js/js-1.8.0-rc1.tar.gz
   2: tar–xzvf js-1.8.0-rc1.tar.gz
   3: cd js/src
   4: make BUILD_OPT=1–f Makefile.ref

编译应该不会出什么问题,如果你的机器没有配置编译环境,你可以参考这篇文章进行配置。

可以当我执行make –f Makefile.ref install的时候傻了,没有这个target,好吧,我们自己写脚本安装这个库。代码如下:

   1: #!/bin/bash
   2: mkdir -p /usr/include/mozjs/ -v
   3: cp *.{h,tbl}
   4: /usr/include/mozjs/ -v
   5: cd Linux_All_OPT.OBJ
   6: cp *.h /usr/include/mozjs/ -v
   7: mkdir -p /usr/local/{bin,lib}/ -v
   8: cp js /usr/local/bin/ -v
   9: cp libjs.so /usr/local/lib/ -v

把上面的代码保存成install.sh,并放在src文件夹下,执行一遍即可。

终于可以编译CouchDB了,脚本如下:

   1:
   2: wget http://labs.xiaonei.com/apache-mirror/couchdb/0.10.0/apache-couchdb-0.10.0.tar.gz
   3: tar–xzvf apache-couchdb-0.10.0.tar.gz
   4: cd apache-couchdb-0.10.0
   5: ./configure
   6: make && make install

这次编译应该不会出什么问题,如果出了,也应该是比较好解决的,我们假设你看这篇文章的时候,有这个能力来解决那些小问题。

然后这个时候就安装成功了。接着是配置CouchDB,官方建议不要用root帐户来运行,所以,我们新建一个账户跟组来运行。脚本如下:

   1: groupadd couchdb
   2: useradd couchdb–g couchdb–d /usr/local/var/lib/couchdb
   3: su– couchdb–c “/user/local/bin/couchdb -b”

最后一行是用来启动couchdb的后台进程,如果要停止,把参数从-b改成-d即可。

新版本的配置文件好像是/user/local/etc/couchdb/local.ini,各取所需,自己修改吧。

 

配置mongodb分片群集(sharding cluster)

 

Sharding cluster介绍

这是一种可以水平扩展的模式,在数据量很大时特给力,实际大规模应用一般会采用这种架构去构建monodb系统。

要构建一个 MongoDB Sharding Cluster,需要三种角色:

Shard Server: mongod 实例,用于存储实际的数据块,实际生产环境中一个shard server角色可由几台机器组个一个relica set承担,防止主机单点故障

Config Server: mongod 实例,存储了整个 Cluster Metadata,其中包括 chunk 信息。

Route Server: mongos 实例,前端路由,客户端由此接入,且让整个集群看上去像单一数据库,前端应用可以透明使用。

Sharding架构图:

本例实际环境架构

本例架构示例图:

  1. 分别在3台机器运行一个mongod实例(称为mongod shard11,mongod shard12,mongod shard13)组织replica set1,作为cluster的shard1
  2. 分别在3台机器运行一个mongod实例(称为mongod shard21,mongod shard22,mongod shard23)组织replica set2,作为cluster的shard2
  3. 每台机器运行一个mongod实例,作为3个config server
  4. 每台机器运行一个mongs进程,用于客户端连接

 

主机 IP 端口信息
Server1 10.1.1.1 mongod shard11:27017
mongod shard12:27018
mongod config1:20000
mongs1:30000
Server2 10.1.1.2 mongod shard12:27017
mongod shard22:27018
mongod config2:20000
mongs2:30000
Server3 10.1.1.3 mongod shard13:27017
mongod shard23:27018
mongod config3:20000
mongs3:30000

 

软件准备

软件准备
1. 创建用户
groupadd -g 20001 mongodb
useradd -u 20001 -g mongodb mongodb
passwd mongodb

2. 安装monodb软件
su – mongodb
tar zxvf mongodb-linux-x86_64-1.7.2.tar
安装好后,目录结构如下:
$ tree mongodb-linux-x86_64-1.7.2
mongodb-linux-x86_64-1.7.2
|– GNU-AGPL-3.0
|– README
|– THIRD-PARTY-NOTICES
`– bin
|– bsondump
|– mongo
|– mongod
|– mongodump
|– mongoexport
|– mongofiles
|– mongoimport
|– mongorestore
|– mongos
|– mongosniff
`– mongostat
1 directory, 14 files

3. 创建数据目录
根据本例sharding架构图所示,在各台sever上创建shard数据文件目录
Server1:
su – monodb
cd /home/monodb
mkdir -p data/shard11
mkdir -p data/shard21
Server2:
su – monodb
cd /home/monodb
mkdir -p data/shard11
mkdir -p data/shard22
Server3:
su – monodb
cd /home/monodb
mkdir -p data/shard13
mkdir -p data/shard23

配置relica sets

1. 配置shard1所用到的replica sets:
Server1:
cd /home/mongodb/mongodb-linux-x86_64-1.7.2/bin
./mongod –shardsvr –replSet shard1 –port 27017 –dbpath /home/mongodb/data/shard11 –oplogSize 100 –logpath /home/mongodb/data/shard11.log –logappend –fork

Server2:
cd /home/mongodb/mongodb-linux-x86_64-1.7.2/bin
./mongod –shardsvr –replSet shard1 –port 27017 –dbpath /home/mongodb/data/shard12 –oplogSize 100 –logpath /home/mongodb/data/shard12.log –logappend –fork

Server3:
cd /home/mongodb/mongodb-linux-x86_64-1.7.2/bin
./mongod –shardsvr –replSet shard1 –port 27017 –dbpath /home/mongodb/data/shard13 –oplogSize 100 –logpath /home/mongodb/data/shard13.log –logappend –fork

初始化replica set
用mongo连接其中一个mongod,执行:
> config = {_id: ’shard1′, members: [
{_id: 0, host: ‘10.1.1.1:27017’},
{_id: 1, host: ‘10.1.1.2:27017’},
{_id: 2, host: ‘10.1.1.3:27017’}]
}

> rs.initiate(config);

同样方法,配置shard2用到的replica sets:
server1:
cd /home/mongodb/mongodb-linux-x86_64-1.7.2/bin
./mongod –shardsvr –replSet shard2 –port 27018 –dbpath /home/mongodb/data/shard21 –oplogSize 100 –logpath /home/mongodb/data/shard21.log –logappend –fork

server2:
cd /home/mongodb/mongodb-linux-x86_64-1.7.2/bin
./mongod –shardsvr –replSet shard2 –port 27018 –dbpath /home/mongodb/data/shard22 –oplogSize 100 –logpath /home/mongodb/data/shard22.log –logappend –fork

server3:
cd /home/mongodb/mongodb-linux-x86_64-1.7.2/bin
./mongod –shardsvr –replSet shard2 –port 27018 –dbpath /home/mongodb/data/shard23 –oplogSize 100 –logpath /home/mongodb/data/shard23.log –logappend –fork

初始化replica set
用mongo连接其中一个mongod,执行:
> config = {_id: ’shard2′, members: [
{_id: 0, host: ‘10.1.1.1:27018’},
{_id: 1, host: ‘10.1.1.2:27018’},
{_id: 2, host: ‘10.1.1.3:27018’}]
}

> rs.initiate(config);

到此就配置好了二个replica sets,也就是准备好了二个shards

配置三台config server

Server1:
mkdir -p /home/mongodb/data/config
./mongod –configsvr –dbpath /home/mongodb/data/config –port 20000 –logpath /home/mongodb/data/config.log –logappend –fork   #config server也需要dbpath

Server2:
mkdir -p /home/mongodb/data/config
./mongod –configsvr –dbpath /home/mongodb/data/config –port 20000 –logpath /home/mongodb/data/config.log –logappend –fork

Server3:
mkdir -p /home/mongodb/data/config
./mongod –configsvr –dbpath /home/mongodb/data/config –port 20000 –logpath /home/mongodb/data/config.log –logappend –fork

配置mongs

在server1,server2,server3上分别执行:
./mongos –configdb 10.1.1.1:20000,10.1.1.2:20000,10.1.1.3:20000 –port 30000 –chunkSize 5 –logpath /home/mongodb/data/mongos.log –logappend –fork
#mongs不需要dbpath

Configuring the Shard Cluster

连接到其中一个mongos进程,并切换到admin数据库做以下配置
1. 连接到mongs,并切换到admin
./mongo 10.1.1.1:30000/admin
>db
Admin
2. 加入shards
如里shard是单台服务器,用>db.runCommand( { addshard : “<serverhostname>[:<port>]” } )这样的命令加入,如果shard是replica sets,用replicaSetName/<serverhostname>[:port][,serverhostname2[:port],…]这样的格式表示,例如本例执行:
>db.runCommand( { addshard : “shard1/10.1.1.1:27017,10.1.1.2:27017,10.1.1.3:27017″,name:”s1″,maxsize:20480} );
>db.runCommand( { addshard : “shard2/10.1.1.1:27018,10.1.1.2:27018,10.1.1.3:27018″,name:”s2″,maxsize:20480} );
注意:在添加第二个shard时,出现error:test database 已经存在的错误,这里用mongo命令连接到第二个replica set,用db.dropDatabase()命令把test数据库给删除然后就可加入

3. 可选参数
Name:用于指定每个shard的名字,不指定的话系统将自动分配
maxSize:指定各个shard可使用的最大磁盘空间,单位megabytes

4. Listing shards
>db.runCommand( { listshards : 1 } )
如果列出了以上二个你加的shards,表示shards已经配置成功

5. 激活数据库分片
命令:
> db.runCommand( { enablesharding : “<dbname>” } );
通过执行以上命令,可以让数据库跨shard,如果不执行这步,数据库只会存放在一个shard,一旦激活数据库分片,数据库中不同的collection将被存放在不同的shard上,但一个collection仍旧存放在同一个shard上,要使单个collection也分片,还需单独对collection作些操作

Collecton分片

要使单个collection也分片存储,需要给collection指定一个分片key,通过以下命令操作:
> db.runCommand( { shardcollection : “<namespace>”,key : <shardkeypatternobject> });
注:
a. 分片的collection系统会自动创建一个索引(也可用户提前创建好)
b. 分片的collection只能有一个在分片key上的唯一索引,其它唯一索引不被允许
One note: a sharded collection can have only one unique index, which must exist on the shard key. No other unique indexes can exist on the collection.

分片collection例子

>db.runCommand( { shardcollection : “test.c1″,key : {id: 1} } )
>for (var i = 1; i <= 200003; i++) db.c1.save({id:i,value1:”1234567890″,value2:”1234567890″,value3:”1234567890″,value4:”1234567890″});
> db.c1.stats()
{
“sharded” : true,
“ns” : “test.c1″,
“count” : 200003,
“size” : 25600384,
“avgObjSize” : 128,
“storageSize” : 44509696,
“nindexes” : 2,
“nchunks” : 15,
“shards” : {
“s1″ : {
“ns” : “test.c1″,
“count” : 141941,
“size” : 18168448,
“avgObjSize” : 128,
“storageSize” : 33327616,
“numExtents” : 8,
“nindexes” : 2,
“lastExtentSize” : 12079360,
“paddingFactor” : 1,
“flags” : 1,
“totalIndexSize” : 11157504,
“indexSizes” : {
“_id_” : 5898240,
“id_1″ : 5259264
},
“ok” : 1
},
“s2″ : {
“ns” : “test.c1″,
“count” : 58062,
“size” : 7431936,
“avgObjSize” : 128,
“storageSize” : 11182080,
“numExtents” : 6,
“nindexes” : 2,
“lastExtentSize” : 8388608,
“paddingFactor” : 1,
“flags” : 1,
“totalIndexSize” : 4579328,
“indexSizes” : {
“_id_” : 2416640,
“id_1″ : 2162688
},
“ok” : 1
}
},
“ok” : 1
}

 

Connect to Java DB (Derby) with org.apache.derby.jdbc.EmbeddedDriver

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.Statement;

public class JavaDBDemo {
  static Connection conn;

  public static void main(String[] args) {
    String driver = “org.apache.derby.jdbc.EmbeddedDriver”;
    String connectionURL = “jdbc:derby:myDatabase;create=true”;
    String createString = “CREATE TABLE Employee (NAME VARCHAR(32) NOT NULL, ADDRESS VARCHAR(50) NOT NULL)”;
    try {
      Class.forName(driver);
    catch (java.lang.ClassNotFoundException e) {
      e.printStackTrace();
    }
    try {
      conn = DriverManager.getConnection(connectionURL);
      Statement stmt = conn.createStatement();
      stmt.executeUpdate(createString);

      PreparedStatement psInsert = conn.prepareStatement(“insert into Employee values (?,?)”);

      psInsert.setString(1, args[0]);
      psInsert.setString(2, args[1]);

      psInsert.executeUpdate();

      Statement stmt2 = conn.createStatement();
      ResultSet rs = stmt2.executeQuery(“select * from Employee”);
      int num = 0;
      while (rs.next()) {
        System.out.println(++num + “: Name: ” + rs.getString(1“\n Address” + rs.getString(2));
      }
      rs.close();
    catch (Exception e) {
      e.printStackTrace();
    }
  }
}


Derby JDBC Connection

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Statement;

import java.util.Properties;

public class MainClass {
   public static void main(String[] args)
   {
      try {
         String driver = “org.apache.derby.jdbc.EmbeddedDriver”;

         Class.forName(driver).newInstance();
         Connection conn = null;
         conn = DriverManager.getConnection(“jdbc:derby:DerbyTestDB”);
         Statement s = conn.createStatement();
         ResultSet rs = s.executeQuery(“SELECT city, state, zipcode FROM zipcodes”);

         while(rs.next()) {
            System.out.println(“City   : “+ rs.getString(1));
            System.out.println(“State  : “+ rs.getString(2));
            System.out.println(“Zipcode: “+ rs.getString(3));
            System.out.println();
         }

         rs.close();
         s.close();
         conn.close();
      catch(Exception e) {
         System.out.println(“Exception: “+ e);
         e.printStackTrace();
      }
   }
}