Key-value Database

http://blog.csdn.net/byane/article/details/6928519

In traditional file systems, it is necessary to maintain the hierarchy of directories, to store metadata information using complex structures such as dentry,inode,directory, and more and more systems consider using Key-value form to save metadata information in the file system in the face of more custom file system requirements. Using a database to hold these metadata key-value is a good choice, compared to the traditional relational database, Key-value database in this area closer to the application requirements, because the database to save metadata often does not have a complex relationship operation, only need to provide efficient read and write performance, Reliability and durability.

Berkeley DB

Compare the classic Key-value database, C language development, can provide high read and write performance, support mass storage applications, the database itself to implement a backup mechanism, support two backup development mechanism, interface is simple. Open source, but there seems to be no one to maintain, it is said that the persistence is not very good.

Sqlite

1. Acid Transaction
2.0 Configuration – No installation and management configuration required
3. A complete database stored in a single disk file
4. Database files can be freely shared between machines of different byte order
5. Support database size up to 2TB
6. Small enough, roughly 30,000 lines C code, 250K
7. Faster than some popular databases in most common database operations
8. Simple, Easy API
9. Include TCL bindings while supporting other language bindings via wrapper
10. Good annotated source code, and has more than 90% test coverage
11. Independence: No additional reliance
Source completely open, you can use it for any purpose, including selling it
13. Support multiple development languages, C, PHP, Perl, Java, ASP. Net,python

Related article: http://www.sqlite.com.cn/

Redis
Redis is a very new project. Redis is essentially a key-value type of memory database, much like memcached, the entire database is loaded in memory to operate, periodically through asynchronous operations to flush the database data to the hard disk to save. Because it is pure memory operation, Redis performs well and can handle more than 100,000 reads and writes per second. The great feature of Redis is not only performance, but Redis's greatest charm is the ability to save the data structures of list lists and set sets, and it also supports various operations on the list, which can be either string,list,sets or ordered sets. For example, from the list of push and pop data, take list interval, sort and so on, set support various sets of set intersection operation, in addition, the maximum limit of a single value is 1GB, unlike memcached can only save 1MB of data, So Redis can be used to implement a lot of useful functions, such as using his list to do FIFO doubly linked list, to achieve a lightweight high-performance Message Queuing service, with his set can do high-performance tag system and so on. In addition, Redis can also set expire time for key-value, so it can also be used as a function-enhanced version of the memcached.

The main disadvantage of Redis is that database capacity is limited by physical memory and cannot be used as a high-performance read-write for massive data , and it has no native extensible mechanism, no scale (extensible) capability, and relies on clients for distributed read and write. So the Redis-fit scenario is largely confined to high-performance operations and operations with smaller data volumes . According to Redis's official website test report, 50 concurrent requests, 10w accesses, write speed of 11x10e4/s, read speed of 8,100 times/s. There are currently github,engine Yard on the site using Redis.

Basic data type Description: http://www.cnblogs.com/xhan/archive/2011/02/02/1948891.html

http://timyang.net/data/redis-misunderstanding/

Interactive command: Http://redis.io/commands

Tokyo Cabinet and Tokoy tyrant
TC and TT developers are Japanese Mikio Hirabayashi, mainly used in Japan's largest SNS website mixi.jp, TC development Time earliest, now is a very mature project, is also the biggest hot spot in Kye-value database field, It is now widely used in many websites. TC is a high-performance storage engine, while TT provides multi-threaded high concurrent server, performance is also excellent, can handle 450,000 read and write operations per second. In addition to supporting Key-value storage, TC supports saving Hashtable data type, so it is much like a simple database table, and also supports column-based conditional query, paging query and sorting function, basically equivalent to support single table basic query function, So you can simply replace many of the operations of a relational database. Tc/tt in the practical application of Mixi, storing more than 20 million data, while supporting tens of thousands of concurrent connections, is a proven project. The TC has a reliable data persistence mechanism while guaranteeing very high concurrent read and write performance, as well as supporting hashtable and simple conditions, paging and sorting operations like relational database table structures, and is a great NoSQL database.

The main disadvantage of TC is that the performance of concurrent write data will be greatly reduced after the data volume reaches the billion level, Nosql:if only It is that the easy mentioned, they found in TC inserted 160 million 2-20KB data, write performance began to drop sharply. It seems that when the data amount of billions of times, TC performance began to fall sharply , from the TC author's own Mixi data, at least the thousands data amount of time has not encountered such a significant write performance bottleneck. Flare, which is an improvement to the TC and TT, is primarily to support scalability.

Mongodb
To meet the massive storage needs, MONGO mainly solves the massive data access efficiency problem, according to the official document, when the data volume reaches above 50GB, the MONGO database accesses the speed is more than 10 times times MySQL. MONGO's concurrent read and write efficiency is not particularly good, according to official performance tests, which can handle 5,000 to 1.5 read and write requests per second

Couchdb
With the support of mass storage, COUCHDB provides only HTTP rest-based interfaces, so COUCHDB is very poor in terms of concurrency and read-write performance alone.

Cassandra

A distributed computing-oriented database that meets high scalability and availability is seen as an open source Google Big table. Both Facebook,twitter and digg.com are using Cassandra. The main characteristic of Cassandra is that it is not a database, but a distributed network service composed of a bunch of database nodes, a write operation to Cassandra will be copied to the other nodes, and the read operation to Cassandra will be routed to a node to read. For a Cassandra cluster, scaling performance is a simple matter, just add nodes to the cluster. See an article that says Facebook's Cassandra Cluster has more than 100 servers that make up a database cluster. Cassandra is measured by a single node, its node concurrency read and write performance is not particularly good, there is article said evaluation down Cassandra per second about less than 10,000 read and write requests, its concurrency performance depends on the total number of nodes in the system, routing efficiency, not just a single node concurrent load capacity.

Voldemort

Similar to Cassandra, it is a distributed computing-oriented database that provides high scalability and availability. Voldemort official given Voldemort the concurrent read and write performance is also very good, more than 15,000 times per second read and write.

LevelDB

Google developed the database, LEVELDB is an embedded key-value database. Its key and associated values can be any byte array, and sorted by key value, the sorting mechanism can be overloaded. The data storage mechanism is very simple, supporting only the put,get and delete commands, followed by forward and back iteration traversal. The data is automatically compressed using snappy, a compression library that Google uses for Bigtable,mapreduce and RPC, and announces open source. LEVELDB also has some limitations: SQL queries and indexes are not supported, multi-threaded single-process access is supported, and can be used with embedded devices. LEVELDB optimized for bulk write operations. It caches multiple modification requests in memory, and then writes them to disk after accumulating the pre-set thresholds for the configuration file. for sequential and random write operations, and sequential read operations, it is very good performance , according to Google's performance benchmark, it can be in some test projects to score the leading SQLite two orders of magnitude. SQLite is slightly better than leveldb in random read operations, and is twice times faster than leveldb when writing large data. Leveldb also performed better than Kyoto cabinet, Kyoto cabinet is also a key-value database, but Google has not been compared in all test projects like SQLite. Similarly, Riak conducted some test comparisons with Leveldb and InnoDB, and in some test projects, Google's leveldb was better than InnoDB or could achieve the same performance. Leveldb is written in C + +, and some external dependent libraries have been successfully ported to Windows, Mac OS X, Android, and various Unix. In practical applications, LEVELDB has been used in some of the experimental versions of Chrome as an implementation of the Indexdb API. The Riak is used for node-level storage.

Nosql

The regular relational database only supports thousands of or tens of thousands of accesses per second, and the in-memory database can be accessed tens of thousands of times to Brovants, supporting high concurrency, mass storage, high scalability, and high availability

Resources:

http://blog.csdn.net/21aspnet/article/details/6614013

Http://blog.evanweaver.com/articles/2009/07/06/up-and-running-with-cassandra

Http://hb.qq.com/a/20110823/000019.htm

Http://www.docin.com/p-115838909.html

http://www.iteye.com/topic/617156

http://blog.s135.com/dtcc/