Presentation is loading. Please wait.

Presentation is loading. Please wait.

WHAT THE MARKET-LEADING DBMS VENDORS DON’T WANT YOU TO KNOW Disruption is gathering steam.

Similar presentations


Presentation on theme: "WHAT THE MARKET-LEADING DBMS VENDORS DON’T WANT YOU TO KNOW Disruption is gathering steam."— Presentation transcript:

1 WHAT THE MARKET-LEADING DBMS VENDORS DON’T WANT YOU TO KNOW Disruption is gathering steam

2 Curt Monash Analyst since 1981  Covered DBMS since the pre-relational days  Also analytics, search, etc. Own firm since 1987 Publicly available research  Feed at www.monash.com/signup.htmlwww.monash.com/signup.html  Blogs, including www.dbms2.comwww.dbms2.com  White papers and more at www.monash.comwww.monash.com

3 Database diversity Mike Stonebraker, PhD  “One size doesn’t fit all” Curt Monash, PhD  “Horses for courses”  “Database diversity” Mike and Curt  The world needs 9 to 11 different kinds of data management software

4

5 Large enterprise DBMS portfolio Principal OLTP/multipurpose DBMS Principal OLAP DBMS Midrange OLTP/multipurpose DBMS Search Legacy DBMS Other specialty data management

6

7 Midrange OTLP/multipurpose DBMS “Standard editions”  Oracle, DB2, SQL*Server, Informix SE  Deliberately crippled VAR-centric  Progress OpenEdge, Intersystems Cache’  Accidentally crippled “Open-source”  MySQL, EnterpriseDB

8 OLTP DBMS worries Besides the greatest horror – data corruption – concerns include: License/maintenance cost Performance/scalability Ease of administration Ease of programming Reliability/uptime Security

9 Three major kinds of transactions Traditional business transactions  Orders  Employment changes  Compliance/risk monitoring Simple events = sensors, logs, etc.  Web site clicks  Network events  Device monitoring  Vehicle monitoring  RFID Content serving

10 Traditional business transactions are Complex Consistent in the face of complexity Stringently industrial-strength  Real business need  Customer expectations  Compliance

11 Issues to consider for applications that record complex transactions Schema complexity (integrity) Schema variability Peak performance Uptime Security

12 Issues to consider for applications that record simple events Performance Uptime What happens to the data next?

13 Issues to consider for applications that serve content Which datatypes? Scale The alphanumeric parts

14 Application metrics Peak concurrent update throughput Query complexity and volume Transaction (and constraint!) complexity Overall database size (and change!) Uptime requirements Security/compliance requirements Datatype needs

15 And how will those evolve? Business model changes  Functional changes

16 Environmental considerations Hardware (SMP, blade, toy collection) Middle tier DBMS expertise (and where it sits in the organization) Database administration tools Development tools Fixed-point applications (and how good is their generic JDBC/ODBC support?)

17 And how will THOSE evolve? Consolidation -- but what does that mean in your shop? Modularity

18 Example 1: Compliance/risk monitoring Many feeder systems One schema per feeder system Accept both relational ETL and XML Output via BI

19 Key requirements 1 Rigorous security Easy administration Eventual XML support Unknown scalability

20 Example 2: Contractually-defined products Complex financial instruments Vacations Warranties

21 Key requirements 2 Strong native XML Complex constraints Availability Security Volume?

22 Example 3: Content sharing and selling Web-facing – video, music, photo, etc. Internal content management

23 Key requirements 3 Performant media datatype support Performant order entry Performant user tracking and personalization Spike scalability 24/7 availability

24 Major areas of OLTP DBMS differentiation Performance and scaling Administration and 24/7 operation Constraints and referential integrity Triggers and stored procedures Datatype support

25 Performance and scaling Baseline, peak, future For which features? How sub-linear?

26 Administration and uptime Ongoing functions – backup, security, etc. Indexes and mandatory maintenance?? Replication, fail-over, etc.

27 Database constraints What can be done in theory? Does it perform?

28 Triggers and stored procedures Performance Languages Automatic generation Development, debugging, maintenance

29 Datatype support What do you need? Performance Datatype extensibility (Where relevant) Quality of search

30 Today’s main topics You can and should use multiple DBMS In particular, midrange OLTP DBMS are appealing Not all midrange OLTP DBMS are created equal Both application and environmental considerations are important More info at www.monash.com and www.dbms2.comwww.monash.com www.dbms2.com


Download ppt "WHAT THE MARKET-LEADING DBMS VENDORS DON’T WANT YOU TO KNOW Disruption is gathering steam."

Similar presentations


Ads by Google