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

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

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

3、插入數(shù)據(jù)太大也會報錯

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

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

delete from 表名 表別名?where?表別名.col = '1' ?會報錯

5、內(nèi)存使用有問題，GO語言導致不知道回收機制什么時候運作。內(nèi)存使用過多會導致TIDB當機(這點完全不像MYSQL)

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

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

7、不支持GBK

8、不支持存儲過程

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

外面文章的一些建議

3TiKV＋3PD＋2TiDB

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

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

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

在 Snappydata 中進行 update 和 delete，以達到想要的目的。因為都是 Spark 的項目，因此在融合兩個項目的時候還是比較輕松的。

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

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

總結(jié)

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

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