, Es performance optimization is no silver bullet, what does it mean? Just do not look forward to readily adjust a parameter, you can deal with all of the Almighty slow performance scene. Maybe some scenes you change parameters or adjust the syntax, you can get, but definitely not all scenes are like this.
To analyze it piece by piece
In this scenario of massive data, how to improve the performance of search es, but also our environment prior to production resulting experience
(1) Performance Optimization killer --filesystem cache
os cache, the operating system's cache
Es to you to write data actually written to the disk file to go, and disk data in the file operating system will automatically inside the data cache to go inside os cache
es search engine is heavily dependent on the underlying filesystem cache, if more memory to your filesystem cache, try to make the memory can accommodate all indx segment file index data file, so when you search on the go basically memory, performance It will be very high.
The performance gap can be large, and before we test a lot of pressure measurement, if the disk to go on a general affirmation seconds, search performance is definitely the second level, 1 second, 5 seconds, 10 seconds. But if it is to go filesystem cache, taking a pure memory, then the general disk performance than go to an order of magnitude, basically millisecond, ranging from a few milliseconds to a few hundred milliseconds.
Before there is a student, I've been asked that his search performance, polymerization performance, inverted index, a positive index, disk file, ten seconds. . . .
Students real case
For example, you, es node has three machines, each machine, it seems a lot of memory, 64G, total memory, 64 * 3 = 192g
Each machine is to es jvm heap 32G, then the rest to leave the filesystem cache of each machine is only 32g, to a total cluster filesystem cache is 32 * 3 = 96g memory
I asked him, ok, so your data is written to the cluster es how much the amount of data?
If you are at this time, your whole, the index data file on disk, on three machines, taking up a total disk capacity of 1T, your es the amount of data is 1t, the amount of data each machine is 300g
Do you think your performance can be okay? filesystem cache memory only 100g, you can put one-tenth of the data memory, the rest are in the disk, and then you perform a search operation, most of the operations are taking disk, performance is certainly poor
Then their situation is like this, es in the test, get three machines, feel pretty good, 64G memory physical machine. I think they can hold the amount of data of 1T.
Ultimately, you have to let es performance is better, the best case, is your machine's memory, you can fit at least half of the total amount of data
For example, you want to store a total of 1T data in es, then your multiple machines to leave a filesystem cache memory integrated together, at least until 512G, at least half of the cases, the search is to take the memory, performance can generally be to several seconds, 2 seconds, 3 seconds, 5 seconds
If the best case, our own production experience, so that we had the strategy is just to keep in es small amount of data that you want to use those indexes to search, left filesystem cache memory, and on the 100G, then you control within 100gb, equivalent, almost all of your data go to search for memory, performance is very high, generally in less than one second
For example, you now have a line of data
id name age .... 30 fields
But now you search, you only need to search by id name age three fields
If you silly row of data is written to all of the fields in es, saying it will lead to 70% of the data is not used to search, the results simply take up space on the filesystem cache es machine, the greater the amount of data singled data the less will lead to filesystem cahce can cache data
Just write a few fields in which you want to retrieve es can, for example, is written es id name age three fields on it, then you can put other fields exist inside the mysql data, we generally is recommended es + hbase of such a framework.
hbase feature is applicable to online storage of massive data, that is, hbase can write huge amounts of data, do not do complex searches, it is to do some very simple operation such a query based on the id or scope on it
The name and age to search from es, the results might get id DOC 20, and then go hbase id to query the complete data for each corresponding DOC id, to check out, return to the leading end according to the doc.
Es you write data is preferably less than or equal, or slightly larger than the es filesystem cache memory capacity
Then you may spend es retrieved from 20ms, and then query based on id's return to hbase es, 20 check data, may also spend a 30ms, the original so you might play, 1T data is put es, will each queries are 5 to 10 seconds, will now be high performance, each inquiry is 50ms.
elastcisearch reduce the amount of data to be used to search only put a few key fields can try with the amount of data written es es machine filesystem cache is almost on it; others do not have to retrieve the data put hbase years, or mysql.
So before some students also asked, I also told them that, as far es, the data is stored must be used to search, for example, you now have a copy of the data, there are 100 field, in fact, used to search for only 10 fields, 10 is the recommended data fields, into es, the remaining 90 data fields, you can put mysql, hadoop hbase, can
In this case, es small amount of data, 10 data fields, you can put a memory, it is used to search, search out some of the id, id go through mysql, hbase which to query data details of
(2) preheating Data
If you say, even if you do it in accordance with the above scheme, the amount of data written to each machine in the cluster es or exceed the filesystem cache doubled, for example, you write a machine data 60g, 30g on the results filesystem cache , there are 30g data left on the disk.
For example, they say, microblogging, you can put some big v, usually see a lot of people ahead of your own data to the back-end system put forward, every moment, your own back-office systems to search thermal data, brush go to the filesystem cache, back when the user actually look at this hot data, they are search directly from memory, and soon.
Electricity supplier, you can usually see the most of some commodities, such as iphone 8, the heat ahead of the background data to put forward a program, every minute access time on their own initiative, brush filesystem cache to go.
For data that you think is hot, often someone visits, it is best to do a special pre-caching subsystem, the thermal data is, every once in a while, you'll visit in advance and let the data into the filesystem cache to go inside . Such people look forward to the next visit, be sure the performance will be better.
(3) cold separator
About es performance optimization, data split, I would say a large number of fields are not searched, split to go to another store, this is similar to the back of my last talk about mysql vertical split sub-library sub-table before.
es split level similar to mysql can do, that will access a large number of small, very low frequency data, write a single index, and then write a separate index to access the data very frequently hot
You'd better write data to a cold index, then the data is written to another heat index, which ensures data after being preheated hot, try to let them stay in the filesystem os cache inside, do not let the cold data to washed away.
Look, suppose you have six machines, two indexes, a data allowed to cool, a heat data, each shard index 3
3 exotherm machine index data; 3 additional data allowed to cool machines index
Then this is the case, a lot of the time you are accessing hot data index, thermal data probably 10% of the total amount of data, at this time the amount of data is small, almost all remain in the filesystem cache inside, you can ensure access to hot data performance is very high.
But for cold data, is in the other index, the data with the heat index is no longer the same machine, we have no touch with each other. If someone visits the cold data, it may be a lot of data on the disk, in which case the performance handicap, 10% of people go to visit the cold data; 90% of people accessing data in the heat.
(4) document model design
Many students ask me, mysql, there are two tables
Orders table: id order_code total_price
1 Test Order 5000
Order entry table: id order_id goods_id purchase_count price
1 1 1 2 2000
2 1 2 5 200
I mysql where all select * from order join order_item on order.id = order_item.order_id where order.id = 1
1 Test Order 500011122000
1 Test Order 50002125200
How to play at es, the complex relationship es inside queries, complex query syntax, try not to use, once with the performance generally not very good
Es in the design of the data model
When written es, the two into an index, order index, orderItem index
order index, which contains id order_code total_price
orderItem index, which when written into, join operations complete, id order_code total_price id order_id goods_id purchase_count price
es of java system writes, the association is complete, the data is written directly associated with good es, the time of the search, there is no need to use search syntax es to accomplish join the search for
model design document is very important, many operations do not only want to perform a complicated mess of various operations at the time of the search. es to support the operation is so much to do something do not consider it a bad operation with es. If you really have that kind of operation, as far as possible when document model design, when the write is complete. In addition to some of the very complex operations, such as join, nested, parent-child search should be avoided, performance is poor.
Many students ask me, a lot of complicated mess of some operations, how to perform
Two ideas, search / query time, especially complex operations to be performed strongly related to some business:
1) When data is written, it is a good design model, plus several fields, plus the processed data is written inside the field
2) used java program package, es do, do with es, search out the data, do it in java program which, for example, we, es based java package with some special complex operations
(5) Performance Optimization tab
Paging es is relatively pit, so why then? To give an example, if you are 10 data per page, and you now want to query on page 100, in fact, before 1000 the data stored on each shard would have found on a coordinator node, if you have a 5 a shard, then there is 5000 data, then the coordinator node some of these 5000 data merge process, and then get to the final 10 on page 100 of the data.
Distributed, you have to check 10 on page 100 of the data, you can not say is from 5 shard, each shard to check 2 data? Finally, the coordinator node merged into 10 data? You have to check all the data came from 1000 for each shard, and then sorted according to your needs, screening, etc. operations, the last page again, to get the data inside on page 100.
You turn the pages, turn the deeper, the more each shard data returned, and the longer the coordinator node processing. Very pit father. So do pagination with es, you will find more turn back, the more slowly.
Before we also encountered this problem, use es as paging, the first few pages to tens of milliseconds, after turn 10, when dozens of pages, basically going from 5 to 10 seconds to check out a page of data
1) does not allow the depth of sort / paging default depth miserable performance
Your system does not allow him to turn the page so deep, pm, default turn deeper, worse performance
2) similar to the app in the Testimonials continue to drop down out page by page
Like microblogging, microblogging drop-down brush, brush out page by page, you can scroll api, themselves Baidu
scroll will give you generate a one-time snapshot of all the data, and then move the cursor through each page is to get nextnext this way, the performance than the kind of page says a lot of high performance
To address this issue, you can consider to be treated with scroll, scroll principle is actually reserved a snapshot of the data, and then within a certain time, if you continue to slide back flip when you are browsing similar to microblogging constantly refresh flip down. Then scroll through a cursor with a continuous access to data Next, this performance is very high, much better than the actual es page.
But the only thing is, this is suitable for the kind of pull-down flip of a similar microblogging and can not jump to any page of the scene. While the scroll is to retain data for a period of time snapshot, you need to ensure that users are not constantly flip turn a few hours.
No matter how many pages turn, basically millisecond performance
Because scroll api is only one page next turn, and can not say, first enter the page 10, then go 120 back to 58 and can not bounce page. So now many products, you are not allowed to randomly flip, app, there are some sites, you can only do is pull down, turn page by page