本文来源于我在InfoQ中文站翻译的文章，原文地址是：http://www.infoq.com/cn/news/2015/12/introducing-kinto

Kinto是个提供了同步与分片功能的轻量级JSON存储服务，并且易于使用。

它在Mozilla内部得到了广泛的应用，基于Apache v2许可。

基本上，Kinto是个服务，client应用能够通过它存储和获取JSON数据。为了对这些数据提供同步与共享特性，Kinto引入了一些基本概念。

• Bucket：能够将bucket看作是命名空间：假设存储在不同的bucket中。那么集合名之间是不会出现冲突的。
• Collection：记录的集合。
• Record：实际存储的数据。
• Group：定义权限的具名principal列表。

Record是数据的最小单元。默认情况下是无模式的。JSON能够包括不论什么数据。Collection是一组Record。我们以列表的形式操纵Record。能够对其进行过滤和排序。Bucket是个抽象的概念，用于组织集合及其权限。

Kinto提供了一个名为default的Bucket，其集合与记录仅仅可由当前用户訪问。

Kinto所操纵的每一种对象都共享一些公用的属性：

• 一个唯一标识符
• 一个版本，有改动时会自增
• 一组权限

这些概念非常相似于磁盘，其中的Bucket就是分区、Collection是文件夹，而Record则是文件。

Kinto拥有一个用户组的概念。一个组会有一个成员列表，他们属于一个Bucket。

权限引用的是组而非单个用户，这使得我们能够轻松定义“角色”，特别是在将同一组权限应用到几个对象的时候。

为了控制记录的查看、创建、改动与删除操作。Kinto能够在Bucket、Group、Collection与单个Record上定义权限。既然在Bucket、Collection与Record之间存在着继承的概念。因此Kinto考虑到了从父对象继承权限的问题。比方说。假设一个Bucket定义了一个权限，同意匿名用户读取。那么该Bucket中的每一个Collection的每一条Record就都能够读取。这都是继承的结果。创建新对象的权限定义在父对象中。比方说，创建Record的权限定义在Collection中。创建Collection或是Group的权限定义在Bucket中。

只是，创建新Bucket的权限则是通过server配置来控制的。

Kinto的主要应用场景例如以下所看到的：

• 为前端应用提供了通用的Web数据库
• 构建带有细粒度权限控制的协作式应用
• 可存储加密数据
• 在不同设备间同步应用数据

值得一提的是，Kinto眼下在Firefox与Firefox OS上得到了广泛的应用。主要用于对设置与各种信息进行全局同步；此外，它还是浏览器扩展与Web应用中个人数据存储的首选解决方式。

Kinto的主要特性例如以下所看到的：

• 数据同步
• 细粒度权限控制
• JSON Schema验证
• 通用且多client支持
• 开源、自托管
• 良好的设计

Kinto的亮点有：

• 充分利用了HTTP最佳实践
• 可插拔的认证机制
• 可插拔的存储、缓存与权限支持
• 可通过INI文件或是环境变量进行配置
• 内建的监控支持
• 缓存控制

双向的记录同步是个非常困难的事情。

Kinto走了一些捷径，它仅仅对并发控制与变更轮询提供了一些基本保障手段。并且不会自己主动解决冲突问题。基本上，每一个对象都有一个版本，每次改动后该版本都会添加。Kinto并不会保存对象老的版本。

client能够获取到自某个特定的版本以来记录集合所发生的变更列表，Kinto还能够通过它防止对象的意外更新。

Kinto同步功能是由Mozilla Firefox Sync团队进行设计并开发的。

在開始构建自己的数据存储服务前。我们先来看看市场上已经存在的产品。

Kinto团队一開始的想法是使用并扩展已有的社区项目。并没有打算又一次发明轮子。只是，经过了一些尝试后。团队发现既有的这些解决方式都无法非常好地解决团队所面临的问题。比方说细粒度权限控制等。

因此，团队基于开发Firefox Sync所积累的经验開始构建自己的数据存储服务。

下表展示了Kinto与市场上同类产品的功能比較，这有助于读者了解Kinto相对于其它竞品来说有哪些优势。

[1] 眼下，Hoodie的用户插件会自己主动让用户认证通过，只是他们正在解决问题。

[2] CouchDB将Map/Reduce作为查询机制，这对于新人来说不太好理解。

[3] Remote Storage能够对文件夹使用“ls”，只是内容项并非排好序的。也没有分页。

[4] 对于冲突处理来说，Kinto使用了与Remote storage同样的机制。

[5] Remote Storage支持OAuth2.0 Implicit Grant Flow。

[6] 对去中心化的发现支持在计划其中，只是尚未实现。

[7] Remote Storage并没有定义不论什么默认实现（由于它是个协议），只是能够通过JavaScript与Node.js轻松上手。

感兴趣的读者还能够通过这里了解到创建Kinto背后的种种抉择与动机。

以下是关于Kinto的一些FAQ，能够帮助读者更好地了解这款轻量级JSON存储的设计原理与具体使用场景。

Kinto能够对数据进行加密么？

Kintoserver会将传递过来的不论什么数据存储起来，不管数据是否加密都如此。我们觉得加密应该是client做的事情。你能够通过我们提供的Kinto.jsclient轻松实现对数据的加密处理。

对于我所使用的操作系统来说，Kinto是否提供了包下载工具？

没有，只是这个想法非常不错。为几个平台维护包是一件非常耗时间的事情。况且我们如今还是个小团队。眼下，你能够通过我们提供的Makefile或是Dockerfile轻松执行server。能够通过pip轻松安装Kinto。在Docker hub也有镜像。只是，假设你愿意帮助我们在你所喜欢的操作系统上维护Kinto包。那么我们将万分感激！

为何会选择使用Python而不是其它语言？

我们喜欢Python。由于它是门简洁且富于表现力的语言，同一时候又提供了强大的数据结构，并且易于学习。因此，开发团队选择了使用Python。

此外。Mozilla的运维团队也对在生产环境下部署和管理Python应用驾轻就熟。

只是，Python本身仅仅是个实现细节而已。Kinto是由HTTP协议定义的。能够使用不论什么语言实现。

可否在Kinto中存储文件？

如今还不行。只是我们已经设计了一个文件存储特性，如今正在实现中，估计将于明年公布。与此同一时候，假设想要尝试最新版。我们非常期待你的反馈。

何为Cliquet？Cliquet与Kinto存在哪些区别？

Cliquet是个用于设计微服务的工具集。Kinto则是通过该工具集构建的server。

我遇到了Exception错误。哪里出错了呢？

能够通过Troubleshooting了解关于错误的具体信息。

感兴趣的读者能够尝试Kinto，这里是Kinto的文档说明。