Recently in Database architecture Category

In this post, Mike Stonebraker tackles two issues with regards to row- versus column-store databases. In the first issue, he looks at performance challenges given the demands of users. In the second issue, he discusses the availability of third-party connectivity as well as automatic database design tools. Continue reading "Supporting Column Store Performance Claims" »

In this response to a Curt Monash post over at the DBMS2 blog, Mike Stonebraker offers his reactions. He sees two categories of relational analytic/data warehouse databases, row stores and column stores, and notes that they have very different characteristics and should not be lumped together. He also points out that if high performance is required, current high-end relational engines can be beaten by a factor of 80 or so on TPC-C. Continue reading "In response to Monash's post on the four categories of RDBMS" »

In this post, Mike Stonebraker comments on a post over at DBMS2 titled "Database management system choices - overview." Mike makes two points. First, he offers his list of the different types of DBMSs that he sees as viable. Second, he discusses OLTP and the shared nothing architecture. Continue reading "Responding to Monash's recent post on diversity of database systems" »

In this post, Stan Zdonik examines the issue of INSERT performance in column stores. By implementing certain strategies, he notes that it is possible to have a column store with INSERT performance that is at least competitive in performance with that of the major row stores. Continue reading "INSERT performance in column stores" »

In this follow up post, David DeWitt and Michael Stonebraker discuss the feedback from their previous post on MapReduce. They focus on four criticisms of their first article: 1) that MapReduce is not a database system and should not be judged as one; 2) that MapReduce has excellent scalability, demonstrated by Google's use; 3) that MapReduce is cheap compared to high-end DBMS solutions; 4) and that their stance was the result of DBMS "gray beards" trying to defend their turf/legacy from the MapReduce "young turks." Continue reading "MapReduce II" »

In this post, David DeWitt and Michael Stonebraker discuss MapReduce. While it may be a good idea for writing certain types of general-purpose computations, they believe it is a giant step backward in the programming paradigm for large-scale data intensive applications; a sub-optimal implementation, in that it uses brute force instead of indexing; not novel, as it represents a specific implementation of well known techniques developed nearly 25 years ago; missing most of the features that are routinely included in current DBMS; and incompatible with all of the tools DBMS users have come to depend on. Continue reading "MapReduce: A major step backwards" »

Enterprises must integrate data in a number of operational systems. But how should they do it? There are two technical approaches: ETL or Federate. Michael Stonebraker discusses the pros and cons of each approach in regards to data element "heat," indexing, resource management, complexity of schema change, contention, timeliness, and mapping, concluding that the ETL approach makes sense in most cases. Continue reading "To ETL or federate ... that is the question" »

Don Haderle responds to two commenters from his previous post about DBMS history. He notes that "You ask whether it's possible to render a single implementation of a DBMS that satisfactorily handles all usages (OLTP, analytics, ...) well enough such that we don't need another. I think not. Existing implementations work ... Someday the economics may change -- but not at present. So one leaves the existing system intact and moves the data to another system (e.g., columnar) to do analysis ..." Continue reading "Haderle responds to commenters regarding RDBMS history" »

Current relational database management systems are largely built on designs from the 1980s. Back then, computers were expensive and slow relative to today's systems. The minimization of expensive CPU cycles -- not I/O considerations -- was the driving force in early relational DBMS design. The market sweet spot was transaction... Continue reading "Once upon a time ... the origins of today's relational database architectures" »

Large databases require the use of parallel computing resources to get good performance. There are several fundamentally different parallel architectures in use today: shared memory, shared disk, and shared nothing. This post examines each approach in terms of how it impacts database scalability. Continue reading "Database parallelism choices greatly impact scalability" »