carbondata-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CARBONDATA-284) Abstracting Index and Segment interface
Date Sat, 08 Oct 2016 16:31:21 GMT


ASF GitHub Bot commented on CARBONDATA-284:

Github user jackylk commented on a diff in the pull request:
    --- Diff: hadoop/src/main/java/org/apache/carbondata/hadoop/internal/segment/
    @@ -0,0 +1,70 @@
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *
    + *
    + * Unless required by applicable law or agreed to in writing,
    + * software distributed under the License is distributed on an
    + * KIND, either express or implied.  See the License for the
    + * specific language governing permissions and limitations
    + * under the License.
    + */
    +package org.apache.carbondata.hadoop.internal.segment;
    +import java.util.LinkedList;
    +import java.util.List;
    +import org.apache.carbondata.hadoop.api.CarbonInputFormatBase;
    +import org.apache.carbondata.hadoop.internal.index.Index;
    +import org.apache.carbondata.hadoop.internal.index.IndexLoader;
    +import org.apache.carbondata.scan.filter.resolver.FilterResolverIntf;
    +import org.apache.carbondata.scan.model.QueryModel;
    +import org.apache.hadoop.mapreduce.InputSplit;
    +import org.apache.hadoop.mapreduce.JobContext;
    +public class IndexedSegment extends Segment {
    --- End diff --
    Do you mean a non-indexed and non-streaming segment? Yes, I think we can have a segment
like that, then reading of this segment will be pure scan only without any index. 
    But what is the benefit doing that? 
    I think the real issue is how to let optimizer to decide when to use index and when not
to use index. I think I will create another `Estimator` interface to expose cost information
for optimizer. What do you think?

> Abstracting Index and Segment interface
> ---------------------------------------
>                 Key: CARBONDATA-284
>                 URL:
>             Project: CarbonData
>          Issue Type: Improvement
>          Components: hadoop-integration
>    Affects Versions: 0.1.0-incubating
>            Reporter: Jacky Li
>             Fix For: 0.2.0-incubating
> This issue is intended to abstract developer API and user API to achieve following goals:
> Goal 1: User can choose the place to store Index data, it can be stored in
> processing framework's memory space (like in spark driver memory) or in
> another service outside of the processing framework (like using a
> independent database service, which can be shared across client)
> Goal 2: Developer can add more index of his choice to CarbonData files.
> Besides B+ tree on multi-dimensional key which current CarbonData supports,
> developers are free to add other indexing technology to make certain
> workload faster. These new indices should be added in a pluggable way.
> This Jira has been discussed in maillist: 

This message was sent by Atlassian JIRA

View raw message