Drought cavity be out of tune

• After the IP-CM project is finished, it is very difficult to write a SAO article, even if you forget what features you did? For example: you get a new change requirement to locate the corresponding code, the mind of a hundred thousand grass mud horse, who wrote the code really f * * king bad, followed by the code directly above, comments this bug made in Jiang Shuai; Anyway, I’m not embarrassed. It’s the code.

• Elasticsearch is the most popular QA service for Elasticsearch.

Directory:

Article purpose: the form of question and answer, trample pits to share

• 1. Pit for ElasticSearch installation (cut account startup, extranet access, permission control)
• 2. Pit selected for ElasticSearch version
• 3.ElasticSearch supports data structures, Object and NestObject pits
• 4. Flexible form entity design, Mapping needs to be created in advance, otherwise it will be a pit
• 5. Specific code typing a little tired, to be continued…

Get to the point

Bug # 1: ElasticSearch install pit

• Pit 1: Create account attention! Es startup is not allowed to use the root account to start, so we need to create another account and give it the corresponding authority useradd esuser

• Pit 2: # must be assigned permissions, or you will quote no permissions error chown -r esuser: esuser/data/elasticsearch/elasticsearch – 5.6.8

#切换账号 su esuser#启动 ES ./elasticsearch &

• Enter the configuration file and change the value of network.host to 0.0.0.0. Because it is a YML file, you must pay attention to the format.

• Max file Descriptors [4096] for ElasticSearch process is too low, increase to at least [65536]

Each process maximum at the same time open the file number is too small, can through the following two commands to view the current number of ulimit – Hn ulimit – Sn modify/etc/security/limits file, increase the configuration, take effect after the user login again

•           soft    nofile          65536
  Copy the code

•           hard    nofile          65536
  Copy the code

Pits for ElasticSearch data types Object and NestObject

NestObject is the basic data structure supported by ElasticSearch. NestObject is the basic data structure supported by ElasticSearch. NestObject is the basic data structure supported by ElasticSearch. But something dramatic happened. We use ES to store the following JSON string

To create the mapping

Insert data

Select * from * where age = 37 and name = YanXi;

But here’s the result: “Nani, I got it all, ES hot chicken stuff.”

This is because the json document we passed in above is stored in one document, and the above insert is actually converted to:

What to do? !!!!! That’s where the Nested type comes in

As expected, the query was not found, and the result was verified correctly:

Pit selected for ElasticSearch version

1.ES has been released in 7.x version so far. There are great changes from 6.x version to 7.x version, and some functions and APIS have been changed; So the question is, how to choose the appropriate version, is the latest version of the better? In fact, most of our current applications are using Springboot as the integration framework, so there are advantages, I recommend a small tip. After the data-ElasticSearch dependency is introduced, SpringBoot automatically selects an appropriate ElasticSearch version based on the spring-boot-starter-parent version number.

<dependency>

    <groupId>org.springframework.boot</groupId>

    <artifactId>spring-boot-starter-data-elasticsearch</artifactId>

</dependency>

Copy the code

This way we can happily choose the appropriate ES version, and if the project requires an IK participle, we need to match the IK version with it.

1. It has to be said that all the design in the early stage of development is very difficult, not only to meet the existing demand, but also considering the maintainability of the data in the later stage combined with the actual business volume. Since Mysql is a good place for programmers, let’s talk about the design of using Mysql

The design of the Mysql

Here is only demo is not the point, the front end is dead page, the back end is flexible, of course, there are many design methods for the details of the first query, {“name”:” jiang “,”age”:”16″,”sex”: male}

But what about paging queries by field criteria like this? Do you also have to create a table for query fields, which seems a bit lame?

If the front end is also not fixed, you need to set up a T_field_config table to maintain all the fields so that you can render all the form controls on the detail page

In the previous article, I said that using a relational database Mysql must be a pit if the business fields are not fixed.

Back to business: ElasticSearch or Mysql is a database that uses a specific field as an index or query, and the field must be fixed within the entity. This is not the same as flexible forms with variable fields. For example, although everyone is different, they always have eyes, nose and mouth, right? So regression design, is it possible that fields in a form generally have English attribute names, Chinese aliases and field values? We go forward based on this idea.

In this case, we design the entity, in short, want to do a general module, it must connect each application system, so the use of appID to distinguish applications, the use of module ID to distinguish functional modules in the application, of course, including public field creation and modification of the time, people, whether to delete, no more talk, directly paste code

@Document(indexName = "qaindex".type = "qatype")

public class QAEsCommonModel{

    @Id

    private Long id;

/ / application

    @Field(type = FieldType.keyword)

    private String appId;

/ / module

    @Field(type = FieldType.keyword)

    private String moduleId;



    @Field(type = FieldType.keyword)

    private String createName;



    @Field(type = FieldType.keyword)

    private String createTime;



    @Field(type = FieldType.keyword)

    private Integer isDeleted;



// Flexible field collection

    @Field(type = FieldType.Nested)

    private List<CommonParam> commonParamList;

}

Copy the code

@Data

@ToString

@AllArgsConstructor

@NoArgsConstructor

public class CommonParam {

/ * *

* Field names such as: sex

* /

    @Field(type = FieldType.keyword)

    private String property;



/ * *

* Field aliases such as gender

* /

    @Field(type = FieldType.keyword)

    private String alias;



/ * *

* Field values (need word segmentation, need to participate in the full text index such as: title, answer, etc.)

* /

    @Field(analyzer = "ik_max_word".type = FieldType.text)

    private String textValue;



/ * *

* Field value (no word segmentation required)

* /

    @Field(type = FieldType.keyword)

    private String keywordValue;

}

Copy the code

@Document(indexName = “qaindex”, type = “qatype”)

• Qaindex: database
• Qatype (); qatype (); qatype (); qatype ()