一个承载着CouchDB服务器主机的数据库，以文档方式存储。每个文档在数据库中都有唯一的名称，CouchDB提供一个RESTful HTTP API来读取和更新(添加、编辑、删除)数据库文档。
文档是CouchDB中的主要数据单元，由任意数量的字段和附件组成。文档还包括数据库系统维护的元数据。文档字段是唯一命名的，并且包含不同类型的值(文本、数字、布尔值、列表等)，并且没有对文本大小或元素数量的设置限制。
CouchDB文档更新模型是无锁且乐观的。文档编辑是通过客户机应用程序加载文档、应用更改并将它们保存回数据库来完成的。如果另一个编辑相同文档的客户端首先保存其更改，则客户端在保存时将获得编辑冲突错误。要解决更新冲突，可以打开最新的文档版本，重新应用编辑并再次尝试更新。
MongoDB和Cassandra都属于NoSQL数据库系列，它们也恰好都是开源，但是，它们的相似之处仅此而已。
在深入探讨MongoDB和Cassandra的不同之处之前，让我们先看看它们的相似之处。
显然，它们都是数据库。更重要的是，它们都是NoSQL数据库。NoSQL是一种数据库架构类型，其中数据主要以相对非结构化的方式存储。与更传统的SQL式数据库相比，NoSQL可以更有效地存储大量非结构化数据，企业在大数据操作中通常会涉及非结构化数据。
Cloudera在2016年发布了新型的分布式存储系统——kudu，kudu目前也是Apache下面的开源项目。Hadoop生态圈中的技术繁多，HDFS作为底层数据存储的地位一直很牢固。而HBase作为Google BigTable的开源产品，一直也是Hadoop生态圈中的核心组件，其数据存储的底层采用了HDFS，主要解决的是在超大数据集场景下的随机读写和更新的问题。
Kudu的设计有参考HBase的结构，也能够实现HBase擅长的快速的随机读写、更新功能。那么同为分布式存储系统，HBase和Kudu二者有何差异？两者的定位是否相同？我们通过分析HBase与Kudu整体结构和存储结构等方面对两者的差异进行比较。
Mongodb-3.2已经WiredTiger设置为了默认的存储引擎，最近通过阅读wiredtiger源代码（在不了解其内部实现的情况下，读代码难度相当大，代码量太大，强烈建议官方多出些介绍文章），理清了wiredtiger的大致原理，并简单总结，不保证内容都是正确的，如有问题请指出，欢迎讨论交流。
按照Mongodb默认的配置，WiredTiger的写操作会先写入Cache，并持久化到WAL(Write ahead log)，每60s或log文件达到2GB时会做一次Checkpoint，将当前的数据持久化，产生一个新的快照。Wiredtiger连接初始化时，首先将数据恢复至最新的快照状态，然后根据WAL恢复数据，以保证存储可靠性。
注：Lindorm是阿里内部HBase分支的别称，在阿里云上对外售卖的版本叫做HBase增强版，之后文中出现的HBase增强版和Lindorm都指同一个产品。
2019年以来，Lindorm已经服务了包括淘宝、天猫、蚂蚁、菜鸟、妈妈、优酷、高德、大文娱等数十个BU，在今年的双十一中，Lindorm峰值请求达到了7.5亿次每秒，天吞吐22.9万亿次，平均响应时间低于3ms，整体存储的数据量达到了数百PB。这些数字的背后，凝聚了HBase&Lindorm团队多年以来的汗水和心血。
Lindorm脱胎于HBase，是团队多年以来承载数百PB数据，亿级请求量，上千个业务后，在面对规模成本压力，以及HBase自身缺陷下，全面重构和引擎升级的全新产品。相比HBase，Lindorm无论是性能，功能还是可用性上，都有了巨大飞跃。本文将从功能、可用性、性能成本、服务生态等维度介绍Lindorm的核心能力与业务表现，最后分享部分我们正在进行中的一些项目。
1. What is Time Series data?
Time series data is a series of values where the time information (timestamp) corresponds to data recorded or an event that happened at that point in time. The data can have both regular and fluctuating intervals. For example, temperature recordings would be recorded at a set time, every minute or hour, while a stock price would be recorded every time a trade is completed.
Time Series data is usually a log or “append-only”, records are rarely updated except upon deletion when they expire. You wouldn’t update values in your web server logs and the same holds true for most Time Series data collections.
KeyDB is an in-memory, high performance database with support for numerous data types, on-disk persistence and high availability. Compatible with Redis™ API and protocols, KeyDB is a drop-in replacement for your existing Redis™ deployments with numerous enhancements, higher performance, and lower Total Cost of Ownership (TCO).
Designed for use as both a cache as well as use as a primary database, KeyDB is a fast and versatile NOSQL database useful in many applications. Its low resource requirements and high-speed mean fewer instances to manage and much lower costs. KeyDB looks to fully utilize the hardware provided to your instances enabling a higher throughput and efficiency.
随着CoreOS和Kubernetes等项目在开源社区日益火热，它们项目中都用到的etcd组件作为一个高可用强一致性的服务发现存储仓库，渐渐为开发人员所关注。在云计算时代，如何让服务快速透明地接入到计算集群中，如何让共享配置信息快速被集群中的所有机器发现，更为重要的是，如何构建这样一套高可用、安全、易于部署以及响应快速的服务集群，已经成为了迫切需要解决的问题。etcd为解决这类问题带来了福音，本文将从etcd的应用场景开始，深入解读etcd的实现方式，以供开发者们更为充分地享用etcd所带来的便利。
要问etcd是什么？很多人第一反应可能是一个键值存储仓库，却没有重视官方定义的后半句，用于配置共享和服务发现。
A highly-available key value store for shared configuration and service discovery.
实际上，etcd作为一个受到ZooKeeper与doozer启发而催生的项目，除了拥有与之类似的功能外，更专注于以下四点。
Nebula Graph：一个开源的分布式图数据库。作为唯一能够存储万亿个带属性的节点和边的在线图数据库，Nebula Graph 不仅能够在高并发场景下满足毫秒级的低时延查询要求，还能够实现服务高可用且保障数据安全性。
Nebula Graph 是开源的第三代分布式图数据库，不仅能够存储万亿个带属性的节点和边，而且还能在高并发场景下满足毫秒级的低时延查询要求。不同于 Gremlin 和 Cypher，Nebula 提供了一种 SQL-LIKE 的查询语言 nGQL，通过三种组合方式（管道、分号和变量）完成对图的 CRUD 的操作。在存储层 Nebula Graph 目前支持 RocksDB 和 HBase 两种方式。