zabbix 可以用nosql來存儲(chǔ)數(shù)據(jù)嗎

做過Zabbix的同學(xué)都知道，Zabbix通過專用的Agent或者SNMP收集相關(guān)的監(jiān)控?cái)?shù)據(jù)，然后存儲(chǔ)到數(shù)據(jù)庫里面實(shí)時(shí)在前臺(tái)展示。Zabbix監(jiān)控?cái)?shù)據(jù)主要分為以下兩類：

南開網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),南開網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為南開近1000家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請(qǐng)找那個(gè)售后服務(wù)好的南開做網(wǎng)站的公司定做！

歷史數(shù)據(jù)：history相關(guān)表,從history_uint表里面可以查詢到設(shè)備監(jiān)控項(xiàng)目的最大，最小和平均值,即存儲(chǔ)監(jiān)控?cái)?shù)據(jù)的原始數(shù)據(jù)。

趨勢數(shù)據(jù)：trends相關(guān)表,趨勢數(shù)據(jù)是經(jīng)過Zabbix計(jì)算的數(shù)據(jù)，數(shù)據(jù)是從history_uint里面匯總的，從trends_uint可以查看到監(jiān)控?cái)?shù)據(jù)每小時(shí)最大，最小和平均值，即存儲(chǔ)監(jiān)控?cái)?shù)據(jù)的匯總數(shù)據(jù)。

Zabbix可以通過兩種方式獲取歷史數(shù)據(jù)：

1.通過Zabbix前臺(tái)獲取歷史數(shù)據(jù)

通過Zabbix前臺(tái)查看歷史數(shù)據(jù)非常簡單，可以通過Monitoring-Lastest data的方式查看。也可以點(diǎn)擊右上角的As plain test按鈕保存成文本文件。

2.通過前臺(tái)獲取的數(shù)據(jù)進(jìn)行處理和二次查詢有很多限制，因此可以通過SQL語句直接從后臺(tái)DB查詢數(shù)據(jù)。

首先大家應(yīng)該熟悉SQL語句Select 常用用法：

SELECT [ALL | DISTINCT] Select_List [INTO [New_Table_name]

FROM { Table_name | View_name} [ [,{table2_name | view2_name}

[,…] ]

[ WHERE Serch_conditions ]

[ GROUP BY Group_by_list ]

[ HAVING Serch_conditions ]

[ ORDER BY Order_list [ASC| DEsC] ]

說明：

1)SELECT子句指定要查詢的特定表中的列，它可以是*，表達(dá)式，列表等。

2)INTO子句指定要生成新的表。

3)FROM子句指定要查詢的表或者視圖。

4)WHERE子句用來限定查詢的范圍和條件。

5)GROUP BY子句指定分組查詢子句。

6)HAVING子句用于指定分組子句的條件。

7)ORDER BY可以根據(jù)一個(gè)或者多個(gè)列來排序查詢結(jié)果，在該子句中，既可以使用列名，也可以使用相對(duì)列號(hào)，ASC表示升序，DESC表示降序。

8）mysql聚合函數(shù)：sum()，count()，avg()，max()，avg()等都是聚合函數(shù)，當(dāng)我們在用聚合函數(shù)的時(shí)候，一般都要用到GROUP BY 先進(jìn)行分組，然后再進(jìn)行聚合函數(shù)的運(yùn)算。運(yùn)算完后就要用到Having子句進(jìn)行判斷了,例如聚合函數(shù)的值是否大于某一個(gè)值等等。

sql聚合函數(shù)有哪些？

聚集函數(shù)

和大多數(shù)其它關(guān)系數(shù)據(jù)庫產(chǎn)品一樣，PostgreSQL

支持聚集函數(shù)。一個(gè)聚集函數(shù)從多個(gè)輸入行中計(jì)算出一個(gè)結(jié)果。比如，我們有在一個(gè)行集合上計(jì)算

count(數(shù)目),

sum(總和),

avg(均值),

max(最大值),

min(最小值)的函數(shù)。

比如，我們可以用下面的語句找出所有低溫中的最高溫度：

SELECT

max(temp_lo)

FROM

weather;

max

-----

46

(1

row)如果我們想知道該讀數(shù)發(fā)生在哪個(gè)城市，可能會(huì)用：

SELECT

city

FROM

weather

WHERE

temp_lo

=

max(temp_lo);

--

錯(cuò)！不過這個(gè)方法不能運(yùn)轉(zhuǎn)，因?yàn)榫奂瘮?shù)

max

不能用于

WHERE

子句中。存在這個(gè)限制是因?yàn)?/p>

WHERE

子句決定哪些行可以進(jìn)入聚集階段；因此它必需在聚集函數(shù)之前計(jì)算。不過，我們可以用其它方法實(shí)現(xiàn)這個(gè)目的；這里我們使用子查詢：

SELECT

city

FROM

weather

WHERE

temp_lo

=

(SELECT

max(temp_lo)

FROM

weather);

city

---------------

San

Francisco

(1

row)這樣做是可以的，因?yàn)樽硬樵兪且淮为?dú)立的計(jì)算，它獨(dú)立于外層查詢計(jì)算自己的聚集。

聚集同樣也常用于

GROUP

BY

子句。比如，我們可以獲取每個(gè)城市低溫的最高值：

SELECT

city,

max(temp_lo)

FROM

weather

GROUP

BY

city;

city

|

max

---------------+-----

Hayward

|

37

San

Francisco

|

46

(2

rows)這樣每個(gè)城市一個(gè)輸出。每個(gè)聚集結(jié)果都是在匹配該城市的行上面計(jì)算的。我們可以用

HAVING

過濾這些分組：

SELECT

city,

max(temp_lo)

FROM

weather

GROUP

BY

city

HAVING

max(temp_lo)

40;

city

|

max

---------+-----

Hayward

|

37

(1

row)這樣就只給出那些

temp_lo

值曾經(jīng)有低于

40

度的城市。最后，如果我們只關(guān)心那些名字以"S"開頭的城市，我們可以用：

SELECT

city,

max(temp_lo)

FROM

weather

WHERE

city

LIKE

'S%'

GROUP

BY

city

HAVING

max(temp_lo)

40;語句中的

LIKE

執(zhí)行模式匹配，在節(jié)9.7里有解釋。

理解聚集和

SQL

的

WHERE

和

HAVING

子句之間的關(guān)系非常重要。WHERE

和

HAVING

的基本區(qū)別如下：WHERE

在分組和聚集計(jì)算之前選取輸入行(它控制哪些行進(jìn)入聚集計(jì)算)，而

HAVING

在分組和聚集之后選取輸出行。因此，WHERE

子句不能包含聚集函數(shù)；因?yàn)樵噲D用聚集函數(shù)判斷那些行將要輸入給聚集運(yùn)算是沒有意義的。相反，HAVING

子句總是包含聚集函數(shù)。當(dāng)然，你可以寫不使用聚集的

HAVING

子句，但這樣做沒什么好處，因?yàn)橥瑯拥臈l件可以更有效地用于

WHERE

階段。

在前面的例子里，我們可以在

WHERE

里應(yīng)用城市名稱限制，因?yàn)樗恍枰奂?。這樣比在

HAVING

里增加限制更加高效，因?yàn)槲覀儽苊饬藶槟切┪赐ㄟ^

WHERE

檢查的行進(jìn)行分組和聚集計(jì)算。

sql聚合函數(shù)的應(yīng)用

聚合函數(shù)對(duì)一組值執(zhí)行計(jì)算,并返回單個(gè)值。除了

COUNT

以外，聚合函數(shù)都會(huì)忽略空值。聚合函數(shù)經(jīng)常與

SELECT

語句的

GROUP

BY

子句一起使用。

所有聚合函數(shù)均為確定性函數(shù)。也就是說，只要使用一組特定輸入值調(diào)用聚合函數(shù)，該函數(shù)總是返回相同的值。有關(guān)函數(shù)確定性的詳細(xì)信息，請(qǐng)參閱確定性函數(shù)和不確定性函數(shù)。

聚合函數(shù)只能在以下位置作為表達(dá)式使用：

SELECT

語句的選擇列表（子查詢或外部查詢）。

COMPUTE

或

COMPUTE

BY

子句。

HAVING

子句。

Transact-SQL

提供下列聚合函數(shù)：

AVG

MIN

CHECKSUM

SUM

CHECKSUM_AGG

STDEV

COUNT

STDEVP

COUNT_BIG

VAR

GROUPING

VARP

sql中常用的聚合函數(shù)有哪些

聚合函數(shù)是對(duì)一組值執(zhí)行計(jì)算并返回單一的值的函數(shù)，它經(jīng)常與SELECT語句的GROUP BY子句一同使用，SQL SERVER 中具體有哪些聚合函數(shù)呢？我們來一一看一下：

1. AVG 返回指定組中的平均值，空值被忽略。

例：select prd_no,avg(qty) from sales group by prd_no

2. COUNT 返回指定組中項(xiàng)目的數(shù)量。

例：select count(prd_no) from sales

3. MAX 返回指定數(shù)據(jù)的最大值。

例：select prd_no,max(qty) from sales group by prd_no

4. MIN 返回指定數(shù)據(jù)的最小值。

例：select prd_no,min(qty) from sales group by prd_no

5. SUM 返回指定數(shù)據(jù)的和，只能用于數(shù)字列，空值被忽略。

例：select prd_no,sum(qty) from sales group by prd_no

6. COUNT_BIG 返回指定組中的項(xiàng)目數(shù)量，與COUNT函數(shù)不同的是COUNT_BIG返回bigint值，而COUNT返回的是int值。

例：select count_big(prd_no) from sales

7. GROUPING 產(chǎn)生一個(gè)附加的列，當(dāng)用CUBE或ROLLUP運(yùn)算符添加行時(shí)，輸出值為1.當(dāng)所添加的行不是由CUBE或ROLLUP產(chǎn)生時(shí)，輸出值為0.

例：select prd_no,sum(qty),grouping(prd_no) from sales group by prd_no with rollup

8. BINARY_CHECKSUM 返回對(duì)表中的行或表達(dá)式列表計(jì)算的二進(jìn)制校驗(yàn)值，用于檢測表中行的更改。

例：select prd_no,binary_checksum(qty) from sales group by prd_no

9. CHECKSUM_AGG 返回指定數(shù)據(jù)的校驗(yàn)值，空值被忽略。

例：select prd_no,checksum_agg(binary_checksum(*)) from sales group by prd_no

10. CHECKSUM 返回在表的行上或在表達(dá)式列表上計(jì)算的校驗(yàn)值，用于生成哈希索引。

11. STDEV 返回給定表達(dá)式中所有值的統(tǒng)計(jì)標(biāo)準(zhǔn)偏差。

例：select stdev(prd_no) from sales

12. STDEVP 返回給定表達(dá)式中的所有值的填充統(tǒng)計(jì)標(biāo)準(zhǔn)偏差。

例：select stdevp(prd_no) from sales

13. VAR 返回給定表達(dá)式中所有值的統(tǒng)計(jì)方差。

例：select var(prd_no) from sales

14. VARP 返回給定表達(dá)式中所有值的填充的統(tǒng)計(jì)方差。

例：select varp(prd_no) from sales

elasticsearch可以代替NoSQL嗎

我們使用Elasticsearch存儲(chǔ)的文檔數(shù)量接近50億（算上1份復(fù)制，接近100億文檔），總共10個(gè)數(shù)據(jù)節(jié)點(diǎn)和2個(gè)元數(shù)據(jù)節(jié)點(diǎn)（48GB內(nèi)存，8核心CPU，ES使用內(nèi)存達(dá)到70%），每天的文檔增量大概是3000W條（速度持續(xù)增加中）。目前來看，單個(gè)文檔的查詢效率基本處于實(shí)時(shí)狀態(tài)；對(duì)于1到2周的數(shù)據(jù)的聚合統(tǒng)計(jì)操作也可以在10秒之內(nèi)返回結(jié)果。

但是，還有提升的空間：

1. 對(duì)于查詢單條數(shù)據(jù)的應(yīng)用場景來說，我們可以使用ES的路由機(jī)制，將同一索引內(nèi)的具有相同特征（比如具有相同的userid）的文檔全部存儲(chǔ)于一個(gè)節(jié)點(diǎn)上，這樣我們之后的查詢都可以直接定位到這個(gè)節(jié)點(diǎn)上，而不用將查詢廣播道所有的節(jié)點(diǎn)上；

2. 隨著數(shù)據(jù)節(jié)點(diǎn)的增加，適當(dāng)增加分片數(shù)量，提升系統(tǒng)的分布水平，也可以通過分而治之的方式優(yōu)化查詢性能；

個(gè)人以為Elasticsearch作為內(nèi)部存儲(chǔ)來說還是不錯(cuò)的，效率也基本能夠滿足，在某些方面替代傳統(tǒng)DB也是可以的，前提是你的業(yè)務(wù)不對(duì)操作的事性務(wù)有特殊要求；而權(quán)限管理也不用那么細(xì)，因?yàn)镋S的權(quán)限這塊還不完善。由于我們對(duì)ES的應(yīng)用場景僅僅是在于對(duì)某段時(shí)間內(nèi)的數(shù)據(jù)聚合操作，沒有大量的單文檔請(qǐng)求（比如通過userid來找到一個(gè)用戶的文檔，類似于NoSQL的應(yīng)用場景），所以能否替代NoSQL還需要各位自己的測試。如果讓我選擇的話，我會(huì)嘗試使用ES來替代傳統(tǒng)的NoSQL，因?yàn)樗臋M向擴(kuò)展機(jī)制太方便了。

在我的工作過程中，我深切體會(huì)到：經(jīng)驗(yàn)固然是一個(gè)很重要的東西，因?yàn)樗軌驇椭覀兩僮吆芏鄰澛?，但同時(shí)也應(yīng)該看到經(jīng)驗(yàn)的另一面——它會(huì)變成一個(gè)籠子，將我們閉塞其中，使我們錯(cuò)過一些可能更好的解決方案，關(guān)鍵是我們要學(xué)會(huì)嘗試，接觸新的世界。