| commit | 21ed0f72681a20ccb6a654f9aa4d54b8d0ea9c5c | [log] [tgz] |
|---|---|---|
| author | luochen01 <cluo8@uci.edu> | Sun Oct 08 17:23:44 2017 -0700 |
| committer | Luo Chen <cluo8@uci.edu> | Tue Oct 10 08:42:36 2017 -0700 |
| tree | 8095286e62844a46566a52e409dc0b9807c2a512 | |
| parent | 64965900c4fc4a33fe97bc1db6fa9ba946621b31 [diff] |
[ASTERIXDB-2103][STO] Too many disk components for CorrelatedPolicy - user model changes: no - storage format changes: no - interface changes: yes Details: Currently CorrelatedMergePolicy uses component Ids to ensure disk components of primary and secondary indexes are merged together, but without synchronization. However, this results in too many disk components for secondary InvertedIndex. The reason is that secondary index could miss some round of merges, if the merge policy finds out the corresponding secondary components are not available (either being merged or being flushed). Even though flow-control on secondary indexes can guarantee the secondary index would catch up the next time, it is still possible that the primary component is finialized, which leaves the secondary components which miss this round of merge are never merged again. This patch fixes this bug by: - Add the mechanism of depending operations to LSM IO operation. An operation finishes only after all depending operations have finished. - For correlated merge policy, the flush/merge of the primary index depends on all flushes/merges of secondary indexes. This ensures when the correlated policy schedules merge, all related components of all indexes are available to merge. Change-Id: Ib6c06ee23f3bfd16b758802388389c00e29780b1 Reviewed-on: https://asterix-gerrit.ics.uci.edu/2018 Sonar-Qube: Jenkins <jenkins@fulliautomatix.ics.uci.edu> Tested-by: Jenkins <jenkins@fulliautomatix.ics.uci.edu> Contrib: Jenkins <jenkins@fulliautomatix.ics.uci.edu> Integration-Tests: Jenkins <jenkins@fulliautomatix.ics.uci.edu> Reviewed-by: Jianfeng Jia <jianfeng.jia@gmail.com>
AsterixDB is a BDMS (Big Data Management System) with a rich feature set that sets it apart from other Big Data platforms. Its feature set makes it well-suited to modern needs such as web data warehousing and social data storage and analysis. AsterixDB has:
Data model
A semistructured NoSQL style data model (ADM) resulting from extending JSON with object database ideas
Query languages
Two expressive and declarative query languages (SQL++ and AQL) that support a broad range of queries and analysis over semistructured data
Scalability
A parallel runtime query execution engine, Apache Hyracks, that has been scale-tested on up to 1000+ cores and 500+ disks
Native storage
Partitioned LSM-based data storage and indexing to support efficient ingestion and management of semistructured data
External storage
Support for query access to externally stored data (e.g., data in HDFS) as well as to data stored natively by AsterixDB
Data types
A rich set of primitive data types, including spatial and temporal data in addition to integer, floating point, and textual data
Indexing
Secondary indexing options that include B+ trees, R trees, and inverted keyword (exact and fuzzy) index types
Transactions
Basic transactional (concurrency and recovery) capabilities akin to those of a NoSQL store
Learn more about AsterixDB at its website.
To build AsterixDB from source, you should have a platform with the following:
Instructions for building the master:
Checkout AsterixDB master:
$git clone https://github.com/apache/asterixdb.git
Build AsterixDB master:
$cd asterixdb $mvn clean package -DskipTests
Here are steps to get AsterixDB running on your local machine:
Start a single-machine AsterixDB instance:
$cd asterixdb/asterix-server/target/asterix-server-*-binary-assembly/ $./opt/local/bin/start-sample-cluster.sh
Good to go and run queries in your browser at:
http://localhost:19001
Read more documentations to learn the data model, query language, and how to create a cluster instance.