commit | 7505a796f8c480c72f2e42893188bdf4e092528c | [log] [tgz] |
---|---|---|
author | luochen01 <cluo8@uci.edu> | Thu Jun 15 16:39:27 2017 -0700 |
committer | Yingyi Bu <buyingyi@gmail.com> | Thu Jun 15 17:57:30 2017 -0700 |
tree | 563d9cfeedf96b0e59f0f9b720e45e518155c26d | |
parent | a21388e0f94669a672bcfe3f069a9b49e26509c4 [diff] |
Avoid always merging old components in prefix policy Current, the prefix policy always looks at the components from oldest to newest to schedule merge. One negative consequence is that the oldest (largest) component gets merged over and over again until it reaches the size limit. This is undesirable since it takes O(n^2) disk IOs (n is the number of flushed components) to produce a final component. This patch is a temporary fix of this behavior, taken from the idea of HBase compaction policy (https://www.ngdata.com/visualizing-hbase -flushes-and-compactions/). The basic idea is that it introduces some size factor (for now it's 1.2) to control the merge behavior. When the prefix policy finds a sequence of components to merge, we also check the oldest (largest) component in the sequence should be smaller than 1.2*the total size of all younger components. By doing so, we can avoid merging oldest components over and over again, making the disk IOs O(nlog n). Change-Id: I464da3fed38cded0aee7b319a35664eae069a2ba Reviewed-on: https://asterix-gerrit.ics.uci.edu/1818 Tested-by: Jenkins <jenkins@fulliautomatix.ics.uci.edu> BAD: Jenkins <jenkins@fulliautomatix.ics.uci.edu> Integration-Tests: Jenkins <jenkins@fulliautomatix.ics.uci.edu> Reviewed-by: Yingyi Bu <buyingyi@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.