文件分割html
"www.laiwunews.cn/xinxi/25324717.html"
"www.zznews.cn/xinxi/10411214.html"
"tongren.qd8.com.cn/daikuan/xinxi2_41773448.html"
"www.ailaba.org/sell/2804817.html"
"bbs.28tui.com/xinxi/3632846.html"
"www.ailaba.org/sell/1777560.html"
"bbs.28tui.com/xinxi/6626601.html"
"info.b2b168.com/s168-58071410.html"
"www.laiwunews.cn/xinxi/21446979.html"
"www.ailaba.org/sell/473886.html"
"info.b2b168.com/s168-43564514.html"
"info.b2b168.com/s168-56905740.html"
"info.b2b168.com/s168-45450164.html"
"info.b2b168.com/s168-45284506.html"
"info.b2b168.com/s168-15929619.html"
4877978node
[root@iZ2uZ xiaole_chk_url]# python
執行對分割後的文件執行腳本git
Dload Upload Total Spent Left Speed
100 2411k 100 1835k 100 575k 2131k 668k --:--:-- --:--:-- --:--:-- 2129k
/root/xiaole_chk_url/splitfile/4360000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2412k 100 1836k 100 576k 3823k 1199k --:--:-- --:--:-- --:--:-- 3825k
/root/xiaole_chk_url/splitfile/4370000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2410k 100 1835k 100 575k 4999k 1566k --:--:-- --:--:-- --:--:-- 5000k
/root/xiaole_chk_url/splitfile/4380000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2413k 100 1836k 100 576k 4647k 1459k --:--:-- --:--:-- --:--:-- 4650k
/root/xiaole_chk_url/splitfile/4390000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2411k 100 1835k 100 575k 4162k 1305k --:--:-- --:--:-- --:--:-- 4162k
/root/xiaole_chk_url/splitfile/4400000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 576k 100 391 100 576k 23277 33.5M --:--:-- --:--:-- --:--:-- 35.1M
/root/xiaole_chk_url/splitfile/440000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2415k 100 1837k 100 577k 3168k 996k --:--:-- --:--:-- --:--:-- 3168k
/root/xiaole_chk_url/splitfile/4410000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2413k 100 1837k 100 576k 4504k 1414k --:--:-- --:--:-- --:--:-- 4502k
/root/xiaole_chk_url/splitfile/4420000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2414k 100 1837k 100 577k 5531k 1738k --:--:-- --:--:-- --:--:-- 5534k
/root/xiaole_chk_url/splitfile/4430000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2414k 100 1837k 100 577k 5305k 1667k --:--:-- --:--:-- --:--:-- 5310k
/root/xiaole_chk_url/splitfile/4440000bulk.index.del.splitfile.json
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 2413k 100 1836k 100 576k 4914k 1543k --:--:-- --:--:-- --:--:-- 4911kgithub
[root@12 xiaole_chk_url]# cat looh.index.splitfile.es.sh split_file_dir='/root/xiaole_chk_url/splitfile/*' log_file=bulk.index.del.es.json.log for fl in $split_file_dir do if test -f $fl then echo $fl curl -XPOST 10.11.17.14:9200/direct_vote/kwaddress/_bulk --data-binary @$fl >> $log_file fi done echo exit 0 [root@12 xiaole_chk_url]# cat looh.index.splitfile.es.sh split_file_dir='/root/xiaole_chk_url/splitfile/*' log_file=bulk.index.del.es.json.log for fl in $split_file_dir do if test -f $fl then echo $fl curl -XPOST 10.11.17.14:9200/direct_vote/kwaddress/_bulk --data-binary @$fl >> $log_file fi done echo exit 0 [root@12 xiaole_chk_url]# [root@12 xiaole_chk_url]# cat looh.index.sh loop_c=0 loop_step=10000 loop_tag=0 #str_head='{"delete":{"_index":"direct_vote","_type":"kwaddress","_id":"' #str_foot='"}}' #str_head='{"delete":{"_id":"' #str_foot='"}}' str_head='{"delete":{"_id":' str_foot='}}' bulk_file=bulk.del.index.es.json log_file=bulk.del.index.es.json.log echo '' > $bulk_file #for LINE in `cat /root/xiaole_chk_url/chk_url_404_pure_url_4877954.txt` for LINE in `cat /root/xiaole_chk_url/chk_url_404_pure_url3.txt` do echo $LINE loop_c=$((loop_c+1)) loop_tag=$((loop_c%loop_step)) echo ${str_head}$LINE${str_foot} >> $bulk_file echo $loop_c if [ $loop_tag -eq 0 ] then echo $loop_c # curl -XPOST 10.11.17.14:9200/_bulk --data-binary @$bulk_file >> $log_file curl -XPOST 10.11.17.14:9200/direct_vote/kwaddress/_bulk --data-binary @$bulk_file >> $log_file sleep 180s echo '' > $bulk_file else continue fi done echo $loop_c #curl -XPOST 10.11.17.14:9200/_bulk --data-binary @$bulk_file >> $log_file curl -XPOST 10.11.17.14:9200/direct_vote/kwaddress/_bulk --data-binary @$bulk_file >> $log_file echo exit 0 [root@12 xiaole_chk_url]#
查詢驗證 es查詢
查詢驗證 es查詢 curl '10.11.17.14:9200/direct_vote/kwaddress/_search?pretty=true' -d '{"from": 1,"size": 2}' curl '10.11.17.14:9200/direct_vote/kwaddress/_search' -d ' { "query": { "bool": { "must": [ { "match": { "_id": "www.ailaba.org/sell/3788942.html" } } ] } } }' curl '10.11.17.14:9200/direct_vote/kwaddress/_search' -d ' { "query": { "bool": { "must": [ { "match": { "_id": "www.fltbearing.com/sell/show-22694236.html" } } ] } } }'
組合過濾器 | Elasticsearch: 權威指南 | Elastic https://www.elastic.co/guide/cn/elasticsearch/guide/current/combining-filters.htmlweb
這種狀況下,咱們須要 bool
(布爾)過濾器。 這是個 複合過濾器(compound filter) ,它能夠接受多個其餘過濾器做爲參數,並將這些過濾器結合成各式各樣的布爾(邏輯)組合。shell
一個 bool
過濾器由三部分組成:數據庫
{ "bool" : { "must" : [], "should" : [], "must_not" : [], } }
must
AND
等價。
must_not
NOT
等價。
should
OR
等價。
集羣內的原理 | Elasticsearch: 權威指南 | Elastic https://www.elastic.co/guide/cn/elasticsearch/guide/current/distributed-cluster.htmljson
ElasticSearch 的主旨是隨時可用和按需擴容。 而擴容能夠經過購買性能更強大( 垂直擴容 ,或 縱向擴容) 或者數量更多的服務器( 水平擴容 ,或 橫向擴容 )來實現。windows
雖然 Elasticsearch 能夠獲益於更強大的硬件設備,可是垂直擴容是有極限的。 真正的擴容能力是來自於水平擴容--爲集羣添加更多的節點,而且將負載壓力和穩定性分散到這些節點中。
對於大多數的數據庫而言,一般須要對應用程序進行很是大的改動,才能利用上橫向擴容的新增資源。 與之相反的是,ElastiSearch天生就是 分佈式的 ,它知道如何經過管理多節點來提升擴容性和可用性。 這也意味着你的應用無需關注這個問題。
空集羣 | Elasticsearch: 權威指南 | Elastic https://www.elastic.co/guide/cn/elasticsearch/guide/current/_an-empty-cluster.html
【個節點都知道任意文檔所處的位置,而且可以將咱們的請求直接轉發到存儲咱們所需文檔的節點。】
一個運行中的 Elasticsearch 實例稱爲一個 節點,而集羣是由一個或者多個擁有相同 cluster.name
配置的節點組成, 它們共同承擔數據和負載的壓力。當有節點加入集羣中或者從集羣中移除節點時,集羣將會從新平均分佈全部的數據。
當一個節點被選舉成爲 主 節點時, 它將負責管理集羣範圍內的全部變動,例如增長、刪除索引,或者增長、刪除節點等。 而主節點並不須要涉及到文檔級別的變動和搜索等操做,因此當集羣只擁有一個主節點的狀況下,即便流量的增長它也不會成爲瓶頸。 任何節點均可以成爲主節點。咱們的示例集羣就只有一個節點,因此它同時也成爲了主節點。
做爲用戶,咱們能夠將請求發送到 集羣中的任何節點 ,包括主節點。 每一個節點都知道任意文檔所處的位置,而且可以將咱們的請求直接轉發到存儲咱們所需文檔的節點。 不管咱們將請求發送到哪一個節點,它都能負責從各個包含咱們所需文檔的節點收集回數據,並將最終結果返回給客戶端。 Elasticsearch 對這一切的管理都是透明的。
https://www.elastic.co/guide/en/elasticsearch/guide/current/_add_an_index.html
To add data to Elasticsearch, we need an index—a place to store related data. In reality, an index is just a logical namespace that points to one or more physical shards.
A shard is a low-level worker unit that holds just a slice of all the data in the index. In Inside a Shard, we explain in detail how a shard works, but for now it is enough to know that a shard is a single instance of Lucene, and is a complete search engine in its own right. Our documents are stored and indexed in shards, but our applications don’t talk to them directly. Instead, they talk to an index.
Shards are how Elasticsearch distributes data around your cluster. Think of shards as containers for data. Documents are stored in shards, and shards are allocated to nodes in your cluster. As your cluster grows or shrinks, Elasticsearch will automatically migrate shards between nodes so that the cluster remains balanced.
A shard can be either a primary shard or a replica shard. Each document in your index belongs to a single primary shard, so the number of primary shards that you have determines the maximum amount of data that your index can hold.
咱們往 Elasticsearch 添加數據時須要用到 索引 —— 保存相關數據的地方。 索引其實是指向一個或者多個物理 分片 的 邏輯命名空間 。
一個 分片 是一個底層的 工做單元 ,它僅保存了 所有數據中的一部分。 在分片內部機制
中,咱們將詳細介紹分片是如何工做的,而如今咱們只需知道一個分片是一個 Lucene 的實例,以及它自己就是一個完整的搜索引擎。 咱們的文檔被存儲和索引到分片內,可是應用程序是直接與索引而不是與分片進行交互。
Elasticsearch 是利用分片將數據分發到集羣內各處的。分片是數據的容器,文檔保存在分片內,分片又被分配到集羣內的各個節點裏。 當你的集羣規模擴大或者縮小時, Elasticsearch 會自動的在各節點中遷移分片,使得數據仍然均勻分佈在集羣裏。
一個分片能夠是 主 分片或者 副本 分片。 索引內任意一個文檔都歸屬於一個主分片,因此主分片的數目決定着索引可以保存的最大數據量。
技術上來講,一個主分片最大可以存儲 Integer.MAX_VALUE - 128 個文檔,可是實際最大值還須要參考你的使用場景:包括你使用的硬件, 文檔的大小和複雜程度,索引和查詢文檔的方式以及你指望的響應時長。
While a primary shard can technically contain up to Integer.MAX_VALUE - 128 documents, the practical limit depends on your use case: the hardware you have, the size and complexity of your documents, how you index and query your documents, and your expected response times.
一個副本分片只是一個主分片的拷貝。 副本分片做爲硬件故障時保護數據不丟失的冗餘備份,併爲搜索和返回文檔等讀操做提供服務。
在索引創建的時候就已經肯定了主分片數,可是副本分片數能夠隨時修改。
讓咱們在包含一個空節點的集羣內建立名爲 blogs
的索引。 索引在默認狀況下會被分配5個主分片, 可是爲了演示目的,咱們將分配3個主分片和一份副本(每一個主分片擁有一個副本分片):
PUT /blogs { "settings" : { "number_of_shards" : 3, "number_of_replicas" : 1 } }
水平擴容 | Elasticsearch: 權威指南 | Elastic https://www.elastic.co/guide/cn/elasticsearch/guide/current/_scale_horizontally.html
固然,若是隻是在相同節點數目的集羣上增長更多的副本分片並不能提升性能,由於每一個分片從節點上得到的資源會變少。 你須要增長更多的硬件資源來提高吞吐量。
可是更多的副本分片數提升了數據冗餘量:按照上面的節點配置,咱們能夠在失去2個節點的狀況下不丟失任何數據。
文檔元數據 | Elasticsearch: 權威指南 | Elastic https://www.elastic.co/guide/cn/elasticsearch/guide/current/_Document_Metadata.html
一個文檔不只僅包含它的數據 ,也包含 元數據 —— 有關 文檔的信息。 三個必須的元數據元素以下:
_index
_type
_id
一個 索引 應該是因共同的特性被分組到一塊兒的文檔集合。 例如,你可能存儲全部的產品在索引 products
中,而存儲全部銷售的交易到索引 sales
中。 雖然也容許存儲不相關的數據到一個索引中,但這一般看做是一個反模式的作法。
咱們將在 索引管理 介紹如何自行建立和管理索引,但如今咱們將讓 Elasticsearch 幫咱們建立索引。 全部須要咱們作的就是選擇一個索引名,這個名字必須小寫,不能如下劃線開頭,不能包含逗號。咱們用website
做爲索引名舉例。
數據可能在索引中只是鬆散的組合在一塊兒,可是一般明肯定義一些數據中的子分區是頗有用的。 例如,全部的產品都放在一個索引中,可是你有許多不一樣的產品類別,好比 "electronics" 、 "kitchen" 和 "lawn-care"。
這些文檔共享一種相同的(或很是類似)的模式:他們有一個標題、描述、產品代碼和價格。他們只是正好屬於「產品」下的一些子類。
Elasticsearch 公開了一個稱爲 types (類型)的特性,它容許您在索引中對數據進行邏輯分區。不一樣 types 的文檔可能有不一樣的字段,但最好可以很是類似。 咱們將在 類型和映射 中更多的討論關於 types 的一些應用和限制。
一個 _type
命名能夠是大寫或者小寫,可是不能如下劃線或者句號開頭,不該該包含逗號, 而且長度限制爲256個字符. 咱們使用 blog
做爲類型名舉例。
ID 是一個字符串, 當它和 _index
以及 _type
組合就能夠惟一肯定 Elasticsearch 中的一個文檔。 當你建立一個新的文檔,要麼提供本身的 _id
,要麼讓 Elasticsearch 幫你生成。
還有一些其餘的元數據元素,他們在 類型和映射 進行了介紹。經過前面已經列出的元數據元素, 咱們已經能存儲文檔到 Elasticsearch 中並經過 ID 檢索它--換句話說,使用 Elasticsearch 做爲文檔的存儲介質。
路由一個文檔到一個分片中 | Elasticsearch: 權威指南 | Elastic https://www.elastic.co/guide/cn/elasticsearch/guide/current/routing-value.html
爲何咱們要在建立索引的時候就肯定好主分片的數量 而且永遠不會改變這個數量
當索引一個文檔的時候,文檔會被存儲到一個主分片中。 Elasticsearch 如何知道一個文檔應該存放到哪一個分片中呢?當咱們建立文檔時,它如何決定這個文檔應當被存儲在分片 1
仍是分片 2
中呢?
首先這確定不會是隨機的,不然未來要獲取文檔的時候咱們就不知道從何處尋找了。實際上,這個過程是根據下面這個公式決定的:
shard = hash(routing) % number_of_primary_shards
routing
是一個可變值,默認是文檔的 _id
,也能夠設置成一個自定義的值。 routing
經過 hash 函數生成一個數字,而後這個數字再除以 number_of_primary_shards
(主分片的數量)後獲得 餘數 。這個分佈在 0
到 number_of_primary_shards-1
之間的餘數,就是咱們所尋求的文檔所在分片的位置。
這就解釋了爲何咱們要在建立索引的時候就肯定好主分片的數量 而且永遠不會改變這個數量:由於若是數量變化了,那麼全部以前路由的值都會無效,文檔也再也找不到了。
集羣健康度
[root@a2 xiaole_chk_url]# curl 104.217.217.101:9200/_cluster/health
{"cluster_name":"es_app","status":"green","timed_out":false,"number_of_nodes":4,"number_of_data_nodes":3,"active_primary_shards":169,"active_shards":338,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":0,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":100.0}
[root@a2 xiaole_chk_url]#
|
status
字段指示着當前集羣在整體上是否工做正常。它的三種顏色含義以下:
green
yellow
red
刪除操做
curl '101.217.217.110:9200/direct_vote/kwaddress/_bulk' -d '
{"delete" : {"_index":"direct_vote","_type":"kwaddress","_id":"www.fltbearing.com/sell/show-22694236.html"}}
'
檢測集羣健康與刷新
[root@a2 ~]# curl 10.27.217.10:9200/_cluster/health
{"cluster_name":"es_app","status":"green","timed_out":false,"number_of_nodes":4,"number_of_data_nodes":3,"active_primary_shards":169,"active_shards":338,"relocating_shards":0,"initializing_shards":0,"unassigned_shards":0,"delayed_unassigned_shards":0,"number_of_pending_tasks":0,"number_of_in_flight_fetch":0,"task_max_waiting_in_queue_millis":0,"active_shards_percent_as_number":100.0}
[root@a2 ~]# curl 10.27.217.10:9200/_refresh
{"_shards":{"total":338,"successful":338,"failed":0}}[root@a2 ~]#
檢驗存在性
curl '130.22.217.10:9200/direct_vote/kwaddress/_search?pretty=true' -d '
{
"query": {
"bool": {
"should": [
{
"match": {
"_id": "site.leshou.com/s/3477475.html"
}
}
]
}
}
}
'
今日完成工做: 2018年3月22日 18:20:26
檢測es刪除url的質量;
解決2個bug:對源自windows的txt文檔進行dos2unix處理,shell刪除操做過快,致使部分命令沒有執行;
延長批處理的間隔提交時間,由2秒變爲10秒,瀏覽器端實時檢測效果,發現執行結果正確,達到刪除目的。
#split_file_dir='/data/xiaole_chk_url/splitfile01/*'
split_file_dir='/data/xiaole_chk_url/splitfile01/*'
log_file=${BASH_SOURCE}.log
#log_file=bulk.index.del.es.json.domaindel.log
for fl in $split_file_dir
do
if test -f $fl
then
echo $fl
curl -XPOST 10.27.217.10:9200/direct_vote/kwaddress/_bulk --data-binary @$fl >> $log_file
sleep 10s
fi
done
echo
exit 0
選出若干
curl 'hadoop:9200/direct_vote/kwaddress/_search?pretty=true' -d '
{
"from": 1,
"size": 10
}'
curl hadoop2:9200/direct_vote/kwaddress/_search?pretty=true -d "{"from": 1,"size": 10,"_source": false}"
shell 數組遍歷 獲取系統當前時間
elasticsearch 查詢過濾
[root@hadoop3 xiaole_chk_url]# cat looh.the.site.del.sh arr=(8 11 16 27 68 74 75 77 81) cur="`date +%Y%m%d%H%m%s`" res_file=res.${BASH_SOURCE}.${cur}.json.txt log_file=${BASH_SOURCE}.log es_str='' for v in ${arr[@]} do es_str='curl hadoop4:9200/direct_vote/kwaddress/_search?pretty=true -d "{"_source": false,"query": {"match": {"site": "'$v'"}},"from": 1,"size": 9999}"' echo $es_str eval $es_str >> $res_file done exit 0 [root@hadoop3 xiaole_chk_url]# l l-as