Definition: a data architecture pattern is a consistent way of representing data in a regular structure that will be stored in memory. Although the memory you store data in is usually long-term persistent memory, such as solid state disk or hard drives, these structures can also be stored in RAM and then transferred to persistent memory by another process.

There are two types of architectural Patterns:

• High level Architecture Pattern
• Low level Architecture Pattern

Architectural patterns allow you to give precise names to recurring high level data storage patterns. When you suggest a specific data architecture pattern as a solution to a business problem, you should use a consistent process that allows you to name the pattern, describe how it applies to the current business problem, and articulate the pros and cons of the proposed solution. It’s important that all team members have the same understanding about how a particular pattern solves your problem so that when implemented, business goals and objectives are met.

Types of Architecture Patterns:

1. Key Value Store: A key-value store is a simple database that when presented with a simple string (the key) returns an arbitrary large BLOB of data (the value). Key-value stores have no query language; they provide a way to add and remove key-value pairs (a combination of key and value where the key is bound to the value until a new value is assigned) into/from a database. A key-value store is like a dictionary. A dictionary has a list of words and each word has one or more definitions

The key in a key-value store is flexible and can be represented by many formats:

• Logical path names to images or files
• Artificially generated strings created from a hash of the value
• REST web service calls
• SQL queries

1. Graph stores A graph store is a system that contains a sequence of nodes and relationships that, when combined, create a graph. A graph store has three data fields: nodes, relationships, and properties. Some types of graph stores are referred to as triple stores because of their node-relationship-node structure

Graph nodes are usually representations of real-world objects like nouns. Nodes can be people, organizations, telephone numbers, web pages, computers on a network, or even biological cells in a living organism. The relationships can be thought of as connections between these objects and are typically represented as arcs (lines that connect) between circles in diagrams.

Figure: A graph store consists of many node-relationship-node structures. Properties are used to describe both the nodes and relationships.

Graph stores are important in applications that need to analyze relationships between objects or visit all nodes in a graph in a particular manner (graph traversal). Graph stores are highly optimized to efficiently store graph nodes and links, and allow you to query these graphs. Graph databases are useful for any business problem that has complex relationships between objects such as social networking, rules-based engines, creating mashups, and graph systems that can quickly analyze complex network structures and find patterns within these structures.

1. Column Family (BigTable) Stores:

   Column family systems are important NoSQL data architecture patterns because they can scale to manage large volumes of data. They’re also known to be closely tied with many MapReduce systems. Column family stores use row and column identifiers as general purposes keys for data lookup. They’re sometimes referred to as data stores rather than databases, since they lack features you may expect to find in traditional databases. For example, they lack typed columns, secondary indexes, triggers, and query languages. Almost all column family stores have been heavily influenced by the original Google Bigtable paper. HBase, Hypertable, and Cassandra are good examples of systems that have Bigtablelike interfaces, although how they’re implemented varies.

Figure: The key structure in column family stores is similar to a spreadsheet but has two additional attributes. In addition to the column name, a column family is used to group similar column names together. The addition of a timestamp in the key also allows each cell in the table to store multiple versions of a value over time.

4. Document Stores:

Think of a document store as a tree-like structure, as shown in figure. Document trees have a single root element (or sometimes multiple root elements). Beneath the root element there is a sequence of branches, sub-branches, and values. Each branch has a related path expression that shows you how to navigate from the root of the tree to any given branch, sub-branch, or value. Each branch may have a value associated with that branch. Sometimes the existence of a branch in the tree has specific meaning, and sometimes a branch must have a given value to be interpreted correctly.

Fig: 1 Document stores use a tree structure that begins with a root node, and have subbranches that can also contain sub-branches. The actual data values are usually stored at the leaf levels of a tree.