DB IN SOFTware architecture
Software architect's role in providing a DB solution in building a software
application by taking real life scenarios that software architects face.
By Thejaka Usgoda Arachchi, MSc
Software Architect
To Get a better direction
Be open minded.
Clear your doubts here than try them in production.
This is the place to make mistakes.
Share your thoughts for others to learn.
Why do we bother so much on DB?
1 Many Different Uses
2 Higher Availability
3 Higher Reliability
4 Better Efficiency
05
database
is an
Overhead?
Handle High Volume Databases with Care.
03
Are there systems
without
stored data
46
DATA
organisation
46
can data
organisation
go mad? We can go on normalising data. But?
What if accessing millions of data?
How difficult to change data?
Easy to maintain ??
Avoids Data duplication Difficult to read
Keeps Data Integrity Cluttered
Less efficient ??
34
transaction isolation
Per transaction
Standard default: Serializable
Some systems (ex. Oracle and Mysql) default: Repeatable Read
Stale
acid transactions Active
fully consistent?
In general, ACID transactions do not solve all concurrency issues.
Concurrent transactions could contain stale data.
33
pessimistic vs. optimistic concurrency
Locking is a major concern in concurrency and performance.
pessimistic locking optimistic locking
• High locking overheads. • Assume conflicts don’t occur
• Low concurrency. • Reduced locking.
• For short transactions. • High concurrency.
• For long transactions
27
do transactions trouble your system?
Transactions adds performance overhead, which could be noticed when there
is a heavy load.
27
Consistency vs.
availability
Tradeoff between these two is a business decision
41
Tool first or purpose first?
Rather than selecting the tool first and then fitting the data to the tool, developers will determine how the
various data elements will be manipulated and then will choose the appropriate tools for those specific purposes.
27
domain driven database design
Allows everyone to speak in customer language.
multi model databases
Aggregates would not just the best
fit. So, we get multiple models in
place.
30
improve performance further
unit of work
This will enable batch processing.
relaxing durability
When delay the writes to disk, we can reduce
I/O, which will increase the performance.
stored procedures
Stored procedures run very close to the
database making operations faster.
views / materialised views
Used mostly for reporting purposes. Security.
Encapsulation (DB schema can be changed).
connection pool
Drastically reduces connection time.
16
Further improve
performance By
Caching
Identity map is one
of the essential
approaches.
For example,
Hibernate L1 cache
is an
implementation of
this and it is always
activated.
46
clustered
cashing
Entity level caching data caching
• Query caching
• When record size is big
• To minimise execution time
• Caching groups
• Mostly placed in business layer
• Use immutable objects
cache invalidation
42
Caching,
but?
when overhead
46
clustering using database
Cluster management involve considerable
amount of data that needs to be transferred in
between the nodes involve.
quartz scheduling job process clustering
store
Job store needs to Daemon data stored
be created when in table(s), which
configuring quartz referred by each
scheduler. The job process.
store could be
accessed by each
node.
21
Is it
worth being
schema less?
Implicit schema needs to be managed, which is rather difficult.
03
distributed
transactions two
phase commit
• JTA implements X/
Open XA
specification.
• XA - A system
interface defines
how distributed
transactions done.
• Transaction
context is retained
in the current
thread context.
46
lazy
loading
Lazy load leaves a
marker in the object
structure so that if
the data is needed it
can be loaded only
when it is used.
52
