Tutorial on

NoSQL Data Management:

Concepts and Systems

Holger Schwarz
Matthias Wieland
IPVS, Universität Stuttgart, Germany

SummerSOC 2015
 NoSQL Data Management

Overview

• Introduction to NoSQL

• Basic Concepts for NoSQL

• Overview of NoSQL Systems

2
 NoSQL Data Management

History of NoSQL

• SQL Databases were dominant for decades

 Persistent storage
 Standards based
 Concurrency Control
 Application Integration
 ACID
•  Designed to run on a single „big“ machine

• Cloud computing changes that dramatically

 Cluster of machines
 Large amount of unreliable machines
 Distributed System
 Schema-free unstructured Big Data

3
 NoSQL Data Management

Methods to Run a Database

• Virtual Machine Image
 Users purchase virtual machine instances to run a database on these
 Upload and setup own image with database, or use ready-made images with
optimized database installations
 E.g. Oracle Database 11g Enterprise Edition image for Amazon EC2 and for
Microsoft Azure.
• Database as a service (DBaaS)
 Using a database without physically launching a virtual machine instance
 No configuration or management needed by application owners
 E.g. Amazon Web Services provide SimpleDB, Amazon Relational Database Service
(RDS), DynamoDB,
• Managed database hosting
 Not offered as a service, but hosted and managed by the cloud database vendor
 E.g. Rackspace offers managed hosting for MySQL
• The TOSCA way
 Description of Cloud Services as Topology combined with the database stack
 Vendor-neutral automatic provisioning and management with OpenTOSCA
 Policies to define security requirements of the Cloud Service
 Portable and interoperable definition of data security and compliance aspects

4
 NoSQL Data Management

Which Data Model?

• Relational Databases
 Standard SQL database available for Cloud Environments as Virtual Machine
Image or as a service depending on the vendor
 Not cloud-ready: Difficult to scale
• NoSQL databases
 Database which is designed for the cloud
 Built to serve heavy read/write loads
 Good ability to scale up and down
 Applications built based on SQL data model require a complete rewrite
 E.g. Apache Cassandra, CouchDB and MongoDB

5
 NoSQL Data Management

How to scale the data management?

• Vertical scaling – Scale up

• Horizontal scaling – Scale out

6
 NoSQL Data Management

Definition and Goals of NoSQL databases

• No formal NoSQL definition
available!
• Store very large scale data
called “Big data”
• Typically scale horizontally
• Simple query mechanisms
• Often designed and set up for
a concrete application

• Typical characteristics of
NoSQL databases are:
 Non-relational
 Schema-free
 Open Source
 Simple API
 Distributed
 Eventual consistency
Source: https://clt.vtc.edu.hk/what-happens-online-in-60-seconds/
7
 NoSQL Data Management

Non-relational

• NoSQL databases generally do not follow the relational model

• Do not provide tables with flat fixed-column records
• Work with self-contained (hierarchical) aggregates or BLOBs
• No need for object-relational mapping and data normalization
• No complex and costly features like query languages, query planners,
referential integrity, joins, ACID

Schema-free
• Most NoSQL databases are schema-free or have relaxed schemas
• No need for definition of any sort of schema of the data
• Allows heterogeneous structures of data in the same domain

8
 NoSQL Data Management

Simple API

• Often simple interfaces for storage and querying data provided

• APIs often allow low-level data manipulation and selection methods
• Often no standard based query language is used
• Text-based protocols often using HTTP REST with JSON
• Web-enabled databases running as internet-facing services

Distributed
• Several NoSQL databases can be executed in a distributed fashion
• Providing auto-scaling and fail-over capabilities
• Often ACID is sacrificed for scalability and throughput
• Often no synchronous replication between distributed nodes is possible, e.g.
asynchronous Multi-Master Replication, peer-to-peer, HDFS Replication
• Only providing eventual consistency
9
 NoSQL Data Management

Core Categories of NoSQL Systems

• Key-Value Stores
 Manage associative arrays Value
 Big hash table
• Wide Column Stores
 Each storage block contains only data from one column
 Read and write is done using columns (rather than rows – like
in SQL)
• Document Stores
 Store documents consisting of tagged values
 Data is a collection of key value pairs
 Provides structure and encoding of the managed data
 Encoded using XML, JSON, BSON {
 Schema-free “id”: 123,
• Graph DB “name”:”Matthias”,
 Network database using graphs with node and edges for “location”:{
storage “city”:”Hersonissos”,
 Nodes represent entities, edges represent their relationships “region”:”Crete”
}
• Other NoSQL systems }
 ObjectDB
 XML DB
 Special Grid DB relation
 Triple Store A B

C
10
 NoSQL Data Management

Usage of NoSQL in Practice

• Google
 Big Table
 Google Apps, Google Search

• Facebook
 Social network

• Twitter

• Amazon
 DynamoDB and SimpleDB

• CERN

• GitHub

11
 NoSQL Data Management

Overview

• Introduction to NoSQL

• Basic Concepts for NoSQL

 CAP-Theorem
 Eventual Consistency
 Consistent Hashing
 MVCC-Protocol
 Query Mechanisms for NoSQL

• Overview of NoSQL Systems

12
 NoSQL Data Management

CAP Theorem – Brewer's theorem

Choose two!

• States that it is impossible for a

distributed system to provide all
three of the following guarantees

 Consistency: all nodes see the

same data at the same time
NoSQL (AP)
 Availability: every request
receives a response about
whether it succeeded or failed Domain Name
System DNS (AP)
 Partition tolerance: the
system continues to operate
Cloud Computing
despite physical network
(AP)
partitions

13
 NoSQL Data Management

Eventual consistency and BASE

• The term “eventual consistency”
 Copies of data on multiple machines to achieve high availability and scalability
 A change to a data item on one machine has to be propagated to other replicas
 Propagation is not instantaneous so the copies will be mutually inconsistent
 The change will eventually be propagated to all the copies
 Fast access requirement dominates
 Different replicas can return different values for the queried attribute of the object
 A System that achieved eventual consistency converged, or achieved replica
convergence

• Eventual consistency guarantees:

 If no new updates are made to a given data item eventually all accesses to that item will
return the last updated value

• Eventually consistent services provide weak consistency using BASE

 Basically Available, Soft state, Eventual consistency
 Basically available indicates that the system guaranteed availability (CAP theorem)
 Soft state indicates that the state of the system may change over time, even without input
 Eventual consistency indicates that the system will become consistent over time

14
 NoSQL Data Management

Consistent Hashing
• Technique how to efficiently distribute replicas to nodes
• Consistent hashing is a special kind of hashing
 When hash table is resized only K/n keys need to be remapped on average
 K is the number of keys, and n is the number of slots
 In traditional hash tables nearly all keys have to be remapped
• Insert Servers on ring
 Hash based e.g. on IP, Name, …
 Take over objects between own and processor hash
• Insert Objects on ring 0
 Hash based on key
 Walks around the circle until 2
falling into the first bucket Server 1
• Delete Servers
 Copy objects to next server Server
Server2/1
2
• Virtual Servers Server 2/2
 More than one hash per server
• Replication 12
 Place objects multiple times Server 3
 Improves reliability

15
 NoSQL Data Management

Multiversion Concurrency Control (MVCC)

User 1 User 2
• Concurrency control method to
provide concurrent access to the
database
transaction T
User 1
write
V Lock!
• LOCKING
 All readers wait until the writer is done
read V (Delayed)
 This can be very slow!

• MVCC User 1 User 2

 An write adds a new version
 Read is always possible
 Any changes made by a writer will not
be seen by other users of the database
transaction T
User 1
write
V1 MVCC
until they have been committed V0 read V0-Old Version
 Conflicts (e.g. V1a ,V1b) can occur and
have to be handled V1 read V1

16
 NoSQL Data Management

Query Mechanisms for NoSQL

• REST based retrieval of a value based on its key/ID with
GET resource

• Document stores allow more complex queries

 E.g. CouchDB allows to define views with MapReduce

• MapReduce
 Available in many NoSQL databases
 Can run fully distributed
 It is Functional Programming, not writing queries!
 Map phase - perform filtering and sorting
 Reduce phase - performs a summary operation
 ~ SELECT and GROUP BY of a relational database
 More details later!

• Apache Spark is an open source big data processing

framework providing more operations than MapReduce

• Example use cases for MapReduce

 Distributed Search
 Counting – URL, Words
 Building linkage graphs for web sites
 Sorting distributed data

Source: @tgrall
17
 NoSQL Data Management

Overview

• Introduction to NoSQL

• Basic Concepts for NoSQL

• Overview of NoSQL Systems

 Key-Value Stores
 Document Stores
 Wide-column stores
 Graph Stores
 Hadoop Map/Reduce and more …

18
NoSQL Data Management

Key Value Stores

• Developer: Basho Technologies

(http://basho.com/)
• Current version: 2.1.1
• Available since: 2009
• Licence: Apache licence 2.0
• Supported operating systems:
Linux, BSD, Mac OS, Solaris
• Client libraries for:
 Java, Ruby, Python, C#, Erlang
(the official ones)
Project
 C, Node.js, PHP (the unofficial
ones)
Voldemort
 even more form the Riak
Memcached community

19
 NoSQL Data Management

Typical Use Cases

sessionid=A08154711 id
• Session data userlogin=“xyz”
date_of_expiry=2015/12/31

• User profiles

key value

timestamp x y z temperature

01.01.2014 350 120 78 -10°

01.01.2014 350 120 95 -9

• Sensor data (IOT) 01.01.2014 350 100 78 -10°

02.01.2014 350 120 78 -5°

02.01.2014 350 120 95 -8°

20
NoSQL Data Management

Key Functionality

bucket types

buckets create bucket type

activate bucket type

key value
store <k,v>
update bucket type
key value
get <k> get status of bucket type
key value
get bucket properties
delete <k>
key value set bucket properties

21
 NoSQL Data Management

Instances and Vnodes

• Riak runs on potentially large

clusters
• Each host in the cluster runs a
single instance of Riak (Riak
node)
• Each Riak node manages a set of
virtual node (vnodes)

• Mapping of <bucket,key> pairs

 compute 160-bit hash
 map result to a ring position
 ring is divided into partitions
 each vnode is responsible for one
partition

docs.basho.com 22
 NoSQL Data Management

Configure Replication

• Some bucket parameters

 N: replication factor
 R: number of servers that must
respond to a read request
 W: number of servers that must
respond to a write request
 DW: number of servers that
must report that a write has
successfully been written to disk
 …
 Parameters allow to trade
consistency vs. availability vs.
performance

docs.basho.com 23
 NoSQL Data Management

Transactions and Consistency

• No multi-operation transactions are supported

• Eventual consistency is default (and was the only option before Riak 2.0)
 Vector clocks and Dotted Version Vectors (DVV) used to resolve object
conflicts
• Strong consistency as an alternative option
 A quorum of nodes is needed for any successful operation

24
 NoSQL Data Management

Riak Search

• For Raik KV, a value is just a value possibly associated with a type
• Riak Search 2.0
 Based on Solr, the search platform built on Apache Lucene
 Define extractors, i.e., modules responsible for pulling out a list of fields and
values from a Riak object
 Define Solr schema to instruct Riak/Solr how to index a value
 Queries:
exact match, globs, inclusive/exclusive range queries, AND/OR/NOT, prefix
matching, proximity searches, term boosting, sorting, …

25
NoSQL Data Management

Document Stores

• Developer: MongoDB, Inc.

(https://www.mongodb.com/)
• Available since: 2009
• Licence: GNU AGPL v3.0
• Supported operating systems: all
major platforms
• Drivers for:
 C, C++, C#, Java, Node.js,
Perl, PHP, Python, Motor,
Ruby, Scala, …

26
 NoSQL Data Management

What are Documents?

{
"firstName": "John",
• Aggregated data "lastName": "Smith",
• No fixed schema "age": 25,
"address":
• Internal structure matters {
• Format: JSON, BSON, … "streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
{ "postalCode": "10021"
"firstName": “Paul", },
"lastName": “Adam", "phoneNumbers":
"age": 45, [
"address": {
{ "type": "home",
"streetAddress": "22 2nd Street", "number": "212 555-1234"
"city": "New York", },
"state": "NY", {
"postalCode": "10021" "type": "fax",
} "number": "646 555-4567"
} }
]
}
27
 NoSQL Data Management

Typical Use Cases

• Simple content management

 e.g. blogging platforms
• Logging events
 cope with event type heterogeneity
 data associated with events changes over time
• E-Commerce applications
 flexible schema for product and order data

28
 NoSQL Data Management

Data Organization

• Collections of documents that

share indexes (but not a schema) databases

• Collections are organized into collections

databases
• Documents stored in BSON

29
 NoSQL Data Management

Key Functionality

query data inside

the documents databases

collections create collection

find <field critera> drop collection

insert document

update document(s)
create index

delete document(s) drop index

30
NoSQL Data Management

Querying Documents

www.mongodb.com 31
 NoSQL Data Management

Availability

• Each Replica set is group of

MongoDB instances that hold the
same dataset
• one primary instance that takes read/write
all write operations
• multiple secondary instances
sec. sec.
• changes are replicated to the prim.
1 2
secondaries
• if the primary is unavailable, the apply opplog
replica set will elect a secondary
to be primary replica set

• Specific secondaries
 priority 0 member  delayed member
 hidden member  arbiter

32
 NoSQL Data Management

Scalability

• Replica sets for read scalability

read/write
 reading from secondaries may
provide stale data config
• Sharding for write scalability config
server
config
server
router
 at collection level server
 using indexed field that is metadata
available in all documents of the
collection
 range-based or hash-based
shard shard shard
 Each shard is a MongoDB 1 2 3
instance
 background processes to
maintain even distribution:
splitting + balancer
 Shards may also hold replica sets

33
 NoSQL Data Management

Transactions and Consistency

• Write concern, w option

 default: confirms write operations only on the primary
 num.: Guarantees that write operations have propagated successfully to
the specified number of replica set members including the primary
 majority: Confirms that write operations have propagated to the majority of
voting nodes
• Read preference
 describes how MongoDB clients route read operations to the members of a
replica set, i.e., from one of the secondaries or the primary
 eventual consistency!
• No multi-operation transactions supported. reading stale data
from the primary
is possible!

34
 NoSQL Data Management

Wide-Column Stores / Column Family Stores

• 2006: originally project of

company Powerset
• 2008: HBase becomes Hadoop
sub-project.
• 2010: HBase becomes Apache
top-level project.
• runs on top of HDFS (Hadoop
Distributed File System)
• providing BigTable-like
capabilities for Hadoop
• APIs: Java, REST, Thrift, C/C++

35
 NoSQL Data Management

Logical Data Model

• Table rows contain:

 row key
 versions, typically a timestamp
 multiple column families per key
- define column families at design time
- add columns to a column family at runtime

sparse table

• Metadata
 there is no catalog that provides the set of all columns for a certain table
 left to the user/application

36
 NoSQL Data Management

Physical Data Model

• Store each column familiy separately

• Sorted by timestamp (descending)
• Empty cells from the logical view are not stored

• Key/Value class
keylength valuelength key value

rowlength row columnfamily column columnqualifier timestamp keytype

key length family

e.g. com.cnn.
www
2 anchor cnnsi.com t9 put

37
NoSQL Data Management

Key Functionality

namespaces

get <k, t> regions

table

key family c, …, c split

put <k, …>
key family c, …, c merge
scan create
key family c, …, c
alter
delete <k> key family c, …, c drop

38
 NoSQL Data Management

MasterServer and RegionServer

HMaster HRegionServer
• monitors RegionServers • manages regions
• operations related to metadata • operations related to data (put,
(tables, column families, regions) get, …)
• operations related to regions
(split, merge, …)
META: list of regions for each table

Backup HMaster
…

• Failover • Failover
 HBase clients talk directly to the  Region immediately becomes
RegionServers, hence they may unavailable when the RegionServer is
continue without MasterServer (at least down
for some time)  The Master will detect that the
 catalog table META exists as HBase RegionServer has failed
tables, i.e., not resident in the  region assignments will be considered
MasterServer invalid
 assign region to a new RegionServer

39
 NoSQL Data Management

Storage Structure

• Table T with column families a and b

HRegionServer HRegionServer
main memory

Store a Store b Store a Store b Store a Store b

MemStore MemStore MemStore MemStore MemStore MemStore

StoreFile StoreFile StoreFile StoreFile StoreFile StoreFile

file system

StoreFile StoreFile StoreFile StoreFile StoreFile

StoreFile StoreFile

Log Log

regions Block Block

<k,v> <k,v> …

Block Block

40
 NoSQL Data Management

Write Data
write table_T.family_a.field_f

HRegionServer HRegionServer
main memory

Store a Store b Store a Store b Store a Store b

MemStore MemStore MemStore MemStore MemStore MemStore

StoreFile StoreFile StoreFile StoreFile StoreFile StoreFile

file system

StoreFile StoreFile StoreFile StoreFile StoreFile

StoreFile StoreFile

Log Log

1. Write change to log (WAL)

2. Write change to MemStore
3. Regularily flush MemStore to disk (into StoreFiles) and empty MemStore
41
 NoSQL Data Management

Read Data
read table_T.family_a.field_f

HRegionServer HRegionServer
main memory

Store a Store b Store a Store b Store a Store b

MemStore MemStore MemStore MemStore MemStore MemStore

StoreFile StoreFile StoreFile StoreFile StoreFile StoreFile

file system

StoreFile StoreFile StoreFile StoreFile StoreFile

StoreFile StoreFile

Log Log

1. Read from Block Cache

2. Read from MemStore
3. Read from all relevant StoreFiles
4. Merge results

42
 NoSQL Data Management

StoreFile Reorganisation

• minor compaction Store a Store a

 merge various StoreFiles, without MemStore MemStore

considering tombstones etc.
• major compaction StoreFile
 reorg of store files, e.g. by StoreFile
removing deleted rows StoreFile
 significantly reduces file size
StoreFile
 at a configurable time interval
or manually
• Merge Regions
 consolidate several regions of one table into a single region
 offline reorg initiated manually!
• Split Regions
 distribute data from one region to several regions
 configurable by parameter max.filesize or manually

43
 NoSQL Data Management

Transactions and Consistency

• No explicit transaction boundaries

• Atomicity
 atomic row-level operations (either "success" or "failure")
 operations spanning several rows (batch put) are not atomic
• Consistency
 Default: Strong consistency by routing all through a single region server
 Optional: Region replication for high availability
- Writes only through the primary
- Reads may also be processed by the secondaries

44
NoSQL Data Management

CQL in Cassandra
CREATE KEYSPACE demodb WITH REPLICATION =
{'class' : 'SimpleStrategy', 'replication_factor': 3};

SELECT * CREATE TABLE users (

FROM emp user_name varchar,
WHERE empID IN (130,104) password varchar,
ORDER BY deptID DESC; gender varchar,
session_token varchar,
state varchar,
birth_year bigint,
SELECT WRITETIME (name) PRIMARY KEY (user_name));
FROM excelsior.clicks
WHERE url = 'http://apache.org';

INSERT INTO excelsior.clicks (userid, url, date, name)

VALUES ( 3715e600-2eb0-11e2-81c1-0800200c9a66,
'http://apache.org', '2013-10-09', 'Mary')
USING TTL 86400;

cassandra.apache.org 45
NoSQL Data Management

Graph Databases

• Developer: Neo Technology

(http://www.neotechnology.com)
• Available since: 2007
• Licence: GPLv3 and AGPLv3,
commercial
• Supported operating systems: all
major platforms
• Drivers for:
 Java, .NET, JavaScript, Python,
Ruby, PHP
 and R, Go, Clojure, Perl, Haskell
Flock DB

46
 NoSQL Data Management

Typical Use Cases

• Highly connected data,

e.g., social networks,
employees and their knowledge

smartblogs.com
• Location-based services, 5 7

e.g., planning delivery 1

50

15
9

20 12 graph with
distances

• Recommendation systems,
e.g., bought products, often-visited attractions

people who visited … also visited …

47
 NoSQL Data Management

Graph Data Model

node

relationship

properties

• No need to define a schema

neo4j.com 48
 NoSQL Data Management

Basic Functionality

graph

match node create node/relationship

patterns
delete node/relationship
graph traversal
set property

remove property
query index
create index

49
 NoSQL Data Management

Cypher Example

• Many query languages: Cypher, Gremlin, G, GraphLog, GRAM, GraphDB,

…
• No standard

CREATE (me:PERSON {name:”Holger”})

CREATE (mat:PERSON {name:”Matthias”})
CREATE (fra:PERSON {name:”Frank”})
CREATE (me) -[knows:KNOWS]-> (mat)
CREATE (me) -[knows:KNOWS]-> (fra)
CREATE (mat) -[knows:KNOWS]-> (me)

MATCH (n {name:”Holger”})-[:KNOWS]->(m)

50
 NoSQL Data Management

Scalability

• Strategies for read scaling

a) large enough memory graph
for the working set of nodes data

node memory

b) adding read-only slaves S3 S4

graph graph graph graph
data data data data
S1 S2
slave memory

c) application-level sharding

automatic graph graph

sharding? appl data data
query
north/south? north south

51
 NoSQL Data Management

High Availability

• HA availability feature in neo4j

 cluster of 1 master and n slave nodes
 continues to operate from any number of nodes down to a single machine
 nodes may leave and re-join the cluster
 in case of master failure, a new master will be elected
 read operations are possible on any node
 write operations are possible on any node and propagated to the others

write on master
 write  commit

M S1 S2 S3

 propagate
52
 NoSQL Data Management

High Availability

• HA availability feature in neo4j

 cluster of 1 master and n slave nodes
 continues to operate from any number of nodes down to a single machine
 nodes may leave and re-join the cluster
 in case of master failure, a new master will be elected
 read operations are possible on any node
 write operations are possible on any node and propagated to the others

write on slave
 write  commit
 propagate pull asynchronously

M S1 S2 S3 M S1 S2 S3

 propagate
 commit
53
 NoSQL Data Management

Transactions and Consistency

• Set transaction boundaries explicitly

• Transactions are possible on any node in the cluster
• Transactions are atomic and durable
• Writes are eventually consistent
 optimistically pushed to slaves
 slaves can also be configured to pull updates asynchronously

54
 NoSQL Data Management

Hadoop Ecosystem

Hive Pig …

MapReduce Framework
HBase
(Coordination)
Zookeeper

YARN
(Cluster Resource Management)

HDFS
(Hadoop Distributed File System)

• Apache project http://hadoop.apache.org/

55
 NoSQL Data Management

Principles of Map Reduce

• User provides data in files

• Data model: key/value pairs (k, v)
• Based on higher-order functions MAP and REDUCE
• Tasks of the programmer
 User-defined functions m and r serve as input to MAP and REDUCE
 m and r define what the job actually does
• MAP m: , ↦ , ∗
• REDUCE r: , ∗ ↦( ,
• Example: Aggregate salary per department:

(employee, <name, department, salary, …>) (department, <salary, salary, …>)

MAP RED

(department, salary) (department, salary)

56
 NoSQL Data Management

Execution of Map/Reduce Jobs

program job tracker

client start &

control

task tracker m1 task tracker r1

file k/v 1
k/v 2

task tracker m2 task tracker r2

split 1
split 2 map()
shuffle() reduce()
split 3 combine() k/v 1
split 4 sort() output()
k/v 2
split 5 partition()

task tracker m3
file
k/v 1
k/v 2

… phases defined by user 57

 NoSQL Data Management

Fault Tolerance

• map node fails

 job tracker receives no report for a certain time -> mark node as failed
 restart map job on a different node
 new job reads another copy of the necessary input split
• reduce node fails
 job tracker receives no report for a certain time -> mark node as failed
 restart reduce job on a different node
 read necessary intermediate input data from map nodes
• To make this work, all relevant data has to be stored in a distributed file
system, in particular
 the input splits
 intermediate data produced by map jobs

Hadoop Files System (HDFS)

58
NoSQL Data Management

HDFS Architecture

HDFS Users Guide at http://hadoop.apache.org 59

 NoSQL Data Management

Is that all?

• Other systems build on or extend this

basic functionality
• Build an SQL layer on to of Hadoop MapReduce
 Hive
 Pig
• Others focus on datastream and in-memory processing
 Spark
 Flink

60
 NoSQL Data Management

What we also Skipped Today

• Further classes of NoSQL systems

 Triple stores, …
• NewSQL
• Cloud offerings for the various types of NoSQL data stores
 e.g., Riak CS (Cloud Storage)
• More cloud platforms
 IBM Bluemix
 Google app engine

61
 NoSQL Data Management

Conclusion
• Relational Databases provide To make a proper decision,
 Data spread over many tables carefully examine your application
 Schema needs to be defined • the data model that is most
 Structured query language (SQL) appropriate
 Transactions • the query complexity
• the consistency needs
 Strong Consistency
• the transactional requirements
 General purpose applicability
• NoSQL
 Aggregated data in one object (identified by a key)
 No predefined schema
 No declarative query language
 Limited transactional capability
 Eventual consistency rather ACID property
 Focus on scalability and availability
 Often selected and customized for a concrete application scenario

62