A. 不同的存儲策略的運用需要注意什麼
總的來說首先要注意屬性，然後是索引。
互聯網時代各種存儲框架層出不窮，眼花繚亂，比如傳統的關系型資料庫：Oracle、Mysql，新興的NoSQL：HBase、Cassandra、Redis，全文檢索框架：ES、Solr等。如何為自己的業務選取合適的存儲方案，相信弊棗橋大家都思考過這個問題，本文簡單聊聊我對Mysql、HBase、ES的理解，希望能和大家一起探討進步，有不對的地方還請指出。
MySQL：關系型資料庫，主要面向OLTP，支持事務，支持二級索引，支持sql，支持主從、GroupReplication架構模型（本文全部以Innodb為例，不涉及別的存儲引擎）。
HBase：基於HDFS，支持海量數據讀寫（尤其是寫），支持上億行、上百萬列的，面向列的分布式NoSql資料庫。天然分布式，主從架構，不支岩大持事務，不支持二級索引，不支持sql。
ElasticSearch：ES是一款分布式的全文檢索框架，底層基於Lucene實現，雖然ES也提供存儲，檢索功能，但我一直不認為ES是一款租猛資料庫，但是隨著ES功能越來越強大，與資料庫的界限也越來越模糊。天然分布式，p2p架構，不支持事務，採用倒排索引提供全文檢索。
B. 什麼是對象存儲
什麼是對象存儲？
存儲區域網(SAN)和網路附加存儲(NAS)是我們比較熟悉的兩種主流網路存儲架構，而對象存儲(Object-based Storage)是一種新的網路存儲架構，基於對象存儲技術的設備就是對象存儲設備(Object-based Storage Device)簡稱OSD。
對象存儲的發展歷史：
1999年成立的全球網路存儲工業協會(SNIA)的對象存儲設備(Object Storage Device)工作組發布了ANSI的X3T10標准。
對象存儲的優點：
總體上來講，對象存儲同兼具SAN高速直接訪問磁碟特點及NAS的分布式共享特點。
SAN(Storage Area Network)結構
採用SCSI 塊I/O的命令集，通過在磁碟或FC(Fiber Channel)級的數據訪問提供高性能的隨機I/O和數據吞吐率，它具有高帶寬、低延遲的優勢，在高性能計算中佔有一席之地，如SGI的CXFS文件系統就是基於SAN實現高性能文件存儲的，但是由於SAN系統的價格較高，且可擴展性較差，已不能滿足成千上萬個CPU規模的系統。
C. Druid 簡介
Druid是一款開源的，為實時和離線數據的亞秒級查詢設計的數據存儲引擎。它主要用於對事實數據（event data）進行商業智能OLAP分析。Druid提供低延時（實時）數據導入，靈活的數據探索（data exploration）和快速的數據聚合。目前Druid可以適用於萬億條和PB級的數據量，Druid最常用於面向用戶的數據分析應用枝嘩哪中。
這部分提供了Druid適合滿足的猛碼需求。如果我們要開發的應用正好有相同的需求，那麼Druid是一個很好的選擇。
這里將Druid和其他常見的數據存儲和查詢引擎進行對比，以便於更好的理解Druid使用場景。
Druid最適合的場景是，對海量實時數據，從Kafka導入到Druid中，並進行OLAP查詢。當然，Druid同時也支持離線數據的導入和查詢，也蘆答可以達到很高的查詢性能。
D. HBASE之創建表、插入值、表結構查看
hbase中的一些語句其實都很熟悉了，但是真正要用到的時候，發現其中的一些語培早句就不知道怎麼下手了。寫的很好地一篇文章，值得用的時候在回來看看。
http://www.itcast.cn/news/20201117/14100430162.shtml
HBASE基於HDFS作為默認推薦的存儲引擎，海量級別存儲時使用，HBASE中核心的組件就是RegionServer，由WAL和Region組成WAL，日誌備份Region：數據存儲。
HBASE適合海量數據、基於列的存儲，流式（實時）計算框架。
HBASE是否指模運行，可以通過在hbase shell進入執行命令：list ，正常運行即表示正常。
語法：當列族中只有一個列時，'列族名:列名 使用'列族名'
put 'table name','row1','column family: column name', 'value' 即
put '表名','行鍵','列族名', '列值' 或者
put '表名','行鍵','列族名: 列名', '列值'
其中 row1 為行鍵(即Row Key); column family：column name 為列族名和列名; value 為插入列的值。
示例
1.插入數據，插入表名為 LIB:IDL_I_ALL_DAY_UID_FEATURE_HBASE ，插入值為1的數據：
put 'LIB:IDL_I_ALL','0000030000000DIU', 'FEATURE:F_DYNAMIC_2','1'
put 'LIB:IDL_I_ALL','0000030000000DIU' ,'FEATURE:F_DYNAMIC_2_1','1'
put 'LIB:IDL_I_ALL','0000030000000DIU' ,'FEATURE:F_DYNAMIC_2_2','1'
2.插入數據，插入表名為 t_cuishou_visualize_label ，插入用戶為 90011112323232 這條數據列名為FEATURE,值為1的數據：
put 't_cuishou_visualize_label','90011112323232','data:age','28'
put 't_cuishou_visualize_label','90011112323232','data:name','張三'
put 't_cuishou_visualize_label','90011112323232','data:id','1'
表失效： disable 'ext_label_uid'
修改表壓縮方式： alter 'ext_label_uid'NAME=>'label_info',COMPRESSION=>'snappy'
表生效： enable 'ext_label_uid'
scan：獲取表的所有數據，
1、全表掃描語法： scan '表名'
例子： scan 'tbl_user'
2、掃描整個列族-語法： scan '表名',{COLUMN => '列族名'}
例子： scan 'tbl_user'，{COLUMN=>'info'}
3、掃描整個列族的某個列-語法： scan '表名',{COLUMN => '列族名:列名'}
例子： scan 'tbl_user'，{COLUMN=>'info：age'}
1、獲取數據，get語唯中緩法：get '表名','行鍵'
例子： get 'tbl_user','mengday'
2、根據某一行某列族的數據，語法：get '表名','行鍵','列族名'
例子： get 'tbl_user','mengday','info'
3、從創建到獲取數據的全實例
格式： create 'table name','column family'
其中 table name 為表名，創建表必須指定;
column family 為列族名，創建表也必須指定。
比如：
創建列族名為 label_info 的表： create 'ext_label_uid', 'label_info'
查看錶： scan 'ext_label_uid'
格式：describe 'table name'
NAME：表示列族名。
BLOOMFILTER：表示為列族級別的類型(讀者只作了解即可)。
VERIONS：表示版本數。
N_MEMORY：設置是否存入內存。
KEEP_DELETED_CELLS：設置被刪除的數據，在基於時間的歷史數據查詢中是否依然可見。
DATA_BLOCK_ENCODING：表示數據塊的演算法(讀者只作了解即可)。
TTL：表示版本存活的時間。
COMPRESSION：表示設置壓縮演算法。
MIN_VERSIONS：表示最小版本數。
BLOCKCACHE：表示是否設置讀緩存。
REPLICATION：表示設置備份。
E. 趙弘揚：阿里雲Elasticsearch技術演進之路
導讀： 全文將圍繞以下三方面內容介紹睜鍵罩阿里雲Elasticsearch技術。
01
阿里雲Elasticsearch業務
1. 業務規模
阿里雲Elasticsearch業務（簡稱ES），從2017年至今已經服務了幾千個客戶，數據規模達20PB，在公共雲上擁有10000+集群，10W+節點規模，是一個成熟的雲原生服務。
2. Elasticsearch在日誌場景通常會遇到的問題
在企業的數字化轉型過程中會生成大量日誌數據，企業通過Elasticsearch滿足日誌檢索、存儲、歸檔審計的需求，而這些需求歸根結底都會落到成亮凳本的增加，體現在以下三個方面：
3. 風險解讀
在正常情況下，流量到ES協調節點，然後將數據寫入Data Node；當流量變成正常情況的10倍時，對ES集群的壓力就變得很大，一系列問題會接踵而來。
這種情況可以通過集群擴容的方式進行緩解，但擴容的同時又會產生新的問題：
① 穩定性風險
② 運維復雜度風險
③ 成本風險
--
02
阿里雲Elasticsearch日誌Serverless服務
1. 日誌Serverless服務能力解讀
基於上述問題和風險，阿里雲引入了 兩個新功能 ：
① Indexing Service
Indexing Service是一個超大的ES集群陣列，專做Indexing Build，每個客戶可靈活使用， 它具有以下特性：
圖中灰色虛線內是用戶的ES集群，當流量洪峰到來時，用戶可以將流量轉發至Indexing Service的SLB中進行build index，然後通過segment merge的方式，回到用戶ES集群的Data Node。這樣通過外部的雲上彈性服務，減輕了用戶ES集群壓力，實現秒級彈性擴縮容的需求。
② 智能海量存儲引擎
2. 日誌Serverless服務價值解讀
① Serverless日誌寫入服務：Indexing Service
通過讀寫分離架構，ES集群的數據寫入在雲端服務進行託管加速，為用戶實例和雲端服務搭建橋梁，依託雲端彈性計算能力，突破本地集群的物理資源限制。
對比開源ELK生態：
② Serverless日誌存儲服務：智能海量存儲引擎
基於計算存儲分離架構及多層存儲介質混合，提供可靠的海量彈性低成本存儲並保證查詢性能，無須提前預留集群存儲容量，根據實際數據的存儲量按量計費。
3. Elasticsearch日誌Serverless服務發布
全球范圍內首個在雲上提供Serverless能力的雲原生Elasticsearch服務， 其核心價值體現在三個方面：
4. 真實案例收益
①客戶場景描述
汽車 行業的IT系統，大多是分批建設，技術架構及系統復雜有 歷史 包袱，IDC、多雲架構比較普遍。新興的業務部門，一方面需要滿足政策合規要求，一方面希望對整體日誌數據進行價值挖掘，通常會遇到如下悉鬧問題：
②方案構架及價值點
--
03
阿里雲Elasticsearch技術演進之路
阿里雲Elasticsearch技術演進圖
Elasticsearch未來的發展會繼續在雲原生Serverless上進行演進和迭代，在日誌場景下優化成本，通過服務化的能力提升日誌場景中的ES產品的易用性，幫助客戶解決日誌場景下前置日誌鏈路上的問題。
同時，與ES社區就Elasticsearch TSDB時序引擎進行共建，相信很快可以在未來的ES新版本中推出TSDB能力。
今天的分享就到這里，謝謝大家。
分享嘉賓：趙弘揚 阿里雲 高級產品專家
出品平台：DataFunTalk
01/ 分享嘉賓
02/ 報名看直播 免費領PPT
04/ 關於我們
歡迎轉載分享評論，轉載請私信。
F. 海量數據存儲
存儲技術經歷了單個磁碟、磁帶、RAID到網路存儲系統的發展歷程。網路存儲技術就是將網路技術和I/O技術集成起來，利用網路的定址能力、即插即用的連接性、靈活性，存儲的高性能和高效率，提供基於網路的數據存儲和共享服務。在超大數據量的存儲管理、擴展性方面具有明顯的優勢。
典型的網路存儲技術有網路附加存儲NAS（Network Attached Storage）和存儲區域網SAN（Storage Area Networks）兩種。
1）NAS技術是網路技術在存儲領域的延伸和發展。它直接將存儲設備掛在網上，有良好的共享性、開放性。缺點是與LAN共同用物理網路，易形成擁塞，而影響性能。特別是在數據備份時，性能較低，影響在企業存儲應用中的地位。
2）SAN技術是以數據存儲為中心，使用光纖通道連接高速網路存儲的體系結構。即將數據存儲作為網路上的一個區域獨立出來。在高度的設備和數據共享基礎上，減輕網路和伺服器的負擔。因光纖通道的存儲網和LAN分開，使性能得到很大的提高，而且還提供了很高的可靠性和強大的連續業務處理能力。在SAN中系統的擴展、數據遷移、數據本地備份、遠程數據容災數據備份和數據管理等都比較方便，整個SAN成為一個統一管理的存儲池（Storage Pool）。SAN存儲設備之間通過專用通道進行通信，不佔用伺服器的資源。因此非常適合超大量數據的存儲，成為網路存儲的主流。
3）存儲虛擬化技術是將系統中各種異構的存儲設備映射為一個單一的存儲資源，對用戶完全透明，達到互操作性的目的和利用已有的硬體資源，把SAN內部的各種異構的存儲資源統一成一個單一視圖的存儲池，可根據用戶的需要方便地切割、分配。從而保持已有的投資，減少總體成本，提高存儲效率。
存儲虛擬化包括3個層次結構：基於伺服器的虛擬化存儲、基於存儲設備的虛擬化存儲和基於網路的虛擬化存儲。
1）基於伺服器的虛擬化存儲由邏輯管理軟體在主機/伺服器上完成。經過虛擬化的存儲空間可跨越多個異構的磁碟陣列，具有高度的穩定性和開放性，實現容易、簡便。但對異構環境和分散管理不太適應。
2）基於存儲設備的虛擬化存儲，因一些高端磁碟陣列本身具有智能化管理，可以實現同一陣列，供不同主機分享。其結構性能可達到最優。但實現起來價格昂貴，可操作性差。
3）基於網路的虛擬化存儲，通過使用專用的存儲管理伺服器和相應的虛擬化軟體，實現多個主機/伺服器對多個異構存儲設備之間進行訪問，達到不同主機和存儲之間真正的互連和共享，成為虛擬存儲的主要形式。根據不同結構可分為基於專用伺服器和基於存儲路由器兩種方式。①基於專用伺服器的虛擬化，是用一台伺服器專用於提供系統的虛擬化功能。根據網路拓撲結構和專用伺服器的具體功能，其虛擬化結構有對稱和非對稱兩種方式。在對稱結構中數據的傳輸與元數據訪問使用同一通路。實現簡單，對伺服器和存儲設備的影響小，對異構環境的適應性強。缺點是專用伺服器可能成為系統性能的瓶頸，影響SAN的擴展。在非對稱結構中，數據的傳輸與元數據訪問使用不同通路。應用伺服器的I/O命令先通過命令通路傳送到專用伺服器，獲取元數據和傳輸數據視圖後，再通過數據通路得到所需的數據。與對稱結構相比，提高了存儲系統的性能，增加了擴展能力。②基於存儲路由器的SAN虛擬化，存儲路由器是一種智能化設備，既具有路由器的功能，又針對I/O進行專門優化。它部署在存儲路由器上，多個存儲路由器保存著整個存儲系統中的元數據多個副本，並通過一定的更新策略保持一致性。這種結構中，因存儲路由器具有強大的協議功能，所以具有更多的優勢。能充分利用存儲資源，保護投資。能實現軟硬體隔離，並輔有大量的自動化工具，提高了虛擬伺服器的安全性，降低對技術人員的需求和成本。
G. 大數據的核心技術有哪些
大數據技術的體系龐大且復雜，基礎的技術包含數據的採集、數據預處理、分布式存儲、資料庫、數據倉庫、機器學習、並行計算、可視化等。
1、數據採集與預處理：
Flume NG實時日誌收集系統，支持在日誌系統中定製各類數據發送方，用於收集數據；
Zookeeper是一個分布式的，開放源碼的分布式應用程序協調服務，提供數據同步服務。
2、數據存儲：
Hadoop作為一個開源的框架，專為離線和大規模數據分析而設計，HDFS作為其核心的存儲引擎，已被廣泛用於數據存儲。
HBase，是一個分布式的、面向列的開源資料庫，可以認為是hdfs的封裝，本質是數據存儲、NoSQL資料庫。
3、數據清洗：MapRece作為Hadoop的查詢引擎，用於大規模數據集的並行計算
4、數據查詢分析：
Hive的核心工作就是把SQL語句翻譯成MR程序，可以將結構化的數據映射為一張資料庫表，並提供 HQL(Hive SQL)查詢功能。
Spark 啟用了內存分布數據集，除了能夠提供互動式查詢外，它還可以優化迭代工作負載。
5、數據可視化：對接一些BI平台，將分析得到的數據進行可視化，用於指導決策服務。
H. 曲靖java培訓學校告訴你大規模資料庫的性能和伸縮性的優化
在需要支持移動/平板電腦應用及普通桌面瀏覽器訪問的時代，網站的普及率和有效性很大叢猜程度上取決於其可用性和性能。一個訪問緩慢的網站會使得訪問者或潛在的客戶流失，並導致商業的失敗。IT培訓http://www.kmbdqn.cn/認為一個訪問速度相當快的網站將會決定訪客是否會使用網站提供的產品或服務。
擁有大規模資料庫的網站始終需要適當的關注、配置、優化、調整和維護，以確保網站的快速載入。這篇文章將討論如何優化有海量數據的MySQL資料庫。
選擇InnoDB作為存儲引擎
大型產品的資料庫對於可靠性和並發性的要求較高，InnoDB作為默認的MySQL存儲引擎，相對於MyISAM來說是個更佳的選擇。
優化資料庫結構
組織資料庫的schema、表和欄位以降低I/O的開銷，將相關項保存在一起，並提前規劃，以便隨著數據量的增長，性能可以保持較高的水平。
設計數據表應盡量使其佔用的空間最小化，表的主鍵應盡吵清可能短。
對於InnoDB表，主鍵所在的列在每個輔助索引條目中都是可復制的，因此如果有很多輔助索引，那麼一個短的主鍵可以節省大量空間。
僅創建你需要改進查詢性能的索引。索引有助於檢索，但是會增加插入和更新操作的執行時升鄭前間。
InnoDB的ChangeBuffering特性
InnoDB提供了changebuffering的配置，可減少維護輔助索引所需的磁碟I/O。大規模的資料庫可能會遇到大量的表操作和大量的I/O，以保證輔助索引保持最新。當相關頁面不在緩沖池裡面時，InnoDB的changebuffer將會更改緩存到輔助索引條目，從而避免因不能立即從磁碟讀取頁面而導致耗時的I/O操作。當頁面被載入到緩沖池時，緩沖的更改將被合並，更新的頁面之後會刷新到磁碟。這樣做可提高性能，適用於MySQL5.5及更高版本。
I. SQL Server 和 Oracle 以及 MySQL 有哪些區別
三者是目前市場佔有率最高（依安裝量而非收入）的關系資料庫，而且很有代表性。排行第四的DB2（屬IBM公司），與Oracle的定位和架構非常相似，就不贅述了。
如果要說明三者的區別，首先就要從歷史入手。
Oracle：中文譯作甲骨文，這是一家傳奇的公司，有一個傳奇的大老闆Larry Ellision。 Ellision 32歲還一事無成，讀了三個大學，沒得到一個學位文憑，換了十幾家公司，老婆也離他而去。開始創業時只有1200美元，卻使得Oracle公司連續12年銷售額每年翻一番。
Oracle成立於1977年，早期的理論基礎，反而來自於一篇IBM的論文《A Relational Model of Data for Large Shared Data Banks》【1】。作者CODD選取了關系代數的五種運算，並基於運算，架構了一種新型的數據存儲模型。基於這種模型，Oracle成為了一個非常典型的關系歷拿資料庫。因此也變的嚴謹、安全、高速、穩定，並且變的越來越龐大。
由於其誕生早、結構嚴謹、高可用、高性能等特點，使其在傳統資料庫應用中大殺四方，金融、通信、能源、運輸、零售、製造等各個行業的大型公司基本都是用了Oracle，早些年的時候，世界500強幾乎100%都是Oracle的用戶。
MySQL ：MySQL的最初的核心思想，主要是開源、簡便易用。其開發可追溯至1985年，而第一個內部發行版本誕生，已經是1995年。到1998年，MySQL已經可以支持10中操作系統了，其中就包括win平台。但依然問題多多，如不支持事務操作、子查詢 、辯冊外鍵、存儲過程和視圖等功能。下圖是一個截止至2006年的資料庫市場佔有率【2】：
圖中可以看出，MySQL的爆發實際是在01、02年，尤其是02年發布的4.0 Beta版，正式選定InnoDB作為默認引擎，對事務處理能力及數據緩存能力有了極大的提高。同年4.1版開始支持子查詢，至此MySQL終於蛻變成一個成熟的關系型資料庫系統。05年的5.0版本又添加了存儲過程、服務端游標、觸發器、查詢優化以及分布式事務功能，但同年被Oracle抄了後路，InnoDB被Oracle收編。08年，MySQL被Sun收購，09年，Oracle收購了Sun和MySQL。
由於MySQL的早期定位，其主要應用場景就是互聯網開發。基本上，互聯網的爆發成就了MySQL，LAMP架構風靡天下。而由於MySQL更多的的追求輕量、易用，以及早期的事物操作及復雜查詢優化的缺失，在傳統的資料庫應用場景中，份額極少。
SQL Server：一提到SQL Server，大家一般都只想到Microsoft SQL Server，而非Sybase SQL Server。SQL Server最初是由Microsoft, Sybase and Ashton-Tate三家公司攔下的生意，是為IBM（又出現了）公司的OS/2操作系統開發的。隨著OS/2項目的失敗，大家也分道揚鑣。 Microsoft自然轉向自己的win操作系統，作為windows NT軟體方案的一部分。而Sybase則專注於Linux/Unix方向的資料庫開發。
MS SQL Server主要面向中小企業。其最大的優勢就是在於集成了MS公司的各類產品及資源，提供了強大的可視化界面、高度集成的管理開發工具，在快速構建商業智能（BI）方面頗有建樹。 MS SQL Server是MS公司在軟體集成方案中的重要一環，也為WIN系統在企業級應用中的普及做出了很大貢獻。
典型應用場景
關於「大型資料庫」，並沒有嚴格的界定，有說以數據量為准，有說以恢復時間為准。如果綜合資料庫應用場景來說，大型資料庫應肢灶搭用有以下特點：海量數據、高吞吐量；復雜邏輯、高計算量，以及高可用性。從這點上來說，Oracle，DB2就是比較典型的大型資料庫，Sybase SQL Server也算是吧。下面分別說明之前三種資料庫的應用場景。
Oracle。Oracle的應用，主要在傳統行業的數據化業務中，比如：銀行、金融這樣的對可用性、健壯性、安全性、實時性要求極高的業務；零售、物流這樣對海量數據存儲分析要求很高的業務。此外，高新製造業如晶元廠也基本都離不開Oracle；電商也有很多使用者，如京東（正在投奔Oracle）、阿里巴巴（計劃去Oracle化）。而且由於Oracle對復雜計算、統計分析的強大支持，在互聯網數據分析、數據挖掘方面的應用也越來越多。一個典型場景是這樣的：
某電信公司（非國內）下屬某分公司的數據中心，有4台Oracle Sun的大型伺服器用來安裝Solaris操作系統和Oracle並提供計算服務，3台Sun Storage磁碟陣列來提供Oracle數據存儲，12台IBM小型機，一台Oracle Exadata伺服器，一台500T的磁帶機用來存儲歷史數據，San連接內網，使用Tuxedo中間件來保證擴展性和無損遷移。建立支持高並發的Oracle資料庫，通過OLTP系統用來對海量數據實時處理、操作，建立高運算量的Oracle數據倉庫，用OLAP系統用來分析營收數據及提供自動報表。總預算約750萬美金。
MySQL。MySQL基本是生於互聯網，長於互聯網。其應用實例也大都集中於互聯網方向，MySQL的高並發存取能力並不比大型資料庫差，同時價格便宜，安裝使用簡便快捷，深受廣大互聯網公司的喜愛。並且由於MySQL的開源特性，針對一些對資料庫有特別要求的應用，可以通過修改代碼來實現定向優化，例如SNS、LBS等互聯網業務。一個典型的應用場景是：
某互聯網公司，成立之初，僅有PC數台，通過LAMP架構迅速搭起網站框架。隨著業務擴張、市場擴大，迅速發展成為6台Dell小型機的中型網站。現在花了三年，終於成為垂直領域的最大網站，計劃中的數據中心，擁有Dell機架式伺服器40台，總預算20萬美金。
MS SQL Server。windows生態系統的產品，好處壞處都很分明。好處就是，高度集成化，微軟也提供了整套的軟體方案，基本上一套win系統裝下來就齊活了。因此，不那麼缺錢，但很缺IT人才的中小企業，會偏愛 MS SQL Server 。例如，自建ERP系統、商業智能、垂直領域零售商、餐飲、事業單位等等。
1996年，Bill Gates親自出手，從Borland挖來了大牛Anders，搞定了C#語言。微軟02年搞定了http://ASP.NET。成熟的.NET、Silverlight技術，為 MS SQL Server贏得了部分互聯網市場，其中就有曾經的全球最大社交網站MySpace，其發展歷程很有代表性，可作為一個比較特別的例子【3】。其巔峰時有超過1.5億的注冊用戶及每月400億的訪問量。應該算是MS SQL Server支撐的最大的數據應用了。
架構。其實要說執行的區別，主要還是架構的區別。正是架構導致了相同SQL在執行過程中的解釋、優化、效率的差異。這里只做粗略說明，就不細說了：
Oracle： 數據文件包括：控制文件、數據文件、重做日誌文件、參數文件、歸檔文件、密碼文件。這是根據文件功能行進行劃分，並且所有文件都是二進制編碼後的文件，對資料庫演算法效率有極大的提高。由於Oracle文件管理的統一性，就可以對SQL執行過程中的解析和優化，指定統一的標准：
RBO（基於規則的優化器）、CBO（基於成本的優化器）
通過優化器的選擇，以及無敵的HINT規則，給與了SQL優化極大的自由，對CPU、內存、IO資源進行方方面面的優化。
MySQL：最大的一個特色，就是自由選擇存儲引擎。每個表都是一個文件，都可以選擇合適的存儲引擎。常見的引擎有 InnoDB、 MyISAM、 NDBCluster等。但由於這種開放插件式的存儲引擎，比如要求資料庫與引擎之間的松耦合關系。從而導致文件的一致性大大降低。在SQL執行優化方面，也就有著一些不可避免的瓶頸。在多表關聯、子查詢優化、統計函數等方面是軟肋，而且只支持極簡單的HINT。
SQL Server ：數據架構基本是縱向劃分，分為：Protocol Layer（協議層）， Relational Engine（關系引擎）， Storage Engine（存儲引擎）， SQLOS。SQL執行過程就是逐層解析的過程，其中Relational Engine中的優化器，是基於成本的（CBO），其工作過程跟Oracle是非常相似的。在成本之上也是支持很豐富的HINT，包括：連接提示、查詢提示、表提示。
J. nuclear(一種網路數據存儲系統)詳細資料大全
Nuclear存儲系統，是中國最大的SNS網站人人網下屬UGC團隊在遇到海量的UGC數據存儲需求情況下，開發的在高性能、高可靠、可擴展方面有著優良表現的海量數據存儲系統。
它參考了dynamo設計文檔，並且分析了現存開源no-sql系統的優劣，完整分析了Cassandra、Voldemort代碼的基礎之上，在UGC小組的努力下，加入了自動平衡機器負載，簡單切換底層引擎等特色而適用的功能，還有相關的附屬功能，可以使一個系統從普通的DB輕易將數據移到nuclear集群中來。
基本介紹
- 中文名 ：Nuclear存儲系統攔友
- 外文名 ：Nuclear
- 所屬機構 ：人人網下屬UGC團隊
- 參考 ：dynamo設計文檔，開源no-sql系統
分區
Nuclear是一個分散式的Key-Value存儲系統，那麼key對應的數據分布在簡棗槐什麼節點上，需要遵守一定的規則。熟悉MemecachedClient的同學一定清楚一致性Hash的套用，沒錯，HashRing就是我們的不二選擇。在Nuclear中，數據分布在0~2的HashRing上，Nuclear集群初始化的時候，根據節點數均分整個Hash Ring。 在N=3時，A,B,C三個節點的配置就是系統需要的最少節點了。Nuclear中，順時針的開始值和結束值確定一個分區管理的數據范圍，同時規定分區的范圍左開右閉。因此，如上圖，我們記錄A,B,C分別管理的分區范圍是： A {[c,a],[b, c],[a,b]} B {[a,b],[c,a],[b,c]} C {[b,c],[a,b],[c,a]} 可以看出，A處理管理自己的分區數據外，還會把自己管理的數據順時針往前復制到2(N-1)個節點中。節點變更
Nuclear增加節點時需要制定目標節點的名稱，即增加的節點是用來分擔目標節點的負載的。這點不同於Dynamo的分區策略，節點增加的時候會均衡的從現有的節點竊取分區，Nuclear中增加的節點只會影響到鄰近的三個節點。 記錄N,A,B,C管理的分區如下： N {[c,n],[b,c],[a,b]} A {[n,a],[c,n],[b,c]} B {[a,b],[n,a],[c,n]} C {[b,c],[a,b],[n,a]} Nuclear的分區管理模組將自動的計算出需要同步到N上的數據: A [a,b] => N B [b,c] => N C [c,n] => N 不難明白，其實就是把A,B,C不再需要的數據挪給新的節點了。刪、替換節點原理大同小異，不再冗述。路由
Nuclear提供伺服器端路由策略，Client的請求隨機落在Node節點上，由接收到請求的節點處理後續的邏輯。相對於Client端路由來說，優點是Client無需知道Nuclear集群元數據，易於維護；缺點是會造成一定程度的延時，不過我們的測試結果顯示延時在可接受范圍之內。 兩個設計上的Tips貢獻給大家: 1. 萬事皆非同步 我們在編碼的過程中走了一些彎路，同步的操作在高並發的情況下帶來的性能下降是非常恐怖的，於是乎，Nuclear系統中任何的高並發操作都岩含消除了Block。no waiting, no delay。 2. 根據系統負載控制後台執行緒的資源佔用 Nuclear系統中有不少的後台執行緒默默無聞的做著各種辛苦的工作，但是它們同樣會佔用系統資源，我們的解決方案是根據系統負載動態調整執行緒的運行和停止，並達到平衡。特性
高可拓展
一個Nuclear集群支持1到n(n<2的64平方)個節點(Node)的規模，每台伺服器(Server)支持部署多個節點。當集群資源達到瓶頸時，可以通過增加新的節點來擴展。增加新節點的過程，系統服務無需停止，無需人工干預遷移數據。Nuclear理論上可以無限Scale-Out。高可靠性
單個節點的crash永遠對系統的運行造成影響，不存在單點風險。數據的寫入參考Dynamo的W+R>N理論，簡釋之，例如設定系統每一份數據都存儲在3個節點上(N=3)，那麼讀的話必須成功讀到兩個節點上的數據才認為讀成功 (R=2)，寫的話必須成功寫到兩個節點上才認為寫成功( W=2)。系統永遠可寫入(Hinted HandOff)。高性能
在Xeon E5405 CPU的伺服器上，單節點每秒最高2.5w req/s。整個集群的性能取決於一致性級別、N、W、R數及底層存儲引擎的選擇。