Binary Large Object and Transaction Processing Council - Essay Example

With the passage of the Utah Digital Signature Act of 1995 and the Federal Electronic Signature Act of 2000, more and more paper documents are being stored electronically. These digitized documents have "electronic signatures" attached to them that serve not only as unique identifiers but make them legally binding and enforceable as well. One obvious medium that is used to quickly access and store these electronic documents is the database. Many online and distributed systems require the efficient access of thousands of binary files such as music (the sample files streamed to potential customers), digital signatures, and other documents and videos that generally range in size from 10KB to SMB. The storage and retrieval of these items can be accomplished through a database system using a column type capable of storing binary data (commonly referred to as a "binary large object" or a BLOB). There are many existing database systems capable of storing BLOBs. Such systems' functionality, performance and cost vary greatly among vendors (with some costing as much as $25,000 for a single CPU license). The prohibitive cost often keeps some organizations from conducting full assessments of database systems for possible use in their operations, potentially causing a loss or revenue. Entities with limited resources need an affordable means of assessing or benchmarking their own database utilization. This thesis, first and foremost, provides a database benchmark for storing BLOBs in a database. Secondly, a database benchmark framework is provided with the example implementation being the BLOB database benchmark. By so doing: Developers will finally have a database benchmark for the storage of small, medium and large BLOBs in a database. Users will have a reliable and affordable means to benchmark their applications' database utilization on multiple database systems. Users will be able to determine the performance of different accessible system configurations (hardware, database and operating systems). Users will be able to get results reflecting the configuration capability of their organization. Running the benchmark locally will allow reliable replication of the benchmark without reading large disclosure documents provided with results from commercial benchmarks. The software development community will now have a benchmark for storing BLOBs in a database. This benchmark will fill a void as most database benchmarks focus on OLTP (online transaction processing) that consist of very small records and none focus on the general storage of BLOBs. EXISTING DATABASE BENCHMARKS My research indicates that no research has been done comparing the performance of database systems' ability to store BLOBs. Similar research regarding database performance (for datasets not including binary data) does exist and come from the following sources: the Transaction Processing Counsel (TPC), Storage Performance Council (SPC), Open Source Database Benchmark (OSDB), Engineering Database Benchmark (EDB) and Wisconsin Database (Bitton). In addition to not considering BLOBs, the TPC and SPC benchmarks are implemented by vendors who perform many specialized database and operating system configurations. Thus, they are not pertinent to this discussion. These nonstandard configurations take advantage of the vendors' specialized knowledge of the hardware, database, operating system and benchmark. This thesis provides the first benchmark to assess the storage of BLOBs in relational database systems. The performance results are categorized into three general BLOB sizes: small, medium and large. Below is a brief description of the five similar database performance resources. Transaction Processing Council (TPC) Each TPC benchmark consists of a set of functional requirements to be run on any transaction processing system independent of the hardware or operating system. It is then up to the test sponsor to submit proof (in the form of a full disclosure report) that they have met all the requirements. The TPC has four non-obsolete database benchmarks: TPC-C, TPC-H, TPC-R and TPC-W. The four current TPC benchmarks define the requirements of database utilization, scaling, transaction types and how the business activities should be modeled. Two shortcomings of the TPC benchmarks are these. First, vendors implement and perform the benchmarks, and second, users cannot assess the benchmark's performance on their hardware or modify the benchmark to closely resemble their applications. In order to realize similar performance results and due to these shortcomings, developers must utilize the exact hardware and configuration used to implement the benchmark and then model their application after the benchmark definition rather than their own needs. While the TPC benchmarks have value, none of them deal with the storage of BLOBs in the database or provide a standard code base from which users can extend, enhance or even run the benchmarks themselves. Currently, the TPC provides four of these benchmarks; a general description of each follows: A. TPC-C is an OLTP benchmark for a wholesale parts supplier and is the latest revision of the original TPC-A benchmark that was the first benchmark implemented by the TPC and was described as an OLTP Debit-Credit benchmark. B. TPC-H is a decision support benchmark. This benchmark illustrates decision support systems that examine large volumes of data, execute queries with a high degree of complexity, and give answers to critical business questions. C. The TPC-R benchmark is a decision support benchmark similar to TPC- H, but which allows additional optimizations based on advanced knowledge of the queries. D. TPC-W benchmarks typical activities for a business-oriented web server for a transaction E-commerce application Storage Performance Council (SPC) The SPC has two benchmarks (SPC-1 and SPC-2) for analyzing the performance of storage subsystems. These benchmarks are very general and not specific to database performance. SPC-1 represents a segment of applications characterized by predominately random I/O operations and requiring both queries as well as update operations (for example OLTP systems, database systems, or mail server applications). Like the TPC benchmarks, both SPC-1 and SPC-2 are generated by vendors trying to show excellent performance for their hardware or software. Open Source Database Benchmark (OSDB) OSDB is based on the ANSI SQL Scalable and Portable Benchmark (AS3AP), documented in The Benchmark Handbook [6]. The AS3AP specification defines a set of single-and multi-user tests that are then run against a database and scaled complete in 12 hours. The single-user tests provide a benchmark of the basic functions supported by a relational database that must support to comply with the ANSI SQL 2 standard. The multi-user tests benchmark OLTP, information retrieval, and mixed workloads including a balance of short transactions, report queries, relation scan, and long transactions. As with the other benchmarks, the OSDB does not provide any analysis of storing BLOB fields in the database. However, as it is an open source, users can run this benchmark and alter it. Engineering Database Benchmark (EDB) The EDB was developed specifically for benchmarking typical database performance of engineering products such as computer-aided design (CAD) applications and is also documented in The Benchmark Handbook. The focus on engineering database utilization has limited its scope to the domain of engineering applications unlike the BLOB benchmark which is not limited to one particular domain. Wisconsin Database Benchmark This benchmark was developed in 1983 and is no longer relevant due to the exponential improvements in hardware, software, and database related capabilities. Read More