Elasticsearch Mapping parameters(主要参数一览)

Stella981
• 阅读 580

Elasticsearch在创建类型映射时可以指定映射参数,下面将一一进行介绍。

analyzer

指定分词器。elasticsearch是一款支持全文检索的分布式存储系统,对于text类型的字段,首先会使用分词器进行分词,然后将分词后的词根一个一个存储在倒排索引中,后续查询主要是针对词根的搜索。

analyzer该参数可以在查询、字段、索引级别中指定,其优先级如下(越靠前越优先):

  1. 字段上定义的分词器

  2. 索引配置中定义的分词器

  3. 默认分词器(standard)

在查询上下文,分词器的查找优先为:

  1. full-text query中定义的分词器

  2. 定义类型映射时字段中search_an
    alyzer定义的分词器

  3. 定义字段映射时analyzer定义的分词器

  4. 索引中default_search中定义的分词器

  5. 索引中默认定义的分词器

  6. 标准分词器(standard)

normalizer

规划化,主要针对keyword类型,在索引该字段或查询字段之前,可以先对原始数据进行一些简单的处理,然后再将处理后的结果当成一个词根存入倒排索引中,举例如下:

 1PUT index 2{ 3  "settings": { 4    "analysis": { 5      "normalizer": { 6        "my_normalizer": {                                    // @1 7          "type": "custom", 8          "char_filter": [], 9          "filter": ["lowercase", "asciifolding"]             // @210        }11      }12    }13  },14  "mappings": {15    "_doc": {16      "properties": {17        "foo": {18          "type": "keyword",19          "normalizer": "my_normalizer"                      // @320        }21      }22    }23  }24}
  1. 代码@1:首先在settings中的analysis属性中定义normalizer。

  2. 代码@2:设置标准化过滤器,示例中的处理器为小写、asciifolding。

  3. 代码@3:在定义映射时,如果字段类型为keyword,可以使用normali
    zer引用定义好的normalizer。

boost

权重值,可以提升在查询时的权重,对查询相关性有直接的影响,其默认值为1.0。其影响范围为词根查询(team que-ry),对前缀、范围查询、全文索引(match query)不生效。

注意:不建议在创建索引映射时使用boost属性,而是在查询时通过boost参数指定。其主要原因如下:

  1. 无法动态修改字段中定义的boost值,除非使用reindex命令重建索引。

  2. 相反,如果在查询时指定boost值,每一个查询都可以使用不同的boost值,灵活。

  3. 在索引中指定boost值,boost存储在记录中,从而会降低分数计算的质量。

coerce

是否进行类型“隐式转换”。es最终存储文档的格式是字符串。
例如存在如下字段类型:

1"number_one": {2   "type": "integer"3}

声明number_one字段的类型为数字类型,那是否允许接收“6”字符串形式的数据呢?因为在JSON中,“6”是可以用来赋给int类型的字段。默认coerce为tru-e,表示允许这种赋值,但如coerce设置为false,此时es只能接受不带双引号的数字,如果在coerce=false时,将“6”赋值给number_one时会抛出类型不匹配异常。

可以在创建索引时指定默认的coerce值,示例如下:

1PUT my_index2{3  "settings": {4    "index.mapping.coerce": false5  },6  "mappings": {7    // 省略字段映射定义8  }9}

copy_to

copy_to参数允许您创建自定义的_all字段。换句话说,多个字段的值可以被复制到一个字段.例如,将first_name和la-st_name字段复制到full_name,其具体实现如下:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "first_name": { 7          "type": "text", 8          "copy_to": "full_name"  9        },10        "last_name": {11          "type": "text",12          "copy_to": "full_name" 13        },14        "full_name": {15          "type": "text"16        }17      }18    }19  }20}

表示字段full_name的值来自first_nam-e+last_name。

关于copy_to重点说明:

  1. 字段的复制是原始值,而不是分词后的词根。

  2. 复制字段不会包含在_souce字段中,但可以使用复制字段进行查询。

  3. 同一个字段可以复制到多个字段,写法如下:"copy_to": [ "field_1", "field_2" ]

doc_values

当需要对一个字段进行排序时,es需要提取匹配结果集中的排序字段值集合,然后进行排序。倒排索引的数据结构对检索来说相当高效,但对排序就不那么擅长了。

业界对排序、聚合非常高效的数据存储格式首推列式存储,在elasticsearch中,doc_values就是一种列式存储结构,绝大多数数据类型doc_values默认为ture,即在索引时会将字段的值(或分词后的词根序列)加入到倒排索引中,同时也会该字段的值加入doc_values中,所有该类型的索引下该字段的值用一列存储。

doc_values的使用示例:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "status_code": {  7          "type":       "keyword"      // 默认情况下,“doc_values”:true 8        }, 9        "session_id": { 10          "type":       "keyword",11          "doc_values": false12        }13      }14    }15  }16}

dynamic

是否允许动态的隐式增加字段。在执行index api或更新文档API时,对于_sour-ce字段中包含一些原先未定义的字段采取的措施,根据dynamic的取值,会进行不同的操作:

  • true,默认值,表示新的字段会加入到类型映射中。

  • false,新的字段会被忽略,即不会存入_souce字段中,即不会存储新字段,也无法通过新字段进行查询。

  • strict,会显示抛出异常,需要新使用put mapping api先显示增加字段映射。

可以通过put mapping api对dynamic值进行更新。

举例说明:

 1PUT my_index/_doc/1  2{ 3  "username": "johnsmith", 4  "name": { 5    "first": "John", 6    "last": "Smith" 7  } 8} 9PUT my_index/_doc/2              // @110{11  "username": "marywhite",12  "email": "mary@white.com",13  "name": {14    "first": "Mary",15    "middle": "Alice",16    "last": "White"17  }18}19GET my_index/_mapping  // @2

代码@1在原有的映射下,增加了user-name,name.middle两个字段,通过代码@2获取映射API可以得知,es已经为原本不存在的字段自动添加了类型映射定义。

注意:dynamic只对当前层级具有约束力,例如:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "dynamic": false,         // @1 6      "properties": { 7        "user": {                    // @2 8          "properties": { 9            "name": {10              "type": "text"11            },12            "social_networks": {    // @313              "dynamic": true,14              "properties": {}15            }16          }17        }18      }19    }20  }21}

代码@1:_doc类型的顶层不能不支持动态隐式添加字段映射。
代码@2:但_doc的嵌套对象user对象,是支持动态隐式添加字段映射。
代码@3:同样对于嵌套对象social_n-etworks,也支持动态隐式添加字段映射。

enabled

enabled属性,用来对映射类型(_type)和object类型的字段来启用或禁用索引功能,如果enabled属性设置为false,表示只存储,但不创建索引,意味者无法使用该字段的值进行查询。

示例如下:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "user_id": { 7          "type":  "keyword" 8        }, 9        "last_updated": {10          "type": "date"11        },12        "session_data": { 13          "enabled": false14        }15      }16    }17  }18}1920PUT my_index/_doc/session_121{22  "user_id": "kimchy",23  "session_data": { 24    "arbitrary_object": {25      "some_array": [ "foo", "bar", { "baz": 2 } ]26    }27  },28  "last_updated": "2015-12-06T18:20:22"29}

上述示例,es会存储session_data对象的数据,但无法通过查询API根据sessi-on_data中的属性进行查询。

同样,可以通过put mapping api更新enabled属性。

eager_global_ordinals

全局序列号,它以字典顺序为每个唯一的术语保持递增的编号。

全局序号只支持字符串类型(关键字和文本字段)。

在关键字字段中,全局序列号默认可以开启,但文本字段只能fielddata=true时才能开启。

doc_values(和fielddata)也有序号,是特定段(segment)和字段中所有词根的唯一编号。全局序号只是在此之上构建的,它提供了段序号(segment ordin-als)和全局序号(global ordinals)之间的映射,全局序号在整个分片中是唯一的。

由于每个字段的全局序号与一个分片的所有段相关联,因此当一个新的segme-nt(段)变为可见时,需要完全重新构建它们。

术语聚合依懒全局序号,首先在分片级别执行聚合,然后汇聚所有分片的结果(reduce)并将全局序号转换为真正的词根,合并后返回聚合的结果。

默认情况下,全局序号是在搜索时加载的,这对提高索引API的速度会非常有利。但是,如果您更加重视搜索性能,那么在您计划使用的聚合的字段上设置eager_global_ordinals,会对提高查询效率更有帮助。eager_global_o-rdinals的意思是预先加载全局序号。

其示例如下:

1PUT my_index/_mapping/_doc2{3  "properties": {4    "tags": {5      "type": "keyword",6      "eager_global_ordinals": true7    }8  }9}

fielddata

为了解决排序与聚合,elasticsearch提供了doc_values属性来支持列式存储,但doc_values不支持text字段类型。因为text字段是需要先分析(分词),会影响doc_values列式存储的性能。

Elasticsearch为了支持文本字段高效排序与聚合,引入了一种新的数据结构(fielddata),使用内存进行存储。

默认是在第一次聚合查询、排序操作时构建,主要存储倒排索引中的词根与文档的映射关系,聚合、排序操作在内存中执行。因此fielddata需要消耗大量的JVM堆内存。一旦fielddata加载到内存后,它将永久存在。

通常情况下,加载fielddata是一个昂贵的操作,故默认情况下,文本类型的字段默认是不开启fielddata机制。在使用fielddata之前请慎重考虑其必要性。

通常text字段用来进行全文搜索,对于聚合、排序字段,建议使用doc_values机制。

为了节省内存的使用,es提供了另一项机制(fielddata_frequency_filter),允许只加载那些词根频率在指定范围(最大,小值)直接的词根与文档的映射关系,最大最小值可以指定为绝对值,例如数字,也可以基于百分比(百分比的计算是基于整个分段(segment),其频率分母不是分段(segment)中所有的文档,而是segment中该字段有值的文档)。

可以通过min_segment_size参数来指定分段中必须包含的最小文档数量来排除小段,也就是说可以控制fielddata_freq-uency_filter的作用范围是包含大于min_-segment_size的文档数量的段。

fielddata_frequency_filter的使用示例如下:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "tag": { 7          "type": "text", 8          "fielddata": true, 9          "fielddata_frequency_filter": {10            "min": 0.001,11            "max": 0.1,12            "min_segment_size": 50013          }14        }15      }16    }17  }18}

format

在JSON文档中,日期表示为字符串。Elasticsearch使用一组预先配置的格式来识别和解析这些字符串,并将其解析为long类型的数值(毫秒)。
日期格式主要包括如下3种方式:

  • 自定义格式

  • date mesh(已在DSL查询API中详解)

  • 内置格式

自定义格式

首先可以使用java定义时间的格式,例如:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "date": { 7          "type":   "date", 8          "format": "yyyy-MM-dd HH:mm:ss" 9        }10      }11    }12  }13}

date mesh

某些API支持,已在DSL查询API中详细介绍过,这里不再重复。

内置格式

elasticsearch为我们内置了大量的格式,如下:

  • epoch_millis
    时间戳,单位,毫秒。

  • epoch_second
    时间戳,单位,秒。

  • date_optional_time
    日期必填,时间可选,其支持的格式如下:

  • basic_date
    yyyyMMdd

  • basic_date_time
    yyyyMMdd'T'HHmmss.SSSZ

  • basic_date_time_no_millis
    yyyyMMdd'T'HHmmssZ

  • basic_ordinal_date
    4位数的年 + 3位(day of year),其格式字符串为yyyyDDD

  • basic_ordinal_date_time
    yyyyDDD'T'HHmmss.SSSZ

  • basic_ordinal_date_time_no_millis
    yyyyDDD'T'HHmmssZ

  • basic_time
    HHmmss.SSSZ

  • basic_time_no_millis
    HHmmssZ

  • basic_t_time
    'T'HHmmss.SSSZ

  • basic_t_time_no_millis
    'T'HHmmssZ

  • basic_week_date
    xxxx'W'wwe,4为年 ,然后用'W', 2位week of year(所在年里周序号)1位 day of week。

  • basic_week_date_time
    xxxx'W'wwe'T'HH:mm:ss.SSSZ.

  • basic_week_date_time_no_millis
    xxxx'W'wwe'T'HH:mm:ssZ.

  • date
    yyyy-MM-dd

  • date_hour
    yyyy-MM-dd'T'HH

  • date_hour_minute
    yyyy-MM-dd'T'HH:mm

  • date_hour_minute_second
    yyyy-MM-dd'T'HH:mm:ss

  • date_hour_minute_second_fraction
    yyyy-MM-dd'T'HH:mm:ss.SSS

  • date_hour_minute_second_millis
    yyyy-MM-dd'T'HH:mm:ss.SSS

  • date_time
    yyyy-MM-dd'T'HH:mm:ss.SSS

  • date_time_no_millis
    yyyy-MM-dd'T'HH:mm:ss

  • hour
    HH

  • hour_minute
    HH:mm

  • hour_minute_second
    HH:mm:ss

  • hour_minute_second_fraction
    HH:mm:ss.SSS

  • hour_minute_second_millis
    HH:mm:ss.SSS

  • ordinal_date
    yyyy-DDD,其中DDD为 day of year。

  • ordinal_date_time
    yyyy-DDD‘T’HH:mm:ss.SSSZZ,其中DDD为 day of year。

  • ordinal_date_time_no_millis
    yyyy-DDD‘T’HH:mm:ssZZ

  • time
    HH:mm:ss.SSSZZ

  • time_no_millis
    HH:mm:ssZZ

  • t_time
    'T'HH:mm:ss.SSSZZ

  • t_time_no_millis
    'T'HH:mm:ssZZ

  • week_date
    xxxx-'W'ww-e,4位年份,ww表示week of year,e表示day of week。

  • week_date_time
    xxxx-'W'ww-e'T'HH:mm:ss.SSSZZ

  • week_date_time_no_millis
    xxxx-'W'ww-e'T'HH:mm:ssZZ

  • weekyear
    xxxx

  • weekyear_week
    xxxx-'W'ww,其中ww为week of year。

  • weekyear_week_day
    xxxx-'W'ww-e,其中ww为week of year,e为day of week。

  • year
    yyyy

  • year_month
    yyyy-MM

  • year_month_day
    yyyy-MM-dd,温馨提示,日期格式时,es建议在上述格式之前加上strict_前缀。

ignore_above

超过ignore_above设置的字符串不会被索引或存储。对于字符串数组,将分别对每个数组元素应用ignore_above,超过ignore_above的字符串元素将不会被索引或存储。目前测试的结果为:对于字符串字符长度超过ignore_above会存储,但不索引(也就是无法根据该值去查询)。其测试效果如下:

 1public static void create_mapping_ignore_above() {   // 创建映射 2        RestHighLevelClient client = EsClient.getClient(); 3        try { 4            CreateIndexRequest request = new CreateIndexRequest("mapping_test_ignore_above2"); 5            XContentBuilder mapping = XContentFactory.jsonBuilder() 6                    .startObject() 7                        .startObject("properties") 8                            .startObject("lies") 9                                .field("type", "keyword")      // 创建关键字段10                                .field("ignore_above", 10)     // 设置长度不能超过1011                            .endObject()12                        .endObject()13                    .endObject();1415//            request.mapping("user", mapping_user);16            request.mapping("_doc", mapping);17            System.out.println(client.indices().create(request, RequestOptions.DEFAULT));18        } catch (Throwable e) {19            e.printStackTrace();20        } finally {21            EsClient.close(client);22        }23    }2425    public static void index_mapping_ignore_above() {  // 索引数据26        RestHighLevelClient client = EsClient.getClient();27        try {28            IndexRequest request = new IndexRequest("mapping_test_ignore_above2", "_doc");29            Map<String, Object> data = new HashMap<>();30            data.put("lies", new String[] {"dingabcdwei","huangsw","wuyanfengamdule"});31            request.source(data);32            System.out.println(client.index(request, RequestOptions.DEFAULT));33        } catch (Throwable e) {34            e.printStackTrace();35        } finally {36            EsClient.close(client);37        }38    }3940public static void search_ignore_above() {  // 查询数据41        RestHighLevelClient client = EsClient.getClient();42        try {43            SearchRequest searchRequest = new SearchRequest();44            searchRequest.indices("mapping_test_ignore_above2");45            SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();46            sourceBuilder.query(47                    // QueryBuilders.matchAllQuery()    // @148                    // QueryBuilders.termQuery("lies", "dingabcdwei")  // @249                    // QueryBuilders.termQuery("lies", "huangsw")      // @350            ); 51            searchRequest.source(sourceBuilder);52            SearchResponse result = client.search(searchRequest, RequestOptions.DEFAULT);53            System.out.println(result);54        } catch (Throwable e) {55            e.printStackTrace();56        } finally {57            EsClient.close(client);58        }59    }

代码@1:首先查询所有数据,其_sou-ce字段的值为:"_source":{"lies":["dingabcdwei","huangsw","wuyanfengamdule"]},表名不管字符串的值是否大于ignore_above指定的值,都会存储。
代码@2:用超过ignore_above长度的值尝试去搜索,发现无法匹配到记录,表明并未加入到倒排索引中。
代码@3:用未超过ignore_above长度的值尝试去搜索,发现能匹配到记录。
注意:在es中,ignore_above的长度是字符的长度,而es其底层实现lucene是使用字节进行计算的,故,如果要反馈到lucnce,请注意关系。

ignore_malformed

试图将错误的数据类型索引到字段中,默认情况下会抛出异常,并拒绝整个文档。ignore_malformed参数,如果设置为真,允许错误被忽略。格式不正确的字段不建立索引,但是文档中的其他字段正常处理。该参数也可以在创建索引时通过index.mapping.ignore_malformed来配置索引级别的默认值,其优先级为字段级、索引级。

index

定义字段是否索引。

  • true:代表索引,默认值。

  • false表示不索引(则无法通过该字段进行查询)。

index_options

控制文档添加到反向索引的额外内容,其可选择值如下:

  • docs:文档编号添加到倒排索引。

  • freqs:文档编号与访问频率。

  • positions:文档编号、访问频率、词位置(顺序性),proximity 和phrase queries 需要用到该模式。
    = offsets:文档编号,词频率,词偏移量(开始和结束位置)和词位置(序号),高亮显示,需要设置为该模式。

默认情况下,被分析的字符串(analyz-ed string)字段使用positions,其他字段使用docs;

fields

fields允许对同一索引中同名的字段进行不同的设置,举例说明:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "city": { 7          "type": "text",        // @1 8          "fields": {              // @2 9            "raw": { 10              "type":  "keyword"   // @311            }12          }13        }14      }15    }16  }17}

@1:上述映射为city字段,定义类型为text,使用全文索引。
@2:为city定义多字段,city.raw,其类型用keyword。

主要就可以用user进行全文匹配,也可以用user.raw进行聚合、排序等操作。另外一种比较常用的场合是对该字段使用不同的分词器。

norms

字段的评分规范,存储该规范信息,会提高查询时的评分计算效率。

虽然规范对计分很有用,但它也需要大量磁盘(通常是索引中每个字段的每个文档一个字节的顺序,甚至对于没有这个特定字段的文档也是如此)。

从这里也可以看出,norms适合为过滤或聚合的字段。

注意,可以通过put mapping api 将nor-ms=true更新为norms=false,但无法从false更新到true。

null_value

将显示的null值替换为新定义的额值。用如下示例做一个说明:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "status_code": { 7          "type":       "keyword", 8          "null_value": "NULL"             // @1 9        }10      }11    }12  }13}1415PUT my_index/_doc/116{17  "status_code": null                     // @218}1920PUT my_index/_doc/221{22  "status_code": []                       // @323}2425GET my_index/_search26{27  "query": {28    "term": {29      "status_code": "NULL"               // @430    }31  }32}

代码@1:为status_code字段定义"NU-LL"为空值null;
代码@2:该处,存储在status_code为  null_value中定义的值,即"NULL"
代码@3:空数组不包含显式null,因此不会被null_value替换。
代码@4:该处查询,会查询出文档1。其查询结果如下:

 1{ 2    "took":4, 3    "timed_out":false, 4    "_shards":{ 5        "total":5, 6        "successful":5, 7        "skipped":0, 8        "failed":0 9    },10    "hits":{11        "total":1,12        "max_score":0.2876821,13        "hits":[14            {15                "_index":"mapping_test_null_value",16                "_type":"_doc",17                "_id":"RyjGEmcB-TTORxhqI2Zn",18                "_score":0.2876821,19                "_source":{20                    "status_code":null21                }22            }23        ]24    }25}

null_value具有如下两个特点:

  • null_value需要与字段的数据类型相同。例如,一个long类型的字段不能有字符串null_value。

  • null_value只会索引中的值(倒排索引),无法改变_souce字段的值。

position_increment_gap

针对多值字段,值与值之间的间隙。举例说明:

 1PUT my_index 2{ 3  "mappings": { 4    "_doc": { 5      "properties": { 6        "names": { 7          "type": "text", 8          "position_increment_gap": 0      // @1 9          // "position_increment_gap": 10  // @210        }11      }12    }13  }14}1516PUT my_index/_doc/117{18    "names": [ "John Abraham", "Lincoln Smith"]19}

names字段是个数组,也即ES中说的多值字段。

当position_increment_gap=0时,es的默认使用标准分词器,分成的词根为:
position    0   :  john
position    1   :  abraham
position    2   :  lincoln
position    3   :  smith

当position_increment_gap = 10时,es使用默认分词器,分成的词根为:
position    0   :  john
position    1   :  abraham
position    11   :  lincoln  这是第二个词,等于上一个词的position + pos-ition_increment_gap。
position    12   :  smith

针对如下下查询:

1GET my_index/_search2{3    "query": {4        "match_phrase": {5            "names": "Abraham Lincoln" 6        }7    }8}

针对position_increment_gap=0时,能匹配上文档,如果position_increment_gap=10,则无法匹配到文档,因为abraham与lincoln的位置相差10,如果要能匹配到该文档,需要在查询时设置slop=10,该参数在前面的DSL查询部分已详细介绍过。

properties

为映射类型创建字段定义。

search_analyzer

通常,在索引时和搜索时应用相同的分析器,以确保查询中的术语与反向索引中的术语具有相同的格式,如果想要在搜索时使用与存储时不同的分词器,则使用search_analyzer属性指定,通常用于ES实现即时搜索(edge_ngram)。

similarity

指定相似度算法,其可选值:

  • BM25
    当前版本的默认值,使用BM25算法。

  • classic
    使用TF/IDF算法,曾经是es,lucene的默认相似度算法。

  • boolean
    一个简单的布尔相似度,当不需要全文排序时使用,并且分数应该只基于查询条件是否匹配。布尔相似度为术语提供了一个与它们的查询boost相等的分数。

store

默认情况下,字段值被索引以使其可搜索,但它们不存储。这意味着可以查询字段,但无法检索原始字段值。通常这并不重要。字段值已经是_source字段的一部分,该字段默认存储。

如果您只想检索单个字段或几个字段的值,而不是整个_source,那么这可以通过字段过滤上下文(source filting context来实现,在某些情况下,存储字段是有意义的。

例如,如果您有一个包含标题、日期和非常大的内容字段的文档,您可能只想检索标题和日期,而不需要从大型_sou-rce字段中提取这些字段,es还提供了另外一种提取部分字段的方法stored_field-s。

stored_fields只支持字段的store定义为ture,该部分内容已经在Elasticsearch Doc api时,_souce过滤部分详细介绍过,这里不过多介绍。

term_vector

term_vector包含分析过程产生的术语的信息,包括:

  • 术语列表。

  • 每一项的位置(或顺序)。

  • 开始和结束字符偏移量。

term_vector可取值:

  • no
    不存储term_vector信息,默认值。

  • yes
    只存储字段中的值。

  • with_positions
    存储字段中的值与位置信息。

  • with_offsets
    存储字段中的值、偏移量

  • with_positions_offsets
    存储字段中的值、位置、偏移量信息。

Elasticsearch Mapping 参数就介绍到这里了。


更多文章请关注微信公众号:

Elasticsearch Mapping parameters(主要参数一览)

本文分享自微信公众号 - 中间件兴趣圈(dingwpmz_zjj)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
Jacquelyn38 Jacquelyn38
2年前
2020年前端实用代码段,为你的工作保驾护航
有空的时候,自己总结了几个代码段,在开发中也经常使用,谢谢。1、使用解构获取json数据let jsonData  id: 1,status: "OK",data: 'a', 'b';let  id, status, data: number   jsonData;console.log(id, status, number )
皕杰报表之UUID
​在我们用皕杰报表工具设计填报报表时,如何在新增行里自动增加id呢?能新增整数排序id吗?目前可以在新增行里自动增加id,但只能用uuid函数增加UUID编码,不能新增整数排序id。uuid函数说明:获取一个UUID,可以在填报表中用来创建数据ID语法:uuid()或uuid(sep)参数说明:sep布尔值,生成的uuid中是否包含分隔符'',缺省为
Stella981 Stella981
2年前
Elasticsearch Mapping之字段类型(field datatypes)
ElasticSearch支持如下数据类型:基本类型string(字符串类型)字符串类型包含text与keyword两种类型。1.text文本类型,在索引文件中,存储的不是原字符串,而是使用分词器对内容进行分词处理后得到一系列的词根,然后一一存储在index的倒排索引中。text类型支持如下
Easter79 Easter79
2年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Stella981 Stella981
2年前
Django中Admin中的一些参数配置
设置在列表中显示的字段,id为django模型默认的主键list_display('id','name','sex','profession','email','qq','phone','status','create_time')设置在列表可编辑字段list_editable
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
Stella981 Stella981
2年前
ELK学习笔记之ElasticSearch的索引详解
0x00ElasticSearch的索引和MySQL的索引方式对比Elasticsearch是通过Lucene的倒排索引技术实现比关系型数据库更快的过滤。特别是它对多条件的过滤支持非常好,比如年龄在18和30之间,性别为女性这样的组合查询。倒排索引很多地方都有介绍,但是其比关系型
Python进阶者 Python进阶者
3个月前
Excel中这日期老是出来00:00:00,怎么用Pandas把这个去除
大家好,我是皮皮。一、前言前几天在Python白银交流群【上海新年人】问了一个Pandas数据筛选的问题。问题如下:这日期老是出来00:00:00,怎么把这个去除。二、实现过程后来【论草莓如何成为冻干莓】给了一个思路和代码如下:pd.toexcel之前把这