1、對硬盤要求很高，沒上SSD硬盤的不建議使用

2、不支持分區(qū)，刪除數(shù)據(jù)是個(gè)大坑。

解決方案：set @@session.tidb_batch_delete=1;

3、插入數(shù)據(jù)太大也會(huì)報(bào)錯(cuò)

解決方案：set @@session.tidb_batch_insert=1;

4、刪除表數(shù)據(jù)時(shí)不支持別名

delete from 表名 表別名?where?表別名.col = '1' ?會(huì)報(bào)錯(cuò)

5、內(nèi)存使用有問題，GO語言導(dǎo)致不知道回收機(jī)制什么時(shí)候運(yùn)作。內(nèi)存使用過多會(huì)導(dǎo)致TIDB當(dāng)機(jī)(這點(diǎn)完全不像MYSQL)

測試情況是，32G內(nèi)存，在10分鐘后才回收一半。

6、數(shù)據(jù)寫入的時(shí)候，tidb壓力很大, tikv的CPU也占用很高

7、不支持GBK

8、不支持存儲(chǔ)過程

9、列數(shù)支持太少，只支持100列，和oralce/mysql的1000列少太多(Oracle 最大列數(shù)為 1000；MySQL對于每個(gè)表具有4096個(gè)列的硬限制, 其中InnoDB每個(gè)表的限制為1017列, 最大行大小限制為65,535字節(jié))

外面文章的一些建議

3TiKV＋3PD＋2TiDB

在有了 TiSpark 之后，我們便利用 TiSpark 將中間表緩存為 Spark 的內(nèi)存表，只需要將最后的數(shù)據(jù)落地回 TiDB，再執(zhí)行 Merge 操作即可，這樣省掉了很多中間數(shù)據(jù)的落地，大大節(jié)省了很多腳本執(zhí)行的時(shí)間

在查詢速度解決之后，我們發(fā)現(xiàn)腳本中會(huì)有很多針對中間表 update 和 delete 的語句。目前 TiSpark 暫時(shí)不支持 update 和 delete 的操作(和 TiSpark 作者溝通，后續(xù)會(huì)考慮支持這兩個(gè)操作)，

我們便嘗試了兩種方案，一部分執(zhí)行類似于 Hive，采用 insert into 一張新表的方式來解決；另外一部分，我們引入了 Spark 中的 Snappydata 作為一部分內(nèi)存表存儲(chǔ)，

在 Snappydata 中進(jìn)行 update 和 delete，以達(dá)到想要的目的。因?yàn)槎际?Spark 的項(xiàng)目，因此在融合兩個(gè)項(xiàng)目的時(shí)候還是比較輕松的。

最后，關(guān)于實(shí)時(shí)的調(diào)度工具，目前我們是和離線調(diào)度一起進(jìn)行調(diào)度，這也帶來了一些問題，每次腳本都會(huì)初始化一些 Spark 參數(shù)等，這也相當(dāng)耗時(shí)。在未來，我們打算采用 Spark Streaming 作為調(diào)度工具，

每次執(zhí)行完成之后記錄時(shí)間戳，Spark Streaming 只需監(jiān)控時(shí)間戳變化即可，能夠避免多次初始化的耗時(shí)，通過 Spark 監(jiān)控，我們也能夠清楚的看到任務(wù)的延遲和一些狀態(tài)，這一部分將在未來進(jìn)行測試。

總結(jié)

以上是生活随笔為你收集整理的spark 写tidb_tidb使用坑记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。