數據庫選型

 

主要仍是看後期數據分析的複雜度，若是須要作多表關聯統計分析，mysql 上千萬的數據分析起來就比較吃力了，此種場景甲骨文是最推薦的。
mongodb 太消耗內存，其實不太適合olap 場景的，分析起來比較麻煩，簡單事務處理還行。
。將來若是數據量上去了，再考慮重型武器hbase ，但要知道它只是你ods的補充，別想它能徹底取代你的ods。
題主更多的應該是構建ods 短時間內mysql 能夠快速知足需求

 

500w不大 也談不上要到分佈式
建好索引 MySQL還能再戰五百年

 

主要對比mysql和hbase，mongodb沒用過。mysql在小型數據上仍是表現的不錯的，可是當數據一大，mysql擴展能力和以後的運維都是將面對的問題。目前500w左右數據，天天增量5w，一年就是1850w，固然短時間內，好比兩三年幾千萬數據，是能夠用mysql來處理的。可是以後數據累積到必定量後，mysql避免不了分表分庫，一次多表聯合查詢的效率是很是低的。若是mysql沒法擴展後須要遷移數據，也要耗費大量開銷，人，物，時間。

而hbase是面向列的存儲，全部文件以hdfs做爲存儲空間，讀寫文件在磁盤上是連續的，這樣能夠充分發揮io吞吐能力，所以在讀寫方面hbase是很是快的。使用hdfs爲存儲空間的一個好處是，能夠經過增長廉價服務器來提升hbase的容量和計算能力。

還有一點，題主有大數據分析的需求，難道用幾百臺mysql就能夠進行大數據分析？那，還用hadoop幹啥？

hbase周邊產品也不斷髮展和完善中，好比hive on hbase，phoenix on hbase等能夠直接寫sql語句來操做hbase，大大下降了hbase的學習成本。
最後，推薦題主去google下，hbase replace mysql 

500W級別，用infobright最合適，列式存儲，若是列中重複數據多，壓縮比還能夠最高能夠到10倍。
另外，你的mysql同步的數據能夠這麼搞， 搞一個備庫同步文件使用ROW的方式

binlog_format="ROW"

的方式，就是每一條記錄對應着一行， 而後實時解析下，接入你的infobright. 固然若是數據量大，能夠寫個mapreduce將這部分增量數據與全量數據merge下造成快照。
另外500W的數據，單條算1K,才5G，直接單機用python均可以搞定。若是需求簡單，甚至能夠用grep -F -mmap 來搞定

我的以爲mysql足矣，按照天天5萬的量計算，兩年也不算很大，mysql還能夠支持，而從成原本看，集羣搭建至少超過5臺機器(好寒酸 )，集羣過小也沒有意義。此外，hbase對key-value類型的場景支持較好，其餘的效果沒這麼顯著。有道是強扭的瓜不甜，適合的纔是最好的

如今須要作一個數據存儲，500w左右的數據，往後天天大約產生5w條左右的數據。想把這些數據存儲起來，供往後的數據分析用？使用上面說的三種數據庫中的哪中比較好？是否有必要創建集羣？

我的見解是：從長遠角度看，因爲單臺機器的性能瓶頸，後期確定要作集羣，單純的作複製最終也沒法緩解單臺master上讀的負擔。所以，使用mysql的話會使用cluser。可是瞭解到mysql的cluser要用好的化還要作負載均衡，而mysql的均衡器是第三方的，沒法很好的與mysql整合。使用mongodb的自動分片集羣能很好的解決這個問題，並且它的讀寫性能也快。Hbase提供了大數據存儲的解決方案。

回到我問題，最終是要在大數據的基礎上作數據分析，雖然mongodb也能與Mapreduce整合，但想必Hbase作這一塊會更有優點。

咱們的需求是作一個數據倉庫，不是線上數據，便是OLAP。數據來源是不少的線上數據庫（咱們用的是mysql），每隔一段時間會同步數據過來（大概是幾天的樣子）。這些數據將用於往後的數據分析。所以，對實時性要求不是很高。

答案：

百萬級的數據，不管側重OLTP仍是OLAP，固然就是MySql了。

過億級的數據，側重OLTP能夠繼續Mysql，側重OLAP，就要分場景考慮了。

實時計算場景：強調實時性，經常使用於實時性要求較高的地方，能夠選擇Storm;

批處理計算場景：強調批處理，經常使用於數據挖掘、分析，能夠選擇Hadoop;

實時查詢場景：強調查詢實時響應，經常使用於把DB裏的數據轉化索引文件，經過搜索引擎來查詢，能夠選擇solr/elasticsearch;

企業級ODS/EDW/數據集市場景：強調基於關係性數據庫的大數據實時分析，經常使用於業務數據集成，能夠選擇Greenplum；

數據庫系統通常分爲兩種類型：

一種是面向前臺應用的，應用比較簡單，可是重吞吐和高併發的OLTP類型；

一種是重計算的，對大數據集進行統計分析的OLAP類型。

傳統數據庫側重交易處理，即OLTP，關注的是多用戶的同時的雙向操做，在保障即時性的要求下，系統經過內存來處理數據的分配、讀寫等操做，存在IO瓶頸。

OLTP（On-Line Transaction Processing，聯機事務處理）系統也稱爲生產系統，它是事件驅動的、面向應用的，好比電子商務網站的交易系統就是一個典型的OLTP系統。OLTP的基本特色是：

數據在系統中產生；

基於交易的處理系統（Transaction-Based）；

每次交易牽涉的數據量很小；

對響應時間要求很是高；

用戶數量很是龐大，主要是操做人員；

數據庫的各類操做主要基於索引進行。

分析型數據庫是以實時多維分析技術做爲基礎，即側重OLAP，對數據進行多角度的模擬和概括，從而得出數據中所包含的信息和知識。

OLAP（On-Line Analytical Processing，聯機分析處理）是基於數據倉庫的信息分析處理過程，是數據倉庫的用戶接口部分。OLAP系統是跨部門的、面向主題的，其基本特色是：

自己不產生數據，其基礎數據來源於生產系統中的操做數據（OperationalData）；

基於查詢的分析系統；

複雜查詢常用多表聯結、全表掃描等，牽涉的數據量每每十分龐大；

響應時間與具體查詢有很大關係；

用戶數量相對較小，其用戶主要是業務人員與管理人員；

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. 若是時間不是特別緊急，仍是要想一想這個架構選擇是否能支撐兩年的業務需求，若是業務數據量或者豐富度增加很快，大半年就要換架構，那就有點麻煩，不影響業務狀況下換架構並不容易；
2. 樓主天天新增5W，假設這個系統支持業務運行兩年，業務線性增加，則整個系統的數據量爲50K*730+5M =40M 數據； 實際上業務增加可能愈來愈快（老闆也是這麼但願的吧：），到時候沒準有1億條數據；
3. 上面三個系統，HBase撐得起來1億數據沒任何問題，MySQL也有較成熟解決方案，MongoDB感受也沒問題（沒實際用過，從一些技術文章介紹看，MongoDB初版存儲引擎是有些問題，對內存的依賴，碎片，如今WT引擎還須要時間穩定，周邊工具、論壇的豐富程度也低於MySQL）。須要付出的精力我的認爲MongoDB > MySQL >> HBase。正如樓主所言，HBase處理這點量沒有壓力，並且擴容方便。
4. 不知道樓主是否考慮過使用雲計算解決問題？也許能節約精力、節省成本。
國內：
阿里雲 阿里雲-全球領先的雲計算服務平臺，有MySQL託管、KV存儲、相似HBase的OTS產品；
百度雲： 百度雲——雲上的日子 你我共享 竟然須要先登陸才能看產品，我沒有帳號；
金山雲： 金山雲官網 有關係數據庫服務，從產品技術文檔看，後臺應該是MySQL，使用了SSD提升性能來適應遊戲的實時要求，估計價格不便宜；
國外亞馬遜、微軟的雲服務也很是完善，不過一時還用不上，緣由你們都懂。

 

 

我以爲首先來看一看今天企業裏面常常談的一個問題就是整合的問題。爲何會談到整合的問題，由於整合就是你如今有不少沒有被整合的東西，因此是信息孤島，由於有信息孤島的存在，因此須要整合。反過來說爲何信息孤島會存在，誰都沒有但願在建系統的時候要把它作成一個孤島。緣由在於不少時候CIO在選擇建一個整個企業的系統的時候，它是但願由應用來驅動。也就是說他在不斷建一個一個應用，好比說我要建一個ERP的應用，好比說我須要建一我的事的應用，等等有各類各樣的應用，有風險的應用。這樣你會發現每個應用他都創建起來了，可是當他創建了十個、二十個，好比說一個銀行最少有七八十個應用，建了七八十個應用之後，他就發現原來應用和應用系統之間就開始有信息孤島，而後他開始但願作整合。實際上若是說你選擇的時候若是多考慮一下平臺層的問題，你可讓信息孤島的問題有很大程度在早期就能解決，而不是到過後解決。這個平臺層，實際上最重要的一點首先就是應該考慮數據庫。你數據的庫的選擇是很是很是重要的一點，因此說若是說我以爲我給CIO第一個建議，你首先要考慮建一個平臺，而不只僅是說根據你的業務須要建各類各樣的應用，應用是須要的，可是平臺也是很是重要的。這樣在數據庫的選擇上，我以爲重要的一點在於你應該用一個數據庫即雲的服務這樣一個概念來選擇。

　　你們可能會問，你今天來說怎麼樣建數據庫的雲服務呢？你們知道如今有不少種數據庫，甲骨文固然是其中最重要的一種關係型的數據庫。甲骨文的市場份額也很是高，超過了50%。可是你會發現還有一些其餘的數據庫，甚至於還有一些開源的數據庫。好比說甲骨文很是著名的MySQL固然還有一些其餘的好比說非關係型的數據庫，好比noSQL，這些東西怎麼選擇呢？你既然要創建一個database service的平臺，你首先應該想清楚哪些你是關係型的，哪些是非關係型的，這個是最重要的一點。你今天來說，你不可能用一個關係型的數據庫來解決全部的非關係型和關係型的問題。這個世界不是一個只是非黑即白的世界，簡單來說，好比說你們知道非關係型裏面很重要一點就是noSQL和Hadoop，這裏面是最著名的技術，如今業界有一種思潮認爲我能夠用Hadoop解決全部的問題，不只僅能夠解決非關係型的問題，也能夠解決關係型的問題。這個選擇這個想法對不對呢？這個答案首先我能夠告訴各位確定是錯誤的，爲何這麼講？由於Hadoop其實是谷歌發明的技術，可是今天即便在谷歌自己它關係型的數據庫也是由關係型的數據庫解決的，並非用Hadoop解決的。

　　第二個問題在於，我是否是能夠用MySQL來解決這個問題呢？你們說既然我贊成了我不用Hadoop來解決這個問題。我用MySQL來解決這個問題能夠嗎，MySQL也是一個關係型數據庫，只是它開源而已。這裏面首先應該有一個很明確的一點，無論是甲骨文全部的企業級數據庫和甲骨文的MySQL數據庫都是來自於同一家公司甲骨文。MySQL咱們的定位它是解決一些簡單的事物性工做，而企業級是用甲骨文的企業級數據庫，你們說我是否是能夠企業級的也是能夠用MySQL解決，你到底但願你的投資是在數據庫層面上仍是在整個應用層面上。由於MySQL這樣的緣由它沒有辦法支撐數據量很大的狀況，因此他就要求把數據庫拆分。

　　舉個簡單的例子，假如說你是一個廚師，你但願你的後面有各類各樣的原料，你的原料裏面有肉，有魚，有蔬菜，可能還有一些其餘的配料。你究竟是用一個大冰箱來裝，仍是分紅若干個小冰箱來裝。若是說你分紅若干個小冰箱裝，你就要明確肉是裝在1號冰箱的，魚是裝在2號冰箱的，你的蔬菜是3號冰箱。若是你還有各類各樣的配料，你必定要很是很是清楚。所以在應用層面，你就要肯定我要取肉必定是從1號冰箱，可是若是說甲骨文的關係型數據庫，企業級數據庫你就是放在一個大冰箱，整個就是一個一千立升的冰箱，全部的東西擱進去，只要在這個冰箱裏面，就能夠取到你想要的東西。這個實際上就是甲骨文的關係型數據庫，這是一個簡單的例子和MySQL的區別。

　　也就說你選擇甲骨文的企業級數據庫，對你來說，你在應用層相對來說，你是不須要作太多的工做。反而若是說你選擇了MySQL，你須要在應用層作不少的一些工做，確保你的分庫能夠知足你整個系統的要求。這點來說你要作一個選擇，不是說MySQL不能用，而在於你究竟是需求什麼。你們會說對CIO來說，我就是但願在應用層作一些工做，而後我就把它拆成每一個庫，是否是能夠呢？答案是能夠的。可是有一個問題你們不要忘記，第一你的這個集成商你須要之後一直靠着它，這樣你對集成商的需求性是很大的，依賴性很大。某種程度他是被集成商某種程度是綁定的，這是第一個問題。

　　第二個問題，由於將來數據庫很重要的一點不只僅是這個數據庫自己，很重要一點是它的不少選件。若是說你們是使用照相機會知道，照相機上面會配各類各樣的鏡頭。照相機能拍出好多照片跟鏡頭是很是很是大的關係，MySQL上面相對的選件就會比較少，而甲骨文上面選件就會很是很是多，並非這些功能不須要。好比說安全性，好比說數據的一致性等等這些方面，都是有各類各樣的一些選件。所以來說，固然你使用MySQL之後，這些選件你都須要找人來專門開發，這樣你才能達到性能。因此你能夠看到若是你選擇MySQL，答案理論上是能夠的，問題是你是否是願意投入這麼多的資源來作這樣一件事情，咱們實際上你們能夠看到如今業界流行的方法，你把這些專業的事情留給專業的人作，其實做爲一個企業來說，數據庫的開發，選件的開發並非你的強項，你的強項是業務。

　　所以你應該把數據庫的事情給專業的數據庫的人來作，這就是甲骨文來作。因此整體來說咱們給CIO的建議，第一在你選擇你的應用的時候，在你選擇整個系統的時候，不該該僅僅考慮應用層，必定要選擇平臺層，以減小你將來的信息孤島的風險。再選擇平臺層的時候，最重要的是數據庫，數據庫的選擇，今天用Hadoop來解決全部的問題是不可能的，反過來說，用MySQL一種開源的數據庫，和甲骨文來比，的的確確均可以解決關係型數據庫的問題。可是問題是你們的價值取向不同，若是按照整體擁有成原本說必定是甲骨文的企業級數據庫擁有更好的TCO

 

SQL vs NoSQL：數據庫併發寫入性能比拼

來源: Observer專欄雜記  發佈時間: 2010-03-20 11:50  閱讀: 2704 次  推薦: 0    [收藏]  

     最近據說了不少關於NoSQL的新聞，好比以前Sourceforge改用MongoDB，Digg改用Cassandra等等。再加上以前作數據庫比較時有人推薦我mongodb，因此也搜索了一下NoSQL，以爲NoSQL可能真的是將來的趨勢。

　　NoSQL vs SQL

　　傳統SQL數據庫爲了實現ACID(atomicity, consistency, isolation, durability)，每每須要頻繁應用文件鎖，這使得其在現代的Web2.0應用中愈來愈捉襟見肘。如今SNS網站每個點擊都是一條/多條查詢，對數據庫寫的併發要求很是之高，而傳統數據庫沒法很好地應對這種需求。而仔細想來SNS中大部分需求並不要求ACID，好比Like/Unlike投票等等。

　　NoSQL吸收了教訓，好比有些NoSQL採用了eventually consistency的概念，在沒有Update操做一段時間後，數據庫將最終是consistency的，顯然這樣的數據庫將能更好的支持高併發讀寫。

　　SQL數據庫是基於schema的，這對時時刻刻更新着的Web2.0應用開發者來講是個噩夢：隨時隨地有新的應用出現，舊的數據庫沒法適應新的應用，只能不停地更新schema，或者作補丁表，如此一來要麼schema愈加混亂，要麼就是數據庫頻繁升級而耗時耗力耗錢。

　　NoSQL通常就沒有schema這種概念，大部分NoSQL都直接保存json類的Row，好比一個記錄能夠是{ id = 1, name = Bob, phone = 38492839 }，這樣擴展升級很是方便，好比須要地址信息直接加入 address=blahblah 便可。

　　傳統SQL很難進行分佈式應用，即便能夠也每每代價高昂。而NoSQL則很好地解決了這個問題：他們通常都直接從分佈式系統中吸收了Map/Reduce方法，從而很容易就能夠處理規模急速增長的問題。

　　推薦robbin牛的NoSQL數據庫探討之一 － 爲何要用非關係數據庫？一文，介紹了主流的一些NoSQL系統，還有這個站http://nosql-database.org/收集了基本上目前全部的NoSQL系統。

　　總結一下我對NoSQL的見解，NoSQL出現的目的就是爲了解決高併發讀寫的問題，而高併發應用每每須要分佈式的數據庫來實現高性能和高可靠性，因此NoSQL的關鍵字就是concurrency和scalability。

　　個人瓶頸

　　我以前主要關注數據庫的select性能也就是read性能，在讀性能方面SQL數據庫並無明顯的劣勢，應該說純粹高併發讀的性能的話每每要優於NoSQL數據庫，然而一旦涉及寫，事情就不同了。

　　我原本覺得本身不會遇到大量寫的問題，後來發現即便在simplecd這種簡單的應用環境下也會產生大量的併發寫：這就是爬VC用戶評論的時候。事實上，sqlite3在處理這個問題上很是的力不從心，因此我產生了換個數據庫的想法。

　　既然我是要求能高併發讀寫，乾脆就不用SQL了，可是同時我也想測試一下其餘SQL的寫性能。

　　個人數據有180萬條，總共350M，測試用了10個線程，每一個線程作若干次100個數據的bulk寫入，而後記錄總共耗時。結果以下:

innodb: 15.19
myiasm: 14.34
pgsql: 23.41
sqlite3: 鎖住了
sqlite3(單線程): 300+
mongodb: 3.82
couchdb: 90
couchdb(單線程)：66

　　做爲一個MySQL黑，看到這組測試數據我表示壓力很大。在SQL數據庫中，mysql意外地取得了最佳的成績，好於pgsql，遠好於sqlite。更使人意外的是myisam竟然優於號稱insert比較快的innodb。無論如何，對個人應用來講，用mysql保存評論數據是一個更爲明智的選擇。我對mysql完全改觀了，我宣佈我是mysql半黑。之後select-intensive的應用我仍是會選擇sqlite，可是insert/update-intensive的應用我就會改用mysql了。

　　MongoDB和CouchDB同爲NoSQL，表現卻截然相反，MongoDB性能很高，CouchDB的併發性能我只能ORZ，這種性能實在太抱歉了。

　　NoSQL的碎碎念

　　其實我原本還打算測試cassandra的，但是cassandra用的是java，這首先讓我眉頭一皺，內存大戶我養不起啊，其次看了cassandra的文檔，馬上崩潰，這簡直就是沒有文檔麼。（BTW，CouchDB也好不到哪裏去，我都是用python-couchdb而後help(couchdb.client)看用法的）

　　至於CouchDB，多是由於採用http方式發送請求，因此併發性能糟糕的一塌糊塗，很懷疑它是否有存在的理由。

　　MongoDB是我用下來最討人喜歡的一個NoSQL。不但文檔豐富，使用簡單，性能也很是好，它的Map/Reduce查詢(不少NoSQL都有)讓我驚歎，數據庫能夠很是簡單地就擴大規模，徹底不用理會什麼分區分表之類繁瑣的問題，惋惜這方面我暫時沒有需求。可是MongoDB有兩大體命問題。

　　第一是刪除鎖定問題，當批量刪除記錄時，數據庫仍是會鎖定不讓讀寫。這意味着進行數據清理時會讓網站應用失去響應。見locking problems

　　第二是內存佔用問題，MongoDB用了操做系統的內存文件映射，這致使操做系統會把全部空閒內存都分配給MongoDB，當MongoDB有這個須要時。更可怕的是，MongoDB歷來不主動釋放已經霸佔的內存，它只會滾雪球同樣越滾越大，除非重啓數據庫。這樣的上下文環境下，MongoDB只適合一臺主機就一個數據庫，而沒有其餘應用的環境，不然一下子功夫MongoDB就會吃光內存，而後你都fork不出新進程，完全悲劇。見memory limit

　　總之NoSQL雖然讓我眼前一亮，但是目前嘗試的一些產品都讓人望而生畏，如今的NoSQL都把目光放在了巨型網站上，而沒有一個小型的，能夠在VPS裏面應用的高性能NoSQL，令我有點失望。NoSQL還沒有成熟，很期待它的未來發展，目前來講MySQL仍是更好的選擇。

 

 

 

 

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
答：我我的以爲hadoop側重於非關係型數據庫。hbase是基於hadoop的。雖然也支持將oracle這樣的數據導入。可是天生仍是處理非關係型的。
2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
答：主要看應用和數量級。有事務要求和強一致性的用oracle的。數量級很小的用mysql。對事務無要求的用hbase。
3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
答：俗話說，三分開發，七分運維。數據庫是要維護的。定時監控，水平擴展，以及優化和災備都是必須的。優化是永遠的話題，宕機問題最棘手，因此災備必定要有。
5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
答：若是對性能有要求，那麼就是必需品。我會考慮內存計算等方面的數據庫中間件來提升性能。
6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
答：我以爲IO是最大瓶頸。若是1T的硬盤掃描一下1-2秒以內的話，那麼全部問題都不是問題了。也不用內存計算和分佈式了。
7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢
答：OLAP的時候選用rac是好的。OLTP的時候，最後別用RAC。DML的操做會使得栓鎖比較嚴重。

 

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
確定不能了，hadoop的需求定位和就不是爲了解決關係型數據庫和非關係型數據庫的使用。

2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
會考慮業務需求、系統擴展、積極高可用性、維護成本以及整體成本等緣由，平臺服務於應用，因此爲了知足應用需求咱們才選擇是用什麼平臺。

3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
固然不是一勞永逸了，後期維護、需求變動、版本升級都是須要考慮的問題。
最棘手的問題應該是數據庫遷移，系統擴容和數據安全性了。

4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
我我的以爲Oracle適合有必定數據庫量和穩定性的企業，而mysql主要是從節約成本出發所選型的數據庫。
有必定規模的企業不會捨棄安全性、穩定性去使用mysql的。

5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
選件須要根據需求決定，好比說我有數據同步的需求就須要OGG，我有高可用需求就得使用RAC等等。
我會按照業務重要性以及業務需求選用一些組件，經常使用的就是RAC ASM DG OGG等等。

6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
數據中心最大的瓶頸在於規範化和監管上。只有具備必定規範化的流程體系，才能解決瓶頸問題。
好比遇到cpu i/o 網絡相關問題，沒有好的體系流程和監管流程作什麼都不能從根本解決問題。

7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
有時候不少企業一味的認爲只要搭建了RAC就是高可用架構，這種理解很是愚昧。
多數狀況下根據業務數據量和安全性以及擴展性考慮是否選用RAC。
一個數據量不大，訪問很少的系統不建議使用RAC由於維護人員的成本也是成本。

 

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
我的以爲應該不能，若是Hadoop既能解決關係型數據庫，也能夠解決非關係型數據庫，那麼其餘的就沒有必要發展了。這些技術很難達到兩方面都俱全的。貌似雅虎的副總裁說過Hadoop在處理大量結構與非結構數據上是「很是有效的」。它適用於在傳統數據倉庫中對即時查詢需求的支持，但不能取代針對有低潛在因素需求的傳統商業智能（BI）功能的關係型數據庫管理系統（RDBMS）的部署。從這就能夠看出來。
2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
數據庫選型時，必須考慮如下五大因素： 1. 開發要求 2. 性能/成本 3. 數據庫運行和管理 4. 可升級性 5. 整體擁有成本。其餘的也會看數據庫的特色和結構，以及數據庫的設計、操做、監控各個層面都要有，應用層、平臺層都要考慮。
3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
固然不是。後續的問題還有不少的，數據庫的部署以及升級，還有運維等等。
4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
不管Linux仍是Windows，低成本確定用MySQL，須要高級支持的話，與其購買MS的只能運行於Windows的SQL Server（Windows Server也是一大筆費用），還不如買口碑更好的Oracle，盜版就不要用了。
5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
我的以爲應該算是必需品
6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
對數據中心而言我的以爲是數據庫的性能。
7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
應該不會出現濫用吧。高可用多節點時多采用RAC。事務量小，有別的簡單辦法能夠替代時，就不須要RAC。。

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
確定不能了，hadoop的需求定位和就不是爲了解決關係型數據庫和非關係型數據庫的使用。

2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
會考慮業務需求、系統擴展、積極高可用性、維護成本以及整體成本等緣由，平臺服務於應用，因此爲了知足應用需求咱們才選擇是用什麼平臺。

3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
固然不是一勞永逸了，後期維護、需求變動、版本升級都是須要考慮的問題。
最棘手的問題應該是數據庫遷移，系統擴容和數據安全性了。

4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
我我的以爲Oracle適合有必定數據庫量和穩定性的企業，而mysql主要是從節約成本出發所選型的數據庫。
有必定規模的企業不會捨棄安全性、穩定性去使用mysql的。

5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
選件須要根據需求決定，好比說我有數據同步的需求就須要OGG，我有高可用需求就得使用RAC等等。
我會按照業務重要性以及業務需求選用一些組件，經常使用的就是RAC ASM DG OGG等等。

6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
數據中心最大的瓶頸在於規範化和監管上。只有具備必定規範化的流程體系，才能解決瓶頸問題。
好比遇到cpu i/o 網絡相關問題，沒有好的體系流程和監管流程作什麼都不能從根本解決問題。

7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
有時候不少企業一味的認爲只要搭建了RAC就是高可用架構，這種理解很是愚昧。
多數狀況下根據業務數據量和安全性以及擴展性考慮是否選用RAC。
一個數據量不大，訪問很少的系統不建議使用RAC由於維護人員的成本也是成本。

 

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
我的以爲應該不能，若是Hadoop既能解決關係型數據庫，也能夠解決非關係型數據庫，那麼其餘的就沒有必要發展了。這些技術很難達到兩方面都俱全的。貌似雅虎的副總裁說過Hadoop在處理大量結構與非結構數據上是「很是有效的」。它適用於在傳統數據倉庫中對即時查詢需求的支持，但不能取代針對有低潛在因素需求的傳統商業智能（BI）功能的關係型數據庫管理系統（RDBMS）的部署。從這就能夠看出來。

2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？

數據庫選型時，必須考慮如下五大因素： 1. 開發要求 2. 性能/成本 3. 數據庫運行和管理 4. 可升級性 5. 整體擁有成本。其餘的也會看數據庫的特色和結構，以及數據庫的設計、操做、監控各個層面都要有，應用層、平臺層都要考慮。

3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
固然不是。後續的問題還有不少的，數據庫的部署以及升級，還有運維等等。

4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
不管Linux仍是Windows，低成本確定用MySQL，須要高級支持的話，與其購買MS的只能運行於Windows的SQL Server（Windows Server也是一大筆費用），還不如買口碑更好的Oracle，盜版就不要用了。

5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
我的以爲應該算是必需品

6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
對數據中心而言我的以爲是數據庫的性能。

7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
應該不會出現濫用吧。高可用多節點時多采用RAC。事務量小，有別的簡單辦法能夠替代時，就不須要RAC。。

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
答：我我的以爲hadoop側重於非關係型數據庫。hbase是基於hadoop的。雖然也支持將oracle這樣的數據導入。可是天生仍是處理非關係型的。
2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
答：主要看應用和數量級。有事務要求和強一致性的用oracle的。數量級很小的用mysql。對事務無要求的用hbase。
3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
答：俗話說，三分開發，七分運維。數據庫是要維護的。定時監控，水平擴展，以及優化和災備都是必須的。優化是永遠的話題，宕機問題最棘手，因此災備必定要有。
5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
答：若是對性能有要求，那麼就是必需品。我會考慮內存計算等方面的數據庫中間件來提升性能。
6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
答：我以爲IO是最大瓶頸。若是1T的硬盤掃描一下1-2秒以內的話，那麼全部問題都不是問題了。也不用內存計算和分佈式了。
7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢
答：OLAP的時候選用rac是好的。OLTP的時候，最後別用RAC。DML的操做會使得栓鎖比較嚴重。

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
固然不能，互聯網進修越是數據對象的特色愈來愈複雜，很難再靠一瓶萬金油抹全身。

2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
大的方面看數據庫的特色和結構，細到數據庫的設計、操做、監控各個層面都要有，應用層、平臺層都要考慮。

3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
固然不是，看運維的須要，看商業化的售後服務，固然也看數據庫的能不能有持續的完善，越是使用普遍，越升級越強大。

4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
通常傳統的商業應用，用ORACLE居多，一些數據生命週期短的，商業價值小一些的，又想少點費用的，用MySQ。L

5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
必需吧，好比RAC

6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
對數據中心而言，CPU不擔憂，能夠隨時添加，磁盤IO也有辦法規避，但數據庫的自己性能可騰挪的餘地比較少。

7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
高可用多節點時多采用。事務量小且有別的簡單辦法搞定時，就不要是RAC了

 

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
這個是不能的，首先要了解hadoop是什麼，hadoop是一個分佈式系統基礎架構，他的最核心設計是HDFS和MapReduce，HDFS爲海量的數據提供了存儲，MapReduce爲海量的數據提供計算。

2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
數據庫選型時首要是考慮客戶業務和業務涉及的數據形態，平臺要比應用更重要。

3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
沒有一勞永逸的事情，就像天上不會掉餡餅。後續數據庫參數調整、性能優化、備份恢復都是須要持續進行的事情。就像買了一臺車同樣，不能天天除了加油開車外其餘都不作了，你還須要去作保養，換機油、加玻璃水、電池更換、輪胎保養等等。

4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
應用場合我以爲並不能絕對，有時更須要從客戶的需求來看，有的用戶沒有數據庫的預算，你就須要使用mysql的免費版來使用；有的用戶預算不足，你能夠用mysql的收費版來使用；有充足的預算可使用oracle。
並不能絕對說那種場景，好比銀行裏有使用oracle，也有使用db2，informix。阿里也曾經從oracle轉向了mysql。

5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
數據庫的選件由業務或者客戶的需求決定，倒不是奢侈品也不是必需品。使用oracle數據庫時，通常考慮比較多的是RAC,Oracle Partitioning,高級分析和內存選件。其餘每款收費數據庫的選件都不一樣，但高可用性確定是排第一的。

6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
我的見解數據庫的性能仍是最大瓶頸。cpu利用率通常不高。

7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
選擇RAC多的緣由是你們都但願數據庫有一個高可用性。數據庫不可用時，其餘選件再強大也發揮不了做用。
目前不會濫用，對數據庫的可用性要求很高時，好比要求系統的可用達到99.99%時，必不可少。
若是數據對業務的影響很低，系統對用戶的使用頻率和依賴程度很低可使用免費的開源版本mysql便可，能夠不上RAC。

 

1.Hadoop是否是既能解決關係型數據庫，也能夠解決非關係型數據庫呢？爲何？
這個是不能的，首先要了解hadoop是什麼，hadoop是一個分佈式系統基礎架構，他的最核心設計是HDFS和MapReduce，HDFS爲海量的數據提供了存儲，MapReduce爲海量的數據提供計算。

2.您在購買數據庫選型的時候，重點會考慮哪些因素？應用層與平臺層哪一個更重要？
數據庫選型時首要是考慮客戶業務和業務涉及的數據形態，平臺要比應用更重要。

3.買了數據庫是否是就一勞永逸了？後續哪些問題很棘手？
沒有一勞永逸的事情，就像天上不會掉餡餅。後續數據庫參數調整、性能優化、備份恢復都是須要持續進行的事情。就像買了一臺車同樣，不能天天除了加油開車外其餘都不作了，你還須要去作保養，換機油、加玻璃水、電池更換、輪胎保養等等。

4.甲骨文擁有企業級數據庫Oracle和開源數據庫MySQL，MySQL VS Oracle，到底各自用哪些應用場合？請舉例說明。
應用場合我以爲並不能絕對，有時更須要從客戶的需求來看，有的用戶沒有數據庫的預算，你就須要使用mysql的免費版來使用；有的用戶預算不足，你能夠用mysql的收費版來使用；有充足的預算可使用oracle。
並不能絕對說那種場景，好比銀行裏有使用oracle，也有使用db2，informix。阿里也曾經從oracle轉向了mysql。

5.數據庫的選件究竟是奢侈品仍是必需品？您會考慮哪些經常使用的選件？
數據庫的選件由業務或者客戶的需求決定，倒不是奢侈品也不是必需品。使用oracle數據庫時，通常考慮比較多的是RAC,Oracle Partitioning,高級分析和內存選件。其餘每款收費數據庫的選件都不一樣，但高可用性確定是排第一的。

6.對於數據中心而言，到底哪一個成爲性能的最大瓶頸？是CPU利用率仍是數據庫的性能？
我的見解數據庫的性能仍是最大瓶頸。cpu利用率通常不高。

7.國內用戶47%的數據庫選件投資，排在第一位的是RAC，RAC會不會出現濫用的現象？到底何時該用RAC？何時不應用RAC呢？
選擇RAC多的緣由是你們都但願數據庫有一個高可用性。數據庫不可用時，其餘選件再強大也發揮不了做用。
目前不會濫用，對數據庫的可用性要求很高時，好比要求系統的可用達到99.99%時，必不可少。
若是數據對業務的影響很低，系統對用戶的使用頻率和依賴程度很低可使用免費的開源版本mysql便可，能夠不上RAC。

之前在幾個公司用過rac，不過如今以爲通常業務，用dataguard就挺好，固然兩個節點的機器應該配置強一些。
如今用的mysql主從，主庫是8塊800G的intel dc s3500 ssd 的raid10，io沒什麼wait，基本都是cpu在工做。24核cpu，128G內存，dell r720 pc server。

反觀機械硬盤的raid10的從庫，就有較大比例的io wait，6塊sas的15k的600G的raid10. raid5的老機器，那就更不用說了，io就是瓶頸