Standard Normal Z Distribution Probabilities, Schemes and Mind Maps of Statistics

Download Standard Normal Z Distribution Probabilities and more Schemes and Mind Maps Statistics in PDF only on Docsity!

Database System Concepts, 7 th^ Ed. ©Silberschatz, Korth and Sudarshan See www.db-book.com for conditions on re-use

Chapter 25: Advanced Application

Development

Hardware Tuning: Choice of RAID Level

 To use RAID 1 or RAID 5?

• Depends on ratio of reads and writes  RAID 5 requires 2 block reads and 2 block writes to write out one data block

 If an application requires r reads and w writes per second

• RAID 1 requires r + 2w I/O operations per second
• RAID 5 requires: r + 4w I/O operations per second

 For reasonably large r and w, this requires lots of disks to handle

workload

• RAID 5 may require more disks than RAID 1 to handle load!
• Apparent saving of number of disks by RAID 5 (by using parity, as opposed to the mirroring done by RAID 1) may be illusory!

 Thumb rule: RAID 5 is fine when writes are rare and data is very large,

but RAID 1 is preferable otherwise

• If you need more disks to handle I/O load, just mirror them since disk capacities these days are enormous!

Tuning the Database Design (Cont.)

 How to choose set of materialized views

• Helping one transaction type by introducing a materialized view may hurt others
• Choice of materialized views depends on costs  Users often have no idea of actual cost of operations
• Overall, manual selection of materialized views is tedious

 Some database systems provide tools to help DBA choose views to materialize

• “Materialized view selection wizards”

Tuning of Transactions (Cont.)

 Reducing lock contention

 Long transactions (typically read-only) that examine large parts of

a relation result in lock contention with update transactions

• E.g., large query to compute bank statistics and regular bank transactions

 To reduce contention

• Use multi-version concurrency control  E.g., Oracle “snapshots” which support multi-version 2PL
• Use degree-two consistency (cursor-stability) for long transactions  Drawback: result may be approximate

Performance Simulation

 Performance simulation using queuing model useful to predict

bottlenecks as well as the effects of tuning changes, even without

access to real system

 Queuing model as we saw earlier

• Models activities that go on in parallel

 Simulation model is quite detailed, but usually omits some low

level details

• Model service time , but disregard details of service
• E.g., approximate disk read time by using an average disk read time

 Experiments can be run on model, and provide an estimate of

measures such as average throughput/response time

 Parameters can be tuned in model and then replicated in real

system

• E.g., number of disks, memory, algorithms, etc.

Database Application Classes

 Online transaction processing (OLTP)

• requires high concurrency and clever techniques to speed up commit processing, to support a high rate of update transactions.

 Decision support applications

• including online analytical processing, or OLAP applications
• require good query evaluation algorithms and query optimization.

 Architecture of some database systems tuned to one of the two

classes

• E.g., Teradata is tuned to decision support

 Others try to balance the two requirements

• E.g., Oracle, with snapshot support for long read-only transaction

TPC Performance Measures

 Two types of tests for TPC-H and TPC-R

• Power test : runs queries and updates sequentially, then takes mean to find queries per hour
• Throughput test : runs queries and updates concurrently  multiple streams running in parallel each generates queries, with one parallel update stream
• Composite query per hour metric : square root of product of power and throughput metrics
• Composite price/performance metric

Other Benchmarks

 OODB transactions require a different set of benchmarks.

• OO7 benchmark has several different operations, and provides a separate benchmark number for each kind of operation
• Reason: hard to define what is a typical OODB application

 Benchmarks for XML being discussed

SQL Standards History (Cont.)

 More parts undergoing standardization process

• Part 7: SQL/Temporal: temporal data
• Part 9: SQL/MED (Management of External Data)  Interfacing of database to external data sources - Allows other databases, even files, can be viewed as part of the database
• Part 10 SQL/OLB (Object Language Bindings): embedding SQL in Java
• Missing part numbers 6 and 8 cover features that are not near standardization yet

XML-Based Standards

 Several XML based Standards for E-commerce

• E.g., RosettaNet (supply chain), BizTalk
• Define catalogs, service descriptions, invoices, purchase orders, etc.
• XML wrappers are used to export information from relational databases to XML

 Simple Object Access Protocol (SOAP): XML based remote

procedure call standard

• Uses XML to encode data, HTTP as transport protocol
• Standards based on SOAP for specific applications  E.g., OLAP and Data Mining standards from Microsoft

E-Catalogs

 Product catalogs must provide searching and browsing facilities

• Organize products into intuitive hierarchy
• Keyword search
• Help customer with comparison of products

 Customization of catalog

• Negotiated pricing for specific organizations
• Special discounts for customers based on past history  E.g., loyalty discount
• Legal restrictions on sales  Certain items not exposed to under-age customers

 Customization requires extensive customer-specific information

Marketplaces

 Marketplaces help in negotiating the price of a product when there

are multiple sellers and buyers

 Several types of marketplaces

• Reverse auction
• Auction
• Exchange

 Real world marketplaces can be quite complicated due to product

differentiation

 Database issues:

• Authenticate bidders
• Record buy/sell bids securely
• Communicate bids quickly to participants  Delays can lead to financial loss to some participants
• Need to handle very large volumes of trade at times  E.g., at the end of an auction

Order Settlement

 Order settlement: payment for goods and delivery

 Insecure means for electronic payment: send credit card number

• Buyers may present some one else’s credit card numbers
• Seller has to be trusted to bill only for agreed-on item
• Seller has to be trusted not to pass on the credit card number to unauthorized people

 Need secure payment systems

• Avoid above-mentioned problems
• Provide greater degree of privacy  E.g., not reveal buyers identity to seller
• Ensure that anyone monitoring the electronic transmissions cannot access critical information

Secure Payment Systems

 All information must be encrypted to prevent eavesdropping

• Public/private key encryption widely used

 Must prevent person-in-the-middle attacks

• E.g., someone impersonates seller or bank/credit card company and fools buyer into revealing information  Encrypting messages alone doesn’t solve this problem  More on this in next slide

 Three-way communication between seller, buyer and credit-card

company to make payment

• Credit card company credits amount to seller
• Credit card company consolidates all payments from a buyer and collects them together  E.g., via buyer’s bank through physical/electronic check payment