A. LBS資料庫的架構是怎樣的
架構的話有很多嘗試，傳統的Oracle和 Postgre用的比較廣泛, 很多架構在此基礎上同時應用 NoSQL。因為大多數LBS並不涉及更復雜的空間數據存儲，例如多邊形或者三維數據，因此，大多數generic的資料庫架構都可以應用。但是，從產品核心的設計以及發展來看，如果像FourSquare(4SQ)進行數據挖掘並提供收費的數據分析服務，那麼基於空間的利用文件數據結構，以空間POI為基礎的NoSQL，是比較好的選擇。除了其他人介紹的很多LBS，比如街旁和4SQ，應用的Mongo DB， 還有Couch DB, 根據之前來講課的澳洲政府的一個大型空間資料庫項目(集成了多種現有的空間資料庫)的構架師介紹，這個項目應用了Couch DB。雖然理論上Graphic的NoSQL對於存儲空間數據也有很大優勢，但是畢竟相對不成熟，所以實際應用中的NoSQL還是以doc結構的Mongo和Couch為主。
如何提高命中率關鍵是對存儲的空間數據認識程度和對用戶query的類型的統計分析，並在此基礎上開發出適合的演算法，建立緩存或者對傳統的空間索引進行組合，例如應用一些refine-filter策略。空間數據的索引與傳統的索引不同，但是又部分基於傳統索引的基礎之上的。這里只介紹一些簡單的空間索引入門演算法，最後簡單談一下緩存建立的策略。
B. 大數據量高並發訪問資料庫結構的設計
大數據量高並發訪問資料庫結構的設計
如果不能設計一個合理的資料庫模型，不僅會增加客戶端和伺服器段程序的編程和維護的難度，而且將會影響系統實際運行的性能。所以，在一個系統開始實施之前，完備的資料庫模型的設計是必須的。
在一個系統分析、設計階段，因為數據量較小，負荷較低。我們往往只注意到功能的實現，而很難注意到性能的薄弱之處，等到系統投入實際運行一段時間後，才發現系統的性能在降低，這時再來考慮提高系統性能則要花費更多的人力物力，而整個系統也不可避免的形成了一個打補丁工程。
所以在考慮整個系統的流程的時候，我們必須要考慮，在高並發大數據量的訪問情況下，我們的系統會不會出現極端的情況。（例如：對外統計系統在7月16日出現的數據異常的情況，並發大數據量的的訪問造成，資料庫的響應時間不能跟上數據刷新的速度造成。具體情況是：在日期臨界時（00：00：00），判斷資料庫中是否有當前日期的記錄，沒有則插入一條當前日期的記錄。在低並發訪問的情況下，不會發生問題，但是當日期臨界時的訪問量相當大的時候，在做這一判斷的時候，會出現多次條件成立，則資料庫里會被插入多條當前日期的記錄，從而造成數據錯誤。），資料庫的模型確定下來之後，我們有必要做一個系統內數據流向圖，分析可能出現的瓶頸。
為了保證資料庫的一致性和完整性，在邏輯設計的時候往往會設計過多的表間關聯，盡可能的降低數據的冗餘。（例如用戶表的地區，我們可以把地區另外存放到一個地區表中）如果數據冗餘低，數據的完整性容易得到保證，提高了數據吞吐速度，保證了數據的完整性，清楚地表達數據元素之間的關系。而對於多表之間的關聯查詢（尤其是大數據表）時，其性能將會降低，同時也提高了客戶端程序的編程難度，因此，物理設計需折衷考慮，根據業務規則，確定對關聯表的數據量大小、數據項的訪問頻度，對此類數據表頻繁的關聯查詢應適當提高數據冗餘設計但增加了表間連接查詢的操作，也使得程序的變得復雜，為了提高系統的響應時間，合理的數據冗餘也是必要的。設計人員在設計階段應根據系統操作的類型、頻度加以均衡考慮。
另外，最好不要用自增屬性欄位作為主鍵與子表關聯。不便於系統的遷移和數據恢復。對外統計系統映射關系丟失（******************）。
原來的表格必須可以通過由它分離出去的表格重新構建。使用這個規定的好處是，你可以確保不會在分離的表格中引入多餘的列，所有你創建的表格結構都與它們的實際需要一樣大。應用這條規定是一個好習慣，不過除非你要處理一個非常大型的數據，否則你將不需要用到它。（例如一個通行證系統，我可以將USERID，USERNAME，USERPASSWORD，單獨出來作個表，再把USERID作為其他表的外鍵）
表的設計具體注意的問題：
1、數據行的長度不要超過8020位元組，如果超過這個長度的話在物理頁中這條數據會佔用兩行從而造成存儲碎片，降低查詢效率。
2、能夠用數字類型的欄位盡量選擇數字類型而不用字元串類型的（電話號碼），這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接回逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
3、對於不可變字元類型char和可變字元類型varchar都是8000位元組,char查詢快，但是耗存儲空間，varchar查詢相對慢一些但是節省存儲空間。在設計欄位的時候可以靈活選擇，例如用戶名、密碼等長度變化不大的欄位可以選擇CHAR，對於評論等長度變化大的欄位可以選擇VARCHAR。
4、欄位的長度在最大限度的滿足可能的需要的前提下，應該盡可能的設得短一些，這樣可以提高查詢的效率，而且在建立索引的時候也可以減少資源的消耗。
5、基本表及其欄位之間的關系, 應盡量滿足第三範式。但是，滿足第三範式的資料庫設計，往往不是最好的設計。為了提高資料庫的運行效率，常常需要降低範式標准：適當增加冗餘，達到以空間換時間的目的。
6、若兩個實體之間存在多對多的關系，則應消除這種關系。消除的辦法是，在兩者之間增加第三個實體。這樣，原來一個多對多的關系，現在變為兩個一對多的關系。要將原來兩個實體的屬性合理地分配到三個實體中去。這里的第三個實體，實質上是一個較復雜的關系，它對應一張基本表。一般來講，資料庫設計工具不能識別多對多的關系，但能處理多對多的關系。
7、主鍵PK的取值方法，PK是供程序員使用的表間連接工具，可以是一無物理意義的數字串, 由程序自動加1來實現。也可以是有物理意義的欄位名或欄位名的組合。不過前者比後者好。當PK是欄位名的組合時，建議欄位的個數不要太多，多了不但索引佔用空間大，而且速度也慢。
8、主鍵與外鍵在多表中的重復出現, 不屬於數據冗餘，這個概念必須清楚，事實上有許多人還不清楚。非鍵欄位的重復出現, 才是數據冗餘！而且是一種低級冗餘，即重復性的冗餘。高級冗餘不是欄位的重復出現，而是欄位的派生出現。
〖例4〗：商品中的「單價、數量、金額」三個欄位，「金額」就是由「單價」乘以「數量」派生出來的，它就是冗餘，而且是一種高級冗餘。冗餘的目的是為了提高處理速度。只有低級冗餘才會增加數據的不一致性，因為同一數據，可能從不同時間、地點、角色上多次錄入。因此，我們提倡高級冗餘(派生性冗餘)，反對低級冗餘(重復性冗餘)。
9、中間表是存放統計數據的表，它是為數據倉庫、輸出報表或查詢結果而設計的，有時它沒有主鍵與外鍵(數據倉庫除外)。臨時表是程序員個人設計的，存放臨時記錄，為個人所用。基表和中間表由DBA維護，臨時表由程序員自己用程序自動維護。
10、防止資料庫設計打補丁的方法是「三少原則」
(1) 一個資料庫中表的個數越少越好。只有表的個數少了，才能說明系統的E--R圖少而精，去掉了重復的多餘的實體，形成了對客觀世界的高度抽象，進行了系統的數據集成，防止了打補丁式的設計；
(2) 一個表中組合主鍵的欄位個數越少越好。因為主鍵的作用，一是建主鍵索引，二是做為子表的外鍵，所以組合主鍵的欄位個數少了，不僅節省了運行時間，而且節省了索引存儲空間；
(3) 一個表中的欄位個數越少越好。只有欄位的個數少了，才能說明在系統中不存在數據重復，且很少有數據冗餘，更重要的是督促讀者學會「列變行」，這樣就防止了將子表中的欄位拉入到主表中去，在主表中留下許多空餘的欄位。所謂「列變行」，就是將主表中的一部分內容拉出去，另外單獨建一個子表。這個方法很簡單，有的人就是不習慣、不採納、不執行。
資料庫設計的實用原則是：在數據冗餘和處理速度之間找到合適的平衡點。「三少」是一個整體概念，綜合觀點，不能孤立某一個原則。該原則是相對的，不是絕對的。「三多」原則肯定是錯誤的。試想：若覆蓋系統同樣的功能，一百個實體(共一千個屬性) 的E--R圖，肯定比二百個實體(共二千個屬性)的E--R圖，要好得多。
提倡「三少」原則，是叫讀者學會利用資料庫設計技術進行系統的數據集成。數據集成的步驟是將文件系統集成為應用資料庫，將應用資料庫集成為主題資料庫，將主題資料庫集成為全局綜合資料庫。集成的程度越高，數據共享性就越強，信息孤島現象就越少，整個企業信息系統的全局E—R圖中實體的個數、主鍵的個數、屬性的個數就會越少。
提倡「三少」原則的目的，是防止讀者利用打補丁技術，不斷地對資料庫進行增刪改，使企業資料庫變成了隨意設計資料庫表的「垃圾堆」，或資料庫表的「大雜院」，最後造成資料庫中的基本表、代碼表、中間表、臨時表雜亂無章，不計其數，導致企事業單位的信息系統無法維護而癱瘓。
「三多」原則任何人都可以做到，該原則是「打補丁方法」設計資料庫的歪理學說。「三少」原則是少而精的原則，它要求有較高的資料庫設計技巧與藝術，不是任何人都能做到的，因為該原則是杜絕用「打補丁方法」設計資料庫的理論依據。
11、在給定的系統硬體和系統軟體條件下，提高資料庫系統的運行效率的辦法是：
(1) 在資料庫物理設計時，降低範式，增加冗餘, 少用觸發器, 多用存儲過程。
(2) 當計算非常復雜、而且記錄條數非常巨大時(例如一千萬條)，復雜計算要先在資料庫外面，以文件系統方式用編程語言計算處理完成之後，最後才入庫追加到表中去。
(3) 發現某個表的記錄太多，例如超過一千萬條，則要對該表進行水平分割。水平分割的做法是，以該表主鍵PK的某個值為界線，將該表的記錄水平分割為兩個表。若發現某個表的欄位太多，例如超過八十個，則垂直分割該表，將原來的一個表分解為兩個表。
(4) 對資料庫管理系統DBMS進行系統優化，即優化各種系統參數，如緩沖區個數。
(5) 在使用面向數據的SQL語言進行程序設計時，盡量採取優化演算法。
總之，要提高資料庫的運行效率，必須從資料庫系統級優化、資料庫設計級優化、程序實現級優化，這三個層次上同時下功夫。
主鍵設計：
1、不建議用多個欄位做主鍵，單個表還可以，但是關聯關系就會有問題，主鍵自增是高性能的。
2、一般情況下，如果有兩個外鍵，不建議採用兩個外鍵作為聯合住建，另建一個欄位作為主鍵。除非這條記錄沒有邏輯刪除標志，且該表永遠只有一條此聯合主鍵的記錄。
3、一般而言，一個實體不能既無主鍵又無外鍵。在E—R 圖中, 處於葉子部位的實體, 可以定義主鍵，也可以不定義主鍵(因為它無子孫), 但必須要有外鍵(因為它有父親)。
主鍵與外鍵的設計，在全局資料庫的設計中，佔有重要地位。當全局資料庫的設計完成以後，有個美國資料庫設計專家說：「鍵，到處都是鍵，除了鍵之外，什麼也沒有」，這就是他的資料庫設計經驗之談，也反映了他對信息系統核心(數據模型)的高度抽象思想。因為：主鍵是實體的高度抽象，主鍵與、外鍵的配對，表示實體之間的連接。
C. gp資料庫全稱是什麼
gp資料庫全稱是Creenplum。
GP資料庫是業界最快最高性價比的關系型分布式資料庫，它在開源的PostgreSQL的基礎上採用MPP架構（Massive Parallel Processing，海量並行處理），具有強大的大規模數據分析任務處理能力，其主要關注在數據倉庫和商業智能方面。
分布式資料庫系統通常使用較小的計算機系統，每台計算機可單獨放在一個地方，每台計算機中都可能有DBMS的一份完整拷貝副本，或者部分拷貝副本，並具有自己局部的資料庫，位於不同地點的許多計算機通過網路互相連接，共同組成一個完整的、全局的邏輯上集中、物理上分布的大型資料庫。
GP資料庫特點：
1.greenplum是一個關系型資料庫集群，是由數個獨立的資料庫服務組合成的邏輯資料庫。
2.greenplum採用Shared-Nothing架構，整個集群由很多個數據節點（Segment Sever）和控制節點（master server）組成，其中每個數據節點上可以運行多個資料庫。
簡單來說，Shared-Nothing是一個分布式的架構，每個節點相對獨立。在典型的Shared-Nothing中，每一個節點上所有的資源（CPU，內存，磁碟）都是獨立的，每個節點都只有全部數據的一部分，也只能使用本節點的資源。
D. 資料庫軟體架構設計的要點
資料庫軟體架構設計，要關注哪些要點？
方法/步驟
在IT系統架構設計中，資料庫的設計，占據著很重要的地位。那麼主要面臨哪些問題，需要考慮哪些因素呢？
面對數據量過大的問題，通常需要通過分片技術來解決，目前應用較多的是哈希分片。
因為通過范圍簡單分片，可能造成各庫的壓力不均；而統一路由，會增加訪問前查詢的壓力。
通過主從復制的分組，既可以解決可用性的問題，還可以實現一定的性能提升。
資料庫的軟體架構設計，要關注可用性、性能、一致性和擴展性四個方面。
解決可用性的主要思路就是冗餘——站點冗餘、服務冗餘、數據冗餘……
冗餘帶來的可用性問題，就是數據一致性的問題，要保證數據一致性，可以考慮雙寫同步。
擴展性能一般有三種方式——增加索引、增加從庫和增加緩存，要結合實際情況分析應用。
架構的設計是一個動態優化的過程，要綜合考慮幾個方面的因素，尋找合適的平衡點。
E. 目前大型資料庫應用系統採用什麼體系結構
從資料庫最終用戶角度看，資料庫系統的結構分為單用戶結構、主從式結構、分布式結構、客戶/伺服器、瀏覽器/應用伺服器/資料庫伺服器多層結構。這是資料庫外部體系結構。
物理存儲結構、邏輯存儲結構、內存結構和實例進程結構。這是內部體系結構
F. 什麼叫做資料庫的「三層架構」
三層架構可以說是一種設置模式，他的作用只是讓我們更加有效的利用資源，有利於以後的修改和查看，依次分為視圖層，邏輯層，數據層；
試圖層顧名思義就是我們所看到的，他的原代碼並沒有關於處理和連庫等代碼，只是簡單的跳轉頁面，我們沒有辦法看到真正的代碼；
邏輯層就是我們從頁面層發回的問題等請求，從字面意思來看，你可以將他視為一個過渡層，只是連接是圖層和數據層；進行一些連庫，刪除數據等操作了；從試圖層跳轉過來的問題在這里進行處理，並提交給數據層，再返回頁面層共讀者查看；
數據層就不用說了吧！這里存放著所有的數據也就是一個工程的大本營一樣；
三層架構已經不僅僅屬於.net了，他是一種設計形式，從某種意義上來說，所有的開發設計幾乎都已經以三層架構為基礎，三層架構及有效的處理問題，將數據和試圖也有效的分開，這樣防止耦合度過高，有利於處理和修改，（你不會是想將代碼全部寫在視圖頁面上，這樣有一個小小的變動，我們就要翻看幾十萬句代碼，從中找出，那我要替你的眼睛抱不平了）當你將程序做好後，從這台機子移動到另一台機子時，大大減少了出錯的問題；
通俗一點就是，這樣看上去很有層次感，我們查看時，可以減少時間的浪費，也不用在代碼堆里翻來覆去找不到北
G. 資料庫的問題
資料庫，簡而言之可視為電子化的文件櫃——存儲電子文件的處所，用戶可以對文件中的數據進行新增、截取、更新、刪除等操作。
所謂「資料庫」系以一定方式儲存在一起、能予多個用戶共享、具有盡可能小的冗餘度、與應用程序彼此獨立的數據集合。[1]
資料庫管理系統
主條目：資料庫管理系統
資料庫管理系統（英語：Database Management System，簡稱DBMS）是為管理資料庫而設計的電腦軟體系統，一般具有存儲、截取、安全保障、備份等基礎功能。資料庫管理系統可以依據它所支持的資料庫模型來作分類，例如關系式、XML；或依據所支持的計算機類型來作分類，例如伺服器群集、行動電話；或依據所用查詢語言來作分類，例如SQL、XQuery；或依據性能沖量重點來作分類，例如最大規模、最高運行速度；亦或其他的分類方式。不論使用哪種分類方式，一些DBMS能夠跨類別，例如，同時支持多種查詢語言。[1]
類型
關系資料庫
MySQL
MariaDB（MySQL的代替品，英文維基網路從MySQL轉向MariaDB）
Percona Server（MySQL的代替品·）
PostgreSQL
Microsoft Access
Microsoft SQL Server
Google Fusion Tables
FileMaker
Oracle資料庫
Sybase
dBASE
Clipper
FoxPro
foshub
幾乎所有的資料庫管理系統都配備了一個開放式資料庫連接（ODBC）驅動程序，令各個資料庫之間得以互相集成。
非關系型資料庫（NoSQL）
主條目：NoSQL
BigTable（Google）
Cassandra
MongoDB
CouchDB
鍵值（key-value）資料庫
Apache Cassandra（為Facebook所使用）：高度可擴展
Dynamo
LevelDB（Google）[1]
資料庫模型
對象模型
層次模型（輕量級數據訪問協議）
網狀模型（大型數據儲存）
關系模型
面向對象模型
半結構化模型
平面模型（表格模型，一般在形式上是一個二維數組。如表格模型數據Excel)
架構
資料庫的架構可以大致區分為三個概括層次：內層、概念層和外層。
內層：最接近實際存儲體，亦即有關數據的實際存儲方式。
外層：最接近用戶，即有關個別用戶觀看數據的方式。
概念層：介於兩者之間的間接層。
資料庫索引
主條目：資料庫索引
數據索引的觀念由來已久，像是一本書前面幾頁都有目錄，目錄也算是索引的一種，只是它的分類較廣，例如車牌、身份證字型大小、條碼等，都是一個索引的號碼，當我們看到號碼時，可以從號碼中看出其中的端倪，若是要找的人、車或物品，也只要提供相關的號碼，即可迅速查到正確的人事物。
另外，索引跟欄位有著相應的關系，索引即是由欄位而來，其中欄位有所謂的關鍵欄位（Key Field），該欄位具有唯一性，即其值不可重復，且不可為"空值（null）"。例如：在合並數據時，索引便是扮演欲附加欄位數據之指向性用途的角色。故此索引為不可重復性且不可為空。
資料庫操作:事務
主條目：資料庫事務
事務（transaction）是用戶定義的一個資料庫操作序列，這些操作要麼全做，要麼全不做，是一個不可分割的工作單位。 事務的ACID特性：
基元性（atomicity）
一致性（consistency）
隔離性（isolation）
持續性（rability）
事務的並發性是指多個事務的並行操作輪流交叉運行，事務的並發可能會訪問和存儲不正確的數據，破壞交易的隔離性和資料庫的一致性。
網狀數據模型的數據結構 網狀模型 滿足下面兩個條件的基本層次聯系的集合為網狀模型。 1. 允許一個以上的結點無雙親； 2. 一個結點可以有多於一個的雙親。[2]
參見
資料庫理論
信息技術審核
LDAP（輕量級數據訪問協議）
SQL（結構化查詢語言）
H. 資料庫 數據
簡而言之，資料庫是面向事務的設計，數據倉庫是面向主題設計的。
資料庫一般存儲在線交易數據，數據倉庫存儲的一般是歷史數據。
資料庫設計是盡量避免冗餘，一般採用符合範式的規則來設計，數據倉庫在設計是有意引入冗餘，採用反範式的方式來設計。
資料庫是為捕獲數據而設計，數據倉庫是為分析數據而設計，它的兩個基本的元素是維表和事實表。維是看問題的角度，比如時間，部門，維表放的就是這些東西的定義，事實表裡放著要查詢的數據，同時有維的ID。
單從概念上講，有些晦澀。任何技術都是為應用服務的，結合應用可以很容易地理解。以銀行業務為例。資料庫是事務系統的數據平台，客戶在銀行做的每筆交易都會寫入資料庫，被記錄下來，這里，可以簡單地理解為用資料庫記帳。數據倉庫是分析系統的數據平台，它從事務系統獲取數據，並做匯總、加工，為決策者提供決策的依據。比如，某銀行某分行一個月發生多少交易，該分行當前存款余額是多少。如果存款又多，消費交易又多，那麼該地區就有必要設立ATM了。
顯然，銀行的交易量是巨大的，通常以百萬甚至千萬次來計算。事務系統是實時的，這就要求時效性，客戶存一筆錢需要幾十秒是無法忍受的，這就要求資料庫只能存儲很短一段時間的數據。而分析系統是事後的，它要提供關注時間段內所有的有效數據。這些數據是海量的，匯總計算起來也要慢一些，但是，只要能夠提供有效的分析數據就達到目的了。
數據倉庫，是在資料庫已經大量存在的情況下，為了進一步挖掘數據資源、為了決策需要而產生的，它決不是所謂的「大型資料庫」。那麼，數據倉庫與傳統資料庫比較，有哪些不同呢?讓我們先看看W.H.Inmon關於數據倉庫的定義:面向主題的、集成的、與時間相關且不可修改的數據集合。
「面向主題的」:傳統資料庫主要是為應用程序進行數據處理，未必按照同一主題存儲數據;數據倉庫側重於數據分析工作，是按照主題存儲的。這一點，類似於傳統農貿市場與超市的區別—市場裡面，白菜、蘿卜、香菜會在一個攤位上，如果它們是一個小販賣的;而超市裡，白菜、蘿卜、香菜則各自一塊。也就是說，市場里的菜(數據)是按照小販(應用程序)歸堆(存儲)的，超市裡面則是按照菜的類型(同主題)歸堆的。
「與時間相關」:資料庫保存信息的時候，並不強調一定有時間信息。數據倉庫則不同，出於決策的需要，數據倉庫中的數據都要標明時間屬性。決策中，時間屬性很重要。同樣都是累計購買過九車產品的顧客，一位是最近三個月購買九車，一位是最近一年從未買過，這對於決策者意義是不同的。
「不可修改」:數據倉庫中的數據並不是最新的，而是來源於其它數據源。數據倉庫反映的是歷史信息，並不是很多資料庫處理的那種日常事務數據(有的資料庫例如電信計費資料庫甚至處理實時信息)。因此，數據倉庫中的數據是極少或根本不修改的;當然，向數據倉庫添加數據是允許的。
數據倉庫的出現，並不是要取代資料庫。目前，大部分數據倉庫還是用關系資料庫管理系統來管理的。可以說，資料庫、數據倉庫相輔相成、各有千秋。
補充一下，數據倉庫的方案建設的目的，是為前端查詢和分析作為基礎，由於有較大的冗餘，所以需要的存儲也較大。為了更好地為前端應用服務，數據倉庫必須有如下幾點優點，否則是失敗的數據倉庫方案。
1.效率足夠高。客戶要求的分析數據一般分為日、周、月、季、年等，可以看出，日為周期的數據要求的效率最高，要求24小時甚至12小時內，客戶能看到昨天的數據分析。由於有的企業每日的數據量很大，設計不好的數據倉庫經常會出問題，延遲1-3日才能給出數據，顯然不行的。
2.數據質量。客戶要看各種信息，肯定要准確的數據，但由於數據倉庫流程至少分為3步，2次ETL，復雜的架構會更多層次，那麼由於數據源有臟數據或者代碼不嚴謹，都可以導致數據失真，客戶看到錯誤的信息就可能導致分析出錯誤的決策，造成損失，而不是效益。
3.擴展性。之所以有的大型數據倉庫系統架構設計復雜，是因為考慮到了未來3-5年的擴展性，這樣的話，客戶不用太快花錢去重建數據倉庫系統，就能很穩定運行。主要體現在數據建模的合理性，數據倉庫方案中多出一些中間層，使海量數據流有足夠的緩沖，不至於數據量大很多，就運行不起來了。
是否可以解決您的問題？
I. 大數據正在如何改變資料庫格局
大數據正在如何改變資料庫格局
提及「資料庫」，大多數人會想到擁有30多年風光歷史的RDBMS。然而，這可能很快就會發生改變。
一大批新的競爭者都在爭奪這一塊重要市場，他們的方法是多種多樣的，卻都有一個共同點：極其專注於大數據。推動新的數據迭代衍生品大部分都是基於底層大數據的3V特徵：數量，速度和種類。本質上來講，今天的數據比以往任何時候都要傳輸更快，體積更大， 同時更加多樣化。這是一個新的數據世界，換言之，傳統的關系資料庫管理系統並沒有真正為此而設計。「基本上，他們不能擴展到大量，或快速，或不同種類的數據。」一位數據分析、數據科學咨詢機構的總裁格雷戈里認為。這就是哈特漢克斯最近發現。截至到2013年左右，營銷服務機構使用不同的資料庫，包括Microsoft SQL Server和Oracle真正應用集群（RAC）的組合。「我們注意到，數據隨著時間的增長，我們的系統不能足夠快速的處理信息」一位科技發展公司的負責人肖恩說到。「如果你不斷地購買伺服器，你只能繼續走到這幺遠，我們希望確保自己有向外擴展的平台。」最小化中斷是一個重要的目標，Iannuzzi說到，因此「我們不能只是切換到Hadoop。」相反，卻選擇了拼接機器，基本上把完整的SQL資料庫放到目前流行的Hadoop大數據平台之上，並允許現有的應用程序能夠與它連接，他認為。哈特漢克斯現在是在執行的初期階段，但它已經看到了好處，Iannuzzi說，包括提高容錯性，高可用性，冗餘性，穩定性和「性能全面提升」。一種完美風暴推動了新的資料庫技術的出現，IDC公司研究副總裁Carl Olofson說到。首先，「我們正在使用的設備與過去對比，處理大數據集更加快速，靈活性更強」Olofson說。在過去，這樣的集合「幾乎必須放在旋轉磁碟上」，而且數據必須以特定的方式來結構化，他解釋說。現在有64位定址，使得能夠設置更大的存儲空間以及更快的網路，並能夠串聯多台計算器充當單個大型資料庫。「這些東西在不可用之前開辟了可能性」Olofson說。與此同時，工作負載也發生了變化。10年前的網站主要是靜態的，例如，今天我們享受到的網路服務環境和互動式購物體驗。反過來，需要新的可擴展性，他說。公司正在利用新的方式來使用數據。雖然傳統上我們大部分的精力都放在了對事務處理 – 銷售總額的記錄，比如，數據存儲在可以用來分析的地方 – 現在我們做的更多。應用狀態管理就是一個例子假設你正在玩一個網路游戲。該技術會記錄你與系統的每個會話並連接在一起，以呈現出連續的體驗，即使你切換設備或各種移動，不同的伺服器都會進行處理，Olofson解釋說。數據必須保持連續性，這樣企業才可以分析問題，例如「為什麼從來沒有人穿過水晶廳」。在網路購物方面，為什麼對方點擊選擇顏色後大多數人不會購買某個特殊品牌的鞋子。「以前，我們並沒試圖解決這些問題，或者我們試圖扔進盒子也不太合適」Olofson說。Hadoop是當今新的競爭者中一個重量級的產品。雖然他本身不是一個資料庫，它的成長為企業解決大數據扮演關鍵角色。從本質上講，Hadoop是一個運行高度並行應用程序的數據中心平台，它有很強的可擴展性。通過允許企業擴展「走出去」的分布方式，而不是通過額外昂貴的伺服器「向上」擴展，「它使得我們可以低成本地把一個大的數據集匯總，然後進行分析研究成果」Olofson說。其他新的RDBMS的替代品如NoSQL家族產品，其中包括MongoDB -目前第四大流行資料庫管理系統，比照DB引擎和MarkLogic非結構化數據存儲服務。「關系型資料庫一直是一項偉大的技術持續了30年，但它是建立在不同的時代有不同的技術限制和不同的市場需求，」MarkLogic的執行副總裁喬·產品帕卡說。大數據是不均勻的，他說。許多傳統的技術，這仍然是一個基本要求。「想像一下，你的筆記本電腦上唯一的程序是Excel」帕卡說。「設想一下，你要和你的朋友利用網路保持聯系 – 或者你正在寫一個合約卻不適合放進行和列中。」拼接數據集是特別棘手的「關系型，你把所有這些數據集中在一起前，必須先決定如何去組織所有的列，」他補充說。「我們可以採取任何形式或結構，並立即開始使用它。」NoSQL資料庫沒有使用關系數據模型，並且它們通常不具有SQL介面。盡管許多的NoSQL存儲折中支持速度等其他因素，MarkLogic為企業定身量做，提供更為周全的選擇。NoSQL儲存市場有相當大的增長，據市場研究媒體，不是每個人都認為這是正確的做法-至少，不是在所有情況下。NoSQL系統「解決了許多問題，他們橫向擴展架構，但他們卻拋出了SQL，」一位CEO-Monte Zweben說。這反過來，又為現有的代碼構成問題。Splice Machine是一家基於Hadoop的實時大數據技術公司，支持SQL事務處理，並針對OLAP 和OLAP應用進行實時優化處理。它被稱為替代NewSQL的一個例子，另一類預期會在未來幾年強勁增長。「我們的理念是保持SQL，但橫向擴展架構」Zweben說。「這是新事物，但我們正在努力試圖使它讓人們不必重寫自己的東西。」深度信息科學選擇並堅持使用SQL，但需要另一種方法。公司的DeepSQL資料庫使用相同的應用程序編程介面（API）和關系模型如MySQL，意味著沒有應用變化的需求而使用它。但它以不同的方式處理數據，使用機器學習。DeepSQL可以自動適應使用任何工作負載組合的物理，虛擬或雲主機，該公司表示，從而省去了手動優化資料庫的需要。該公司的首席戰略官Chad Jones表示，在業績大幅增加的同時，也有能力將「規模化」為上千億的行。一種來自Algebraix數據完全不同的方式，表示已經開發了數據的第一個真正的數學化基礎。而計算器硬體需在數學建模前建成，這不是在軟體的情況下，Algebraix首席執行官查爾斯銀說。「軟體，尤其是數據，從未建立在數學的基礎上」他說，「軟體在很大程度上是語言學的問題。」經過五年的研發，Algebraix創造了所謂的「數據的代數」集合論，「數據的通用語言」Silver說。「大數據骯臟的小秘密是數據仍然放在不與其他數據小倉融合的地方」Silver解釋說。「我們已經證明，它都可以用數學方法來表示所有的集成。」配備一個基礎的平台，Algebraix現在為企業提供業務分析作為一種服務。改進的性能，容量和速度都符合預期的承諾。時間會告訴我們哪些新的競爭者取得成功，哪些沒有，但在此期間，長期的領導者如Oracle不會完全停滯不前。「軟體是一個非常時尚行業」安德魯·門德爾松，甲骨文執行副總裁資料庫伺服器技術說。「事情經常去從流行到不受歡迎，回再次到流行。」今天的許多創業公司「帶回炒冷飯少許拋光或旋轉就可以了」他說。「這是一個新一代孩子走出學校和重塑的東西。」SQL是「唯一的語言，可以讓業務分析師提出問題並得到答案，他們沒有程序員，」門德爾松說。「大市場將始終是關系型。」至於新的數據類型，關系型資料庫產品早在上世紀90年代發展為支持非結構化數據，他說。在2013年，甲骨文的同名資料庫版本12C增加了支持JSON（JavaScript對象符號）。與其說需要一個不同類型的資料庫，它更是一種商業模式的轉變，門德爾松說。「雲，若是每個人都去，這將破壞這些小傢伙」他說。「大家都在雲上了，所以在這里有沒有地方來放這些小傢伙？「他們會去亞馬遜的雲與亞馬遜競爭？」 他補充說。「這將是困難的。」甲骨文有「最廣泛的雲服務」門德爾松說。「在現在的位置，我們感覺良好。」Gartner公司的研究主任里克·格林沃爾德，傾向於採取了類似的觀點。「對比傳統強大的RDBMS，新的替代品並非功能齊全」格林沃爾德說。「一些使用案例可以與新的競爭者來解決，但不是全部，並非一種技術」。展望未來，格林沃爾德預計，傳統的RDBMS供貨商感到價格壓力越來越大，並為他們的產品增加新的功能。「有些人會自由地帶來新的競爭者進入管理自己的整個數據生態系統」他說。至於新的產品，有幾個會生存下來，他預測「許多人將被收購或資金耗盡」。今天的新技術並不代表傳統的RDBMS的結束，「正在迅速發展自己」IDC的Olofson。贊成這種說法，「RDBMS是需要明確定義的數據 – 總是會有這樣一個角色。」但也會有一些新的競爭者的角色，他說，特別是物聯網技術和新興技術如非易失性內存晶元模塊（NVDIMM）占據上風。以上是小編為大家分享的關於大數據正在如何改變資料庫格局的相關內容，更多信息可以關注環球青藤分享更多干貨