SE 352/452 Object Oriented Enterprise Computing
▪ Administrative
▪ Teamshouldbefinalized ▪ Update on syllabus
▪ Presentation – Team 6 – JC ▪ Keys from last meeting
▪ RDBMS(akaSQL)
▪ DemoofswitchingRDBMS
▪ Presentation(2,4,7,8) ▪ NoSQL Concepts
▪ Presentation(1,3,5,9) ▪ NoSQL Implementation
▪ Before next class
▪ Template code generator – Lombok ▪SQL
▪ Java to SQL using JPA ▪ Spring configuration
Origination
Destination
Annotation at class level to indicate Table name and Class name are not the same
Annotation at property level to indicate Column name and property are not the same
Persistence Primary Key
Course Student
Course_students
Origination
Destination
▪ Application is running
▪ Database – in memory or in process
▪ Data only exists while application is running
App localhost
12 Factor App Concept (https://12factor.net/dev-prod-parity)
Ruby/Rails
ActiveRecord
MySQL, PostgreSQL, SQLite
H2, PostgreSQL
DB and app in same process
DB and app in separate process
DB and app in separate machine
App localhost
localhost Postgres
▪ Website: https://www.postgresql.org/ ▪ PostgreSQL: Downloads
▪ Open source database from UC Berkeley been around for over 30 years
▪ Website: https://www.docker.com/
▪ Download: https://www.docker.com/get-started
▪ Environment to keep environment configuration consistent
▪ Download and install
▪ From Database subdirectory of the SE452 Github run ▪ docker-compose up –d
▪ VS Code – PostgreSQL
▪ Build: Build.gradle
▪ Runtime configuration to include database
▪ Runtime: Application.properties ▪ Spring.datasource.url
▪ JPA – https://docs.oracle.com/javaee/7/tutorial/partpersist.htm ▪ Chapter 37, 38, 43, and 44
▪SpringBootwithJPA (https://spring.io/guides/gs/accessing-data-jpa/)
▪ Characteristics
▪ Formal table or database structure
▪ Scales vertically (or up) ▪ Standards based
▪ Joins to multiple tables
▪ Difficult to change
▪ Joins are painful and can cause slower response ▪ To ensure consistency, pessimistic locking
▪ No fixed schema or formal structure ▪ Scales horizontally (or vertically)
▪ Avoid joins
▪ Most common ▪ Key – Value
▪ Document ▪ Graph
▪ Based on Amazon’s DynamoDB
▪ Hash table where there is a unique key and a pointer to a particular item of data for
O(1) seek time
▪ Mapping are accompanied by cache mechanisms to maximize performance
▪ Usually can’t query by anything other than the key
▪ http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DynamoD BLocal. html#DynamoDBLocal. DownloadingAndRunning
▪ Based on Google’s BigTable
▪ Stores data in columns instead of rows
▪ Store in structured format (XML, JSON) that does not need to be conformed to standardized structure
▪ Organized in “collections” or “databases”
▪ Individual documents can have unique structures but they have unique key
▪ Possible to query a document by fields
▪Example: MongoDB
▪ Based on Graph Theory where graph consists of node (or vertices) which are connected by edge (or lines)
▪ G = (V,E)
▪ Key terminology
▪ Node – Vertices ▪ Properties
▪ Relationships – Edge ▪ Direction
https://en.wikipedia.org/wiki/CAP_theorem
By Eric Brewer from UC Berkeley Presented in 2000
Proposed as theorem in 2002
Availability
• Operational accessible at all times
You can have at most 2 of these properties for any shared data system
Consistency
• Read is most recent write or an error
Partition Tolerance
• Tolerant to network failures
Consistency
Partition Tolerance
▪ System must be available and consistent and so imply that data partition can be tolerated. While in theory it is possible, in “modern distribution computing” this is NOT an option.
▪ Characteristics
▪ Consistency of data is insured during
network issues
▪ Pessimistic locking
▪ Makes minority partitions unavailable
Availability
Consistency
Availability
▪ System maintains consistent data at the cost of availability. It is important that the data is consistent rather than available.
▪ Characteristics
▪ Consistency of data is insured during
network partition issues
▪ Pessimistic locking
▪ Makes minority partitions unavailable
Partition Tolerance
Partition Tolerance
Consistency
▪ System is highly available even if it is only part of the system that may cause inconsistent data for a time period
▪ Characteristics
▪ Optimistic locking
▪ Distributed Cache
▪ Need for conflict resolution
Availability
▪ Extension of CAP theorem to handle network latency scenario ▪ Else Latency and Consistency
▪ To state that you have to choose between Latency and consistency
https://en.wikipedia.org/wiki/PACELC_theorem
▪ Strong consistency ▪ Isolation
▪ Focus on “commit” ▪ Nested transactions ▪ Pessimistic
▪ Difficult to change
▪ Weak consistency – stale data OK ▪ Best effort
▪ Approximate answer OK
▪ Optimistic
▪ Easier evolution ▪ Faster
BASE BASICALLY AVAILABLE
▪ Use replication and sharding to reduce the likelihood of data unavailability and use sharding, or partitioning the data among many different storage servers, to make any remaining failures partial.
▪ The result is a system that is always available, even if subsets of the data become unavailable for short periods of time.
▪ The availability of BASE is achieved through supporting partial failures without total system failure.
▪ Example. If users are partitioned across five database servers, BASE design encourages crafting operations in such a way that a user database failure impacts only the 20 percent of the users on that particular host.
▪ This leads to higher perceived availability of the system. Even though a single node is failing, the interface is still operational.
BASE SOFT STATE
▪ While ACID systems assume that data consistency is a hard requirement, NoSQL systems allow data to be inconsistent and relegate designing around such inconsistencies to application developers.
▪ In other words, soft state indicates that the state of the system may change over time, even without input.
BASE EVENTUALLY CONSISTENT
▪ Although applications must deal with instantaneous consistency, NoSQL systems
ensure that at some future point in time the data assumes a consistent state.
▪ In contrast to ACID systems that enforce consistency at transaction commit, NoSQL guarantees consistency only at some undefined future time.
▪ Where ACID is pessimistic and forces consistency at the end of every operation, BASE is optimistic and accepts that the database consistency will be in a state of flux
▪ As DB nodes are added while scaling up, need for synchronization arises
▪ If absolute consistency is required, nodes need to communicate when read/write
operations are performed on a node
▪ Consistency over availability -> bottleneck
▪ As a trade-off, “eventual consistency” is used
▪ Consistency is maintained later
▪ http://www.planetcassandra.org/what-is-nosql/
▪ Client/Server
▪Database: CRUD
▪ Programming:
▪ Dependencies or library management ▪ Initialization/setup
▪ Interfaces
▪ https://www.mongodb.com/
▪ Local database installation
▪ https://www.mongodb.com/download-center?jmp=nav#community ▪ Hosted database usage
▪ https://cloud.mongodb.com/ ▪ Run database
▪ mongod –port 27017 –dbpath \db\mongodb
▪ NBMongo plugin within NetBeans ▪ RoboMongo
▪ https://robomongo.org/download
Collection
Document or BSON
https://docs.mongodb.com/manual/reference/sql-comparison/
https: //docs. mongodb. com/manual/tutorial/insert-documents/
Find all Find exact
Find based on like
https: //docs. mongodb. com/manual/tutorial/query-documents/
Explanation
db.collection.remove
Delete a single document or all documents that match a specified filter
db.collection.deleteOne
db.collection.deleteMany
https://docs.mongodb.com/manual/tutorial/remove-documents/
▪ Interface
▪ Build.gradle
▪ Application.properties
▪ Client/Server
▪Database: CRUD
▪ Programming:
▪ Dependencies or library management ▪ Initialization/setup
▪ Interfaces
▪ https://neo4j.com/
▪ Local installation
▪ Install database
▪ https://neo4j.com/download/?ref=product
▪ Run database ▪ Neo4j.bat
▪ https://neo4j.com/sandbox-v2/
▪Browser: http://localhost:7474bydefault
Properties
Traversals
Constraints
Relationships
https://neo4j.com/developer/graph-db-vs-rdbms/
https: //www. tutorialspoint. com/neo4j/neo4j_cql_create_node. htm
https://www.tutorialspoint.com/neo4j/neo4j_cql_match_return.htm https://www.tutorialspoint.com/neo4j/neo4j_cql_where_clause.htm
https://www.tutorialspoint.com/neo4j/neo4j_cql_delete.htm https://www.tutorialspoint.com/neo4j/neo4j_cql_remove.htm
▪ Interface
▪ Gradle.properties
▪ Application.properties
DB and app in separate process
DB and app in separate machine
▪ Run sample code
▪ Look at Milestone 2 for Airline Reservation ▪ Update prior documentation as necessary
▪ Overview, Section 1, Appendix A, Appendix B populated ▪ Add Persistence section