共 我們已經花了數十年的工夫在企業運算上，在語言、架構、平台以及程序上看過了許多改變。經過時間的更迭，有一件事情是沒有改變的：使用關聯式資料庫儲存資料。曾有人想要挑戰這個觀念，確實也在一些利基點上取得勝利，但整個資料儲存的問題，已經轉變為要使用哪個關聯式資料庫了。
在關聯式資料庫盛行時的穩定性中蘊含了許多價值。一個組織的資料存活得比它的程式要長久（至少這是那些人說的--我們已經在那看到了許多非常舊的程式）。擁有一個能夠從許多應用程式平台被完善瞭解且存取的穩定資料儲存是非常有價值的。
為了處理大量資料而生的NoSQL
然而，現今出現了一個新的挑戰者，打著對抗的NoSQL標籤。它是為了要處理大量資料的需求而誕生的，這些大量資料驅使轉移至建造大型的硬體平台，將商用伺服器串連成叢集。長久以來，要讓應用程式碼跟關聯式資料庫模型能夠完美配合都不是簡單的事情，而處理大量資料的需求又喚起了這個問題。
NoSQL這個詞彙缺乏嚴謹的定義。它通常套用至數個最新的非關聯式資料庫，如Cassandra、Mongo、Neo4J或Riak。它們都擁有無綱要（schemaless）的資料、在叢集上執行，並且擁有調整傳統一致性來影響其他有用性質的能力。NoSQL資料庫的擁護者宣稱他們能夠建立一個更有效率、擴充率更好，並且更容易撰寫搭配程式的系統。
本書提供您評估技術需求的資訊
這是否是關聯式資料庫的喪鐘首鳴，抑或是另一個王位的覬覦者？我們的答案是：兩者皆非。關聯式資料庫是一個強大的工具，至少還能使用數十年，但目前我們所看到的改變是，關聯式資料庫並不是唯一在使用的資料庫。目前正在進入多語言維持（Polyglot Persistence）的世界，企業會使用許多技術來管理資料。最終，建構者必須要熟悉這些技術並且要能夠評估哪個技術適合用在不同的需求上。若我們沒有想到這塊，就不會花費時間以及心力來撰寫此書了。
本書希望能夠提供給你足夠的資訊，來判斷NoSQL資料庫在未來的專案中，是否值得你導入的這個問題。每個專案都不同，而我們也沒有辦法畫出一個決策樹來決定對的資料儲存方式。我們在此嘗試要提供NoSQL資料庫是如何運作的背景知識，讓你能夠不用找遍整個網際網路就能夠做這些決策。
為何NoSQL資料庫令人感到有趣？
在此列出兩個考慮使用NoSQL資料庫的主要原因：
．應用程式開發的生產力。許多應用程式開發的心力都放在對應記憶體中的資料結構與關聯式資料庫之間的資料。NoSQL資料庫能夠提供更符合應用程式所需的資料模型，因此簡化了這之間的對應，並且可以撰寫以及除錯更少的程式碼。
．大規模的資料量。企業組織發現它能夠用來抓取更多的資料並且更快的處理它。他們發現同樣的狀況，就算能夠使用關聯式資料庫，也會非常昂貴。最主要的原因是，關聯式資料庫是設計在單一機器上執行的，但通常在由許多小型並且便宜的機器所組成的叢集上跑大量資料以及計算負載是較經濟的。許多NoSQL資料庫專門是設計在叢集之上執行的，所以它們較能夠符合大資料量的情境。
作者簡介
Pramod J. Sadalage
ThoughtWorks的首席顧問，喜歡在資料庫專家與應用程式開發者之間的分歧扮演橋接的角色。他通常會接受與擁有特別具有挑戰性的資料並且需要新技術的客戶諮詢。他建立了一個開創性的技術，能夠讓關聯式資料庫基於版本控制綱要的移植而被設計為一個嶄新的進化形式。他與Scott Ambler共同寫作Refactoring Databases (Addison-Wesley, 2006)。
Martin Fowler
ThoughtWorks的首席科學家，專注於更好的設計軟體系統方法，並且提升開發者的生產力。他的書包含了Patterns of Enterprise Application Architecture、UML Distilled第三版、Domain-Specific Languages (與 Rebecca Parsons)以及Refactoring: Improving the Design of Existing Code (與 Kent Beck、John Brant 和 William Opdyke)。所有都是由Addison-Wesley所出版的。
