{{short description|Data storage paradigm}} {{about|a storage system architecture|the mode of data representation|Key–value pair}}

[[File:BabbageKeyValueCard.tiff|thumb|350px|A tabular data card proposed for Babbage's Analytical Engine showing a key–value pair, in this instance a number and its base-ten logarithm]] A '''key-value database''', or '''key-value store''', is a data storage paradigm designed for storing, retrieving, and managing associative arrays, a data structure more commonly known today as a ''dictionary''. Dictionaries contain a collection of ''objects'', or ''records'', which in turn have many different ''fields'' within them. These records are stored and retrieved using a ''key'' that uniquely identifies the record, and is used to find the data within the database.<ref name="corbellini">{{Cite journal| doi = 10.1016/j.is.2016.07.009| issn = 0306-4379| volume = 63| pages = 1–23| last1 = Corbellini| first1 = Alejandro| last2 = Mateos| first2 = Cristian| last3 = Zunino| first3 = Alejandro| last4 = Godoy| first4 = Daniela| last5 = Schiaffino| first5 = Silvia| title = Persisting big-data: The NoSQL landscape| journal = Information Systems| access-date = 2025-05-25| date = 2017-01-01| url = https://www.sciencedirect.com/science/article/pii/S0306437916303210| hdl = 11336/58462| hdl-access = free}}</ref><ref name="autogenerated1">{{Cite conference| doi = 10.1109/CSC.2011.6138544| conference = 2011 International Conference on Cloud and Service Computing| pages = 336–341| last1 = Hecht| first1 =Robin| last2 = Jablonski | first2 = Stefan| title = NoSQL evaluation: A use case oriented survey| date = 2011}}</ref>

thumb|300x300px|A table showing different formatted data values associated with different keys Key-value databases differ from the better known relational databases (RDB). RDBs pre-define the data structure in the database as a series of tables containing fields with well-defined data types. Exposing the data types to the database program allows it to apply various optimizations. In contrast, key-value systems treat the value as opaque to the database itself, and typically support only simple operations such as storing, retrieving, updating, and deleting a value by its key. This offers considerable flexibility and makes such systems well suited to low-latency, high-throughput workloads dominated by direct key lookups, but less suitable for applications that require complex queries or explicit relationships among records.<ref name="Gessert et al. 2017"/><ref name="Grolinger et al. 2013"/>

A lack of standardization, limited transaction support, and relatively simple query interfaces long restricted many key-value systems to specialized uses, but the rapid move to cloud computing after 2010 helped drive renewed interest in them as part of the broader NoSQL movement. Some graph databases, such as ArangoDB,<ref>{{cite web |title=Storage Engines |url=https://www.arangodb.com/docs/stable/architecture-storage-engines.html |website=ArangoDB |access-date=16 November 2020}}</ref> are also key–value databases internally, adding the concept of relationships (''pointers'') between records as a first-class data type.<ref name="Grolinger et al. 2013"/><ref name="Gessert et al. 2017"/>

==Types and examples== Key–value systems span a wide consistency spectrum, from eventually consistent designs to strongly consistent or serializable ones, and some allow the consistency level to be configured as part of the trade-off against latency and availability.<ref name="Gessert et al. 2017"/><ref name="Grolinger et al. 2013"/> Renewed interest in key–value and other NoSQL systems was driven in part by the demands of big data, distributed, and cloud applications. Their scalability and availability made them attractive for cloud data management, although limited transaction support, low-level query interfaces, and the lack of standardization remained obstacles to wider adoption.<ref name="Grolinger et al. 2013"/> Some maintain data in memory (RAM), while others employ solid-state drives or rotating disks.<ref name="corbellini"/>

Some key–value systems add additional structure to their keys. For example, Oracle NoSQL Database organizes records using composite keys with "major" and "minor" components, an arrangement that Oracle compares to a directory-path structure in a file system. More generally, however, key–value stores are defined by their use of unique keys associated with opaque values and by their emphasis on simple key-based operations.<ref>[http://www.thinkmind.org/download.php?articleid=immm_2012_4_10_20050 Oracle NoSQL Database].</ref>

Unix included ''dbm'' (database manager), a minimal database library written by Ken Thompson for managing associative arrays with a single key and hash-based access. Later implementations and related libraries included sdbm, GNU dbm (gdbm), and Berkeley DB.<ref name="Seltzer and Yigit 1991"/>

A more recent example is RocksDB, a persistent key–value storage engine developed at Facebook and designed for large-scale applications.<ref name="Dong et al. 2021"/> Other examples include in-memory systems such as Memcached and Redis, and persistent systems such as Berkeley DB, Riak, and Voldemort.<ref name="Grolinger et al. 2013"/>

==See also== * Data analysis * Document-oriented database * Multi-model database * Tuple space * Ordered key–value store * Name–value pair

==References== <references>

<ref name="Dong et al. 2021">{{cite journal |last1=Dong |first1=Siying |last2=Kryczka |first2=Andrew |last3=Jin |first3=Yanqin |last4=Stumm |first4=Michael |title=Rocksdb: evolution of development priorities in a key-value store serving large-scale applications |journal=ACM Transactions on Storage |year=2021 |volume=17 |issue=4 |pages=1–32 |doi=10.1145/3483840 |doi-access=free}}</ref>

<ref name="Gessert et al. 2017">{{cite journal |last1=Gessert |first1=Felix |last2=Wingerath |first2=Wolfram |last3=Friedrich |first3=Steffen |last4=Ritter |first4=Norbert |title=NoSQL database systems: a survey and decision guidance |journal=Computer Science - Research and Development |year=2017 |volume=32 |issue=3–4 |pages=353–365 |doi=10.1007/s00450-016-0334-3}}</ref>

<ref name="Grolinger et al. 2013">{{cite journal |last1=Grolinger |first1=Katarina |last2=Higashino |first2=Wilson A. |last3=Tiwari |first3=Abhinav |last4=Capretz |first4=Miriam AM |title=Data management in cloud environments: NoSQL and NewSQL data stores |journal=Journal of Cloud Computing: Advances, Systems and Applications |year=2013 |volume=2 |issue=1 |article-number=22 |doi=10.1186/2192-113x-2-22 |doi-access=free}}</ref>

<ref name="Seltzer and Yigit 1991">{{cite conference |last1=Seltzer |first1=Margo I. |last2=Yigit |first2=Ozan |title=A New Hashing Package for UNIX |book-title=Proceedings of the 1991 Winter USENIX Technical Conference |date=January 1991 |pages=173–184 |location=Dallas, Texas |url=https://www.usenix.org/legacy/publications/library/proceedings/seltzer2.pdf}}</ref>

</references>

{{Database models}}

{{DEFAULTSORT:Key-value database}} Category:Types of databases Category:Database theory Category:Associative arrays Category:Key-value databases Category:Data management Category:Databases Category:Data analysis