Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537 Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537
.你是如何理解HTML語義的?
答:使用合適的標簽標示內容。優點在于標簽語義化有利于搜索引擎建立索引進行抓 取,有助于構建良好的HTML結構,便于團隊開發和維護。
2.meta viewport 是做什么用的,怎么寫?
答:meta表示不能被HTML的其它元素(link,script,base, style, title)之一表示的任何元素信息。viewpoint讓web開發者控制視口的尺寸及比例,移動設備的viewpoint指設備屏幕上用來展示網頁的那一塊區域,也就是瀏覽器上用來展示網頁的那部分,可能比瀏覽器的可視區大,也可能比瀏覽器可視區域小,一般情況,比瀏覽器可視區域大。屬性包括width、height、initial-scale、maximum-scale、minimum-scale,使用方式是
<meta name="viewpoint" content="width=device-width, initial-scale=1, maximum-scale=1">
3.canvas 元素是干什么的?
答: canvas是用來繪制圖形的HTML元素。
4.html5新特性?如何處理HTML5新標簽的瀏覽器兼容問題?如何區分 HTML 和 HTML5?
答:html5新特性:
解決兼容性的方法:
<!--[if lt IE 9]> <script> src="http://html5shim.googlecode.com/svn/trunk/html5.js"</script> <![endif]-->
HTML和HTML5
html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional //EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml">
html5:
<!doctype html>
<div id="header"></div>
html5: 具有結構語義
<header></header>
5.Doctype作用?標準模式與兼容模式各有什么區別?
答: Doctype是document type(文檔類型),告訴瀏覽器解析器采用哪種規范(html、xhtml)來解析頁面,Doctype不存在或格式錯誤的情況下,采用兼容模式。
標準模式(嚴格模式)展示的支持最新標準的網頁。兼容模式(松散模式或怪異模式)展示的是兼顧傳統瀏覽器的網頁,向后兼容老式瀏覽器。
具體區別:
6.用戶訪問頁面到最終渲染的整個過程?
用戶輸入url,瀏覽器向服務器發送請求,獲取html,然后進入HTML渲染機制。首先,根據HTML生成DOM樹;其次,根據css和js重排頁面 https://segmentfault.com/a/1190000009317496
7.你對頁面進行性能優化的思路和思想是什么?
答: 減少http請求; 減少DOM操作,避免不必要的重繪和重排;壓縮文件體積;采用CDN;
在實際的生產環境中,一個field的設置是不能被修改的,如果要修改一個Field,那么應該重新按照新的mapping,建立一個index,然后將數據批量查詢出來,重新用bulk api寫入index中。
批量查詢的時候,建議采用scroll api,并且采用多線程并發的方式來reindex數據。例如說每次scoll就查詢指定日期的一段數據,交給一個線程即可。
(1) 一開始,依靠dynamic mapping,插入數據,但是不小心有些數據是2019-09-10這種日期格式的,所以title這種field被自動映射為了date類型,實際上它應該是string類型的。
首先插入以下數據
PUT /my_index/_doc/1
{
"title": "2019-09-10"
}
PUT /my_index/_doc/2
{
"title": "2019-09-11"
}
(2)當后期向索引中加入string類型的title值的時候,就會報錯
PUT /my_index/_doc/3
{
"title": "my first article"
}
報錯
{
"error": {
"root_cause": [
{
"type": "mapper_parsing_exception",
"reason": "failed to parse field [title] of type [date] in document with id '3'. Preview of field's value: 'my first article'"
}
],
"type": "mapper_parsing_exception",
"reason": "failed to parse field [title] of type [date] in document with id '3'. Preview of field's value: 'my first article'",
"caused_by": {
"type": "illegal_argument_exception",
"reason": "failed to parse date field [my first article] with format [strict_date_optional_time||epoch_millis]",
"caused_by": {
"type": "date_time_parse_exception",
"reason": "Failed to parse with all enclosed parsers"
}
}
},
"status": 400
}
(3)如果此時想修改title的類型,是不可能的
PUT /my_index/_mapping
{
"properties": {
"title": {
"type": "text"
}
}
}
報錯
{
"error": {
"root_cause": [
{
"type": "illegal_argument_exception",
"reason": "mapper [title] of different type, current_type [date], merged_type [text]"
}
],
"type": "illegal_argument_exception",
"reason": "mapper [title] of different type, current_type [date], merged_type [text]"
},
"status": 400
}
(4)此時,唯一的辦法,就是進行reindex,也就是說,重新建立一個索引,將舊索引的數據查詢出來,再導入新索引。
(5)如果說舊索引的名字,是old_index,新索引的名字是new_index,終端java應用,已經在使用old_index在操作了,難道還要去停止java應用,修改使用的index為new_index,才重新啟動java應用嗎?這個過程中,就會導致java應用停機,可用性降低。
(6)所以說,給java應用一個別名,這個別名是指向舊索引的,java應用先用著,java應用先用prod_index來操作,此時實際指向的是舊的my_index
PUT /my_index/_alias/prod_index
(7)查看別名,會發現my_index已經存在一個別名prod_index了。
GET my_index/_alias
(8)新建一個index,調整其title的類型為string
PUT /my_index_new
{
"mappings": {
"properties": {
"title": {
"type": "text"
}
}
}
}
(9)使用scroll api將數據批量查詢出來
GET /my_index/_search?scroll=1m
{
"query": {
"match_all": {}
},
"size": 1
}
返回
{
"_scroll_id" : "DXF1ZXJ5QW5kRmV0Y2gBAAAAAAAARUMWQWx5bzRmTW9TeUNpNmVvN0E2dF9YQQ==",
"took" : 4,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 2,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "my_index",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"title" : "2019-09-10"
}
}
]
}
}
(9)采用bulk api將scoll查出來的一批數據,批量寫入新索引
POST /_bulk
{"index":{"_index":"my_index_new","_id":"1"}}
{"title":"2019-09-10"}
(10)反復循環8~9,查詢一批又一批的數據出來,采取bulk api將每一批數據批量寫入新索引
(11)將my_index索引的別名prod_index切換到my_index_new上去,java應用會直接通過index別名使用新的索引中的數據,java應用程序不需要停機,零提交,高可用
POST /_aliases
{
"actions": [
{
"remove": {
"index": "my_index",
"alias": "prod_index"
}
},
{
"add": {
"index": "my_index_new",
"alias": "prod_index"
}
}
]
}
(12)直接通過prod_index別名來查詢,是否ok
GET prod_index/_search
可以看到能夠查詢到新索引my_index_new的數據了
{
"took" : 1117,
"timed_out" : false,
"_shards" : {
"total" : 1,
"successful" : 1,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : {
"value" : 1,
"relation" : "eq"
},
"max_score" : 1.0,
"hits" : [
{
"_index" : "my_index_new",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"title" : "2019-09-10"
}
}
]
}
}
基于alias對client透明切換index
PUT /my_index_v1/_alias/my_index
client對my_index進行操作
reindex操作,完成之后,切換v1到v2
POST /_aliases
{
"actions": [
{ "remove": { "index": "my_index_v1", "alias": "my_index" }},
{ "add": { "index": "my_index_v2", "alias": "my_index" }}
]
}
原文地址:https://www.cnblogs.com/xiaoyh/p/16028045.html
????此賬號為華為云開發者社區官方運營賬號,提供全面深入的云計算前景分析、豐富的技術干貨、程序樣例,分享華為云前沿資訊動態
本文分享自華為云社區《GaussDB(for MySQL)如何快速創建索引?華為云數據庫資深架構師為您揭秘》,作者:華為云數據庫資深架構師蘇斌。
蘇斌,華為云數據庫資深架構師,擁有16年數據庫內核研發經驗,之前作為MySQL官方InnoDB團隊主要研發人員,參與和主導了多個重要特性的開發和發布。目前在華為公司負責和參與華為云RDS主要產品RDS for MySQL和GaussDB(for MySQL)內核功能的設計和研發。
我們都知道,數據庫使用索引技術加快數據的查詢。MySQL數據庫也支持若干種索引結構提高查詢的性能(參見MySQL文檔:https://dev.mysql.com/doc/refman/8.0/en/create-index.html),其中使用最廣泛的是B+tree索引,因為B+tree索引在查詢和修改的性能之間有很好的平衡,同時其存儲和維護的代價也是比較優的。
MySQL的表本身由聚簇索引(必須是B+tree索引)表示,再加上若干個二級索引,包括B+tree索引,共同組成一個MySQL的獨立表,可以說MySQL的表是由一組索引共同組成的。我們都知道索引是一把雙刃劍,充分的索引可以更好地提升可以適配的查詢的性能,但是需要維護這些索引使得其和數據同步,所以在數據修改操作階段,更多的索引也會帶來更高的開銷。索引創建與否的權衡通常是動態的,用戶不一定能做到在表定義之初就知道需要建立哪些索引,需要隨著業務的發展變化而調整索引,這也帶來了動態索引創建的一些問題。
我們先看一下MySQL索引創建的邏輯。首先,MySQL索引的創建可以使用兩種不同的DDL(Data Definition Language: 數據定義語言)算法來實現。第一種是COPY算法,它非常低效,就是在兩個表之間進行數據拷貝,來完成表結構相關的修改,尤其是它要求加表鎖,現在基本不使用了。第二種是INPLACE算法,該算法不要求加鎖,因此很多DDL操作是不阻塞DML(Data ManipulationLanguage: 數據操縱語句)操作的,比如創建索引。該算法具體的實現在存儲引擎層面完成,可以進行更多的優化。實際上DDL語句還有一種INSTANT算法,但是它無法支持創建索引操作,這里不展開介紹。
對于INPLACE算法,在5.7版本之前,是采用索引記錄不斷地向建好的空索引插入的方式。由于插入的數據的無序性,該方法導致了明顯的性能問題和潛在的空間浪費。在5.7版本以后,MySQL優化了建索引步驟,將其改進為對已排序的索引記錄進行自底向上批量插入并且緊湊拼裝的創建方式,如果有多個索引要創建,會單獨對每個索引執行相同的算法。新的算法會經歷讀取數據、排序數據和創建索引這幾個主要步驟。
總體而言,創建索引這類DDL操作,會比普通的DML等操作要費時,而該類DDL耗時會導致用戶在繼續動態添加索引加速查詢的時候,需要等待很長的時間,極大影響業務;而且用戶的MySQL實例開啟了Binlog復制,耗時的DDL操作容易引起備庫的長時間落后。
MySQL的創建索引流程圖
隨著越來越多用戶把數據托管在云服務上,以及用戶數據量的不斷增長,前述的動態添加索引導致的問題非常影響用戶體驗。同時客戶的單表數據逐漸達到幾TB甚至幾十TB,客戶對創建索引太慢所帶來的性能問題的抱怨越來越多,尤其是創建索引周期如果太長,我們可能很難找到一段合適的業務低峰期來動態創建索引,避免業務的波動。因此,如何在云服務環境下,解決客戶基于大量數據創建索引的性能問題,成為云服務廠商的一個挑戰。
在云化場景下,還有一個主要場景對客戶的體驗非常重要。我們知道客戶的業務要遷移上云,需要對數據進行大規模的遷移(華為云提供了數據復制服務DRS工具支持各類數據遷移場景),數據遷移比較高效的方式為:
1)邏輯導出源端數據
2)在目標端建表(注意,表不含二級索引)
3)將源端導出的數據插入到目標端
4)對目標端的表建立二級索引
如果涉及動態數據同步,相關步驟會更復雜一些,由于和該主題無關,這里不展開。以上步驟中,需要重點注意的是步驟2和4,在目標端創建表的時候先不創建二級索引。這個優化對性能影響很大,尤其是一個表有很多二級索引的場景。我們知道Btree索引的插入如果是有序的,對插入性能和結果的空間利用率是最好的,因為Btree索引的分裂會在插入區域的尾部產生,同時由于分裂算法的優化,分裂產生的頁面填充率會比較高;相反地,如果是隨機插入,尤其是并發地隨機插入,很容易導致Btree索引在不同的節點進行分裂,并且分裂后的頁面填充率都處于一個半滿的狀態,導致Btree最終的一個膨脹。
有了這個背景之后,我們就容易理解上面的問題,插入表數據的時候,我們屏蔽了二級索引,等所有數據都準備好了,再采用批量建立索引的方式創建二級索引,這對于二級索引創建效率是最高的。如果不這么做,每插入一條記錄,就要去插入相應的二級索引,那么二級索引就是一個無序的隨機插入,并發起來性能會變差很多。
雖然在數據同步準備好后,批量創建二級索引是一個有效的方案,但是如果數據量很大,這么創建二級索引還是非常耗時,導致客戶在數據遷移完之后需要等待很長時間才能開展業務,這個等待周期可能是小時甚至天級別的。雖然可以考慮表級別的并發創建索引,但是這個方法也有明顯的缺點:應用場景有限,要求有多表;以及表和表之間的并發其實不是一個最有效的并發形式,相互影響比較大。
綜上所述,在創建索引這個點上存在兩個性能瓶頸點:一個是用戶遷移數據之后的批量索引創建;第二個是用戶臨時需要添加一個二級索引。無論哪個點,我們都需要更快的建立好索引,提升用戶的使用體驗。
華為云GaussDB(for MySQL)引入了并行創建索引的技術,它改進了社區版MySQL創建索引只用單線程的問題,以此提高創建索引的效率,并一起解決了前述兩個痛點。前面提到的社區版創建索引邏輯是單線程的,首先存在資源利用率不夠飽滿的問題;其次創建索引過程是CPU和IO開銷交替進行的過程,在做一個操作的時候,即使不是資源競爭的操作也只有等待。多線程創建索引可以充分利用CPU和IO資源,同時有的線程在做CPU計算時,別的線程可以并發的做IO操作。
GaussDB(for MySQL)使用的并行創建索引,是一個全鏈路的并行技術。前面提到,創建索引包含了若干個階段,我們的并行創建算法,對這里的每個階段都做并行處理,從讀取數據、排序、到創建索引,都是并行操作,每一步都由指定的N個線程并發處理。它的邏輯如下圖所示:
GaussDB(for MySQL)尤其對數據的歸并排序做了多種優化,使得我們常規的歸并排序能夠充分的并行,充分利用CPU、內存和IO的資源。在并行創建索引之后的合并步驟,也使用了一套簡化的算法,正確處理各種索引結構的場景。
GaussDB(for MySQL)的并行創建索引功能,目前支持的索引為Btree二級索引。對于virtual index二級索引,將會在不久的將來提供全面的支持,而MySQL的spatial index和fulltext index不在該并行創建索引覆蓋范圍內。
特別要注意的是,主鍵索引的創建目前也是不支持并行的,因此如果一個并行創建索引的SQL語句包含創建主鍵索引,或者前面提及的spatial index與fulltext index,那么客戶端將會收到一個告警,提示該操作不支持并行創建索引,同時該語句會采用單線程創建索引的方式執行完成。
從SQL語句的角度,如前所述,創建索引可以采用不同的算法,由于COPY算法(ALGORITHM=COPY)不是采用批量插入的方式,因此不會受益于該并行創建索引優化。而對于INPLACE算法,如果創建索引用的是非rebuild的方式,都可以受益于該優化;一旦需要使用rebuild的方式創建索引,因為涉及到主鍵索引的建立,將無法使用并行創建索引的算法。
下面我們通過幾個實例來了解一下如何使用并行創建索引算法加快創建速度,以及我們的條件約束是如何生效的。
1.我們使用sysbench的表,表內有1億條數據
2.在該表的k字段建索引,采用社區默認單線程,耗時146.82s
3.通過設置innodb_rds_parallel_index_creation_threads= 4啟用4個線程建索引,可以看到建索引耗時38.72s,速度提升3.79倍。
4. 假設我們要修改主鍵索引,雖然指定了多線程,但是會收到一個warning,實際上只能通過單線程建索引
首先對innodb_rds_parallel_index_creation_threads這個參數進行一下說明,它控制了系統中所有并行DDL可以使用的總線程數,取值范圍是[1-128]。該參數取值為1表示使用原始的單線程創建索引,取值為N,表示接下來的DDL使用N個線程創建。如果一個DDL使用了100個線程在執行,那么另外一個也要使用并行的DDL且最多只能使用剩下的28個線程;而如果128個線程都被并行DDL語句占用了,新來的DDL只能走原始的單線程創建的邏輯。
雖然該并行創建索引加快了索引的創建速度,但是在具體使用場景下,還是需要有審慎的評估。我們知道在并行算法應用之后,該DDL對硬件資源的使用會盡可能的充分,這也意味著其它操作就得不到太多的資源了。因此,針對不同的場景需要具體地分析,它決定了我們如何創建索引。
對于遷移場景,由于這時候還沒有任何業務接入,用戶希望盡快完成所有索引的創建,因此可以盡量設置多線程數,比如我們是16核規格的實例,那么我們就可以把并行線程的數量指定為16,加速完成操作。
如果是用戶業務運行階段要創建索引,我們還是不希望DDL操作,對正在運行的業務如DML操作等有太多的影響。因此,這時候創建索引可以指定相對少一些的線程數量,比如2-4(或者根據CPU規格以及負載決定,同時不鼓勵并發地執行多個DDL操作)。這樣既能相對地加速創建索引的進程,也能保證DML的正常進行。
綜上所述,GaussDB(for MySQL)支持了并行創建索引,通過縮短創建索引使用的時間,很好地解決了客戶關切的兩類問題,提升了客戶的體驗。但技術無止境,在創建索引領域,還有其它的問題需要我們優化解決,例如如何減少創建索引步驟對IO的影響等等。我們后續會針對這些點進行優化,給客戶帶來更多的驚喜。
目前,華為云GaussDB(for MySQL) 并行創建索引優化功能已上線,歡迎大家前往華為云官網體驗:云數據庫_GaussDB(for MySQL) _分布式云數據庫-華為云
附:華為云GaussDB(for MySQL)內核專家系列文章
華為海外女科學家為您揭秘:GaussDB(for MySQL)云棧垂直集成的力量有多大?華為海外女科學家為您揭秘:GaussDB(for MySQL)云棧垂直集成的力量有多大?-云社區-華為云
華為云數據庫內核專家為您揭秘:GaussDB(for MySQL)并行查詢有多快?華為云數據庫內核專家為您揭秘:GaussDB(for MySQL)并行查詢有多快?-云社區-華為云
點擊關注,第一時間了解華為云新鮮技術~華為云博客_大數據博客_AI博客_云計算博客_開發者中心-華為云
*請認真填寫需求信息,我們會在24小時內與您取得聯系。