1 / 30

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

WHAT THE MARKET-LEADING DBMS VENDORS DON’T WANT YOU TO KNOW Disruption is gathering steam. 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.html

ike
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

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.html • Blogs, including www.dbms2.com • White papers and more at www.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. Large enterprise DBMS portfolio • Principal OLTP/multipurpose DBMS • Principal OLAP DBMS • Midrange OLTP/multipurpose DBMS • Search • Legacy DBMS • Other specialty data management

  5. 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

  6. 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

  7. 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

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

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

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

  11. Issues to consider for applications that serve content • Which datatypes? • Scale • The alphanumeric parts

  12. 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

  13. And how will those evolve? Business model changes  Functional changes

  14. 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?)

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

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

  17. Key requirements 1 • Rigorous security • Easy administration • Eventual XML support • Unknown scalability

  18. Example 2: Contractually-defined products • Complex financial instruments • Vacations • Warranties

  19. Key requirements 2 • Strong native XML • Complex constraints • Availability • Security • Volume?

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

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

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

  23. Performance and scaling • Baseline, peak, future • For which features? • How sub-linear?

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

  25. Database constraints • What can be done in theory? • Does it perform?

  26. Triggers and stored procedures • Performance • Languages • Automatic generation • Development, debugging, maintenance

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

  28. 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.com

More Related