Re: Make "HBase options" as default setting?

[Qifan Chen]

I wonder if the nature of the proposal should be to hide the complexity of raw 
hbase options and provide a better semantic specifications for the 
HBASE_OPTIONS clause.


>From 
>http://archive.cloudera.com/cdh5/cdh/5/hbase-0.98.6-cdh5.2.4/book/compression.html,
> there is a good set of rules for the choice of compression.


  *   If you have long keys (compared to the values) or many columns, use a 
prefix encoder. FAST_DIFF is recommended, as more testing is needed for Prefix 
Tree encoding.
  *
  *   If the values are large (and not precompressed, such as images), use a 
data block compressor.
  *
  *   Use GZIP for cold data, which is accessed infrequently. GZIP compression 
uses more CPU resources than Snappy or LZO, but provides a higher compression 
ratio.
  *
  *   Use Snappy or LZO for hot data, which is accessed frequently. Snappy and 
LZO use fewer CPU resources than GZIP, but do not provide as high of a 
compression ratio.
  *
  *   In most cases, enabling Snappy or LZO by default is a good choice, 
because they have a low performance overhead and provide space savings.
  *
  *   Before Snappy became available by Google in 2011, LZO was the default. 
Snappy has similar qualities as LZO but has been shown to perform better.


Instead of saying

   DATA_BLOCK_ENCODING = 'FAST_DIFF',


we can say the following and provide a good compression scheme for the type of 
data behind the scene.

  OPTIMIZED for  data
   := cold | hot | image  (default to hot data, if the OPTIMIZED clause 
is omitted)


On encoding.  it looks like that FAST_DIFF is recommended and therefore we can 
just make it a default value.

On mem store flush size.  The default value should be the one based on the 
nature of the table (dimension, fact and its type (tpcds, or oltp), which 
describes the access attribute of the data, and can take a value of 
load_and_read or read_write. Call the attribute .

So at the end, a HBASE_OPTIONS with better semantic specification could be 
written as follows.

HBASE_OPTIONS
  (
optimized for  ,  data
  )


Examples:

HBASE_OPTIONS
  (
optimized for hot, read_write data
  )

HBASE_OPTIONS
  (
optimized for cold, load_and_read data
  )

And one can of course use the CQD method to provide a default HBASE_OPTIONS 
clause.

Just my 2 cents.

Thanks --Qifan

From: Rohit Jain 
Sent: Wednesday, June 7, 2017 11:51:47 AM
To: user@trafodion.incubator.apache.org
Subject: RE: Make "HBase options" as default setting?

I am suggesting that we change the default settings to those as proposed so 
that all tables use those settings by default.  So, it is a +1.  A CQD might be 
used to override the default.  This, hopefully will be rare.  I just think that 
having entries in a system DEFAULTS table are problematic for the reasons I 
mentioned. Of course, they would be in the compiler’s default settings.

Rohit

From: Dave Birdsall [mailto:dave.birds...@esgyn.com]
Sent: Wednesday, June 7, 2017 11:28 AM
To: user@trafodion.incubator.apache.org
Subject: RE: Make "HBase options" as default setting?

So, would this make you a -1 on the original suggestion? (that is, just 
changing the HBASE_OPTIONS defaults?)

From: Rohit Jain [mailto:rohit.j...@esgyn.com]
Sent: Wednesday, June 7, 2017 9:16 AM
To: 
user@trafodion.incubator.apache.org
Subject: RE: Make "HBase options" as default setting?

Dave,

CQDs indicate that we might make a different decision on these for certain 
customers.  If that is not the case, then we are just increasing the complexity 
of configuring a system with the right default defaults, etc. and opening 
ourselves us for the possibility that something may go wrong.  Often times, 
folks are not even aware as to what is set in the DEFAULTS table and are 
puzzled by the behavior, sometimes because someone added something to that 
table or changed the setting and forgot to set it back, etc.  Then you have to 
document these CQDs, when to change them, etc.  So, while the flexibility of 
having so many buttons may be a good thing to cover all possible 
theoretical combinations one might come up with, from a practical standpoint 
the KISS (Keep It Simple Stupid) principal trumps all.

Rohit

From: Dave Birdsall [mailto:dave.birds...@esgyn.com]
Sent: Wednesday, June 7, 2017 10:44 AM
To: 
user@trafodion.incubator.apache.org
Subject: RE: Make "HBase options" as default setting?

What might make sense is to add a CQD (or maybe a set of them) with default 
values for certain HBASE_OPTIONS settings. Then one could put these CQDs in the 
system DEFAULTS table. So, you’d set it once in a cluster installation and then 
not have to worry about it afterwards.

From: Dave Birdsall
Sent: Wednesday, June 7, 2017 8:26 AM
To: 
user@trafodion.incubator.apache.org
Subject: RE: Make "HBase options" as default setting?

-1  

Re: trafodion query optimization

[Qifan Chen]

Hi Qiao,

Glad to know that the DDL change helped.

I think you can also play with the following for better performance.

   1. CQD parallel_num_esps.  This CQD sets the degree of parallelism to a
   fixed value for all parallel layers (like the layer composed of operator
   1,2 and 3 in the query plan).  It is OK to use the CQD during query
   optimization. In production however, you may consider use a different way
   which is my second point below (item 2). The benefit of *not* using
   CQD parallel_num_esps is that this will allow the compiler to choose the
   parallelism based on data size per layer. Your system resource could be
   better controlled this way.
   2. CQD MAX_ESPS_PER_CPU_PER_OP controls the # of ESPs per node. We
normally allocate 2 ESPs per node (that is the reason there are 6 = 3 * 2
   in the plan). You can alter the CQD MAX_ESPS_PER_CPU_PER_OP to a value so
   that you want maximally X number of ESPs per node (say 4).  The formula for
   the CQD is X / #coresPerNode = X/8. So to boost the degree of parallelism
   from 6 to 12 (or from 2 to 4 ESPs per node), you need to set the CQD to
   4/8=0.5.
   3. From the stats, UID (with total # of distinct value of 8319955) is
   more 'unique' than VID (578912). It will be a good idea to switch the
   position of UID and VID in primary key to favor queries with the search
   condition SID= and V_DATE = and VID=.
   4. The SALT clause (SID, V_DATE, UID, VID) could be reduced to (SID,
   V_DATE, VID) if the above search condition (in item 3) is issued often and
   the expected number of matching rows is small (say less than 200). In this
   case, the compiler may choose a serial plan fragment which is perfect to
   use one ESP to read from one partition where all the matching rows reside.


Thanks --Qifan


LC   RC   OP   OPERATOR  OPT   DESCRIPTION   CARD
       
 -

4.5root
 1.00E+000
3.4sort_partial_aggr_ro
 1.00E+000
2.3esp_exchange1:6(hash2)
 1.00E+000
1.2sort_partial_aggr_le
 1.00E+000
..1trafodion_scan  VISIT_FROM_HIVE
8.03E+006

--- SQL operation complete.



On Tue, Sep 20, 2016 at 12:28 AM, Eric Owhadi <eric.owh...@esgyn.com> wrote:

> I also see that you should not be using DIVISION BY, since your V_DATE are
> already on day boundary. Using DIVISION_BY is counter-productive here.
>
>
>
> And sorry I opened wrong file, I had old and new opened at the same time
> and looked wrong window J, you did change the charset and char length, my
> bad,
>
> Eric
>
> *From:* Eric Owhadi [mailto:eric.owh...@esgyn.com]
> *Sent:* Tuesday, September 20, 2016 12:10 AM
> *To:* '乔彦克' <qya...@gmail.com>; 'user@trafodion.incubator.apache.org' <
> user@trafodion.incubator.apache.org>
> *Cc:* 'dev' <d...@trafodion.incubator.apache.org>; Qifan Chen <
> qifan.c...@esgyn.com>
> *Subject:* RE: trafodion query optimization
>
>
>
> Hi Qiao
>
>
>
> Optimizer picked 6 as DOP. You can force it higher:
>
>
>
> Use
>
> CQD parallel_num_esps ‘12’;
>
> Then prepare and run the query.
>
>
>
> You may experiment with re-generating you table with SALT 15 and CQD
> parallel_num_esps ‘15’.
>
>
>
> you can even draw a curve
>
> SALT 18, parallel_num_esp ‘18’
>
> SALT  21, parallel_num_esps ‘21’
>
> Etc 3 by 3 until you see that performance stop getting better, and
> actually drops.
>
>
>
> I see you did not change VARCHAR to CHAR and did not use Charset ISO88591:
> this is important to optimize row size. UTF8 is very greedy specially for
> PK columns. When I see your sample sid, I wonder if you really need UTF8.
>
>
>
> Same principle apply for the other columns, but less important than for
> key.
>
>
>
> Ultimately you can change the default value of HBASE_OPTIONS BLOCKSIZE
>
> Default is 65565, you can try doubling or quadrupling it. This will
> improve scan rate but crease any query that does random access.
>
>
>
> Also I checked in an experimental feature to allow scanning in parallel
> without using ESP (using multithreading instead), in case memory resource
> consumed by ESP becomes a bottleneck, but I would not recommend it yet as
> it is “experimental” still…
>
> Except if you start seeing memory pressure…
>
> Hope this helps,
> Eric
>
>
>
>
>
>
>
>
>
> *From:* 乔彦克 [mailto:qya...@gmail.com <qya...@gmail.com>]
> *Sent:* Monday, September 19, 2016 11:38 PM
> *To:* user@trafodion.incubator.apache.org
> *Cc:* dev <d...@trafodion.incubator.apache.org>; Eric Owhadi <
> eric.owh...@esgyn.com>; Qifan Chen <qifan.c...@esgyn.com>
> *Subject:* Re: traf

Re: trafodion query optimization

[Qifan Chen]

Hi Qiao,

Thank you for the data. It is very helpful.

There are several things noticed.

   - The key columns are: _SALT_, _DIVISION_1_, SID, V_DATE, UID, VID
   - The salt column is built from column SID only, which means all rows
   with identical SID values V will be stored in the same partition.
   - From the query plan, the compiler assigns 6 executor processes (we
   call ESP) to read the salted table of 12 partitions: 1 ESP reads 2 salt
   partitions.
   - The frequency of V is high when sid='6b2a0957' (~8million rows), all
   these relevant rows are handled by one execution process out of 6. That
   probably is the reason of not much parallelism observed.
   - You can use SQL command *showstats with detail* option to check the
   frequency on column SID.
  - showstats for table TRAFODION.SEABASE.VISIT_FROM_HIVE2 on SID
  detail;
   - If high frequency per unique value on column SID is confirmed, we
   probably should consider our next step of action. For example, we could add
   some columns from the primary key to the SALT clause to help spread V of
   SID to all 12 partitions.

Could you please send us the output of the showstats command above, and the
showstats command below for all columns in the table?

showstats for table TRAFODION.SEABASE.VISIT_FROM_HIVE2 on every column;

Thanks --Qifan

On Mon, Sep 19, 2016 at 3:15 AM, 乔彦克 <qya...@gmail.com> wrote:

> Thanks Eric and Qifan. I am sorry to reply after so long a time because
> I'm on the Chinese mid-autumn festival holiday.
> According to Qifan's advice, I upload a log which contains the DDL and the
> query plan hope to get more advice.
>
> and to Eric, I summit a jira about the block-encoding and the compression,
> https://issues.apache.org/jira/browse/TRAFODION-2195, so I only use the
> hbase compression.
>
> Qifan Chen <qifan.c...@esgyn.com>于2016年9月12日周一 下午10:43写道：
>
>> Hi Qiao,
>>
>> You can also send us the DDL and the query plan to help with the tuning.
>>
>> To generate a query plan, do the following from sqlci, and the plan is in
>> text file mylog.
>>
>>
>>1. log mylog clear;
>>2. prepare xx from ;
>>3. explain xx;
>>4. explain options 'f' xx;
>>5. exit;
>>
>>
>> Thanks --Qifan
>>
>> On Mon, Sep 12, 2016 at 8:21 AM, Eric Owhadi <eric.owh...@esgyn.com>
>> wrote:
>>
>>> Hello Qiao,
>>> When you say whatever the table ddl it limits things a lot, as table ddl
>>> will help define several things that will drastically improve the degree
>>> of
>>> parallelism and the table size.
>>>
>>> The DOP (degree of parallelism) of the scan operator is constrained by
>>> the
>>> number of regions your table uses. So if you want to increase DOP, you
>>> need
>>> to partition your table using the syntax like:
>>> create table customer_demographics_salt
>>> (
>>>  cd_demo_sk int not null
>>>  , cd_gender char(1)
>>>  , cd_marital_status char(1)
>>>  , cd_education_status char(20)
>>>  , cd_purchase_estimate int
>>>  , cd_credit_rating char(10)
>>>  , cd_dep_count int
>>>  , cd_dep_employed_count int
>>>  , cd_dep_college_count int
>>>  , primary key (cd_demo_sk)
>>> )
>>> salt using 12 partitions
>>> ATTRIBUTES ALIGNED FORMAT
>>> HBASE_OPTIONS
>>>   (
>>> DATA_BLOCK_ENCODING = 'FAST_DIFF',
>>> COMPRESSION = 'SNAPPY'
>>>   );
>>>
>>> you can experiment with different values of number of partitions (but
>>> pick a
>>> multiple of 3 since you have 3 nodes).
>>>
>>> Then the optimizer will pick the DOP with a compromise of resource usage
>>> vs
>>> gain in speed.
>>> If you want to force higher DOP than what optimizer selected, you can
>>> use :
>>> CQD parallel_num_esps '12';
>>> To force it to one ESP per partition (assuming you picked 12 partitions).
>>> You can verify what optimizer picked as DOP by doing an explain on the
>>> query.
>>>
>>> Other important factors plays in performance:
>>> - use of aligned format (see above example)
>>> - careful choice of the primary key (bad idea to use a varchar with big
>>> max
>>> size)
>>> - It is good idea to use compression and encoding (see the most common
>>> options we use above)
>>> - you can also increase the HBASE_OPTIONS BLOCKSIZE parameter, but there
>>> is
>>> a drawback: increasing it will increase performance of SCAN but decrease
>>> performance of keyed access. That is why I did not includ

Re: trafodion query optimization

[Qifan Chen]

Hi Qiao,

You can also send us the DDL and the query plan to help with the tuning.

To generate a query plan, do the following from sqlci, and the plan is in
text file mylog.


   1. log mylog clear;
   2. prepare xx from ;
   3. explain xx;
   4. explain options 'f' xx;
   5. exit;


Thanks --Qifan

On Mon, Sep 12, 2016 at 8:21 AM, Eric Owhadi  wrote:

> Hello Qiao,
> When you say whatever the table ddl it limits things a lot, as table ddl
> will help define several things that will drastically improve the degree of
> parallelism and the table size.
>
> The DOP (degree of parallelism) of the scan operator is constrained by the
> number of regions your table uses. So if you want to increase DOP, you need
> to partition your table using the syntax like:
> create table customer_demographics_salt
> (
>  cd_demo_sk int not null
>  , cd_gender char(1)
>  , cd_marital_status char(1)
>  , cd_education_status char(20)
>  , cd_purchase_estimate int
>  , cd_credit_rating char(10)
>  , cd_dep_count int
>  , cd_dep_employed_count int
>  , cd_dep_college_count int
>  , primary key (cd_demo_sk)
> )
> salt using 12 partitions
> ATTRIBUTES ALIGNED FORMAT
> HBASE_OPTIONS
>   (
> DATA_BLOCK_ENCODING = 'FAST_DIFF',
> COMPRESSION = 'SNAPPY'
>   );
>
> you can experiment with different values of number of partitions (but pick
> a
> multiple of 3 since you have 3 nodes).
>
> Then the optimizer will pick the DOP with a compromise of resource usage vs
> gain in speed.
> If you want to force higher DOP than what optimizer selected, you can use :
> CQD parallel_num_esps '12';
> To force it to one ESP per partition (assuming you picked 12 partitions).
> You can verify what optimizer picked as DOP by doing an explain on the
> query.
>
> Other important factors plays in performance:
> - use of aligned format (see above example)
> - careful choice of the primary key (bad idea to use a varchar with big max
> size)
> - It is good idea to use compression and encoding (see the most common
> options we use above)
> - you can also increase the HBASE_OPTIONS BLOCKSIZE parameter, but there is
> a drawback: increasing it will increase performance of SCAN but decrease
> performance of keyed access. That is why I did not include it in the
> example
> above.
>
> Hope this helps,
> Regards,
> Eric
>
>
> -Original Message-
> From: 乔彦克 [mailto:qya...@gmail.com]
> Sent: Monday, September 12, 2016 1:22 AM
> To: user@trafodion.incubator.apache.org; dev@trafodion.incubator.
> apache.org
> Subject: trafodion query optimization
>
> Hi all,
>  I executed the sum and count query on my table where the cluster has
> three nodes. I found that the sum query is not well parallel executed(not
> all the three nodes get high load when executing the sum query) and the cpu
> load is very high while the memory load is very low(the machines have 16
> cores and 16GB memory). My sum query on the 12 million data sets takes
> about
> 2 minutes and a half time.
> So my question is that is there any optimization advice that I can use
> to improve the query performance and maximize the usage of my machines,
> what
> ever the configuration or the table ddl.
> Any replies is appreciated.
>
> Thanks,
> Qiao
>



-- 
Regards, --Qifan

Re: 答复: add a comment to a table

[Qifan Chen]

The implementation probably will be involving the following:

   1. add a new type for column TEXT_TYPE in meta-table
   TRAFODION."_MD_".TEXT, say COMMENT_TYPE;
   2. allow COMMENT ON syntax in the parser;
   3. convert the content of COMMENT ON stmt into insertion/update of a
   row(s) in the TEXT meta-data table for the SQL object in question;
   4. write a UDF to show the comment easily for a SQL object, by hiding
   the join of the meta-data TEXT and OBJECTS table.

The task may be a little bit involving :-).

Thanks  --Qifan

On Fri, Apr 1, 2016 at 1:30 AM, Liu, Ming (Ming)  wrote:

> Shall we file a JIRA to track this requirement?
>
>
>
> Thanks,
>
> Ming
>
>
>
> *发件人:* Suresh Subbiah [mailto:suresh.subbia...@gmail.com]
> *发送时间:* 2016年4月1日 11:54
> *收件人:* user@trafodion.incubator.apache.org
> *主题:* Re: add a comment to a table
>
>
>
> Hi,
>
>
>
> I do not think Trafodion currently supports Oracle's COMMENT ON syntax
>
> *https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_4009.htm
> *
>
>
>
> *It will be a relatively simple feature to add but we do not have it today
> as far as I know.*
>
>
>
> *Thank you*
>
> *Suresh*
>
>
>
>
>
> On Thu, Mar 31, 2016 at 9:56 PM, yongqiang.z...@microinsight.com.cn <
> yongqiang.z...@microinsight.com.cn> wrote:
>
> Hi , all,
>
>
>
>
>
> I want to add a comment to a table,like the use of oracle"
> comment on table tablename
> is annotate", How to use jdbc way to implement it?
>
>
>
>
>
>
>
>
> --
>
> yongqiang.z...@microinsight.com.cn
>
>
>



-- 
Regards, --Qifan

Re: MDAM on index

[Qifan Chen]

The scan optimizer picks the MDAM scan or subset scan based on the *cost*.
For MDAm to win, the  low UEC on the leading key columns is a
pre-condition.

Thanks --Qifan

On Mon, Mar 28, 2016 at 10:23 AM, Rohit  wrote:

> And remember, the key available for MDAM in a secondary index includes
> both the secondary index columns followed by the primary key columns, or
>  c3, c4, c1, c2 in this case.  Same MDAM rules should apply to the
> secondary index as the clustering index since its a clustering index too.
>
> Rohit
>
>
>  Original message 
> From: Dave Birdsall 
> Date: 03/28/2016 10:12 AM (GMT-06:00)
> To: user@trafodion.incubator.apache.org
> Subject: RE: MDAM on index
>
> Hi,
>
>
>
> In principle at least, MDAM should be possible with Query 2. Whether it is
> a good plan or not depends on many things: If the UEC of column c3 is high,
> then MDAM on the index on C4 may not be a good choice. If the query
> accesses other columns in the base table besides c3 and c4, then there is
> an extra join using index access which raises the cost. It still might be a
> good plan though. For example, if there is a highly selective predicate on
> c3 and c4, resulting in just a few accesses to the base table then it still
> may be good. Your mileage will vary.
>
>
>
> Dave
>
>
>
> *From:* Liu, Ming (Ming) [mailto:ming@esgyn.cn]
> *Sent:* Monday, March 28, 2016 5:12 AM
> *To:* user@trafodion.incubator.apache.org
> *Subject:* MDAM on index
>
>
>
> Hi, all,
>
>
>
> If we are creating a table t(c1,c2,c3,c4,,c5, primary key(c1,c2)) and then
> create an index indx on t(c3,c4).
>
> Query 1: select * from t where c2 =10;
>
> Query 2: select * from t where c4 = 10;
>
> I think Query 1 will use MDAM, can Query 2 use MDAM to access indx as well?
>
>
>
> Thanks,
>
> Ming
>
>
>



-- 
Regards, --Qifan

Re: Upsert semantics

[Qifan Chen]

I agree omitting default values from storage is an optimization and as such it 
should provide the same UPSERT semantics as with other storage 
formats/optimizations.

Specially our code could insert default value checking expression to verify 
that an value is exact the same as the default value and omit it for storage 
(extra overhead), or insert/update otherwise.

The other option would be not checking the default value at all and allow mixed 
storage model for default values (fast upsert but some extra storage overhead).

Any change on the handling of CURRENT defaults should still stick  to ANSI. 

Thanks

-Qifan

Sent from my iPhone

> On Mar 18, 2016, at 7:23 AM, Suresh Subbiah  
> wrote:
> 
> Hi,
> 
> To me upsert has meant a faster performing version of insert, with duplicate 
> key errors ignored. I would claim that most users are drawn towards upsert 
> since it performs better than insert.
> I do not think compatibility with Phoenix syntax is an important requirement. 
> As everyone has said we would not want a statement to have different 
> semantics depending on row format.   
> I do not quite understand why an omitted CURRENT default is treated 
> differently from other omitted defaults, so I could see the last column in 
> the first row below also being transformed to "Replace the given columns", 
> but this I do feel is not crucial. Whichever is easier for us to implement as 
> long as it is defined should be sufficient.
> 
> 
> With these principles in mind my vote would be for the proposal Hans gave 
> above.
> 
> I am sorry for not stating my opinion clearly during review. 
> 
> Thank you
> Suresh
> 
>  Aligned FormatAligned 
> format withNon-Aligned with Non-Aligned with
> 
>With no omittedomitted 
> columns   with no omitted   omitted current 
> default
> 
> columns   
>  / omitted non-current columns
> 
>  
> 
> CQD off  Replaces row  MERGE  
>Replace the given columns MERGE
> 
> CQD on (default) Replaces row  Replaces 
> rowReplace all columns  Replace all columns   
>
> 
> 
> 
> 
> 
> 
> 
> 
>> On Thu, Mar 17, 2016 at 4:58 PM, Selva Govindarajan 
>>  wrote:
>> Here is what I found with phoenix, just to compare with phoenix’s behavior 
>> for upsert.
>> 
>>  
>> 
>> Phoenix expects the table to have a primary key. Upsert specification is
>> 
>> Inserts if not present and updates otherwise the value in the table. The 
>> list of columns is optional and if not present, the values will map to the 
>> column in the order they are declared in the schema. The values must 
>> evaluate to constants.
>> 
>> create table phoenix.testtbl (c1 integer not null primary key, c2 integer , 
>> c3 integer) ;
>> upsert into phoenix.testtbl (c1, c2)  values (1,1) ;
>> upsert into phoenix.testtbl (c1,c3)  values (1,1) ;
>> upsert into phoenix.testtbl (c1,c2)  values (1,null) ;
>>  
>> 0: jdbc:phoenix:localhost:51670> select * from phoenix.testtbl ;
>> +--+--+--+
>> |C1|C2   
>>  |C3|
>> +--+--+--+
>> | 1| null
>>  | 1|
>> +--+--+--+
>>  
>> In the raw hbase table, I see the following cells after the above 3 upserts. 
>> It looks like phoenix deletes the cell if it updated with null value.
>>  
>> hbase(main):006:0> scan 'PHOENIX.TESTTBL'
>> ROW  COLUMN+CELL 
>>  
>>
>>  \x80\x00\x00\x01column=0:C3, 
>> timestamp=1458249350858, value=\x80\x00\x00\x01  
>>   
>>  \x80\x00\x00\x01column=0:_0, 
>> timestamp=1458249392491, value=  
>>   
>> 1 row(s) in 0.0210 seconds
>>  
>> 
>> Selva
>> 
>>  
>> 
>> From: Dave Birdsall [mailto:dave.birds...@esgyn.com] 
>> Sent: Thursday, March 17, 2016 11:09 AM
>> 
>> 
>> To: user@trafodion.incubator.apache.org

Re: [VOTE] Apache Trafodion Logo Proposal

[Qifan Chen]

+1 for 13.

On Thu, Feb 18, 2016 at 8:34 PM, Trina Krug  wrote:

> +1 for 13
>
> Trina
>
> On Feb 18, 2016, at 6:01 PM, Roberta Marton 
> wrote:
>
> There has been quite a lot of discussion on our user list regarding the
> proposed Apache Trafodion logos.
>
> It has now come time for a formal vote on the two most popular logos
> fondly known as  4g and 13.
>
> Both have been attached for your reference
>
>
>
> Please respond as follows:
>
>
>
> [ ] +1-4g approve option 4g
>
> [ ] +1-13 approve option 13
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove (and reason why)
>
>
>
> The vote will be open for 72 hours.
>
>
>
>Regards,
>
>Roberta Marton
>
>
>
> 
>
> 
>
>


-- 
Regards, --Qifan

Re: 答复: 答复: 答复: Logo Proposal

[Qifan Chen]

:c...@esgyn.com]
> *Sent:* Friday, February 12, 2016 7:59 AM
> *To:* user@trafodion.incubator.apache.org
> *Cc:* Rohit Jain <rohit.j...@esgyn.com>; Gunnar Tapper <
> tapper.gun...@gmail.com>
> *Subject:* RE: Logo Proposal
>
>
>
> It seems we might need multiple votes:
>
> -  One color or multiple colors?
>
> -  Thin font or thick font?
>
> -  One font or two fonts?
>
> -  Apache or not…
>
>
>
> What was Selva saying about engineers and votes? J
>
> -clr
>
>
>
>
>
> *From:* Amanda Moran [mailto:amanda.mo...@esgyn.com]
> *Sent:* Friday, February 12, 2016 7:21 AM
> *To:* user@trafodion.incubator.apache.org
> *Cc:* Rohit <rohit.j...@esgyn.com>; Gunnar Tapper <tapper.gun...@gmail.com
> >
> *Subject:* Re: Logo Proposal
>
>
>
> -1 all same color.
>
>
>
> I still like option 4 the way it was/is but I can understand wanting to
> remove Apache  But I still like it the way it is
>
>
>
> Sent from my iPhone
>
>
> On Feb 12, 2016, at 7:15 AM, Qifan Chen <qifan.c...@esgyn.com> wrote:
>
> But is it obvious that Trafodion is an Apache project, if one starts to
> read about it?
>
>
>
> On Fri, Feb 12, 2016 at 8:48 AM, Rohit <rohit.j...@esgyn.com> wrote:
>
> It depends on how much value you think Apache adds to Trafodion, as
> compared to those other logos that perhaps already have some cachet.  I
> feel that it adds quite a bit of value to Trafodion.
>
>
>
> Rohit
>
>
>
>  Original message 
> From: Qifan Chen <qifan.c...@esgyn.com>
> Date: 02/12/2016 8:34 AM (GMT-06:00)
> To: user@trafodion.incubator.apache.org
>
> Cc: Gunnar Tapper <tapper.gun...@gmail.com>
> Subject: Re: Logo Proposal
>
> I wonder if we could also consider a mod to option 4 where only the dragon
> and the word trafodion are present. See the two images attached.
>
>
>
> I sampled a couple apache project logs and found they do not have the word
> APACHE in their logos (e.g., HIVE, MONGODB, AVRO, SPARK).
>
>
>
> With this approach, it is possible to put the Trafodion logo into the
> "power by Apache" logo, see URL here
> <http://www.apache.org/foundation/press/kit/>, without the duplication of
> "Apache".
>
>
>
> It also simplifies the design and allows a good focus.
>
>
>
> Thanks --Qifan
>
>
>
> On Fri, Feb 12, 2016 at 7:19 AM, Rohit <rohit.j...@esgyn.com> wrote:
>
> -1
>
>
>
> Check out the other logos I sent to the internal dlist.
>
>
>
> Rohit
>
>
>
>  Original message 
> From: Gunnar Tapper <tapper.gun...@gmail.com>
> Date: 02/12/2016 12:50 AM (GMT-06:00)
> To: user@trafodion.incubator.apache.org
> Subject: Re: Logo Proposal
>
> Hi,
>
>
>
> I suggest that we limit the number of colors used.
>
>
>
> A simple change:
> https://drive.google.com/open?id=0BxlwNhWxn8iTT3NNMTZ0dmhqQm8
>
>
>
> Thanks,
>
>
>
> Gunnar
>
>
>
> On Thu, Feb 11, 2016 at 8:52 PM, Trina Krug <trina.k...@gmail.com> wrote:
>
> Option 4!!
>
>
>
> Trina
>
>
> On Feb 11, 2016, at 7:05 PM, Carol Pearson <carol.pearson...@gmail.com>
> wrote:
>
> Slightly late to the party, but +1 on option 4 as well.  Though I would
> prefer a slightly less formal font, the one in option 6 is too spaced out
> and I'm not fond of it overall...
>
>
>
> But that's really a nit and this is infinitely better than no logo at
> all
>
>
>
> Thanks Ken!
>
>
>
> -Carol P.
>
>
> ---
>
> Email:carol.pearson...@gmail.com
>
> Twitter:  @CarolP222
>
> ---
>
>
>
> On Thu, Feb 11, 2016 at 5:41 PM, Gunnar Tapper <tapper.gun...@gmail.com>
> wrote:
>
> Neither. Keep the font the same for Apache and Trafodion. Bold them both.
>
>
>
> On Thu, Feb 11, 2016 at 4:16 PM, Sandhya Sundaresan <
> sandhya.sundare...@esgyn.com> wrote:
>
> Perhaps we should try and see how lowercase with both placements look. The
> dragon on top looks better to many. We can take votes again J
>
>
>
> *From:* Wei-Shiun Tsai [mailto:wei-shiun.t...@esgyn.com]
> *Sent:* Thursday, February 11, 2016 3:13 PM
>
>
> *To:* user@trafodion.incubator.apache.org
> *Subject:* RE: Logo Proposal
>
>
>
> +1 for Dave’s and Hans’ suggestion.  Like the dragon to sit on the right,
> not on top of Trafodion.  But the font in #4 looks more professional
> (pe

Re: Logo Proposal

[Qifan Chen]

I wonder if we could also consider a mod to option 4 where only the dragon
and the word trafodion are present. See the two images attached.

I sampled a couple apache project logs and found they do not have the word
APACHE in their logos (e.g., HIVE, MONGODB, AVRO, SPARK).

With this approach, it is possible to put the Trafodion logo into the
"power by Apache" logo, see URL here
, without the duplication of
"Apache".

It also simplifies the design and allows a good focus.

Thanks --Qifan

On Fri, Feb 12, 2016 at 7:19 AM, Rohit  wrote:

> -1
>
> Check out the other logos I sent to the internal dlist.
>
> Rohit
>
>
>  Original message 
> From: Gunnar Tapper 
> Date: 02/12/2016 12:50 AM (GMT-06:00)
> To: user@trafodion.incubator.apache.org
> Subject: Re: Logo Proposal
>
> Hi,
>
> I suggest that we limit the number of colors used.
>
> A simple change:
> https://drive.google.com/open?id=0BxlwNhWxn8iTT3NNMTZ0dmhqQm8
>
> Thanks,
>
> Gunnar
>
> On Thu, Feb 11, 2016 at 8:52 PM, Trina Krug  wrote:
>
>> Option 4!!
>>
>> Trina
>>
>> On Feb 11, 2016, at 7:05 PM, Carol Pearson 
>> wrote:
>>
>> Slightly late to the party, but +1 on option 4 as well.  Though I would
>> prefer a slightly less formal font, the one in option 6 is too spaced out
>> and I'm not fond of it overall...
>>
>> But that's really a nit and this is infinitely better than no logo at
>> all
>>
>> Thanks Ken!
>>
>> -Carol P.
>>
>> ---
>> Email:carol.pearson...@gmail.com
>> Twitter:  @CarolP222
>> ---
>>
>> On Thu, Feb 11, 2016 at 5:41 PM, Gunnar Tapper 
>> wrote:
>>
>>> Neither. Keep the font the same for Apache and Trafodion. Bold them both.
>>>
>>> On Thu, Feb 11, 2016 at 4:16 PM, Sandhya Sundaresan <
>>> sandhya.sundare...@esgyn.com> wrote:
>>>
 Perhaps we should try and see how lowercase with both placements look.
 The dragon on top looks better to many. We can take votes again J



 *From:* Wei-Shiun Tsai [mailto:wei-shiun.t...@esgyn.com]
 *Sent:* Thursday, February 11, 2016 3:13 PM

 *To:* user@trafodion.incubator.apache.org
 *Subject:* RE: Logo Proposal



 +1 for Dave’s and Hans’ suggestion.  Like the dragon to sit on the
 right, not on top of Trafodion.  But the font in #4 looks more professional
 (perhaps also in lower case).



 Weishiun



 *From:* Dave Birdsall [mailto:dave.birds...@esgyn.com]
 *Sent:* Thursday, February 11, 2016 3:04 PM
 *To:* user@trafodion.incubator.apache.org
 *Subject:* RE: Logo Proposal



 Hi,



 I like the font for option 4 (perhaps lower cased as Hans mentioned),
 but with the placement of option 6.



 That said, either one is fine.



 Dave



 *From:* Eric Owhadi [mailto:eric.owh...@esgyn.com]
 *Sent:* Thursday, February 11, 2016 3:02 PM
 *To:* user@trafodion.incubator.apache.org
 *Subject:* RE: Logo Proposal



 +1 option 4



 *From:* Anuradha Hegde [mailto:anuradha.he...@esgyn.com]
 *Sent:* Thursday, February 11, 2016 4:57 PM
 *To:* user@trafodion.incubator.apache.org
 *Subject:* RE: Logo Proposal



 +1 option 4



 *From:* Ken Holt [mailto:knhknhknh...@gmail.com]
 *Sent:* Thursday, February 11, 2016 2:51 PM
 *To:* user@trafodion.incubator.apache.org
 *Subject:* Re: Logo Proposal



 Seems like the dragon logo itself is a winner - most everyone liked
 that.

 But the combined logo and name was definitely not popular.



 Here are a couple of new suggestions for the combined logo and name.



 Option 4


 https://drive.google.com/file/d/0B9c1EkzsNnw4T3o3YVBDakNtQkU/view?usp=sharing



 Option 6


 https://drive.google.com/file/d/0B9c1EkzsNnw4Y082OHhNNXBwazA/view?usp=sharing



 Don't ask for options 1-3, & 5 - they didn't make it passed my limited
 field testing!

 Comments on 4 & 6?



 Cheers, Ken



 On Tue, Feb 9, 2016 at 4:03 PM, Sandhya Sundaresan <
 sandhya.sundare...@esgyn.com> wrote:

 I’d say there is enough “curliness” going on with the dragon. So  we
 could try with a simple bold font  . Perhaps with an outline of a different
 color like Hadoop’s/Mahouts is and tie it in with the dragon’s colors as
 well.



 *From:* Hans Zeller [mailto:hans.zel...@esgyn.com]
 *Sent:* Tuesday, February 9, 2016 3:46 PM


 *To:* user@trafodion.incubator.apache.org
 *Subject:* Re: Logo Proposal