RSS

Author Archives: stack247

Event Sourcing Design Pattern

What is Event Sourcing?

Is a architecture design pattern that uses append-only store to record full series of events that happen on specific data. The store also acts as publisher to all subscribers whenever an event is recorded.

Characteristics

  • Append-only store. Some implementation may be different.
  • Event store as system of record.
  • Materialized object is constructed from events.
  • Provide audit trails.
  • Fast performance.

Considerations

  • Undo is adding another event. Perform undo can only be done by adding compensating event since update is not allowed in Event Store
  • Migration to new format. All existing events must be updated.
  • Consistency. Multi-threaded applications may store events in the same event store. The consistency and order must be maintained.
  • Lack of transactions. Event store by its nature is not transactional and it’s eventual consistency. It’s possible to have event to reduce the inventory count while customer is placing order for the same item.
  • Performance. Replaying large amount of events can slow down the result for materialized view.

Reference
Microsoft Docs

Advertisements
 
Leave a comment

Posted by on May 25, 2018 in General

 

Tags: , ,

SQL Server Concurrency Effects

Lost Update

Happens when one transaction update overwrites another, causing the update to be lost.

Dirty Reads

Reading uncommitted records.

Phantom Reads

Reading while another transaction is adding new record, result in different number of rows being returned.

Repeatable Reads

When the same query to read is executed, it will return the same result.

Reference

MSDN

 
Leave a comment

Posted by on May 22, 2018 in General

 

Tags: , , , ,

Columnstore Index

  • New in SQL Server 2012.
  • Stored by columns, a column-based index, instead of row-based like in traditional index. For example, if row-based index is consisted of Firstname and Lastname columns, the column-based index would have 2 different indexes: Firstname in its own index and Lastname in its own index.
  • The index is compressed, allowing high performance.
  • The compressed data is stored in-memory, reducing needs to read off the disks.
  • Compression ratio is generally high because the same data type in a column.
  • Generally a better choice for wide table with many columns, as commonly found in data warehouse tables.
  • Clustered and non-clustered index.
  • Can be combined with row-based index.

Reference
Microsoft Docs

 
Leave a comment

Posted by on May 16, 2018 in General

 

Tags: , , , , ,

Optimistic Concurrency x Eventual Consistency

Optimistic Concurrency

Less strict locking to support more simultaneous access. In optimistic concurrency, multi users are able to perform actions on the same resources without locking each other, for example, one user can write without locking another user that’s reading the same resource. Some actions will still lock the resource exclusively, for example, a schema changes.

Pessimistic Concurrency

Is the opposite, a stricter locking is used. When a user is performing an action that requires lock, other users won’t be able to do anything that would conflict with the lock, until the lock is release from the owner (first user).

Eventual Consistency

Eventual consistency guarantees more of availability than consistent data. This is achieved by prioritize availability (not locking the resource) rather than replicating the data.

Strong Consistency

The opposite of eventual consistency where it’s prioritizing consistent data across the system rather than availability.

BASE

Eventual consistency is classified as BASE (Basically Available, Soft state, Eventual consistency) semantics, as oppose to ACID principle.

Conclusion

Eventual / strong consistency is similar to optimistic / pessimistic concurrency. The difference is the terms eventual / strong consistency is often used in a distributed system where optimistic / pessimistic concurrency is used more in lower level, single entity such as database.

Azure Cosmos DB consistency levels, strong to weakest consistency:
– Strong consistency
– Bounded staleness
– Session
– Consistent prefix
– Eventual consistency

 
Leave a comment

Posted by on May 12, 2018 in General

 

Tags: , , , , ,

SQL Server Isolation Level

Definition

Isolation is the “I” in ACID principal which rules the transactional state and its concurrency. The higher the isolation level, the lower the concurrency effects. And vice versa.

ISO Standard Isolation

The ISO standard defines 4 different isolation levels, from lowest to highest:
– Read uncommitted
– Read committed
– Repeatable read
– Serializable, where transactions are completely isolated from one another.

SQL Server Database Isolation

SQL Server Database supports all levels of isolation defined by ISO standard. In addition, it adds another isolation levels: the Snapshot isolation level (ALLOW_SNAPSHOT_ISOLATION).

SQL Server Database also add another implementation of Read Committed isolation level: Read Committed Snapshot Isolation or RCSI (READ_COMMITTED_SNAPSHOT). The original Read Committed implementation is referred to RC.

In Azure SQL Database, the default setting for Read Committed is RCSI (both ALLOW_SNAPSHOT_ISOLATION and READ_COMMITTED_SNAPSHOT are set to ON).

In on-premise SQL Server, the default is RC (both ALLOW_SNAPSHOT_ISOLATION and READ_COMMITTED_SNAPSHOT are set to OFF). But can be set to use RCSI by setting them to ON.

These two isolation levels, Snapshot isolation and RCSI, use row versioning that is maintained in tempdb.

Code

To check database settings for Snapshot isolation:

SELECT name, snapshot_isolation_state, is_read_committed_snapshot_on FROM sys.databases

To check current connection’s transaction isolation level:

SELECT CASE transaction_isolation_level
WHEN 0 THEN 'Unspecified'
WHEN 1 THEN 'ReadUncommitted'
WHEN 2 THEN 'ReadCommitted'
WHEN 3 THEN 'Repeatable'
WHEN 4 THEN 'Serializable'
WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL
FROM sys.dm_exec_sessions

To set transaction isolation level for current connection. Transaction isolation level is per session / connection.

SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }

Isolation Level and Concurrency Effects Matrix

Isolation Level Dirty Read Lost Update Non Repeatable Read Phantom
Read uncommitted Yes Yes Yes Yes
Read committed No Yes Yes Yes
Repeatable read No No No Yes
Snapshot No No No No
Serializable No No No No

Performance

In a load test, performance is significantly higher in RCSI, but it requires a lot higher throughput in tempdb (some 50x larger I/O). So planning on tempdb scaling is very important.

Reference
Microsoft Docs
Technet Blog
MSDN Blog

 
Leave a comment

Posted by on May 7, 2018 in General

 

Tags: , , , , , , ,

Create All Purpose Self-Signed Certificate with Makecert

All Purpose Certificate

#Root authority certificate
C:\>makecert -n "CN=TempCA" -pe -r -sv TempCA.pvk TempCA.cer
#Certificate
C:\>makecert -sk SignedByCA -iv TempCA.pvk -n "CN=SignedByCA" -ic TempCA.cer SignedByCA.cer -sr currentuser -ss My

The certificate will be installed in Current User, Personal store.

From there you can export the private key. Alternatively, use pvk2pfx to export.

For local SSL specific certificate: How to Create Valid and Trusted SSL Certificate (Wildcard) for Development

Reference
Microsoft Docs

 
Leave a comment

Posted by on May 6, 2018 in General

 

Tags: ,

Database ACID Principal

ACID – Atomicity, Consistency, Isolation, Durability

Atomicity

Requires that each transaction be “all or nothing”.

Consistency

Any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers.

Isolation

Ensures that the concurrent execution of transactions results in a system state that would be obtained if transactions were executed sequentially.
A lower isolation level increases the ability to access the same data at the same time, but increases the number of concurrency effects (such as dirty reads or lost updates) users might encounter.

Durability

Once a transaction has been committed, it will remain so, even in the event of power loss, crashes, or errors. Store in non-volatile memory.

 

References

Wikipedia

 
Leave a comment

Posted by on May 2, 2018 in General

 

Tags: , ,

 
%d bloggers like this: