ldap與nosql的簡單介紹

LDAP是啥意思

成都創(chuàng)新互聯(lián)是專業(yè)的象州網(wǎng)站建設公司，象州接單;提供網(wǎng)站設計、成都網(wǎng)站制作,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行象州網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

在日常交談中，你可能會聽到有些人這么說：“我們要把那些東西存在LDAP中嗎？”，或者“從LDAP數(shù)據(jù)庫中取出那些數(shù)據(jù)！”，又或者“我們怎么把LDAP和關系型數(shù)據(jù)庫集成在一起？”。嚴格地說，LDAP根本不是數(shù)據(jù)庫而是用來訪問存儲在信息目錄（也就是LDAP目錄）中的信息的協(xié)議。更為確切和正式的說法應該是象這樣的：“通過使用LDAP，可以在信息目錄的正確位置讀取（或存儲）數(shù)據(jù)”。但是，也沒有必要吹毛求疵，盡管表達得不夠準確，我們也都知道對方在說什么。

參考：

數(shù)據(jù)庫的問題：關系型數(shù)據(jù)庫與非關系型數(shù)據(jù)庫的區(qū)別，和各自的發(fā)展前景?

當前主流的關系型數(shù)據(jù)庫有Oracle、DB2、Microsoft SQL Server、Microsoft Access、MySQL等。

非關系型數(shù)據(jù)庫有 NoSql、Cloudant。

nosql和關系型數(shù)據(jù)庫比較

優(yōu)點：

1）成本：nosql數(shù)據(jù)庫簡單易部署，基本都是開源軟件，不需要像使用oracle那樣花費大量成本購買使用，相比關系型數(shù)據(jù)庫價格便宜。

2）查詢速度：nosql數(shù)據(jù)庫將數(shù)據(jù)存儲于緩存之中，關系型數(shù)據(jù)庫將數(shù)據(jù)存儲在硬盤中，自然查詢速度遠不及nosql數(shù)據(jù)庫。

3）存儲數(shù)據(jù)的格式：nosql的存儲格式是key,value形式、文檔形式、圖片形式等等，所以可以存儲基礎類型以及對象或者是集合等各種格式，而數(shù)據(jù)庫則只支持基礎類型。

4）擴展性：關系型數(shù)據(jù)庫有類似join這樣的多表查詢機制的限制導致擴展很艱難。

缺點：

1）維護的工具和資料有限，因為nosql是屬于新的技術，不能和關系型數(shù)據(jù)庫10幾年的技術同日而語。

2）不提供對sql的支持，如果不支持sql這樣的工業(yè)標準，將產(chǎn)生一定用戶的學習和使用成本。

3）不提供關系型數(shù)據(jù)庫對事物的處理。

關系型數(shù)據(jù)庫的最大特點就是事務的一致性：傳統(tǒng)的關系型數(shù)據(jù)庫讀寫操作都是事務的，具有ACID的特點，這個特性使得關系型數(shù)據(jù)庫可以用于幾乎所有對一致性有要求的系統(tǒng)中，如典型的銀行系統(tǒng)。

關系型數(shù)據(jù)庫為了維護一致性所付出的巨大代價就是其讀寫性能比較差，而像微博、facebook這類SNS的應用，對并發(fā)讀寫能力要求極高，關系型數(shù)據(jù)庫已經(jīng)無法應付(在讀方面，傳統(tǒng)上為了克服關系型數(shù)據(jù)庫缺陷，提高性能，都是增加一級memcache來靜態(tài)化網(wǎng)頁，而在SNS中，變化太快，memchache已經(jīng)無能為力了)，因此，必須用新的一種數(shù)據(jù)結(jié)構存儲來代替關系數(shù)據(jù)庫。

關系數(shù)據(jù)庫的另一個特點就是其具有固定的表結(jié)構，因此，其擴展性極差，而在SNS中，系統(tǒng)的升級，功能的增加，往往意味著數(shù)據(jù)結(jié)構巨大變動，這一點關系型數(shù)據(jù)庫也難以應付，需要新的結(jié)構化數(shù)據(jù)存儲。

于是，非關系型數(shù)據(jù)庫應運而生，由于不可能用一種數(shù)據(jù)結(jié)構化存儲應付所有的新的需求，因此，非關系型數(shù)據(jù)庫嚴格上不是一種數(shù)據(jù)庫，應該是一種數(shù)據(jù)結(jié)構化存儲方法的集合。

如何建立一個完整可用的安全大數(shù)據(jù)平臺

“

要建立一個大數(shù)據(jù)系統(tǒng)，我們需要從數(shù)據(jù)流的源頭跟蹤到最后有價值的輸出，并在現(xiàn)有的Hadoop和大數(shù)據(jù)生態(tài)圈內(nèi)根據(jù)實際需求挑選并整合各部分合適的組件來構建一個能夠支撐多種查詢和分析功能的系統(tǒng)平臺。這其中既包括了對數(shù)據(jù)存儲的選擇，也涵蓋了數(shù)據(jù)線上和線下處理分離等方面的思考和權衡。此外，沒有任何一個引入大數(shù)據(jù)解決方案的商業(yè)應用在生產(chǎn)環(huán)境上承擔的起安全隱患。

計算框架篇

大數(shù)據(jù)的價值

只有在能指導人們做出有價值的決定時，數(shù)據(jù)才能體現(xiàn)其自身的價值。因此，大數(shù)據(jù)技術要服務于實際的用途，才是有意義的。一般來說，大數(shù)據(jù)可以從以下三個方面指導人們做出有價值的決定：

報表生成（比如根據(jù)用戶歷史點擊行為的跟蹤和綜合分析、應用程序活躍程度和用戶粘性計算等）；

診斷分析（例如分析為何用戶粘性下降、根據(jù)日志分析系統(tǒng)為何性能下降、垃圾郵件以及病毒的特征檢測等）；

決策（例如個性化新聞閱讀或歌曲推薦、預測增加哪些功能能增加用戶粘性、幫助廣告主進行廣告精準投放、設定垃圾郵件和病毒攔截策略等）。

圖 1

進一步來看，大數(shù)據(jù)技術從以下三個方面解決了傳統(tǒng)技術難以達成的目標（如圖1）：

在歷史數(shù)據(jù)上的低延遲（交互式）查詢，目標是加快決策過程和時間，例如分析一個站點為何變緩慢并嘗試修復它；

在實時數(shù)據(jù)上的低延遲查詢，目的是幫助用戶和應用程序在實時數(shù)據(jù)上做出決策，例如實時檢測并阻攔病毒蠕蟲（一個病毒蠕蟲可以在1.3秒內(nèi)攻擊1百萬臺主機）；

更加精細高級的數(shù)據(jù)處理算法，這可以幫助用戶做出“更好”的決策，例如圖數(shù)據(jù)處理、異常點檢測、趨勢分析及其他機器學習算法。

蛋糕模式

從將數(shù)據(jù)轉(zhuǎn)換成價值的角度來說，在Hadoop生態(tài)圈十年蓬勃成長的過程中，YARN和Spark這二者可以算得上是里程碑事件。Yarn的出現(xiàn)使得集群資源管理和數(shù)據(jù)處理流水線分離，大大革新并推動了大數(shù)據(jù)應用層面各種框架的發(fā)展（SQL on Hadoop框架, 流數(shù)據(jù)，圖數(shù)據(jù)，機器學習）。

它使得用戶不再受到MapReduce開發(fā)模式的約束，而是可以創(chuàng)建種類更為豐富的分布式應用程序，并讓各類應用程序運行在統(tǒng)一的架構上，消除了為其他框架維護獨有資源的開銷。就好比一個多層蛋糕，下面兩層是HDFS和Yarn, 而MapReduce就只是蛋糕上層的一根蠟燭而已，在蛋糕上還能插各式各樣的蠟燭。

在這一架構體系中，總體數(shù)據(jù)處理分析作業(yè)分三塊（圖2），在HBase上做交互式查詢（Apache Phoenix, Cloudera Impala等），在歷史數(shù)據(jù)集上編寫MapReduce程序抑或利用Hive等做批處理業(yè)務，另外對于實時流數(shù)據(jù)分析Apache Storm則會是一種標準選擇方案。

雖然Yarn的出現(xiàn)極大地豐富了Hadoop生態(tài)圈的應用場景，但仍存有兩個顯而易見的挑戰(zhàn)：一是在一個平臺上需要維護三個開發(fā)堆棧；二是在不同框架內(nèi)很難共享數(shù)據(jù)，比如很難在一個框架內(nèi)對流數(shù)據(jù)做交互式查詢。這也意味著我們需要一個更為統(tǒng)一和支持更好抽象的計算框架的出現(xiàn)。

圖 2

一統(tǒng)江湖

Spark的出現(xiàn)使得批處理任務，交互式查詢，實時流數(shù)據(jù)處理被整合到一個統(tǒng)一的框架內(nèi)（圖3），同時Spark和現(xiàn)有的開源生態(tài)系統(tǒng)也能夠很好地兼容（Hadoop, HDFS, Yarn, Hive, Flume）。通過啟用內(nèi)存分布數(shù)據(jù)集，優(yōu)化迭代工作負載，用戶能夠更簡單地操作數(shù)據(jù)，并在此基礎上開發(fā)更為精細的算法，如機器學習和圖算法等。

有三個最主要的原因促使Spark目前成為了時下最火的大數(shù)據(jù)開源社區(qū)（擁有超過來自200多個公司的800多個contributors）：

Spark可以擴展部署到超過8000節(jié)點并處理PB級別的數(shù)據(jù)，同時也提供了很多不錯的工具供應用開發(fā)者進行管理和部署；

Spark提供了一個交互式shell供開發(fā)者可以用Scala或者Python即時性試驗不同的功能；

Spark提供了很多內(nèi)置函數(shù)使得開發(fā)者能夠比較容易地寫出低耦合的并且能夠并發(fā)執(zhí)行的代碼，這樣開發(fā)人員就更能集中精力地為用戶提供更多的業(yè)務功能而不是花費時間在優(yōu)化并行化代碼之上。

當然Spark也和當年的MapReduce一樣不是萬靈藥，比如對實時性要求很高的流數(shù)據(jù)處理上Apache Storm還是被作為主流選擇，因為Spark Streaming實際上是microbatch（將一個流數(shù)據(jù)按時間片切成batch,每個batch提交一個job）而不是事件觸發(fā)實時系統(tǒng)，所以雖然支持者們認為microbatch在系統(tǒng)延時性上貢獻并不多，但在生產(chǎn)環(huán)境中和Apache Storm相比還不是特別能滿足對低延時要求很高的應用場景。

比如在實踐過程中，如果統(tǒng)計每條消息的平均處理時間，很容易達到毫秒級別，但一旦統(tǒng)計類似service assurance（確保某條消息在毫秒基本能被處理完成）的指標，系統(tǒng)的瓶頸有時還是不能避免。

但同時我們不能不注意到，在許多用例當中，與流數(shù)據(jù)的交互以及和靜態(tài)數(shù)據(jù)集的結(jié)合是很有必要的, 例如我們需要在靜態(tài)數(shù)據(jù)集上進行分類器的模型計算，并在已有分類器模型的基礎上，對實時進入系統(tǒng)的流數(shù)據(jù)進行交互計算來判定類別。

由于Spark的系統(tǒng)設計對各類工作（批處理、流處理以及交互式工作）進行了一個共有抽象，并且生態(tài)圈內(nèi)延伸出了許多豐富的庫（MLlib機器學習庫、SQL語言API、GraphX）, 使得用戶可以在每一批流數(shù)據(jù)上進行靈活的Spark相關操作，在開發(fā)上提供了許多便利。

Spark的成熟使得Hadoop生態(tài)圈在短短一年之間發(fā)生了翻天覆地的變化， Cloudera和Hortonworks紛紛加入了Spark陣營，而Hadoop項目群中除了Yarn之外已經(jīng)沒有項目是必須的了（雖然Mesos已在一些場合替代了Yarn）, 因為就連HDFS，Spark都可以不依賴。但很多時候我們?nèi)匀恍枰馡mpala這樣的依賴分布式文件系統(tǒng)的MPP解決方案并利用Hive管理文件到表的映射，因此Hadoop傳統(tǒng)生態(tài)圈依然有很強的生命力。

另外在這里簡要對比一下交互式分析任務中各類SQL on Hadoop框架，因為這也是我們在實際項目實施中經(jīng)常遇到的問題。我們主要將注意力集中在Spark SQL, Impala和Hive on Tez上, 其中Spark SQL是三者之中歷史最短的，論文發(fā)表在15年的SIGMOD會議上，原文對比了數(shù)據(jù)倉庫上不同類型的查詢在Shark（Spark最早對SQL接口提供的支持）、Spark SQL和Impala上的性能比較。

也就是說，雖然Spark SQL在Shark的基礎上利用Catalyst optimizer在代碼生成上做了很多優(yōu)化，但總體性能還是比不上Impala, 尤其是當做join操作的時候， Impala可以利用“predicate pushdown”更早對表進行選擇操作從而提高性能。

不過Spark SQL的Catalyst optimizer一直在持續(xù)優(yōu)化中，相信未來會有更多更好的進展。Cloudera的Benchmark評測中Impala一直比其他SQL on Hadoop框架性能更加優(yōu)越，但同時Hortonworks評測則指出雖然單個數(shù)據(jù)倉庫查詢Impala可以在很短的時間內(nèi)完成，但是一旦并發(fā)多個查詢Hive on Tez的優(yōu)勢就展示出來。另外Hive on Tez在SQL表達能力也要比Impala更強（主要是因為Impala的嵌套存儲模型導致的），因此根據(jù)不同的場景選取不同的解決方案是很有必要的。

圖 3

各領風騷抑或代有才人出？

近一年比較吸引人眼球的Apache Flink（與Spark一樣已有5年歷史，前身已經(jīng)是柏林理工大學一個研究性項目，被其擁躉推崇為繼MapReduce, Yarn，Spark之后第四代大數(shù)據(jù)分析處理框架）。與Spark相反，F(xiàn)link是一個真正的實時流數(shù)據(jù)處理系統(tǒng)，它將批處理看作是流數(shù)據(jù)的特例，同Spark一樣它也在嘗試建立一個統(tǒng)一的平臺運行批量，流數(shù)據(jù)，交互式作業(yè)以及機器學習，圖算法等應用。

Flink有一些設計思路是明顯區(qū)別于Spark的，一個典型的例子是內(nèi)存管理，F(xiàn)link從一開始就堅持自己精確的控制內(nèi)存使用并且直接操作二進制數(shù)據(jù)，而Spark一直到1.5版本都還是試用java的內(nèi)存管理來做數(shù)據(jù)緩存，這也導致了Spark很容易遭受OOM以及JVM GC帶來的性能損失。

但是從另外一個角度來說, Spark中的RDD在運行時被存成java objects的設計模式也大大降低了用戶編程設計門檻，同時隨著Tungsten項目的引入，Spark現(xiàn)在也逐漸轉(zhuǎn)向自身的內(nèi)存管理，具體表現(xiàn)為Spark生態(tài)圈內(nèi)從傳統(tǒng)的圍繞RDD（分布式java對象集合）為核心的開發(fā)逐漸轉(zhuǎn)向以DataFrame(分布式行對象集合)為核心。

總的來說，這兩個生態(tài)圈目前都在互相學習，F(xiàn)link的設計基因更為超前一些，但Spark社區(qū)活躍度大很多，發(fā)展到目前毫無疑問是更為成熟的選擇，比如對數(shù)據(jù)源的支持（HBase, Cassandra, Parquet, JSON, ORC）更為豐富以及更為統(tǒng)一簡潔的計算表示。另一方面，Apache Flink作為一個由歐洲大陸發(fā)起的項目，目前已經(jīng)擁有來自北美、歐洲以及亞洲的許多貢獻者，這是否能夠一改歐洲在開源世界中一貫的被動角色，我們將在未來拭目以待。

NoSQL數(shù)據(jù)庫篇

NoSQL數(shù)據(jù)庫在主流選擇上依舊集中在MongoDB, HBase和Cassandra這三者之間。在所有的NoSQL選擇中，用C 編寫的MongoDB幾乎應該是開發(fā)者最快也最易部署的選擇。MongoDB是一個面向文檔的數(shù)據(jù)庫，每個文檔／記錄／數(shù)據(jù)（包括爬取的網(wǎng)頁數(shù)據(jù)及其他大型對象如視頻等）是以一種BSON（Binary JSON）的二進制數(shù)據(jù)格式存儲, 這使得MongoDB并不需要事先定義任何模式, 也就是模式自由（可以把完全不同結(jié)構的記錄放在同一個數(shù)據(jù)庫里）。

MongoDB對于完全索引的支持在應用上是很方便的，同時也具備一般NoSQL分布式數(shù)據(jù)庫中可擴展，支持復制和故障恢復等功能。 MongoDB一般應用于高度伸縮性的緩存及大尺寸的JSON數(shù)據(jù)存儲業(yè)務中，但不能執(zhí)行“JOIN”操作，而且數(shù)據(jù)占用空間也比較大，最被用戶詬病的就是由于MongoDB提供的是數(shù)據(jù)庫級鎖粒度導致在一些情況下建索引操作會引發(fā)整個數(shù)據(jù)庫阻塞。一般來說，MongoDB完全可以滿足一些快速迭代的中小型項目的需求。

下面來主要談談Cassandra和HBase之間的比較選擇。Cassandra和HBase有著截然不同的基因血統(tǒng)。HBase和其底層依賴的系統(tǒng)架構源自于著名的Google FileSystem（發(fā)表于2003年）和Google BigTable設計（發(fā)表于2006年），其克服了HDFS注重吞吐量卻犧牲I/O的缺點，提供了一個存儲中間層使得用戶或者應用程序可以隨機讀寫數(shù)據(jù)。

具體來說，HBase的更新和刪除操作實際上是先發(fā)生在內(nèi)存MemStore中，當MemStore滿了以后會Flush到StoreFile, 之后當StoreFile文件數(shù)量增長到一定閾值后會觸發(fā)Compact合并操作，因此HBase的更新操作其實是不斷追加的操作，而最終所有更新和刪除數(shù)據(jù)的持久化操作都是在之后Compact過程中進行的。

這使得應用程序在向內(nèi)存MemStore寫入數(shù)據(jù)后，所做的修改馬上就能得到反映，用戶讀到的數(shù)據(jù)絕不會是陳舊的數(shù)據(jù)，保證了I/O高性能和數(shù)據(jù)完全一致性；另一方面來說， HBase基于Hadoop生態(tài)系統(tǒng)的基因就已經(jīng)決定了他自身的高度可擴展性、容錯性。

在數(shù)據(jù)模型上，Cassandra和HBase類似實現(xiàn)了一個key-value提供面向列式存儲服務，其系統(tǒng)設計參考了 Amazon Dynamo (發(fā)表于2007年) 分布式哈希（DHT）的P2P結(jié)構（實際上大部分Cassandra的初始工作都是由兩位從Amazon的Dynamo組跳槽到Facebook的工程師完成)，同樣具有很高的可擴展性和容錯性等特點。

除此之外，相對HBase的主從結(jié)構，Cassandra去中心化的P2P結(jié)構能夠更簡單地部署和維護，比如增加一臺機器只需告知Cassandra系統(tǒng)新節(jié)點在哪，剩下的交給系統(tǒng)完成就行了。同時，Cassandra對多數(shù)據(jù)中心的支持也更好，如果需要在多個數(shù)據(jù)中心進行數(shù)據(jù)遷移Cassandra會是一個更優(yōu)的選擇。

Eric Brewer教授提出的經(jīng)典CAP理論認為任何基于網(wǎng)絡的數(shù)據(jù)共享系統(tǒng)，最多只能滿足數(shù)據(jù)一致性、可用性、分區(qū)容忍性三要素中的兩個要素。實際分布式系統(tǒng)的設計過程往往都是在一致性與可用性上進行取舍，相比于HBase數(shù)據(jù)完全一致性的系統(tǒng)設計，Cassandra選擇了在優(yōu)先考慮數(shù)據(jù)可用性的基礎上讓用戶自己根據(jù)應用程序需求決定系統(tǒng)一致性級別。

比如：用戶可以配置QUONUM參數(shù)來決定系統(tǒng)需要幾個節(jié)點返回數(shù)據(jù)才能向客戶端做出響應，ONE指只要有一個節(jié)點返回數(shù)據(jù)就可以對客戶端做出響應，ALL指等于數(shù)據(jù)復制份數(shù)的所有節(jié)點都返回結(jié)果才能向客戶端做出響應，對于數(shù)據(jù)一致性要求不是特別高的可以選擇ONE，它是最快的一種方式。

從基因和發(fā)展歷史上來說，HBase更適合用做數(shù)據(jù)倉庫和大規(guī)模數(shù)據(jù)處理與分析（比如對網(wǎng)頁數(shù)據(jù)建立索引），而Cassandra則更適合用作實時事務和交互式查詢服務。Cassandra在國外市場占有比例和發(fā)展要遠比國內(nèi)紅火，在不少權威測評網(wǎng)站上排名都已經(jīng)超過了HBase。目前Apache Cassandra的商業(yè)化版本主要由軟件公司DataStax進行開發(fā)和銷售推廣。另外還有一些NoSQL分布式數(shù)據(jù)庫如Riak, CouchDB也都在各自支持的廠商推動下取得了不錯的發(fā)展。

雖然我們也考慮到了HBase在實際應用中的不便之處比如對二級索引的支持程度不夠（只支持通過單個行鍵訪問，通過行鍵的范圍查詢，全表掃描），不過在明略的大數(shù)據(jù)基礎平臺上，目前整合的是依然是HBase。

理由也很簡單，HBase出身就與Hadoop的生態(tài)系統(tǒng)緊密集成，其能夠很容易與其他SQL on Hadoop框架（Cloudera Impala, Apache Phoenix, or Hive on Tez）進行整合，而不需要重新部署一套分布式數(shù)據(jù)庫系統(tǒng)，而且可以很方便地將同樣的數(shù)據(jù)內(nèi)容在同一個生態(tài)系統(tǒng)中根據(jù)不同框架需要來變換存儲格式（比如存儲成Hive表或者Parquet格式）。

我們在很多項目中都有需要用到多種SQL on Hadoop框架，來應對不同應用場景的情況，也體會到了在同一生態(tài)系統(tǒng)下部署多種框架的簡便性。但同時我們也遇到了一些問題，因為HBase項目本身與HDFS和Zookeeper系統(tǒng)分別是由不同開源團隊進行維護的，所以在系統(tǒng)整合時我們需要先對HBase所依賴的其他模塊進行設置再對HBase進行配置，在一定程度上降低了系統(tǒng)維護的友好性。

目前我們也已經(jīng)在考慮將Cassandra應用到一些新的客戶項目中，因為很多企業(yè)級的應用都需要將線上線下數(shù)據(jù)庫進行分離，HBase更適合存儲離線處理的結(jié)果和數(shù)據(jù)倉庫，而更適合用作實時事務和并發(fā)交互性能更好的Cassandra作為線上服務數(shù)據(jù)庫會是一種很好的選擇。

大數(shù)據(jù)安全篇

隨著越來越多各式各樣的數(shù)據(jù)被存儲在大數(shù)據(jù)系統(tǒng)中，任何對企業(yè)級數(shù)據(jù)的破壞都是災難性的，從侵犯隱私到監(jiān)管違規(guī)，甚至會造成公司品牌的破壞并最終影響到股東收益。給大數(shù)據(jù)系統(tǒng)提供全面且有效的安全解決方案的需求已經(jīng)十分迫切：

大數(shù)據(jù)系統(tǒng)存儲著許多重要且敏感的數(shù)據(jù)，這些數(shù)據(jù)是企業(yè)長久以來的財富

與大數(shù)據(jù)系統(tǒng)互動的外部系統(tǒng)是動態(tài)變化的，這會給系統(tǒng)引入新的安全隱患

在一個企業(yè)的內(nèi)部，不同Business Units會用不同的方式與大數(shù)據(jù)系統(tǒng)進行交互，比如線上的系統(tǒng)會實時給集群推送數(shù)據(jù)、數(shù)據(jù)科學家團隊則需要分析存儲在數(shù)據(jù)倉庫內(nèi)的歷史數(shù)據(jù)、運維團隊則會需要對大數(shù)據(jù)系統(tǒng)擁有管理權限。

因此為了保護公司業(yè)務、客戶、財務和名譽免于被侵害，大數(shù)據(jù)系統(tǒng)運維團隊必須將系統(tǒng)安全高度提高到和其他遺留系統(tǒng)一樣的級別。同時大數(shù)據(jù)系統(tǒng)并不意味著引入大的安全隱患，通過精細完整的設計，仍然能夠把一些傳統(tǒng)的系統(tǒng)安全解決方案對接到最新的大數(shù)據(jù)集群系統(tǒng)中。

一般來說，一個完整的企業(yè)級安全框架包括五個部分：

Administration: 大數(shù)據(jù)集群系統(tǒng)的集中式管理，設定全局一致的安全策略

Authentication: 對用戶和系統(tǒng)的認證

Authorization：授權個人用戶和組對數(shù)據(jù)的訪問權限

Audit：維護數(shù)據(jù)訪問的日志記錄

Data Protection：數(shù)據(jù)脫敏和加密以達到保護數(shù)據(jù)的目的

系統(tǒng)管理員要能夠提供覆蓋以上五個部分的企業(yè)級安全基礎設施，否則任何一環(huán)的缺失都可能給整個系統(tǒng)引入安全性風險。

在大數(shù)據(jù)系統(tǒng)安全集中式管理平臺這塊，由Hortonworks推出的開源項目Apache Ranger就可以十分全面地為用戶提供Hadoop生態(tài)圈的集中安全策略的管理，并解決授權(Authorization)和審計(Audit)。例如，運維管理員可以輕松地為個人用戶和組對文件、數(shù)據(jù)等的訪問策略，然后審計對數(shù)據(jù)源的訪問。

與Ranger提供相似功能的還有Cloudera推出的Apache Sentry項目，相比較而言Ranger的功能會更全面一些。

而在認證（Authentication）方面, 一種普遍采用的解決方案是將基于Kerberos的認證方案對接到企業(yè)內(nèi)部的LDAP環(huán)境中， Kerberos也是唯一為Hadoop全面實施的驗證技術。

另外值得一提的是Apache Knox Gateway項目，與Ranger提高集群內(nèi)部組件以及用戶互相訪問的安全不同，Knox提供的是Hadoop集群與外界的唯一交互接口，也就是說所有與集群交互的REST API都通過Knox處理。這樣，Knox就給大數(shù)據(jù)系統(tǒng)提供了一個很好的基于邊緣的安全（perimeter-based security）。

基于以上提到的五個安全指標和Hadoop生態(tài)圈安全相關的開源項目，已經(jīng)足已證明基于Hadoop的大數(shù)據(jù)平臺我們是能夠構建一個集中、一致、全面且有效的安全解決方案。

我市再ITjob管網(wǎng)上面找的

數(shù)據(jù)庫的問題

數(shù)據(jù)庫，簡而言之可視為電子化的文件柜——存儲電子文件的處所，用戶可以對文件中的數(shù)據(jù)進行新增、截取、更新、刪除等操作。

所謂“數(shù)據(jù)庫”系以一定方式儲存在一起、能予多個用戶共享、具有盡可能小的冗余度、與應用程序彼此獨立的數(shù)據(jù)集合。[1]

數(shù)據(jù)庫管理系統(tǒng)

主條目：數(shù)據(jù)庫管理系統(tǒng)

數(shù)據(jù)庫管理系統(tǒng)（英語：Database Management System，簡稱DBMS）是為管理數(shù)據(jù)庫而設計的電腦軟件系統(tǒng)，一般具有存儲、截取、安全保障、備份等基礎功能。數(shù)據(jù)庫管理系統(tǒng)可以依據(jù)它所支持的數(shù)據(jù)庫模型來作分類，例如關系式、XML；或依據(jù)所支持的計算機類型來作分類，例如服務器群集、移動電話；或依據(jù)所用查詢語言來作分類，例如SQL、XQuery；或依據(jù)性能沖量重點來作分類，例如最大規(guī)模、最高運行速度；亦或其他的分類方式。不論使用哪種分類方式，一些DBMS能夠跨類別，例如，同時支持多種查詢語言。[1]

類型

關系數(shù)據(jù)庫

MySQL

MariaDB（MySQL的代替品，英文維基百科從MySQL轉(zhuǎn)向MariaDB）

Percona Server（MySQL的代替品·）

PostgreSQL

Microsoft Access

Microsoft SQL Server

Google Fusion Tables

FileMaker

Oracle數(shù)據(jù)庫

Sybase

dBASE

Clipper

FoxPro

foshub

幾乎所有的數(shù)據(jù)庫管理系統(tǒng)都配備了一個開放式數(shù)據(jù)庫連接（ODBC）驅(qū)動程序，令各個數(shù)據(jù)庫之間得以互相集成。

非關系型數(shù)據(jù)庫（NoSQL）

主條目：NoSQL

BigTable（Google）

Cassandra

MongoDB

CouchDB

鍵值（key-value）數(shù)據(jù)庫

Apache Cassandra（為Facebook所使用）：高度可擴展

Dynamo

LevelDB（Google）[1]

數(shù)據(jù)庫模型

對象模型

層次模型（輕量級數(shù)據(jù)訪問協(xié)議）

網(wǎng)狀模型（大型數(shù)據(jù)儲存）

關系模型

面向?qū)ο竽Ｐ?/p>

半結(jié)構化模型

平面模型（表格模型，一般在形式上是一個二維數(shù)組。如表格模型數(shù)據(jù)Excel)

架構

數(shù)據(jù)庫的架構可以大致區(qū)分為三個概括層次：內(nèi)層、概念層和外層。

內(nèi)層：最接近實際存儲體，亦即有關數(shù)據(jù)的實際存儲方式。

外層：最接近用戶，即有關個別用戶觀看數(shù)據(jù)的方式。

概念層：介于兩者之間的間接層。

數(shù)據(jù)庫索引

主條目：數(shù)據(jù)庫索引

數(shù)據(jù)索引的觀念由來已久，像是一本書前面幾頁都有目錄，目錄也算是索引的一種，只是它的分類較廣，例如車牌、身份證字號、條碼等，都是一個索引的號碼，當我們看到號碼時，可以從號碼中看出其中的端倪，若是要找的人、車或物品，也只要提供相關的號碼，即可迅速查到正確的人事物。

另外，索引跟字段有著相應的關系，索引即是由字段而來，其中字段有所謂的關鍵字段（Key Field），該字段具有唯一性，即其值不可重復，且不可為"空值（null）"。例如：在合并數(shù)據(jù)時，索引便是扮演欲附加字段數(shù)據(jù)之指向性用途的角色。故此索引為不可重復性且不可為空。

數(shù)據(jù)庫操作:事務

主條目：數(shù)據(jù)庫事務

事務（transaction）是用戶定義的一個數(shù)據(jù)庫操作序列，這些操作要么全做，要么全不做，是一個不可分割的工作單位。事務的ACID特性：

基元性（atomicity）

一致性（consistency）

隔離性（isolation）

持續(xù)性（durability）

事務的并發(fā)性是指多個事務的并行操作輪流交叉運行，事務的并發(fā)可能會訪問和存儲不正確的數(shù)據(jù)，破壞交易的隔離性和數(shù)據(jù)庫的一致性。

網(wǎng)狀數(shù)據(jù)模型的數(shù)據(jù)結(jié)構網(wǎng)狀模型滿足下面兩個條件的基本層次聯(lián)系的集合為網(wǎng)狀模型。 1. 允許一個以上的結(jié)點無雙親； 2. 一個結(jié)點可以有多于一個的雙親。[2]

參見

數(shù)據(jù)庫理論

信息技術審核

LDAP（輕量級數(shù)據(jù)訪問協(xié)議）

SQL（結(jié)構化查詢語言）

在電子政務方案中看到LDAP技術，什么是LDAP技術？有什么作用？

LDAP的英文全稱是Lightweight Directory Access Protocol，一般都簡稱為LDAP。它是基于X.500標準的，但是簡單多了并且可以根據(jù)需要定制。與X.500不同，LDAP支持TCP/IP，這對訪問Internet是必須的。LDAP的核心規(guī)范在RFC中都有定義，所有與LDAP相關的RFC都可以在LDAPman RFC網(wǎng)頁中找到。現(xiàn)在LDAP技術不僅發(fā)展得很快而且也是激動人心的。在企業(yè)范圍內(nèi)實現(xiàn)LDAP可以讓運行在幾乎所有計算機平臺上的所有的應用程序從LDAP目錄中獲取信息。LDAP目錄中可以存儲各種類型的數(shù)據(jù)：電子郵件地址、郵件路由信息、人力資源數(shù)據(jù)、公用密匙、聯(lián)系人列表，等等。通過把LDAP目錄作為系統(tǒng)集成中的一個重要環(huán)節(jié)，可以簡化員工在企業(yè)內(nèi)部查詢信息的步驟，甚至連主要的數(shù)據(jù)源都可以放在任何地方。

LDAP目錄的優(yōu)勢

如果需要開發(fā)一種提供公共信息查詢的系統(tǒng)一般的設計方法可能是采用基于WEB的數(shù)據(jù)庫設計方式，即前端使用瀏覽器而后端使用WEB服務器加上關系數(shù)據(jù)庫。后端在Windows的典型實現(xiàn)可能是Windows NT + IIS + Acess數(shù)據(jù)庫或者是SQL服務器，IIS和數(shù)據(jù)庫之間通過ASP技術使用ODBC進行連接，達到通過填寫表單查詢數(shù)據(jù)的功能；

后端在Linux系統(tǒng)的典型實現(xiàn)可能是Linux+ Apache + postgresql，Apache和數(shù)據(jù)庫之間通過PHP3提供的函數(shù)進行連接。使用上述方法的缺點是后端關系數(shù)據(jù)庫的引入導致系統(tǒng)整體的性能降低和系統(tǒng)的管理比較繁瑣，因為需要不斷的進行數(shù)據(jù)類型的驗證和事務的完整性的確認；并且前端用戶對數(shù)據(jù)的控制不夠靈活，用戶權限的設置一般只能是設置在表一級而不是設置在記錄一級。

目錄服務的推出主要是解決上述數(shù)據(jù)庫中存在的問題。目錄與關系數(shù)據(jù)庫相似，是指具有描述性的基于屬性的記錄集合，但它的數(shù)據(jù)類型主要是字符型，為了檢索的需要添加了BIN（二進制數(shù)據(jù)）、CIS（忽略大小寫）、CES（大小寫敏感）、TEL（電話型）等語法（Syntax），而不是關系數(shù)據(jù)庫提供的整數(shù)、浮點數(shù)、日期、貨幣等類型，同樣也不提供象關系數(shù)據(jù)庫中普遍包含的大量的函數(shù)，它主要面向數(shù)據(jù)的查詢服務（查詢和修改操作比一般是大于10:1），不提供事務的回滾（rollback）機制，它的數(shù)據(jù)修改使用簡單的鎖定機制實現(xiàn)All-or-Nothing，它的目標是快速響應和大容量查詢并且提供多目錄服務器的信息復制功能。

現(xiàn)在該說說LDAP目錄到底有些什么優(yōu)勢了。現(xiàn)在LDAP的流行是很多因數(shù)共同作用的結(jié)果。可能LDAP最大的優(yōu)勢是：可以在任何計算機平臺上，用很容易獲得的而且數(shù)目不斷增加的LDAP的客戶端程序訪問LDAP目錄。而且也很容易定制應用程序為它加上LDAP的支持。

LDAP協(xié)議是跨平臺的和標準的協(xié)議，因此應用程序就不用為LDAP目錄放在什么樣的服務器上操心了。實際上，LDAP得到了業(yè)界的廣泛認可，因為它是Internet的標準。產(chǎn)商都很愿意在產(chǎn)品中加入對LDAP的支持，因為他們根本不用考慮另一端（客戶端或服務端）是怎么樣的。LDAP服務器可以是任何一個開發(fā)源代碼或商用的LDAP目錄服務器（或者還可能是具有LDAP界面的關系型數(shù)據(jù)庫），因為可以用同樣的協(xié)議、客戶端連接軟件包和查詢命令與LDAP服務器進行交互。與LDAP不同的是，如果軟件產(chǎn)商想在軟件產(chǎn)品中集成對DBMS的支持，那么通常都要對每一個數(shù)據(jù)庫服務器單獨定制。不象很多商用的關系型數(shù)據(jù)庫，你不必為LDAP的每一個客戶端連接或許可協(xié)議付費大多數(shù)的LDAP服務器安裝起來很簡單，也容易維護和優(yōu)化。

LDAP服務器可以用“推”或“拉”的方法復制部分或全部數(shù)據(jù)，例如：可以把數(shù)據(jù)“推”到遠程的辦公室，以增加數(shù)據(jù)的安全性。復制技術是內(nèi)置在LDAP服務器中的而且很容易配置。如果要在DBMS中使用相同的復制功能，數(shù)據(jù)庫產(chǎn)商就會要你支付額外的費用，而且也很難管理。

LDAP允許你根據(jù)需要使用ACI（一般都稱為ACL或者訪問控制列表）控制對數(shù)據(jù)讀和寫的權限。例如，設備管理員可以有權改變員工的工作地點和辦公室號碼，但是不允許改變記錄中其它的域。ACI可以根據(jù)誰訪問數(shù)據(jù)、訪問什么數(shù)據(jù)、數(shù)據(jù)存在什么地方以及其它對數(shù)據(jù)進行訪問控制。因為這些都是由LDAP目錄服務器完成的，所以不用擔心在客戶端的應用程序上是否要進行安全檢查。

LDAP（Lightweight Directory Acess Protocol）是目錄服務在TCP/IP上的實現(xiàn)（RFC 1777 V2版和RFC 2251

V3版）。它是對X500的目錄協(xié)議的移植，但是簡化了實現(xiàn)方法，所以稱為輕量級的目錄服務。在LDAP中目錄是按照樹型結(jié)構組織，目錄由條目（Entry）組成，條目相當于關系數(shù)據(jù)庫中表的記錄；條目是具有區(qū)別名DN（Distinguished

Name）的屬性（Attribute）集合，DN相當于關系數(shù)據(jù)庫表中的關鍵字（Primary

Key）；屬性由類型（Type）和多個值（Values）組成，相當于關系數(shù)據(jù)庫中的域（Field）由域名和數(shù)據(jù)類型組成，只是為了方便檢索的需要，LDAP中的Type可以有多個Value，而不是關系數(shù)據(jù)庫中為降低數(shù)據(jù)的冗余性要求實現(xiàn)的各個域必須是不相關的。LDAP中條目的組織一般按照地理位置和組織關系進行組織，非常的直觀。LDAP把數(shù)據(jù)存放在文件中，為提高效率可以使用基于索引的文件數(shù)據(jù)庫，而不是關系數(shù)據(jù)庫。LDAP協(xié)議集還規(guī)定了DN的命名方法、存取控制方法、搜索格式、復制方法、URL格式、開發(fā)接口等

LDAP對于這樣存儲這樣的信息最為有用，也就是數(shù)據(jù)需要從不同的地點讀取，但是不需要經(jīng)常更新。

例如，這些信息存儲在LDAP目錄中是十分有效的：

l 公司員工的電話號碼簿和組織結(jié)構圖

l 客戶的聯(lián)系信息

l 計算機管理需要的信息，包括NIS映射、email假名，等等

l 軟件包的配置信息

l 公用證書和安全密匙

什么時候該用LDAP存儲數(shù)據(jù)

大多數(shù)的LDAP服務器都為讀密集型的操作進行專門的優(yōu)化。因此，當從LDAP服務器中讀取數(shù)據(jù)的時候會比從專門為OLTP優(yōu)化的關系型數(shù)據(jù)庫中讀取數(shù)據(jù)快一個數(shù)量級。也是因為專門為讀的性能進行優(yōu)化，大多數(shù)的LDAP目錄服務器并不適合存儲需要需要經(jīng)常改變的數(shù)據(jù)。例如，用LDAP服務器來存儲電話號碼是一個很好的選擇，但是它不能作為電子商務站點的數(shù)據(jù)庫服務器。

如果下面每一個問題的答案都是“是”，那么把數(shù)據(jù)存在LDAP中就是一個好主意。

l 需要在任何平臺上都能讀取數(shù)據(jù)嗎？

l 每一個單獨的記錄項是不是每一天都只有很少的改變？

l 可以把數(shù)據(jù)存在平面數(shù)據(jù)庫（flat database）而不是關系型數(shù)據(jù)庫中嗎？換句話來說，也就是不管什么范式不范式的，把所有東西都存在一個記錄中（差不多只要滿足第一范式）。

最后一個問題可能會唬住一些人，其實用平面數(shù)據(jù)庫去存儲一些關系型的數(shù)據(jù)也是很一般的。例如，一條公司員工的記錄就可以包含經(jīng)理的登錄名。用LDAP來存儲這類信息是很方便的。一個簡單的判斷方法：如果可以把保數(shù)據(jù)存在一張張的卡片里，就可以很容易地把它存在LDAP目錄里。

安全和訪問控制

LDAP提供很復雜的不同層次的訪問控制或者ACI。因這些訪問可以在服務器端控制，這比用客戶端的軟件保證數(shù)據(jù)的安全可安全多了。

用LDAP的ACI，可以完成：

l 給予用戶改變他們自己的電話號碼和家庭地址的權限，但是限制他們對其它數(shù)據(jù)（如，職務名稱，經(jīng)理的登錄名，等等）只有“只讀”權限。

l 給予“HR-admins"組中的所有人權限以改變下面這些用戶的信息：經(jīng)理、工作名稱、員工號、部門名稱和部門號。但是對其它域沒有寫權限。

l 禁止任何人查詢LDAP服務器上的用戶口令，但是可以允許用戶改變他或她自己的口令。

l 給予經(jīng)理訪問他們上級的家庭電話的只讀權限，但是禁止其他人有這個權限。

l 給予“host-admins"組中的任何人創(chuàng)建、刪除和編輯所有保存在LDAP服務器中的與計算機主機有關的信息

l 通過Web，允許“foobar-sales"組中的成員有選擇地給予或禁止他們自己讀取一部分客戶聯(lián)系數(shù)據(jù)的讀權限。這將允許他們把客戶聯(lián)系信息下載到本地的筆記本電腦或個人數(shù)字助理（PDA）上。（如果銷售人員的軟件都支持LDAP，這將非常有用）

l 通過Web，允許組的所有者刪除或添加他們擁有的組的成員。例如：可以允許銷售經(jīng)理給予或禁止銷售人員改變Web頁的權限。也可以允許郵件假名（mail aliase）的所有者不經(jīng)過IT技術人員就直接從郵件假名中刪除或添加用戶。“公用”的郵件列表應該允許用戶從郵件假名中添加或刪除自己（但是只能是自己）。也可以對IP地址或主機名加以限制。例如，某些域只允許用戶IP地址以192.168.200.*開頭的有讀的權限，或者用戶反向查找DNS得到的主機名必須為*.foobar.com。

LDAP目錄樹的結(jié)構

LDAP目錄以樹狀的層次結(jié)構來存儲數(shù)據(jù)。如果你對自頂向下的DNS樹或UNIX文件的目錄樹比較熟悉，也就很容易掌握LDAP目錄樹這個概念了。就象DNS的主機名那樣，LDAP目錄記錄的標識名（Distinguished Name，簡稱DN）是用來讀取單個記錄，以及回溯到樹的頂部。后面會做詳細地介紹。

為什么要用層次結(jié)構來組織數(shù)據(jù)呢？原因是多方面的。下面是可能遇到的一些情況：

l 如果你想把所有的美國客戶的聯(lián)系信息都“推”到位于到西雅圖辦公室（負責營銷）的LDAP服務器上，但是你不想把公司的資產(chǎn)管理信息“推”到那里。

l 你可能想根據(jù)目錄樹的結(jié)構給予不同的員工組不同的權限。在下面的例子里，資產(chǎn)管理組對“asset-mgmt"部分有完全的訪問權限，但是不能訪問其它地方。

l 把LDAP存儲和復制功能結(jié)合起來，可以定制目錄樹的結(jié)構以降低對WAN帶寬的要求。位于西雅圖的營銷辦公室需要每分鐘更新的美國銷售狀況的信息，但是歐洲的銷售情況就只要每小時更新一次就行了。

刨根問底：基準DN

LDAP目錄樹的最頂部就是根，也就是所謂的“基準DN"。基準DN通常使用下面列出的三種格式之一。假定我在名為FooBar的電子商務公司工作，這家公司在Internet上的名字是foobar.com。

o="FooBar, Inc.", c=US

（以X.500格式表示的基準DN）

在這個例子中，o=FooBar, Inc. 表示組織名，在這里就是公司名的同義詞。c=US 表示公司的總部在美國。以前，一般都用這種方式來表示基準DN。但是事物總是在不斷變化的，現(xiàn)在所有的公司都已經(jīng)（或計劃）上Internet上。隨著Internet的全球化，在基準DN中使用國家代碼很容易讓人產(chǎn)生混淆。現(xiàn)在，X.500格式發(fā)展成下面列出的兩種格式。

o=foobar.com

（用公司的Internet地址表示的基準DN）

這種格式很直觀，用公司的域名作為基準DN。這也是現(xiàn)在最常用的格式。

dc=foobar, dc=com

（用DNS域名的不同部分組成的基準DN）

就象上面那一種格式，這種格式也是以DNS域名為基礎的，但是上面那種格式不改變域名（也就更易讀），而這種格式把域名：foobar.com分成兩部分 dc=foobar, dc=com。在理論上，這種格式可能會更靈活一點，但是對于最終用戶來說也更難記憶一點。考慮一下foobar.com這個例子。當foobar.com和gizmo.com合并之后，可以簡單的把“dc=com"當作基準DN。把新的記錄放到已經(jīng)存在的dc=gizmo, dc=com目錄下，這樣就簡化了很多工作（當然，如果foobar.com和wocket.edu合并，這個方法就不能用了）。如果LDAP服務器是新安裝的，我建議你使用這種格式。再請注意一下，如果你打算使用活動目錄（Actrive Directory），Microsoft已經(jīng)限制你必須使用這種格式。

更上一層樓：在目錄樹中怎么組織數(shù)據(jù)

在UNIX文件系統(tǒng)中，最頂層是根目錄（root）。在根目錄的下面有很多的文件和目錄。象上面介紹的那樣，LDAP目錄也是用同樣的方法組織起來的。

在根目錄下，要把數(shù)據(jù)從邏輯上區(qū)分開。因為歷史上（X.500）的原因，大多數(shù)LDAP目錄用OU從邏輯上把數(shù)據(jù)分開來。OU表示“Organization Unit"，在X.500協(xié)議中是用來表示公司內(nèi)部的機構：銷售部、財務部，等等。現(xiàn)在LDAP還保留ou=這樣的命名規(guī)則，但是擴展了分類的范圍，可以分類為：ou=people, ou=groups, ou=devices，等等。更低一級的OU有時用來做更細的歸類。例如：LDAP目錄樹（不包括單獨的記錄）可能會是這樣的：

dc=foobar, dc=com

ou=customers

ou=asia

ou=europe

ou=usa

ou=employees

ou=rooms

ou=groups

ou=assets-mgmt

ou=nisgroups

ou=recipes

單獨的LDAP記錄

DN是LDAP記錄項的名字

在LDAP目錄中的所有記錄項都有一個唯一的“Distinguished Name"，也就是DN。每一個LDAP記錄項的DN是由兩個部分組成的：相對DN（RDN）和記錄在LDAP目錄中的位置。

RDN是DN中與目錄樹的結(jié)構無關的部分。在LDAP目錄中存儲的記錄項都要有一個名字，這個名字通常存在cn（Common Name）這個屬性里。因為幾乎所有的東西都有一個名字，在LDAP中存儲的對象都用它們的cn值作為RDN的基礎。如果我把最喜歡的吃燕麥粥食譜存為一個記錄，我就會用cn=Oatmeal Deluxe作為記錄項的RDN。

l 我的LDAP目錄的基準DN是dc=foobar,dc=com

l 我把自己的食譜作為LDAP的記錄項存在ou=recipes

l 我的LDAP記錄項的RDN設為cn=Oatmeal Deluxe

上面這些構成了燕麥粥食譜的LDAP記錄的完整DN。記住，DN的讀法和DNS主機名類似。下面就是完整的DN：

cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com

舉一個實際的例子來說明DN

現(xiàn)在為公司的員工設置一個DN。可以用基于cn或uid（User ID），作為典型的用戶帳號。例如，F(xiàn)ooBar的員工Fran Smith（登錄名：fsmith）的DN可以為下面兩種格式：

uid=fsmith,ou=employees,dc=foobar,dc=com

（基于登錄名）

LDAP（以及X.500）用uid表示“User ID"，不要把它和UNIX的uid號混淆了。大多數(shù)公司都會給每一個員工唯一的登錄名，因此用這個辦法可以很好地保存員工的信息。你不用擔心以后還會有一個叫Fran Smith的加入公司，如果Fran改變了她的名字（結(jié)婚？離婚？或宗教原因？），也用不著改變LDAP記錄項的DN。

cn=Fran Smith,ou=employees,dc=foobar,dc=com

（基于姓名）

可以看到這種格式使用了Common Name（CN）。可以把Common Name當成一個人的全名。這種格式有一個很明顯的缺點就是：如果名字改變了，LDAP的記錄就要從一個DN轉(zhuǎn)移到另一個DN。但是，我們應該盡可能地避免改變一個記錄項的DN。

定制目錄的對象類型

你可以用LDAP存儲各種類型的數(shù)據(jù)對象，只要這些對象可以用屬性來表示，下面這些是可以在LDAP中存儲的一些信息：

l 員工信息：員工的姓名、登錄名、口令、員工號、他的經(jīng)理的登錄名，郵件服務器，等等。

l 物品跟蹤信息：計算機名、IP地址、標簽、型號、所在位置，等等。

l 客戶聯(lián)系列表：客戶的公司名、主要聯(lián)系人的電話、傳真和電子郵件，等等。

l 會議廳信息：會議廳的名字、位置、可以坐多少人、電話號碼、是否有投影機。

l 食譜信息：菜的名字、配料、烹調(diào)方法以及準備方法。

因為LDAP目錄可以定制成存儲任何文本或二進制數(shù)據(jù)，到底存什么要由你自己決定。LDAP目錄用對象類型（object classes）的概念來定義運行哪一類的對象使用什么屬性。在幾乎所有的LDAP服務器中，你都要根據(jù)自己的需要擴展基本的LDAP目錄的功能，創(chuàng)建新的對象類型或者擴展現(xiàn)存的對象類型。

LDAP目錄以一系列“屬性對”的形式來存儲記錄項，每一個記錄項包括屬性類型和屬性值（這與關系型數(shù)據(jù)庫用行和列來存取數(shù)據(jù)有根本的不同）。下面是我存在LDAP目錄中的一部分食譜記錄：

dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com

cn: Instant Oatmeal Deluxe

recipeCuisine: breakfast

recipeIngredient: 1 packet instant oatmeal

recipeIngredient: 1 cup water

recipeIngredient: 1 pinch salt

recipeIngredient: 1 tsp brown sugar

recipeIngredient: 1/4 apple, any type

請注意上面每一種配料都作為屬性recipeIngredient值。LDAP目錄被設計成象上面那樣為一個屬性保存多個值的，而不是在每一個屬性的后面用逗號把一系列值分開。

因為用這樣的方式存儲數(shù)據(jù)，所以數(shù)據(jù)庫就有很大的靈活性，不必為加入一些新的數(shù)據(jù)就重新創(chuàng)建表和索引。更重要的是，LDAP目錄不必花費內(nèi)存或硬盤空間處理“空”域，也就是說，實際上不使用可選擇的域也不會花費你任何資源。

作為例子的一個單獨的數(shù)據(jù)項

讓我們看看下面這個例子。我們用Foobar, Inc.的員工Fran Smith的LDAP記錄。這個記錄項的格式是LDIF，用來導入和導出LDAP目錄的記錄項。

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

objectclass: foobarPerson

uid: fsmith

givenname: Fran

sn: Smith

cn: Fran Smith

cn: Frances Smith

telephonenumber: 510-555-1234

roomnumber: 122G

o: Foobar, Inc.

mailRoutingAddress: fsmith@foobar.com

mailhost: mail.foobar.com

userpassword: {crypt}3x1231v76T89N

uidnumber: 1234

gidnumber: 1200

homedirectory: /home/fsmith

loginshell: /usr/local/bin/bash

屬性的值在保存的時候是保留大小寫的，但是在默認情況下搜索的時候是不區(qū)分大小寫的。某些特殊的屬性（例如，password）在搜索的時候需要區(qū)分大小寫。

讓我們一點一點地分析上面的記錄項。

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

這是Fran的LDAP記錄項的完整DN，包括在目錄樹中的完整路徑。LDAP（和X.500）使用uid（User ID），不要把它和UNIX的uid號混淆了。

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

objectclass: foobarPerson

可以為任何一個對象根據(jù)需要分配多個對象類型。person對象類型要求cn（common name）和sn（surname）這兩個域不能為空。persion對象類型允許有其它的可選域，包括givenname、telephonenumber，等等。organizational Person給person加入更多的可選域，inetOrgPerson又加入更多的可選域（包括電子郵件信息）。最后，foobarPerson是為Foobar定制的對象類型，加入了很多定制的屬性。

uid: fsmith

givenname: Fran

sn: Smith

cn: Fran Smith

cn: Frances Smith

telephonenumber: 510-555-1234

roomnumber: 122G

o: Foobar, Inc.

以前說過了，uid表示User ID。當看到uid的時候，就在腦袋里想一想“l(fā)ogin"。

請注意CN有多個值。就象上面介紹的，LDAP允許某些屬性有多個值。為什么允許有多個值呢？假定你在用公司的LDAP服務器查找Fran的電話號碼。你可能只知道她的名字叫Fran，但是對人力資源處的人來說她的正式名字叫做Frances。因為保存了她的兩個名字，所以用任何一個名字檢索都可以找到Fran的電話號碼、電子郵件和辦公房間號，等等。

mailRoutingAddress: fsmith@foobar.com

mailhost: mail.foobar.com

就象現(xiàn)在大多數(shù)的公司都上網(wǎng)了，F(xiàn)oobar用Sendmail發(fā)送郵件和處理外部郵件路由信息。Foobar把所有用戶的郵件信息都存在LDAP中。最新版本的Sendmail支持這項功能。

Userpassword: {crypt}3x1231v76T89N

uidnumber: 1234

gidnumber: 1200

gecos: Frances Smith

homedirectory: /home/fsmith

loginshell: /usr/local/bin/bash

注意，F(xiàn)oobar的系統(tǒng)管理員把所有用戶的口令映射信息也都存在LDAP中。FoobarPerson類型的對象具有這種能力。再注意一下，用戶口令是用UNIX的口令加密格式存儲的。UNIX的uid在這里為uidnumber。提醒你一下，關于如何在LDAP中保存NIS信息，有完整的一份RFC。在以后的文章中我會談一談NIS的集成。

LDAP復制

LDAP服務器可以使用基于“推”或者“拉”的技術，用簡單或基于安全證書的安全驗證，復制一部分或者所有的數(shù)據(jù)。

例如，F(xiàn)oobar有一個“公用的”LDAP服務器，地址為ldap.foobar.com，端口為389。Netscape Communicator的電子郵件查詢功能、UNIX的“ph"命令要用到這個服務器，用戶也可以在任何地方查詢這個服務器上的員工和客戶聯(lián)系信息。公司的主LDAP服務器運行在相同的計算機上，不過端口號是1389。

你可能即不想讓員工查詢資產(chǎn)管理或食譜的信息，又不想讓信息技術人員看到整個公司的LDAP目錄。為了解決這個問題，F(xiàn)oobar有選擇地把子目錄樹從主LDAP服務器復制到“公用”LDAP服務器上，不復制需要隱藏的信息。為了保持數(shù)據(jù)始終是最新的，主目錄服務器被設置成即時“推”同步。這些種方法主要是為了方便，而不是安全，因為如果有權限的用戶想查詢所有的數(shù)據(jù)，可以用另一個LDAP端口。

假定Foobar通過從奧克蘭到歐洲的低帶寬數(shù)據(jù)的連接用LDAP管理客戶聯(lián)系信息。可以建立從ldap.foobar.com:1389到munich-ldap.foobar.com:389的數(shù)據(jù)復制，象下面這樣：

periodic pull: ou=asia,ou=customers,o=sendmail.com

periodic pull: ou=us,ou=customers,o=sendmail.com

immediate push: ou=europe,ou=customers,o=sendmail.com

“拉”連接每15分鐘同步一次，在上面假定的情況下足夠了。“推”連接保證任何歐洲的聯(lián)系信息發(fā)生了變化就立即被“推”到Munich。

用上面的復制模式，用戶為了訪問數(shù)據(jù)需要連接到哪一臺服務器呢？在Munich的用戶可以簡單地連接到本地服務器。如果他們改變了數(shù)據(jù)，本地的LDAP服務器就會把這些變化傳到主LDAP服務器。然后，主LDAP服務器把這些變化“推”回本地的“公用”LDAP服務器保持數(shù)據(jù)的同步。這對本地的用戶有很大的好處，因為所有的查詢（大多數(shù)是讀）都在本地的服務器上進行，速度非常快。當需要改變信息的時候，最終用戶不需要重新配置客戶端的軟件，因為LDAP目錄服務器為他們完成了所有的數(shù)據(jù)交換工作。

ldap是什么

簡單的說來，LDAP是一個得到關于人或者資源的集中、靜態(tài)數(shù)據(jù)的快速方式。

LDAP是一個用來發(fā)布目錄信息到許多不同資源的協(xié)議。通常它都作為一個集中的地址被使用，不過根據(jù)組織者的需要，它可以做得更加強大。

LDAP其實是一個電話簿，類似于我們所使用諸如NIS(Network Information Service)、DNS (Domain Name Service)等網(wǎng)絡目錄，也類似于你在花園中所看到的樹木。

不少LDAP開發(fā)人員喜歡把LDAP與關系數(shù)據(jù)庫相比，認為是另一種的存貯方式，然后在讀性能上進行比較。實際上，這種對比的基礎是錯誤的。LDAP和關系數(shù)據(jù)庫是兩種不同層次的概念，后者是存貯方式（同一層次如網(wǎng)格數(shù)據(jù)庫，

對象數(shù)據(jù)庫），前者是存貯模式和訪問協(xié)議。LDAP是一個比關系數(shù)據(jù)庫抽象層次更高的存貯概念，與關系數(shù)據(jù)庫的查詢語言SQL屬同一級別。LDAP最基本

的形式是一個連接數(shù)據(jù)庫的標準方式。該數(shù)據(jù)庫為讀查詢作了優(yōu)化。因此它可以很快地得到查詢結(jié)果，不過在其它方面，例如更新，就慢得多。

特殊的數(shù)據(jù)庫

從另一個意義上 LDAP是實現(xiàn)了指定的數(shù)據(jù)結(jié)構的存貯，它是一種特殊的數(shù)據(jù)庫。但是LDAP和一般的數(shù)據(jù)庫不同，明確這一點是很重要的。 LDAP對查詢進行了優(yōu)化，與寫性能相比LDAP的讀性能要優(yōu)秀很多。

就象Sybase、Oracle、Informix或Microsoft的數(shù)據(jù)庫管理系統(tǒng)（DBMS）是用于處理查詢和更新關系型數(shù)據(jù)庫那樣，LDAP服務器也是用來處理查詢和更新LDAP目錄的。換句話來說LDAP目錄也是一種類型的數(shù)據(jù)庫，但不是關系型數(shù)據(jù)庫。要特別注意的是，LDAP通常作為一個 hierarchical數(shù)據(jù)庫使用，而不是一個關系數(shù)據(jù)庫。因此，它的結(jié)構用樹來表示比用表格好。正因為這樣，就不能用SQL語句了。

21世紀的LDAP技術發(fā)展很快。幾乎所有計算機平臺上的所有的應用程序都可以從LDAP目錄中獲取信息。LDAP目錄中可以存儲各種類型的數(shù)據(jù)：電子郵件地址、郵件路由信息、人力資源數(shù)據(jù)、公用密匙、聯(lián)系人列表，等等。通過把LDAP目錄作為系統(tǒng)集成中的一個重要環(huán)節(jié)，可以簡化員工在企業(yè)內(nèi)部查詢信息的步驟，甚至連主要的數(shù)據(jù)源都可以放在任何地方。

服務器

LDAP服務器可以用“推”或“拉”的方法復制部分或全部數(shù)據(jù)，例如：可以把數(shù)據(jù)“推”到遠程的辦公室，以增加數(shù)據(jù)的安全性。復制技術是內(nèi)置在LDAP服務器中的而且很容易配置。如果要在DBMS中使用相同的復制功能，數(shù)據(jù)庫廠商就會要你支付額外的費用，而且也很難管理。

網(wǎng)站欄目：ldap與nosql的簡單介紹
網(wǎng)頁URL：http://chinadenli.net/article45/dsegghi.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供動態(tài)網(wǎng)站、定制網(wǎng)站、用戶體驗、標簽優(yōu)化、軟件開發(fā)、微信小程序

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源：創(chuàng)新互聯(lián)

猜你還喜歡下面的內(nèi)容