The document discusses designing database architectures and applications for high performance. It provides guidance on defining clear performance requirements, designing databases and applications to meet those requirements, and techniques like indexing, partitioning, caching, and array processing to optimize performance. The goal is to map performance needs to the architecture from the start to avoid later issues and ensure requirements are actually achieved.

1. Performance by DesignGuy HarrisonDirector, R&D Melbournewww.guyharrison.net

2. Introductions

3. http://www.motivatedphotos.com/?id=17760

5. Not worrying, just wondering...How will Oracle deal respond to Hadoop?Will Oracle play in the NoSQL database world?What will happen to MySQL?What will happen to red-shirt TOAD?

6. Core messageDesign limits performanceArchitecture maps requirements to designMake sure performance requirements are specifiedMake sure architecture allows for performanceMake sure performance requirements are realized

7. Elements of Performance by Design

8. Methodology

9. High performance can mean different thingsSpeed: response time

10. Efficiency: power consumption

11. Power: throughput

12. Not usually easy to change architectures

13. Poorly defined requirements lead to this:

14. The fail whale

15. Twitter growth

16. “Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency's sake, Twitter was built with technologies and practices that are more appropriate to a content management system.”

17. Patterns of database performanceHard to distinguish patterns at low levels

19. Database Design

20. Normalize, but not too far!

21. Other logical design thoughtsArtificial keysGenerally more efficient than long composite keysNull valuesNot a good idea if you intend to search for “unknown” or “incomplete” valuesNull should not mean somethingBut beneficial as long as you don’t need to look for them. Data typesConstraints on precision can sometimes reduce row lengthsVariable length strings usually betterCarefully consider CLOBs vs long VARCHARs

22. Logical to Physical: Subtypes“Customers are people too”

23. Indexing, clustering and weird table typesLots’ of options:B*-Tree indexBitmap indexHash clusterIndex ClusterNested tableIndex Organized TableMost often useful:B*-Tree (concatenated) indexesBitmap indexesHash Clusters

25. Concatenated index effectivenessSELECT cust_idFROM sh.customers cWHERE cust_first_name = 'Connor'AND cust_last_name = 'Bishop'AND cust_year_of_birth = 1976;

26. Concatenated indexing guidleinesCreate a concatenated index for columns from a table that appear together in the WHERE clause.If columns sometimes appear on their own in a WHERE clause, place them at the start of the index.The more selective a column is, the more useful it will be at the leading end of the index (better single key lookups)But indexes compress better when the leading columns are less selective. (better scans) Index skip scans can make use of an index even if the leading columns are not specified, but it’s a poor second choice to a “normal” index range scan.

27. Bitmap indexes

28. Bitmap indexes

30. Bitmap join performance SELECT SUM (amount_sold)FROM customers JOIN sales s USING (cust_id) WHERE cust_email='flint.jeffreys@company2.com';

31. Index overhead

32. Hash ClusterCluster key determines physical location on diskSingle IO lookup by cluster keyMisconfiguration leads to overflow or sparse tables SparseOverflow

33. Hash Cluster vs B-tree index

34. Hash cluster table scan

35. Denormalization and partitioningRepeating groups – VARRAYS, nested tablesSummary tables – Materialized Views, Result cacheHorizontal partitioning – Oracle Partition Option In-line aggregations – Dimensions Derived columns – Virtual columnsVertical partitioning Replicated columns - triggers

36. Summary tablesAggregate queries on big tables often the most expensivePre-computing them makes a lot of senseBalance accuracy with overhead Aggregate QueryMV on COMMITManual SummaryResult set cacheMV stale tolerated AccuracyEfficiency

37. Vertical partitioning

38. Physical storage optionsLOB StoragePCTFREECompression Block size Partitioning

40. Application Architecture and implementation

41. The best SQL is no SQL Avoid asking for the same data twice.

42. 11g client side cache CLIENT_RESULT_CACHE_SIZE: this is the amount of memory each client program will dedicate to the cache.Use RESULT_CACHE hint or (11GR2) table propertyOptionally set the CLIENT_RESULT_CACHE_LAG

43. Parse overheadIt’s easy enough in most programming languages to create a unique SQL for every query:

44. Bind variables are preferred

45. Parse overhead reduction

46. Identifying similar SQLsSee force_matching.sql at www.guyharrison.net

47. Transaction design Optimistic vs. Pessimistic

48. Using ORA_ROWSCNSetting ROWDEPENDENCIES will reduce false fails

49. Network – stored procedures

50. Network traffic example

51. Array processing - Fetch

52. Network overhead – Array processing

53. Array Insert (Java)

54. Array Insert: (.NET)

55. Array Insert – PL/SQL

56. Array Insert Performance

58. Brockman Kwik-E-Mart, Ms Krabaple, Mrs. Hoover ,WaylanSmithers2)Who is C. Montgomery Burns' assistant?Answer3)Who is Bart's Teacher? Lisa's?Answer6)Kent ______ is the local newscaster.Answer7)____-_-____ is the local convenience store.Answer