|
This paper proposes C-store, a read-optimized and shared-nothing relational DBMS. This design aims at read-mostly applications with a small percentage of updates and more ad-hoc inquiries. For the shared-nothing setting, it is assumed to be a grid environment in which there are G nodes, each with private disk and memory, and data is horizontally partitioned across nodes. The system also uses redundancy to provide K-safe. To get high read performance and reasonable write performance, C-store nodes maintain Writeable Store (WS) and Read-optimized Store (RS) sets, to decouple write to read and achieve desired performance. WS tuples are periodically merged into RS, according to some coordination node's instruction and timestamps kept. Data storage is designed to store data efficiently on disk. The paper provides four data encoding scenarios, depending on whether the column depends on its own ordering, and whether the key has many or few distinct values. Compact data storage lowers the storage overhead and can allow the DBMS to store more projections, which could accelerate more read requests. Snapshot isolation is maintained in C-store system, by maintaining high water mark(HWM, most recent time in the past where snapshot isolation can run) and low water mark (LWM, the earliest time where a read-only transaction can run). These time stamps also help failed nodes recover. When recovering nodes would query other nodes for data related with these timestamps. Tuple mover is designed to efficiently move blocks of tuples in WS to RS. The system basically creates a new RS segment from WS and the old RS. This approach, compared to in-place data merge, is efficient since data is also moved in the in-place approach while the proposed approach allows using old RS when updating. The performance comparison shows that for read-only workloads, the C-store system outperforms state-of-art row store and column store systems in both memory usage and execution speed. The authors propose four reasons: column representation avoids reading unused data / multiple orderings of columns accelerate different queries / data compression allows multiple orderings in the same space / query operators are designed to operate on compressed data. This paper illustrates the C-store architecture clearly. It would be interesting to see the performance with writes (despite the authors claim the system will mainly be used for read-mostly cases). Also, it would be good if an algorithm for selecting different orderings of columns can be shown. In the test provided in the paper, the authors seem to manually select schemas to be stored. |
|
Most current DBMS use continuous memory on disk to store a row of a record because it’s simple to write a record with all attributes updated on continuous disk position. This kind of system optimize write performance. However, when it comes to lots of read request on the same attribute among all records, the write-optimized system is not that efficient. This paper discusses the design of C-store, which stores columns continuously, to meet the need of read-dependent applications. Column store architecture only needs to read the column required by the query, which avoid redundant work to bring irrelevant attributes. The C-store system optimize the tradeoff between CPU cycles and disk bandwidth by using more CPU cycles because it’s abundant. The system store sorted columns, which optimize performance when the query asks for one or more sorted attributes. Physically, the paper proposes to fully utilize the cheap grid environment which deducts hardware cost. Drawbacks of column store system is that it weakens the write performance and read performance when reading different attributes in a single record. The introduction of this paper is too long comparing the length of this paper. It’s better to move some details to later sections or create a new section discussing how read-optimized system solves dilemma and drawbacks of write-optimized systems. |
|
Systems oriented toward ad-hoc querying of large amounts of data should be read-optimized instead of write-optimized in most major DBMSs, and are more efficient and can offer better performance using a column store architecture. Therefore, this paper presented the design of a column store called C-Store that includes a number of novel features relative to existing systems. C-store physically stores a collection of columns, each sorted on some attribute(s). Groups of columns sorted on the same attribute are referred to as “projections”, which can be sorted in different attributes and are implemented in C-store in order to get better performance in terms of read-optimization. C-Store allows redundant objects to be stored in different sort orders providing higher retrieval performance in addition to high availability. C-store connects both a read-optimized column store and an update/insert-oriented writeable store by a tuple mover, which consists of Writeable Store (WS) component and Read-optimized Store (RS) component. WS is architected to support high performance inserts and updates and RS is capable of supporting very large amounts of information. The job of the tuple mover is to move blocks of tuples in a WS segment to the corresponding RS segment, updating any join indexes in the process. C-store turns an update into an insert and a delete in order to provide snapshot isolation, and uses a NO-FORCE, STEAL policy with only log UNDO records to implement locking-based concurrency control. The contributions of this model includes: 1. A column store representation, with an associated query execution engine. 2. A hybrid architecture that allows transactions on a column store. 3. A focus on economizing the storage representation on disk, by coding data values and dense-packing the data. 4. A data model consisting of overlapping projections of tables, unlike the standard fare of tables, secondary indexes, and projections. 5. A design optimized for a shared nothing machine environment. 6. Distributed transactions without a redo log or two phase commit. 7. Efficient snapshot isolation. The main drawbacks are as follows: 1. This paper has not fully integrated the WS and tuple mover, whose overhead may be significant. 2. C-store performs better when the workload cannot be anticipated in advance, but may be optimized when a prespecified set of queries is run at regular intervals. |
|
Problem & Motivations The row-oriented database has many disadvantages on reading data. 1. It needs to read many unnecessary data given a query that only interests some attr. of a record. 2. It cannot encode or compress the data in a more efficient way. Given some database like OLAP which takes a large amount of data retrieving but few updates, the traditional database will be really inefficient. Therefore, it will be better to have an ad-hoc database that can achieve high-efficiency for such situation. Achievement The paper proposes a new way to design the DB, namely c-store, which is the prototype of the later column-oriented database. By storing the attributes of the table in contiguous space, it can apply strategies like encoding, compressing to increase the disk bandwidth. And by nature, it does not need to retrieve irrelevant data which speeds up the querying process. And the paper provides corresponding algorithms for developing the database which satisfies most of the DB requirements, including data format, storage, isolation, consistency & concurrency, recovery and query processor. Drawback: Too abstract! I strongly agree the authors donate many efforts on this paper and it really covers many aspects of DB and seems reasonable. However, the paper lacks a vivid example that helps read understand what the definitions look like and how they interact with each other. Every part of the paper lacks such an example. |
|
Relational database management systems have been widely used for a great deal of tasks, which often vary greatly in terms of requirements. At the time the paper was written, the majority of systems were optimized for row-store, which means that it is write-optimized. In many fields, however, workloads heavily emphasize reading data, which necessitates a column store architecture. This paper proposes a column-oriented DBMS, C-store, to address this deficiency in market offerings. By using column store, a DBMS can avoid reading in irrelevant attributes that would be the case for a row-store system, since reads require all the rows for a particular set of column(s), rather than all the columns for a particular row. Another trend in favor of this trend was the faster growth of CPU speed compared to disk bandwidth, which shifted the original tradeoff between CPU cycles and disk access away from disk access. In order to achieve this goal of a read-optimized system, C-store stores data as columns sorted on some attribute, and multiple columns sorted on the same attribute are known as projections. The system is designed as a shared nothing system. Aggressive compression is used to decrease space usage. Writing transactions is done with a hybrid architecture containing a writable store, which is used for high performance inserts and updates, and read-optimized sore, which can handle large amounts of information but can only support batch movement of records from WS to RS. The paper also details various features of the system common to any DBMS, such as transaction support concurrency control, and query optimization, as well as how they implemented snapshot isolation on C-store. The performance section shows the experimental results from running the system on various benchmarks, and the results are quite remarkable in relation to the row-store systems. In the comparison of C-store to standard relational DBMS, they achieved performance gains ranging from 20x to 350x. Even with the use of materialized views and other aids for the row-store systems, there is still a 6x to 10x improvement, which is very significant. This paper’s main advantages lay in their design and implementation of a new variation of relational databases that is closely optimized to an under-supported use case, the read-heavy workload. In specializing this system, it manages to achieve almost incredible performance improvements. At the same time, they still offer many features like snapshot isolation and K-safety. While these individual features have already been around, what makes the system stand out is its successful integration into one package. Some potential weaknesses likely lie in the optimizations the authors used to decrease resource consumption. One example of this is the use of data compression to deal with the increased storage required for all of these projections. This could potentially result in the loss of information, which may or may not be problematic in certain fields. The decision to use the shared nothing model carries with it its own potential downsides in coordination, etc. inherent to the model. Finally, the system was heavily specialized for read operations, but every potential user will still have to write data at some point, and the paper does not address the performance with any queries containing inserts which would have been helpful in characterizing the performance penalties. |
|
The main contribution of this paper was the design of a storage system optimized for reading data, named C-Store. As opposed to write-optimized designs that store the attributes of a single record next to one another in memory, C-Store stores the values of a single attribute next to all the corresponding values for that attribute of other records. This problem is important because most of the previously implemented storage architectures were write-optimized and “row-oriented,” and there are use cases where the optimizations for writing are not necessary and in fact inefficient. The primary method for achieving this was building a hybrid architecture with a component optimized for high performance inserts and updates, and another component for storing a lot of data in a way that makes accessing the data fast. They save space with data compression and time with snapshot isolation. For safety from failures, the author implemented overlapping projections with different sort orders, so the data is redundant and accessible in different ways that may be optimal depending on the query. The RS component can be self-ordered or foreign-ordered and there is a table of join indices that helps connect all of the projections and the much smaller WS component, which has a one-to-one mapping to the RS component. The read-only transactions use snapshot isolation and the read-write transactions use 2-phase locking and there is a tuple mover that moves the data in the WS component to the RS component. I liked how the article thoroughly introduces the problem and the proposed solution, before then outlining in detail how it will communicate the process of implementing this solution. In general it was very organized and the information flowed logically, from the data model to all the components of this architecture and all of the optimality tradeoffs that they considered in the final implementation. I liked the examples they provided in the Data Model section, because after the previous section described projections on a more conceptual level, I did not have a firm grasp on what one might look like; the examples helped me see associate an image with the concept. I thought that this article did not have the best graphics. I felt that Figure 1 was a bit too simple, to the point where I had to read the accompanying paragraph very carefully and still use some imagination in addition to the basic blocks and arrow they drew. I also thought Figure 3 was just visually cluttered, there were a lot of vertically dense labels and long horizontal arrows indicating what they pointed to across the diagram. This just distracted from the content a bit for me. |
|
C-store first of all is a read-optimized relational DBMS but is designed quite different from the existing column-oriented commercial DBMS. It achieves not only high performance in read transactions but also gives optimization of write transaction in case of volumes of inserting and updating. It also includes snapshot isolation for read-only transaction and the use of bitmap indexes in implementing B-tree structures. This paper first gives an overall introduction of what is the column store architecture and explains why column store architecture is an efficient architecture for reading-only transactions. And it also goes through how column store saves disk bandwidth using CPU cycles and how it uses B-tree structures to store tuples. Then brings the problems that the existing column oriented DBMS fails to efficiently perform transactional updates in read-mostly environment which then be resolved by C-store by using the combination of writeable store and read-optimized store together. This paper claims that the C-store achieves 1)efficiency on warehouse-style queries and 2)reasonable speed on OLTP-style transactions. The data model that C-store adopted is a commonly used relational logical data model. It uses projections to representation of the relationship between columns. And this technical is also used in writeable store and read-optimized store which share the same sid. For read-optimized store, the paper introduces four types of encoding schemes and how the join indexes work. For the writeable store, it use same projections and join indexes in read-optimized store in avoiding writing two optimizers. Also, like RS, WS is horizontally partitioned so that there is 1:1 mapping between these two segments. However in WS, the data are directly represented without compressed for the reason that WS has smaller size than RS. The important feature in WS is its snapshot isolation and locking-based concurrency control. Before that, for multi-core system, It uses globally unique storage key(WS and RS share the same one). And it uses a large main memory buffer pool in avoiding poor performance. It isolates read-only transactions using snapshot isolation so that no locks are needed. The paper gives thorough algorithm in dealing with visibility of different version of data storage and data recovery. And also it gives introduction and reason of implementing Tuple Mover. The paper shows solid experiments which proves the performance of the proposed C-store. I think the main contribution of this paper is creatively adopted snapshot isolation in optimizing write transaction in a column based DBMS scenario. I don't have any drawback to mention at this time. |
|
In this paper, it tries to solve a problem that the traditional relational row store database is designed for write orientated application. However, there is not a specific design for read oriented OLAP applications. Also, the bottleneck of read heavy operation is laid on disk, so we can trade cpu cycles for disk IO. To address this problem, this paper proposed C-Store, which store the data by row. Moreover, it is also desirable to have the DBMS query executor operate on the compressed representation. C-Store divides its physical storage into two layers, a write-optimized Writeable Store (WS) and a read-optimized Store (RS) optimized for reading. Also the whole database is partition horizontally on a large number of nodes and to be configured to tolerant K nodes failure. C-Store considers most transactions to be read-only, so Snapshot Isolation is used. For read and write transactions, C-Store uses a traditional 2PC. As for store, the C store proposed three different coding methods to handle different column data type. The data type is valued on two standards, whether the data is self sorted and how many distinct values exists for this column. Inside C-Store, logical tables are split vertically into projections, and each projection can contain one or more columns, or even columns from other logical tables. Each column will exist on at least one projections. When querying, C-Store will first select a set of projections that can cover all the columns in the result as the covering set, and then perform a join calculation to reconstruct the original row. WS is still logically stored according to the projected column model, but physically uses B-trees to meet fast write requirements. WS is a multi version storage and RS is not, which can be seen as a snapshot of a point in time in the past. The Tuple Mover periodically moves the data from WS to the RS. Updates in the C-Store are implemented through a delete plus an insert. The main job of the Tuple Mover is to update the RS based on the data of the WS: delete the deleted rows and add new rows. The main contributions of C-Store are as follows: propose an innovative combination of several techniques that simultaneously provides improved performance, K-safety, efficient retrieval, and high performance transactions; multiple copies of column data and multiple indexing methods are implemented simultaneously through well-designed projection; the performance of small writing is balanced by means of read-write layering. As the C store system is based on shared nothing distribution system, the paper did not describe the solution on how the data should be partitioned to achieve load balancing. |
|
The paper introduces a column-oriented database, C-Store. As a column-oriented database, it is optimized for reads (while row-oriented RDBMSs are optimized for writes) and uses less storage space. This is particularly useful for analytical workloads, especially on systems where data is periodically dumped, so there are very few updates and many ad-hoc queries. Columns are stored in an order that is optimized for the queries that are run against the database. There is a significant amount of redundancy built in by using multiple projections, which store data in a way that make it fast to access by all queries in the workload. Projections are made up of columns (sometimes from multiple tables), and there must be at least one projection representing each column, such that the full logical table could theoretically be recreated. Many columns can be compressed, which reduces storage utilization. C-Store supports configurable K-Safety, which means that if up to K nodes fail within a certain time, the system can maintain consistency because of redundancy in projections and join indices. Finally, the system is unique in that it implements a separate read and write store as its method for handling (infrequent) writes. I thought that the paper described the data model of the column store well. At first I had a hard time imagining how columns could represent a logical table or row. However, the authors describe join indices and projections very well, which made the material easier to grasp. In only 12 pages, the paper describes many facets of the system - including the data model, storage, recoverability, query optimization, and more. I believe that the authors felt as though they needed to present the full picture because as they state in the introduction, the elements of C-Store are not all novel. The primary technical contribution is the combination of these elements to create a high-performing system. One downside was that the paper used *a ton* of abbreviations. When there were more than three of these in a sentence, it sometimes became very difficult to keep them straight. In some cases, I think it would have been better to expand them, although I’m sure that the authors were trying to make the paper a certain length. I also noted that the state of the project as described in the paper was incomplete. While I agree that this is important work, it definitely seemed like the authors were trying to meet a deadline and ended up presenting only preliminary results, where full results would have been more valuable. Finally, I would have liked to know a bit more about the relational column store that was used in performance testing and had much worse performance. |
|
Major database management systems are implemented in a record-oriented fashion where attributes of a record are placed contiguously in the underlying storage. This method benefits write operation since a single disk write can push all fields of a record out to disk. However, there are many cases where the workloads consist of mostly read operation and the system should be read-optimized. This paper purposed C-Store, a column store architecture where values for a single column is stored contiguously. A column store architecture allows the database system to only bringing into memory attributes relevant to the query and thus improve performance. In addition to that, the purposed C-Store system also introduced other innovative features: compressed column representation, redundant storage of data to improve performance and ensure high availability, snapshot isolation for reads, etc. C-Store contains three main components: a writeable store (WS), a read-optimized store (RS), and a tuple mover. WS is responsible for supporting inserts and updates, while RS is responsible for supporting large read operation. RS can only be modified by the tuple mover which is used to sync write operations in WS to RS. In terms of the data model, C-Store stores only “projections”. Each projection is a set of columns ordered by a key of a set of keys. Columns in one projection don’t have to from the same table, and each column can exist in multiple projections. A projection is further horizontally partitioned into many segments and stored on different nodes. To reconstruct a table, C-Store additionally stores join indexes so that different projections of a table can be converted into the same order. Read-only transactions in C-Store is isolated using snapshot isolation, while for read-write transactions, strict two-phase locking is used. The query processing unit in C-Store is also quite different from other major DBMS since the underlying set of query operators are different. Traditional optimization methods, for example, materialized view also cannot be used. Instead, the optimizer needs to decide which set of projections to use for given query. Performance comparison among C-Store and other row/column store system show that it has a significant performance improvement. However, the performance is only for read-only queries, the performance for read-write queries remains unclear. |
|
In the paper "C-Store: A Column-oriented DBMS", Mike Stonebraker and co. discuss the conception and implementation of a new relational DBMS that is optimized for reads. This is in contrast to the write optimized DBMS that exist in the current market. It may seem like this is going against market trends, but read optimized DBMS have valid applications to real life scenarios such as customer relationship management, library card catalogs, and other inquiry systems. As such, one could imagine that a system optimized for handling aggregates quickly is desirable in these situations. Furthermore, C-store also uses CPU cycles to save disk bandwidth by encoding data elements into a more compact form. These data elements form tuples that are are stored in structures that benefit read operations such as cross table indexes and materialized views. The collection of columns are stored physically, each sorted on a particular attribute. Dedicating space for these sorts enables aggressive reads and better optimizations. Interestingly, redundancy is incorporated to not only guarantee data consistency, but to also store data in different sorted orders to improve retrieval times; a drawback becomes a benefit for them! Since C-Store is a relatively new concept, the optimizer and executor were built from scratch, snapshot isolation was carefully programmed into the run time system, and support for larger queries was implemented. As the paper describes in great passion, even though all these topics have been discussed in detail before, the combination of all these in a real system such as C-Store is what makes this truly unique and fascinating. C-Store comes with many features that were implemented with specific use cases in mind. This means that C-Store needed its own query execution plan and optimizer that implemented its own operators, iterators, and access methods. It supports the standard relational logical data model and uses SQL as its query language, but implements them only using projections. These projections are broken into column components and stored in order of the sort key for the projection. Consequently, C-Store comes with a recovery option by running a query from other projections, maintaining both k-safety and transactional safety. The storage key is calculated on the fly as needed when utilizing the read optimized column store. Similarly, when designing the write optimized column store, the same physical design is used as the read optimized column store, but the storage representation is different because writes need to be efficiently updated per transaction. Thus, C-Store isolates read only transactions using snapshot isolation while keeping update transactions obey strict two phase locking. These implementation decisions are what ultimately led to C-Store outperforming its competitors. One drawback that I noticed was the terribly long introduction. Low level technical details sometimes leak into the motivation and take away from the interpretation of how interesting the problem is. Another drawback to this paper are the methodologies to represent data for performance comparisons. Rather than use graphs, which are more easily comprehendable to humans, tables are used instead. This is something I would like changed. Finally, having so many authors in a joint research project such as this enables a vast perspective on the direction this project can take. However, a section on future work was void - indicating that this may never be revisited. I felt very disheartened by this and lost my initial interest in its potential. |
|
This paper describes a non-standard way to store database data in order to optimize read operations at the expense of writes. Normally, a relational database stores each row contiguously; each column in the row is stored adjacent to each of the other columns. C-Store describes an alternative: all of the values for a single column are stored contiguously, so the values that make up a single row are spread throughout the storage medium. Since reads are mostly on a subset of columns, this storage method prevents loading unnecessary column data into memory. Since rows aren’t in one place, however, normal B+ tree indexes aren’t as useful, and other methods for speeding up queries like materialized views must be used instead. Since the data is stored by columns, large parts of data are of the same data type, so large-scale compression can be done on each column. Some writes still need to be done into the database, so it’s separated into two sections: a read storage and a write storage. The write storage is very small, and writes can be done easily. The read storage is much larger, has the optimizations for transaction reads, and can only be written to from the write storage. A “tuple move” transfers data from write storage to read storage when necessary. This paper describes a unique way to store data in a relational DBMS, which can be very useful for specific workloads. The paper is generally able to effectively show what extra setup is needed to efficiently run a column store DBMS, such as the division into read store and write store. However, the paper doesn’t spend as much time discussing the advantages of C-Store. |
|
The paper illustrates a read-optimized relational DBMS instead of write-optimized. It tries a novel thinking in designing DBMS and achieves great performance, which is worthy for more efforts to research. The innovative features include: a hybrid architecture with a WS component optimized for frequent insert and update and an RS component optimized for query performance; Redundant storage of elements of a table in several overlapping projections in different orders, so that a query can be solved using the optimal projection; Heavily compressed columns using one of several coding schemes; a column-oriented optimizer and executor, with different primitives than in a row-oriented system; high availability and improved performance through k-safety using a sufficient number of overlapping projections; the use of snapshot isolation to avoid 2PC and locking for queries. One improvements can be the serializable execution of the system as the snapshot isolation do not equal to serializability. |
|
This paper presents a design of database that optimizes both read and writes, which is different from most current write-optimized systems. Most important differences are storing data by column rather than by row, storing a collection of column-oriented projections, using high availability and snapshot isolation for read-only transactions, and using bitmap indexes to complement B-tree structures. Author states that column store architecture can avoid bringing into memory irrelevant attributes and save disk bandwidth by coding data elements in to a more compact form. Also, C-Store stores a collections of columns, each sorted on multiple attributes, which allows fewer join indices. It allows redundant objects to be stored in different sort orders to make the system tolerates multiple failures. Following introduction, the paper goes into details of data model, write store, read-optimized store, allocation of data to nodes, updates and transactions, and query optimizer and executer. Many of the features like snapshot isolation and locking based concurrency control are not new in C-Store, what is special about C-Store is it combines all those features in one system. This paper tries to cover a lot of features of C-Store but does not provide a clear high level organization overview of the whole system. The introduction is quite long and disorganized, which makes it hard to track so many ideas. Author presents advantages of C-Store system, but does not have enough analysis on its disadvantages. The last evaluation section only evaluates the query efficiency but ignores the cost of update. I feel like the system will cost more on update than current systems, but the paper does not present that well. |
|
“C-Store: A Column-oriented DBMS” by Mike Stonebraker et al. presents C-Store, a new column-oriented DBMS composed of several features innovative for columnstores that together make it faster or competitive with commercial columnstores. These features include a writeable store and a read-optimized store connected by a tuple mover, redundant storage of data through different projections for performance and K-safety, compressed column data, an optimizer and executor intended for columnstores, and snapshot isolation. The work seems practical, noting that columnstores are useful for warehouse applications with ad-hoc and aggregate queries. The work explores how a particular combination of DBMS components and approaches perform when applied to columnstores specifically. Perhaps the idea could/would be commercialized, especially with DBMS pioneer Mike Stonebraker the leader of the work. The paper proposes designs for the writeable store and tuple mover, but at the time the paper was published, the authors had not finalized their implementations and therefore not tested them. This seems misleading. Perhaps the C-Store design could work well, especially given that it was designed by DBMS experts, but there are no experimental results in the paper to support this. Additionally, although the work appears practical, I wonder whether the DBMS research community considers it novel research, since the subcomponents of C-Store themselves are adapted from prior systems and research. |
|
This paper presents a different design of a read-optimized relational DBMS, while most current systems are write-optimized, by implementing column store architecture. The paper points out that, due to the fact that row storage can write suffices to push all fields of a record into the disk, row storage is proper for write-optimized systems. The technical contributions of this paper are significant. First, it proposes to trade CPU cycles for disk bandwidth. This is very novel to me. It's a real engineering thought to make that tradeoff. Second, it provides transactional updates by the proposed WS-RS structure linked by Tuple Mover, to meet the requirement of a read-mostly environment. Third, it provides redundant storage by using different orders instead of simply making replicas. Besides, different orders can be useful when dealing with different queries. So the availability and performance of the DBMS are both improved. Forth, it provides snapshot isolation to avoid 2PC and locking for queries, which is also efficient under a read-most scenario. Besides all the technical contributions, the write-up of the paper is also commendable. The whole paper is written in a clear structure. And the figures and examples in the paper are really helpful for readers to understand better. |
|
This paper proposes a novel DBMS using column storage called C-Store. At the time when the authors were writing this paper, most DBMS are write-optimized. As for these systems, they are record-oriented storage systems where the attributes of a record are placed contiguously in storage. However, for some systems oriented toward ad-hoc querying of a large amount of data, read functionality should be optimized. This question is very important because in some scenarios like data warehouses, reading speed takes first priority. In order to build a read-optimized DBMS, they introduce C-Store, a design with column storage and includes a number of novel features. The crux of C-Store is the adoption of a column-oriented data model, the read access efficiency outperforms traditional row indexing. This is achieved by using projections, which are sorted subset of attributes. By utilizing these column-oriented projections, C-Stores can select the best projections for query and reach faster read speed. One interesting thing of C-Store is that it can provide good reliability through K-safe, which means that the loss of K nodes in the grid will still allow all tables to be reconstructed despite the K failed sites. In order to achieve this, C-Store also introduces efficient recovery mechanisms. Besides, a key design of C-Stores is the architecture of RS and WS, the RS is optimized for reading while the WS is optimized for write. In RS, columns are compressed using 4 kinds of different encodings. For WS, it shares the most feature of WS, however, the storage representation is drastically different since WS must be efficiently updatable. Besides, snapshot isolation is provided in C-Store and a low-overhead mechanism for HWM selection is introduced to keep track of its value in the multi-site environment. There are several advantages to the C-Store. First, it provides disk bandwidth saving by coding data elements into a more compact form and dense packing values in storage. Second, C-Store provides redundant storage of elements of a table in overlapping projections which enable the query to select the most advantageous projection to improve performance and availability. Next, it adopts an innovative hybrid architecture with WS and RS components to optimize write and read. Besides, C-Store is optimized for a shared-nothing machine environment and use an efficient snapshot isolation level to avoid two-phase commit and locking for queries. I think there are some drawbacks to this column storage approach. First of all, since C-Store is optimized for reading and data in columns are sorted, this greatly degrades the performance of insertion. Although they provide some mechanism to solve this problem (keep a read-optimized column store and an update/insert-oriented writeable store), it still has an overhead for tuple moving process. I think their design will poorly perform in a write-heavy environment because both WS and RS will participate in data manipulation, if one of them is much slower, it will become a bottleneck of the whole system. Next, the read optimization of C-Store is only focused on OLTP applications, however, it does not consider the OLAP environments. |
|
This paper introduces C-Store, which is a read-optimized DBMS. C-Store is built using column-based storage, which gives it inherent read-optimization compared to a row-oriented storage system. Its main architecture consists of a read-optimized store which services read requests, and a write-optimized store (that still uses column-oriented storage) to service write requests. Tuples are moved from the write store to the read store when valid under Snapshot Isolation by the Tuple Mover component. Read-write transactions are implemented by two-phase locking, and the entire system is implemented as a shared-nothing architecture, which uses a slightly modified version of 2PC for consensus. The paper’s main strength is the fact that its an implementation of a column-oriented, read-optimized DBMS, which contrasts with the widely popular (at the time, at least) row-oriented, write-optimized systems sold by vendors. Thus, C-Store is ideal for OLAP workloads. C-Store’s shared-nothing architecture also means that it can run on relatively inexpensive hardware, rather than relying on a central, expensive unit. C-Store’s replication strategy also provides reasonable levels of performance benefits as well as safety. The biggest weakness of C-Store is that a large portion of it was not implemented at the time the paper was published, which means that experimental results were all but missing. Also, the motivation for C-Store’s modification of 2PC was not given; it seems to possibly be for performance reasons but I’m not entirely sure on my own, and I was not satisfied with their explanation of that section. C-Store is also obviously only advantageous for workloads that are focuses on reads, rather than writes—it’s not a universally “better” database than regular databases of the time. |