SnappyDB—Android上的NoSQL数据库简介

参考:http://www.open-open.com/lib/view/open1420816891937.html

参考:http://android-arsenal.com/details/1/936

 

项目GIthub主页:https://github.com/nhachicha/SnappyDB#cookbook

 

在开发App的时候,经常需要缓存一些数据,不至于每次打开App都是空的,需要从网络下载数据。例如新闻客户端,需要缓存上次打开的新闻。

一般的做是使用SQLite数据库来保存数据,或者把数据序列化写到本地文件中。这两中方法,我在之前的项目中都用过。我先来说一下这两种方法的缺点:

  • 使用SQLite数据库保存: 对于保存缓存数据来说,这样做未免太重量级了,存取数据都比较麻烦。当然,你还要知道SQL语法。小心设计数据库结构。对于相对复杂的数据,你还要设计多张表。还需要小心维护数据库的升级。
  • 使用文件缓存: 写文件保存,需要你保存的数据都实现Serializable接口,当然,这不是什么大问题。你要维护你的文件内容结构。如果数据比较多,你可能要维护多个文件的读写。性能也是比较堪忧。

说了上面那些方法的缺点,自然是为了请出本文的主角——SnappyDB

SnappyDB是一个键-值数据库,是非常流行的NoSQL数据库。可以保存任何基本类型和序列化(Serializable)安全的数据及其数组。

首先来看一下基本用法,如下:

DB snappydb = DBFactory.open(context); //create or open an existing databse using the default name

snappydb.put("name", "Jack Reacher");
snappydb.putInt("age", 42);
snappydb.putBoolean("single", true);
snappydb.put("books", new String[]{"One Shot", "Tripwire", "61 Hours"});

String   name   =  snappydb.get("name");
int      age    =  snappydb.getInt("age");
boolean  single =  snappydb.getBoolean("single");
String[] books  =  snappydb.getArray("books", String.class);// get array of string

snappydb.close();

  

可以看到使用非常方便,API简单到不用去学习。

另外,SnappyDB在保存和读取序列对象的时候,使用的是Kryo库,也Java内置序列化更快。更大的优势是,你并不要为数据去显式的去实现Serializable接口。这就意味着你以前的代码完全不要做任何改动。

Number[] array = {new AtomicInteger (42), new BigDecimal("10E8"), Double.valueOf(Math.PI)};

snappyDB.put("array", array);

  

更多API文档,请看官方的Cookbook

再来看看性能,如下图:  可以看到,性能上甩SQLite几条街。

当然,SnappyDB在数据的稳定性上,还是有待验证的,应该是不如成熟的SQLite。多线程访问安全问题,作者也没有提到。但是从我们的需求(用来缓存数据)来看,SnappyDB应该是非常好的选择。其他例如realm-java,是一个比较严谨NoSQL的实现,还有简单轻量级的实现,如Couchbase-Lite-AndroidSimpleNoSQL

时间: 2024-10-11 11:15:48

SnappyDB—Android上的NoSQL数据库简介的相关文章

Android中的SQLite数据库简介

SQLite简介: SQLite是Android系统采用的一种开源的轻量级的关系型的数据库,Android中允许每个应用程序都拥有自己独立的数据库,每个应用程序的数据库的位置一般在/data/data/<package_name>/databases中.为了方便开发人员的使用,Android的API对增删查改实现了封装,通过SQLiteOpenHelper类可以方便的实现对数据库的创建和管理操作.不过正式的使用数据库之前,我们还要知道两个基本知识点. Content Values 和Curso

细数 Windows 平台上的 NoSQL 数据库

从可查询的分布式解决方案,如MongoDB,到简单的分布式Key/Value存储解决方案,如Cassandra.此外,还有Riak,Tokyo Cabinet,Voldemort,CouchDB和Redis.但目前仅有少量的NoSQL项目支持在Windows平台上运行,如果要说到生产应用那就更少了. Memcached Memcached传统上认为它不属于NoSQL的范畴,而是一个分布式Key/Value内存缓存解决方案,它可以用来存储各种各样的临时数据集,存储方式和其它NoSQL数据库解决方案

在AWS上配置NoSQL数据库 需要考虑什么?

OmniTI(web架构和工程公司)的首席执行官罗伯特·特里特认为AWS基础设施越来越流行为企业APP后端配置NoSQL数据库.企业架构师在开发能够从云计算中收益最多的数据库结构的时候,需要考虑各种各样的挑战并找寻最佳方案,这些挑战包括AWS的短暂性.Noisy Neighbors带来的问题.潜在的AWS托管基础设施之间的细微差别.以及NoSQL软件实现的差异. Aerospike(数据库软件供应商)的创始人兼首席技术官Brian Bulkowski宣称尽管存在这些挑战,但是AWS拓展性非常好,

NoSQL数据库的出现及选择哪种NoSQL数据库

    在没有NOSQL数据时,关系型数据库一直是数据持久化的唯一选择,比较典型的关系型数据库有SQL Server.Oracle,MySQL,DB2.做.NET开发的同学一般会选择SQL Server,做JAVA的可能会偏向Oracle,MySQL,Python则是PostgreSQL或MySQL等等.过去很长一段时间内,关系数据库的健壮性已经在多数应用程序中得到证实.我们可以使用这些传统数据库良好的控制并发操作.事务等等.然而如果传统的关系型数据库一直这么可靠,那么为什么还会出现NOSQL呢

解读NoSQL数据库的四大家族

在目前的企业IT架构中,系统管理员以及DBA都会考虑使用NoSQL数据库来解决RDBMS所不能解决的问题,特别是互联网行业.传统的关系型数据库主要以表(table)的形式来存储数据,而无法应对非结构化数据的挑战.在进行数据标准化的过程中,关系型数据库性能遭遇了瓶颈. NoSQL顾名思义就是Not-Only SQL,它可以作为关系型数据库的良好补充.在TechTarget数据库之前的报道中,我们也对NoSQL数据库的应用场景做了详细的介绍.NoSQL不像传统的关系型数据库,其种类繁多,且各有各的优

面向Android上Dalvik运行时的C# 编译器dot42简介

Mono for Android最大的缺点是需要在Mono上面构建,这与Android预期的运行时完全不同.尽管能够直接访问完整的CLR的确有些优势,但是它与Android的Dalvik 运行时之间的封送调用(marshalling call)可能非常昂贵.那为什么不跳过IL代码直接生成Dex代码呢? 事实上这有点夸张.dot42编译器实际上并没有跳过IL.恰恰相反,它读取IL代码并将其转换为一种叫做RL或Register Language的新语言.IL和RL主要的差异在于IL是基于栈的(有点像

大数据管理系统:NoSQL数据库前世今生

文章讲的是大数据管理系统:NoSQL数据库前世今生,NoSQL一词最早出现于1998年,它是Carlo Strozzi开发的一个轻量.开源.不提供SQL功能的关系型数据库(他认为,由于NoSQL悖离传统关系数据库模型,因此,它应该有一个全新的名字,比如"NoREL"或与之类似的名字). 2009年,Last.fm的Johan Oskarsson发起了一次关于分布式开源数据库的讨论,来自Rackspace的Eric Evans再次提出了NoSQL的概念,这时的NoSQL主要指非关系型.分

Java中8个顶级开源NoSQL数据库!

Java中8个顶级开源NoSQL数据库! NoSQL Databases, Java, Terrastore, Neo4j, Voldemort, HBase, InfoGrid, HyperGraphDB, Perst, NeoDatis ODB NoSQL正在崛起.许多企业和用户已经将MySQL数据库替换成了NoSQL数据库.NoSQL使分析非结构化的数据变得更容易,因此开发者必须意识到存在于NoSQL世界中的趋势和工具. 1.Terrastore 新的文档存储技术可以提供先进的伸缩性和弹性

云计算一周热文回顾:NoSQL数据库技术特性解析之文档数据库

NoSQL数据库技术特性解析之文档数据库 现今云计算的从业人员对NoSQL一词并不感到陌生,虽然很多技术人员都长期从事关系数据库的工作,但现在他们对NoSQL技术充满期待.对于企业来说,从关系型数据库到NoSQL数据库转变绝对是个需要深思熟虑的大改变.这涉及的不仅是软件的变化,更多的是对于数据存储上观念性的变化. 大多数非关系数据库都具有快速和可伸缩的特性.通过放弃关系存储模型和架构,关系数据库便可脱离由紧密结合的架构所带来对其施加的限制.应用程序也无需再链接数据库内表中的数据. MongoDB