InfiniDB在大數(shù)據(jù)的實戰(zhàn)應(yīng)用

Infinidb在大數(shù)據(jù)的實戰(zhàn)應(yīng)用目錄?

背景?

InfiniDB的特點?

Infinidb的實戰(zhàn)問題一個真實的血案：?

需求：我們在數(shù)據(jù)庫mysql要做基于pv的分析。日均裸數(shù)據(jù)增量>10g?

初始方案：

使用innodb問題：數(shù)據(jù)量增加太快,磁盤空間增加太快(40g)數(shù)據(jù)加載太慢了最最重要統(tǒng)計類查詢太慢了，需要建太多的索引/匯總表?

改進方案：換成tokudb解決問題：數(shù)據(jù)壓縮4倍，空間增加勉強可以接受(10g)數(shù)據(jù)加載快些了4倍左右，勉強可以接受未解決：最最重要查詢太慢了，一個查詢5分鐘甚至更長，優(yōu)化太痛苦，需要建太多的索引/匯總表問題一個真實的血案：?

需求：我們在數(shù)據(jù)庫mysql要做基于pv的分析。日均裸數(shù)據(jù)增量>10g?

初始方案：

使用innodb問題：數(shù)據(jù)量增加太快,磁盤空間增加太快(40g)數(shù)據(jù)加載太慢了最最重要統(tǒng)計類查詢太慢了，需要建太多的索引/匯總表?

改進方案：換成tokudb解決問題：數(shù)據(jù)壓縮4倍，空間增加勉強可以接受(10g)數(shù)據(jù)加載快些了4倍左右，勉強可以接受未解決：最最重要查詢太慢了，一個查詢5分鐘甚至更長，優(yōu)化太痛苦，需要建太多的索引/匯總表解決：--換成infinidb?

最終方案：

使用infinidb(和最初方案innodb比較)–

空間增量2g

(

原來增量40g)–

加載數(shù)據(jù)

20萬/每秒

（原來

<1萬/每秒）–

查詢一般小于1分鐘（原來5分鐘，甚至20分鐘）–

免優(yōu)化（再也不要建index了哦）?

業(yè)務(wù)線的反饋目錄?

背景?

InfiniDB的特點?

Infinidb的實戰(zhàn)Infinidb的定位Hbase

等infinidbinfinidbinfinidb產(chǎn)品介紹產(chǎn)品特點：?

Mysql協(xié)議兼容?

全功能，支持dml?

統(tǒng)計類查詢10倍?

Load數(shù)據(jù)快（每秒>10萬）?

壓縮率5倍（和裸數(shù)據(jù)比）?

免優(yōu)化Infinidb的單機構(gòu)架InfiniDB

分布式框架集群文件系統(tǒng)（hdfs/gfs）

2013.10.15

支持hdfs

–不太建議生產(chǎn)環(huán)境用真實業(yè)務(wù)性能測試—查詢性能分析類存儲引擎InfiniDB

–

查詢性能對比測試TPCH測試（以下以1G數(shù)據(jù)量，150000行用戶數(shù)據(jù)測試）InfiniDB存儲

–

為啥查詢這樣快數(shù)據(jù)存儲方面，“拆拆拆”：?

按列拆?

按行（范圍）拆：核心算法：hash

joinInfiniDB存儲

–

按列拆InfiniDB存儲

–

按行（范圍）拆每個范圍（術(shù)語：Extent

Map）都有最大/最小值，方便過濾Extent

Map

的向上擴展更大的范圍（術(shù)語：Partition）也有最大值/最小值每個Extent

Map

可以并行計算InfiniDB存儲

–

hash

join核心算法：hash

join?

每行都有一個rowid?

查詢2列以上：通過行rowid關(guān)聯(lián)，使用hash

join?

不太怕表的關(guān)聯(lián)?

很怕Select

*InfiniDB存儲

–

為啥查詢這樣快（總結(jié)）數(shù)據(jù)存儲方面，“拆拆拆”：?

按列拆?

按行（范圍）拆：?

通過核心算法：hash

join實現(xiàn)關(guān)聯(lián)裝載和更新-真實業(yè)務(wù)性能測試InfiniDB存儲

–

數(shù)據(jù)裝載語法load

data

local

infile

…?

速度超快

(>10萬/每秒)?

一個表只能對應(yīng)一個load語句，不可并行內(nèi)部過程：?

內(nèi)部實現(xiàn)轉(zhuǎn)換成cpimport的方式?

內(nèi)部實現(xiàn)

并行加載（不可以調(diào)并行度，代碼寫死了）?

Cpimport的實現(xiàn)是append

文件的方式

InfiniDB存儲

–-鎖、事務(wù)和mvcc對于DML:頁級別的鎖

Version

Buffer

(SCN)

:

1.

保存被修改的數(shù)據(jù)塊，用于管理回滾、MVCC支持和snapshot

2.

Initial

4M

內(nèi)存hash表，默認文件1G，VersionBufferFileSize控制大小

3.

在HDFS上，MVCC是disabled的，回滾只支持在語句級對應(yīng)load數(shù)據(jù)：append數(shù)據(jù)到文件末尾，需要回滾時直接拋棄數(shù)據(jù)InfiniDB

–

壓縮每一列的重復(fù)值多，所以壓縮率5倍set

infinidb_compression_type

=

n可以在實例級或session啟用關(guān)閉壓縮。0)

關(guān)閉壓縮1

or

2)

啟用壓縮，默認為2（quicklz算法）InfiniDB

–

免優(yōu)化?

無index?

自動分區(qū)?

dba唯一可以做的：sql優(yōu)化只能調(diào)整表的連接次序InfiniDB

–

和其他產(chǎn)品的對比Inforbright社區(qū)版?功能：不支持DML?

限制功能的開源Hbase?

Hbase本質(zhì)上是個key

–多value的構(gòu)架?

復(fù)雜?

擴展性好?

和infinidb是互補的結(jié)構(gòu)infinidb產(chǎn)品特點（總結(jié)）產(chǎn)品特點：?

Mysql協(xié)議兼容?

全功能，支持dml?

統(tǒng)計類查詢10倍?

Load數(shù)據(jù)快（每秒>10萬）?

壓縮率5倍（和裸數(shù)據(jù)比）?

免優(yōu)化目錄?

背景?

InfiniDB的特點?

Infinidb的實戰(zhàn)InfiniDB

–

社區(qū)支持問題現(xiàn)在支持比較差，未來前景比較好?

（現(xiàn)狀）文檔和問題資料比較少?

2000

年公司，發(fā)布產(chǎn)品?

2013.10月，支持hadoop文件系統(tǒng)?

2014.10月公司倒閉?

2014.10月

mariadb接手?

2015.Q1會發(fā)布新的版本InfiniDB

–

高可用問題集群版本沒有高可用文檔，但是也許不太穩(wěn)定單機版本本身不提供高可用???備份/恢復(fù)方案+手工補缺少數(shù)據(jù)

使用lvmDrbd的方案Mysql主從方案不適應(yīng)（

因為有binlog問題）InfiniDB

–

高可用drbdInfiniDB

–

規(guī)范（合適的場景）InfiniDB

–規(guī)范（不合適的場景）InfiniDB-兼容

性不支持最新版本mysql

官方的java驅(qū)動支持marridb的mysql驅(qū)動InfiniDB

–應(yīng)用類問題?Infinidb數(shù)據(jù)會混亂?使用最簡單的語法?Infinidb的數(shù)據(jù)表損壞?重新建立表，然后把數(shù)據(jù)導(dǎo)回去?大量的delete/load并行容易死鎖?比如一天

84次delete,每次600萬?Infinidb數(shù)據(jù)量排序大報錯?max_length_for_sort_data?infindb

server本地