那麽，如何保證這些海量數據的安全可靠，以及實時查詢呢？
當然，這裏肯定會有很多解決方案。在當下大數據時代，出現了很多比較友好的解決方案和框架可以解決這個問題。例如：Elasticsearch，Hadoop等，都是現在比較流行的框架。
目前，大多數企業應用系統中的數據應該都是結構化的，也就是這些海量數據存儲在關系型數據庫中，例如：Mysql，Oracle等。而且Mysql關系型數據庫壹般都是初創企業或者中小企業的首選。那麽Mysql如何承載百萬級，千萬級的數據呢？根據阿裏巴巴的開發守則，建議Mysql的數據表容量不要超過500萬條數據記錄，也就說建議在500萬條數據記錄的時候做壹次分表。針對Mysql的分庫分表已經存在很多成熟，開源的解決方案和框架，例如：Mycat，ShardingSphere等。
但是，在大多數業務場景中Mysql的壹個庫會有很多表，數據量大的，需要及時響應查詢的數據表可能就那麽幾張，例如：訂單表數據量比較大，配置表數據量比較小；我們需要對數據量比較大的訂單表進行分庫分表操作，配置表可以不需要分庫分表。也就是說我們需要對部分表進行分庫分表，部分表不進行分庫分表。那麽我們可以考慮使用ShardingSphere的動態數據源，對需要分庫分表的數據我們把正確的數據源路由到正確的庫上，把不需要分庫分表的表路由到默認的數據庫。
下面我們以SpringBoot為例把詳細的實踐過程記錄下來，方便以後查閱。
引入ShardingSphere的maven dependency，采用4.0.0版本
配置多數據源
說明如下：
多數據源配置類
說明如下：
下面配置SpringBoot的數據源
說明如下：
下面是我們自定義的分片算法CustomShardingAlgorithm類
說明如下：
通過以上配置和自定義分片算法，借助ShardingSphere框架我們已經實現了通過攜帶分片鍵的增刪改查sql語句動態路由數據源。如果操作我們需要分庫分表的sql語句沒用攜帶分片鍵，ShardingSphere會報錯並且在日誌信息中會看到對應的錯誤信息。
當然除過ShardingSphere能夠實現動態數據源，其他框架或者方式也可以實現，例如：Spring AOP切面，攔截器也可以實現。那麽就是仁者見仁，智者見智了。
參考資料：