Essentially, extensible record stores are mostly patterned after Google’s BigTable that use a sparse, distributed muti-dimensional sorted map and that use primary key per column family to store data (Strauch et al. 2011). Figure below shows a simplified example of Big Table where “com.cnn.www” is the primary key which is used to retrieve data on columns “contents”, “anchor:cnnsi.com”, and “anchor:my.look.ca.” Therefore, similar to key value stores, there application is also limited to areas that only query data by a single primary key.
Unlike traditional RDBMS that use rows in their basic model, extendible record stores use both rows and columns in their basic model. Specifically, they achieve horizontal scalability by splitting both rows and columns over multiple nodes (Cattell, 2011). Therefore, these are also called column-oriented data stores in which the storage is done by column, not by row alone (Stonebraker et al. 2005).
Unlike document-oriented data stores but like key value stores, they cannot support nested objects (Cattell, 2011). They generally support only scalar data types and therefore have moderate flexibility in handling data variety (Stonebraker et al. 2005; Cattell, 2011). Moreover, unlike traditional RDBMS, these are schema-flexible data stores that typically have high horizontal scalability, that do not support joins and real queries, and that could handle moderate variety of data with low operational complexity (Bourret, 2006; Cattell, 2011). In addition, they are inefficient for row operations that effect multiple columns and inefficient for writing new rows. However, like traditional RDBMS, they could support strong concurrency and atomicity properties (Cattell, 2011).
Overall, extensible record stores have following internal strengths and weaknesses, and external opportunities and threats:
Contact us for more information.