p2p資料庫
❶ 為什麼沒有人實現 P2P 資料庫
通用的資料庫，很難P2P了。性能會是問題，網路速度就是大問題；有人沒上線，專或者網路割裂，數據屬就不完整；某些人搞破壞，只要在自己的機器上做就好了，不容易被發現……
你要是用安全的機房、高速網路、伺服器集群，那就是HBase之類的分布式資料庫，或者是常見的資料庫系統都支持的集群了。
特殊用途的，P2P下載經常用的DHT、磁力鏈接，應該就是吧，整個網路一起維護種子和內容的信息。
之所以可以這樣做，是需求特殊。因為信息有大量冗餘，完整性就不是問題；因為下載時間比較長，信息交換的速度慢一點，問題也不大；沒什麼關鍵信息，造假也沒什麼破壞性……
而且還帶來了額外好處，有人想查版權，或者禁某些內容，都不容易了……你懂的……
廣義來講，P2P就是你從不同節點那下載的相同的數據，但是從狹義的資料庫來說，你要考慮更多的東西，比如數據一致性，比如資料庫不光讓你查(就是所謂下載)，還得增、刪、改，你怎麼在P2P里保證這些一致性，所有的P可都是別人的節點，說白了你沒有任何控制權。資料庫數據的安全你沒法得到保障，比如某個節點安全性特別差怎麼辦？狹義的資料庫不是簡單的數據放在那而已！你又如何保證呢？
❷ p2p數據包傳輸協議是什麼
P2P的問題很復雜,關於鏈路傳輸有如下幾點供參考.
1) 首先作為P2P的營運商，可以多設幾台P2P種子伺服器，分布在不同的網段中。比如：北方網通設一台(組)，南方電信設一台(組)，種子的內容是一樣的。種子伺服器多了，可以降低優化演算法的難度。
(2) 種子伺服器和普通節點的優先順序：種子伺服器的優先順序總數低於普通節點的，如果普通節點的速度快了，就減少從種子伺服器獲取的數據量。
(3) 全球IP地址表。P2P節點仲裁伺服器中，應該有一個全球IP地址表，分中國大陸、香港、台灣、北美、歐洲、澳洲、其它。中國大陸先按照營運商分：電信、網通、鐵通、聯通、教育網等，再按照省份分類。(網上有下載，可以整理)
(4) 高速網段表。在P2P訪問中，節點動態地將速度快的其它節點IP地址傳回伺服器，伺服器根據全球IP地址表算出網段，以網段-網段的方式記錄在資料庫中。
(5) 當一個新用戶連入節點時，在全球IP地址表中找到最近的節點，按照比例依次分配最快網段的節點;最近的節點;差一個級別的稍近的節點;隨機節點以及種子伺服器。
(6) P2P在數據傳送中，可以將30秒數據文件作為1塊數據包;數據包中按照每16KB作為一個數據塊。每個時間段(如2秒)，本節點向其它節點交換一下數據塊的傳送情況，然後計算一下數據包中每個數據塊的擁有率，優先傳送擁有率低的數據塊。在擁有率相當的情況下，隨機選擇。
(7) 在數據交換中，對於傳送慢的節點，定期剔除，然後問節點仲裁伺服器要新的節點。
(8) 如果數據包中小於10%的數據塊沒有傳送完畢，在時間充足的情況下，對於餘下的數據塊，可以同一個數據塊向多個節點請求。
(9) 節點仲裁伺服器也會將新的P2P節點強行載入到另一個節點上，但不能超過節點最大連接數。
下面解釋一下上面的文章中沒有提及或者說我覺得比較欠缺的地方.
私有地址/埠和公有地址/埠:我們知道,現在大部分網路採用的都是NAPT(Network Address/Port Translator)了,這個東東的作用是一個對外的對話在經過NAT之後IP地址和埠號都會被改寫,在這里把一次會話中客戶自己認為在使用的IP地址和埠號成為私有地址/埠,而把經過NAPT之後被改寫的IP地址和埠號稱為公有地址/埠.或者可以這么理解,私有地址/埠是你家裡人對你的昵稱而公有地址/埠則是你真正對外公開的名字.如何獲得用戶的私用地址/埠號,這個很簡單了,而要得到公有地址/埠號就要在連接上另一台機器之後由那台機器看到的IP地址和埠號來表示.
如果明白了上面的東西,下面進入我們的代碼,在這里解釋一下關鍵部分的實現:
客戶端首先得到自己的私有地址/終端,然後向server端發送登陸請求,server端在得到這個請求之後就可以知道這個client端的公有地址/終端,server會為每一個登陸的client保存它們的私有地址/埠和公有地址/埠.
OK,下面開始關鍵的打洞流程.假設client A要向client B對話,但是A不知道B的地址,即使知道根據NAT的原理這個對話在第一次會被拒絕,因為client B的NAT認為這是一個從沒有過的外部發來的請求.這個時候,A如果發現自己沒有保存B的地址,或者說發送給B的會話請求失敗了,它會要求server端讓B向A打一個洞,這個B->A的會話意義在於它使NAT B認為A的地址/埠是可以通過的地址/埠,這樣A再向B發送對話的時候就不會再被NAT B拒絕了.打一個比方來說明打洞的過程,A想來B家做客,但是遭到了B的管家NAT B的拒絕,理由是:我從來沒有聽我家B提過你的名字,這時A找到了A,B都認識的朋友server,要求server給B報一個信,讓B去跟管家說A是我的朋友,於是,B跟管家NAT B說,A是我認識的朋友,這樣A的訪問請求就不會再被管家NAT B所拒絕了.簡而言之,UDP打洞就是一個通過server保存下來的地址使得彼此之間能夠直接通信的過程,server只管幫助建立連接,在建立間接之後就不再介入了.
❸ P2P自建徵信資料庫是美夢還是噩夢
前瞻產業研究院《2015-2020年中國徵信行業市場前瞻與投資戰略規劃分析報告 》指出對於P2P公司而言，在目前這個市場競爭越來越激烈的態勢之下，對風控體系建設和徵信資料庫的完善，更應該是一個長期的戰略任務，而並非是短期的戰術任務，對於任何一家P2P公司而言，相信目前更看重的是在風險可控的前提下（不良率較低，或者是平台的收入能夠覆蓋不良的風險），盡快進行業務的拓展和異地市場的開拓，包括開設異地的分支機構以及人員的招聘和培訓等，這些都需要預留一定的業務發展經費。
而自建徵信資料庫，要麼是購買其他平台的資料庫，當然這個代價會比較昂貴，且購買過來的數據由於並非是具有高粘性的活性的，而是此前一段時間的沉澱數據，也許並不能給P2P平台的日常業務運營帶來很大的幫助。另外，即便是購買的數據，也存在一個校驗和失真的問題，數據積累也是個反復試錯的過程，源源不斷的資金支持必不可少。除了購買其他平台的數據，還有就是通過購買或者研發大平台的數據抓取軟體，來進行高強度，廣范圍，大覆蓋的網路數據集成，但是，這個需要強大的資金和人力投入，光開發或者購買軟體就需要一筆不菲的費用。對於國內大多數還在盈利邊緣掙扎的中小型P2P公司而言，更多的是考慮如何進一步通過現有的方式降低不良率，提高平台的可量化收益，先活下來，而並非是考慮在還沒有吃飽的情況下進行大規模的後台徵信資料庫的完善，這不太現實。
即便是資金實力雄厚的大公司，目前也需要衡量風控可控情況下，加強後台徵信資料庫以前台業務擴張的關系，道理很簡單，再怎麼加強後台的徵信數據能力，也不能以喪失前台的業務市場空間為前提，否則一旦失去了市場與客戶的佔有率優勢，恐怕再好的徵信資料庫也只能成為別人的一種後台支撐了。
例如，國內某著名P2P公司在徵信系統建設方面累計已投入資金超過500萬美元，預計未來還將投入1000萬~2000萬美元。而在此之前，該平台已經進行過兩輪融資，很明顯，絕大多數中小平台並不具備完善後台徵信資料庫的資金實力。
簡而言之，在目前這個P2P行業「群魔亂舞」的時代，在P2P行業還沒有進入規范化的標准化階段，目前更重要的還是以業務發展為主導，特別是對於中小的P2P公司而言，在現有可以掌握的細分市場內，依靠現有的徵信模式來控制風險，以換取長期發展的資本積累。對於大型的P2P平台而言，也要考慮長遠的徵信建設與短期的業務發展之間的關系，不能以喪失市場來換取徵信庫的完善，否則也可能是捨本逐末，得不償失。目前更好的策略是邊走邊看，有實力的平台可以投入部分資金完善自己最拿手的部分市場的徵信資料庫，同時等待央行和其他資料庫開源時代的帶來，以時間換取空間。
❹ 為什麼對資料庫的p2p的表userinfo可以進行查詢操作，但是換成插入就執行不了，到底哪裡錯了
語句引號加的不對。
"Insert INTO userinfo(uname,pword,age,address,email) values("+ name+"','"+ pwd+"','"+ age+"','"+ address+"','"+ email+"')'" .這樣試試。
還有既然url中包含了databasename，語句中就沒有必要再寫use p2p了
❺ p2p網貸系統設計中資料庫構架考慮哪些內容
其實P2P網貸系統來設計中的資料庫構自架考慮的主要是設計p2p網貸系統的資料庫架構，也就是網貸平台開發要用到的資料庫表和欄位。p2p網貸系統資料庫的數據字典模板設計是工作量極大的活，需要有足夠的耐心和細心.
（PS:迪蒙網貸系統網路上有數據字典設計模板圖，可以去看下欄位內容）。
❻ 在p2p系統中，應怎樣構建分布式的p2p資料庫
Spring Cloud項目的既定目標在於為Spring開發人員提供一整套易於使用的工具集，從而保證其輕松構建起自己需要的分布式系統方案。為了實現這一目標，Spring Cloud以Netflix OSS堆棧為基礎將大量實現堆棧加以整合並打包。這些堆棧而後可以通過大家所熟知的各類基於注釋的配置工具、Java配置工具以及基於模板的編程工具實現交付。下面就讓我們一起了解Spring Cloud當中的幾類常見組件。 Spring Cloud Config Server Spring Cloud Config Server能夠提供一項具備橫向擴展能力的集中式配置服務。它所使用的數據被保存在一套可插拔庫層當中，後者目前能夠支持本地存儲、Git以及Subversion。通過利用一套版本控制系統作為配置存儲方案，開發人員能夠輕松實現版本與審計配置的內容調整。 如何利用Spring Cloud構建起自我修復型分布式系統 配置內容會以Java屬性或者YAML文件的形式體現。該Config Server會將這些文件合並為環境對象，其中包含易於理解的Spring屬性模型以及作為REST API存在的配置文件。任何應用程序都能夠直接調用該REST API當中所包含的配置數據，但我們也可以將智能客戶端綁定方案添加到Spring Boot應用程序當中，並由後者自動將接收自Config Server的配置信息分配至任意本地配置當中。 Spring Cloud Bus Spring Cloud Config Server是一套強大的配置分發機制，能夠在保障一致性的前提下將配置內容分發到多個應用程序實例當中。然而根據其設計思路的限定，我們目前只能在應用程序啟動時對其配置進行更新。在向Git中的某一屬性發送新值時，我們需要以手動方式重啟每個應用程序進程，從而保證該值被切實納入應用當中。很明顯，大家需要能夠在無需重啟的前提下完成對應用程序配置內容的更新工作。 如何利用Spring Cloud構建起自我修復型分布式系統 Spring Cloud Bus的任務正是為應用程序實例添加一套管理背板。它目前依靠將一套客戶端綁定至一組AMQP交換與隊列當中來實現，但這一後端在設計上也實現了可插拔特性。Spring Cloud Bus為我們的應用程序帶來了更多管理端點。在圖二中，我們可以看到一個面向greeting屬性的值被發送至Git當中，而後一條請求被發送至應用A中的/bus/refresh端點。該請求會觸發以下三個事件： 應用A從Config Server處請求獲取最新版本的配置內容。任意註明了@RefreshScope的Spring Bean都會被重新初始化並載入新的配置內容。 應用A向AMQP交換機制發送一條消息，表明其已經收到更新指示。 通過監聽AMQP隊列而被納入Cloud Bus的應用B與應用C會獲取到上述消息，並以與應用A同樣的方式實現配置更新。 現在我們已經有能力在無需重啟的情況下對應用程序配置進行更新了。
❼ 請問p2p 網貸 資料庫設計需要注意什麼
資料庫將反映的現實p2p網貸系序中的實體、屬性和它們之間的關系等的原始數據形式，包括各數據項、記錄、系、文卷的標識符、定義、類型、度量單位和值域，建立本資料庫的每一幅用戶視圖。更多也可以參考迪蒙p2p網貸系統網路：
資料庫表名與欄位名應遵守一定規則，包含一到多個單詞，每一個單詞第一個字母大寫，其餘字母均小寫。
如果是關聯表，則命名規則為R_表A_表B，如R_ProctInfo_Tag等。
對於視圖命名，規則為View_表A,視圖由多個表產生，就用下劃線連接幾個表名，如View_ProctInfo_ProctClass。
存儲過程，命名規則為P_表名_存儲過程功能名稱。如P_ProctInfo_Add;如果該存儲過程是很多表共用的，命名為：P_All_存儲過程功能名稱
數據欄位命名。當欄位引用的是其他表欄位時，使用表名_其他表欄位名稱，間用下劃線隔開，命名規則：表名_單詞。如ProctInfo表與ProctClass表關聯的欄位：ProctClass_Id，ProctClass_Name等。與外表的主鍵或相關欄位引用時(包括狀態值)，須加同時添加外表所引用主鍵(或狀態值)對應的名稱，以方便查詢時減少多表關聯語句的編寫，提高代碼執行效率。
❽ 怎麼進行p2p資料庫設計
P2P資料庫設計是一項重要工作，前期平台的前台後台設計與開發專都依據數據屬庫設計。這里迪蒙網貸資料庫設計小編分享下經驗：
數據表設計要求：應遵守一定規則，包含一到多個單詞。
如果是關聯表，則命名規則為R_表A_表B.
對於視圖命名，規則為View_表A,視圖由多個表產生，就用下劃線連接幾個表名。
存儲過程，命名規則為P_表名_存儲過程功能名稱。
數據欄位命名，命名規則：表名_單詞。
你get到了嗎？
❾ p2p網貸資料庫設計是怎麼樣的
p2p網貸資料庫的數據字典模板設計是工作量極大的活，需要有足夠的耐心和細心，具體的結構設計可以去迪蒙網貸系統看看，有詳細的圖解，望採納，謝謝！
❿ 什麼是p2p技術 資料庫地圖化 又指的是什麼
P2P是peer-to-peer的縮寫，peer在英語里有"（地位、能力等）同等者"、"同事"和"夥伴"等意義。這樣一來，P2P也就可以理解為"夥伴對夥伴"的意思，或稱為對等聯網。目前人們認為其在加強網路上人的交流、文件交換、分布計算等方面大有前途。
簡單的說，P2P直接將人們聯系起來，讓人們通過互聯網直接交互。P2P使得網路上的溝通變得容易、更直接共享和交互，真正地消除中間商。P2P就是人可以直接連接到其他用戶的計算機、交換文件，而不是像過去那樣連接到伺服器去瀏覽與下載。P2P另一個重要特點是改變互聯網現在的以大網站為中心的狀態、重返"非中心化"，並把權力交還給用戶。 P2P看起來似乎很新，但是正如B2C、B2B是將現實世界中很平常的東西移植到互聯網上一樣，P2P並不是什麼新東西。在現實生活中我們每天都按照P2P模式面對面地或者通過電話交流和溝通。
即使從網路看，P2P也不是新概念，P2P是互聯網整體架構的基礎。互聯網最基本的協議TCP/IP並沒有客戶機和伺服器的概念，所有的設備都是通訊的平等的一端。在十年之前，所有的互聯網上的系統都同時具有伺服器和客戶機的功能。當然，後來發展的那些架構在TCP/IP之上的軟體的確採用了客戶機/伺服器的結構：瀏覽器和Web伺服器，郵件客戶端和郵件伺服器。但是，對於伺服器來說，它們之間仍然是對等聯網的。以email為例，互聯網上並沒有一個巨大的、唯一的郵件伺服器來處理所有的email，而是對等聯網的郵件伺服器相互協作把email傳送到相應的伺服器上去。另外用戶之間email則一直對等的聯絡渠道。當然但是過去的5年裡，互聯網的發展至少從表面上遠離了P2P，互聯網上絕大部分的節點也不能和其他節點直接地交流。Napster正是喚醒了深藏在互聯網背後的對等聯網。Napster的文件共享功能在區域網中共享目錄也是再平常不過的事情。但是Napster的成功促使人們認識到把這種"對等聯網"拓展到整個互聯網范圍的可能性。當然，在許多人的眼中，Napster並不是純粹的P2P，它仍然需要一個處於中心協調機制。
事實上，網路上現有的許多服務可以歸入P2P的行列。即時訊息系統譬如ICQ、AOL Instant Messenger、Yahoo Pager、微軟的MSN Messenger以及國內的OICQ是最流行的P2P應用。它們允許用戶互相溝通和交換信息、交換文件。用戶之間的信息交流不是直接的，需要有位於中心的伺服器來協調。但這些系統並沒有諸如搜索這種對於大量信息共享非常重要的功能，這個特徵的缺乏可能正為什麼即時訊息出現很久但是並沒有能夠產生如Napster這樣的影響的原因之一。
另外一個可以歸入P2P是拍賣網站譬如eBay，人們在總結eBay的模式的時候用了C2C，是不是和P2P有一點類似？eBay就是一個將人們聯系的和交易物品的社區，用戶可以方便的搜索其他用戶叫賣的商品。eBay提供了一些使得交易得以順利進行的服務，但是交易是直接在用戶之間進行的。如果將"交易"的概念推廣，C2C就是P2P的一個特例，這里人們互相交換的是商品。
但如果仔細深究的話，Napster和即時訊息在賦予用戶之間直接交流的能力、eBay使用戶可以直接交易的同時，卻破壞了伺服器端的那種自互聯網出現之初就存在的對等聯網思想，因為它們都需要有一個位於中心的伺服器來協調，而不是分布在世界上不同地方的、對等聯網的許多伺服器。這也正是諸如Gnotella和Freenet不斷的宣稱它們創造了"純粹"的P2P，完全沒有中心伺服器的P2P服務。