阿里云數(shù)據(jù)庫多少錢一年 大數(shù)據(jù)和商業(yè)智能的關(guān)系是什么？
大數(shù)據(jù)和商業(yè)智能的關(guān)系是什么？大數(shù)據(jù)和商業(yè)智能BI的關(guān)系從應(yīng)用上來講，BI（BusinessIntelligence）即商業(yè)智能，它是一套完整的解決方案，用來將企業(yè)中現(xiàn)有的數(shù)據(jù)進行有效的整合，快速準確
大數(shù)據(jù)和商業(yè)智能的關(guān)系是什么？
大數(shù)據(jù)和商業(yè)智能BI的關(guān)系從應(yīng)用上來講，BI（BusinessIntelligence）即商業(yè)智能，它是一套完整的解決方案，用來將企業(yè)中現(xiàn)有的數(shù)據(jù)進行有效的整合，快速準確的提供報表并提出決策依據(jù)，幫助企業(yè)做出明智的業(yè)務(wù)經(jīng)營決策。
商業(yè)智能BI在數(shù)據(jù)架構(gòu)中處于前端分析的位置，其核心作用是對獲取數(shù)據(jù)的多維度分析、數(shù)據(jù)的切片、數(shù)據(jù)的上鉆和下鉆、cube等。通過ETL數(shù)據(jù)抽取、轉(zhuǎn)化形成一個完整的數(shù)據(jù)倉庫、然后對數(shù)據(jù)倉庫的數(shù)據(jù)進行抽取，而后是商業(yè)智能的前端分析和展示。
商業(yè)智能BI處理的數(shù)據(jù)量是極大的，如 FineBI商業(yè)智能，自帶ETL，可在短時間內(nèi)響應(yīng)數(shù)據(jù)處理的請求，并輸出分析結(jié)果。
BI對穩(wěn)定性以及易用性有一定要求，這是其他數(shù)據(jù)分析工具所不能比擬的。
大數(shù)據(jù)的應(yīng)用的數(shù)據(jù)來源包括結(jié)構(gòu)化數(shù)據(jù)，如各種數(shù)據(jù)庫、各種結(jié)構(gòu)化文件、消息隊列和應(yīng)用系統(tǒng)數(shù)據(jù)等，其次才是非結(jié)構(gòu)化數(shù)據(jù)。
國內(nèi)銀行系統(tǒng)用美國甲骨文Oracle數(shù)據(jù)庫不怕泄密嗎？
典型的總有刁民想害朕的心態(tài)[靈光一閃]
為什么傳統(tǒng)行業(yè)幾乎都用Oracle，而互聯(lián)網(wǎng)行業(yè)幾乎都不用Oracle呢？
首先銀行要求絕對穩(wěn)定性，使用付費不開源產(chǎn)品可以完全責(zé)任委托，而且數(shù)據(jù)庫廠商還會有專門維護，省心，省力，安全。
mysql呢，開源產(chǎn)品，穩(wěn)定性沒有o高，如果要深度開發(fā)倒是很省事，不過使用mysql就完全要看自己了，銀行不會為了一個隨時都有可能出現(xiàn)意外的定時炸彈找專門團隊維護，而且銀行交易量很大，但并非像互聯(lián)網(wǎng)應(yīng)用一樣超級并發(fā)，大部分都是內(nèi)部接口使用，而且分地區(qū)都是不同的服務(wù)器，每個地區(qū)只存儲自己相關(guān)的數(shù)據(jù)，比如你從廣東給山東異地轉(zhuǎn)賬，原始山東賬戶里并不存你的記錄，轉(zhuǎn)了之后山東數(shù)據(jù)庫才有記錄，在依賴oracle商業(yè)委托的基礎(chǔ)下，銀行還會有對賬，來保證數(shù)據(jù)一致性。
但是反觀互聯(lián)網(wǎng)企業(yè)就不一樣了，超級并發(fā)，小型機已經(jīng)不滿足這種并發(fā)條件了，哪怕oracle足夠優(yōu)秀，所以要使用應(yīng)對更高并發(fā)特制的mysql，需要有專業(yè)的團隊進行維護，穩(wěn)定性不如oracle，不過分布式集群可以避免這種情況。而且mysql因為開源還可以針對自己的需求特制功能。不過大部分企業(yè)用不上[捂臉]，小公司用啥都一樣。阿里重新開發(fā)mysql除了自己用外還可以賣服務(wù)。
再說一句，阿里其實棄o選m其實除了并發(fā)問題，還因為oracle太貴，因為企業(yè)要考慮收支，就算阿里利潤率也比不上銀行[靈光一閃]
Facebook用戶量十分龐大，為什么還使用MySQL數(shù)據(jù)庫？
盡管Facebook使用MySQL，但它們并不是一成不變的使用它。 事實上，他們的團隊已經(jīng)提交了許多MySQL核心和Innodb插件的高性能增強。 他們的主要重點是增加性能計數(shù)器到Innodb。 其他更改集中在IO子系統(tǒng)上，包括以下新功能：
1 innodb_io_capacity：設(shè)置服務(wù)器的IO容量以確定后臺IO的速率限制
2 innodb_read_io_threads， innodb_write_io_threads：設(shè)置后臺IO線程
3 innodb_max_merged_io：設(shè)置可能合并到一個大IO請求中的相鄰IO請求的最大數(shù)量
Facebook使用MySQL作為鍵值存儲，其中數(shù)據(jù)隨機分布在一大組邏輯實例中。 這些邏輯實例分散在物理節(jié)點之間，負載均衡在物理節(jié)點級完成。 Facebook已經(jīng)開發(fā)了一個分區(qū)方案，其中全局ID被分配給所有的用戶數(shù)據(jù)。 他們也有一個自定義的歸檔方案，它基于每個用戶的頻繁和最近的數(shù)據(jù)。 大部分數(shù)據(jù)是隨機分布的。 令人驚訝的是，據(jù)傳Facebook有1800個MySQL服務(wù)器，但只有3個全職DBA
Facebook主要將MySQL用于結(jié)構(gòu)化數(shù)據(jù)存儲，例如墻貼，用戶信息等。這些數(shù)據(jù)在各個數(shù)據(jù)中心之間復(fù)制。 對于blob存儲（照片，視頻等），F(xiàn)acebook使用一個自定義的解決方案，涉及外部的CDN和內(nèi)部的NFS
同樣重要的是，F(xiàn)acebook大量使用Memcache，這是一種內(nèi)存緩存系統(tǒng)，通過在RAM中緩存數(shù)據(jù)和對象來加速動態(tài)數(shù)據(jù)庫驅(qū)動的網(wǎng)站，以減少閱讀時間。 Memcache是Facebook的主要緩存形式，大大減少了數(shù)據(jù)庫的負載。 擁有一個緩存系統(tǒng)可以使Facebook的速度與調(diào)用數(shù)據(jù)一樣快。 如果不需要訪問數(shù)據(jù)庫，則只需根據(jù)用戶標(biāo)識從緩存中獲取數(shù)據(jù)
所以，“Facebook使用什么數(shù)據(jù)庫”似乎是一個簡單的問題，你可以看到他們已經(jīng)添加了各種其他系統(tǒng)，使其真正的具有網(wǎng)絡(luò)可擴展性。 但是，仍然可以自由地使用這樣一個觀點：“MySQL和Oracle或者MS SQL Server一樣好或者更好，因為就算只有Facebook使用它，它也有5億用戶！”