What is Persistence?
All Applications “Manage Data”.
The term Manage Data is interesting as it reflects the two types of Software Entities: State and Behavior.
STATE represents the DATA within the Application
… BEHAVIOR represents the ability to MANAGE the data
An ability to manage the data created, read, updated and deleted is the preeminent responsibility of the application.
Persistence is the act of retaining Data
in a Usable State allowing the Application
to Consume the Persisted Data
at some point in the future
What are the Types of Data?
How you persist data depends on how the information will be consumed: The Type of Data.
Sometimes data needs to be Consistent. This is called: Data Consistency.
There are three types of Data Consistency:
Transaction Consistency – A logical unit of work that succeeds or fails as an atomic operation. Transaction Consistency is also referred to as Data Atomicity
Application Consistency – Application Consistency is similar to Transaction Consistency, but instead of Data Consistency within the scope of a single transaction the data must be consistent within the confines of different transaction streams from one or more applications
Point-in-Time (PiT) Consistency – All related data components are as they were at any single instant in time
Sometimes data needs to be optimized for Data Performance. This data type is called: Slow Changing Data.
Slow Changing Data does not have to be Point in Time Consistent.
Examples of slow changing data are look-up values such as ZIP Codes and a list of the States in the United States.
Changes in data optimized for performance are generally not issues during the run-time of an application. The staleness of the data can be managed for performance through a “Time to Live” refresh strategy.
Optimizing the Persistence Model based on
the kind of State that is being persisted
guarantees that you have a balance
between Consistency and Performance
What are the Types of Persistence?
The Persistence Semantic can represent a number of Data Persistence strategies.
The Semantic Design Series will concentrate these six persistence models:
SQL Databases – Relational databases that uses declarative queries
NoSQL Databases – Non-relationship databases that are free of a pre-defined schema and uses imperative queries
In-Memory Databases – Data repositories that are loaded completely into RAM for peak performance
Cloud-based Stores – Data repositories that are stored and managed in the Cloud
File-bases Stores – Information that are persisted within files on disk drives
Cache Persistence – Data repositories that are managed as reusable objects stored and managed in RAM
The Semantic Design Series persistence layer is a “Horizontal Access Layer” and not the traditional “Vertical Stack Layer”.
This architecture makes available the type of persistence that best fits the model at the stack layer.
…This Minimizes Repetitive Traversal of the Entire Stack
…… Just to get a Single Piece of Information
Optimization can be achieved at the layer level based on the persistence type required.
The thought of the Data Repository Layer as being the Lowest Abstraction Layer within an Architectural Stack to being a Vertical Access Layer is a major paradigm shift.
This creates the ability to visualize all forms of Data Persistence as a Data Repository and not just databases.
This mental shift allows an Application State Management schema to be managed in the same fashion as a Database or a Cloud Service.
Application Cache and In-Memory Databases are now available at all levels of the Architectural Stack as a “First Class” citizen.
Layer-centric Optimization can be employed
… Based on the Best Persistence Type Required
…… Defined by the Responsibilities of the Model Layer
The Vertical Stack Layer Paradigm
Creates Collections of Persistence Types
that can support each Layer in the Model
Independently of the other Model Layers
Wisdom Pearl # 134 – Knowledge or Wisdom
Data Creates Information
… Information creates Knowledge
But Wisdom only comes from Knowledge
… Used for a Successful Outcome
Don’t Confuse Knowledge for Wisdom!
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services