2011-08-09 52 views
0

什麼是最好的數據庫類型(面向文檔,關係,鍵值等)來存儲一個HTML文件(小尺寸,〜最大700kb)進入數據庫?最好的數據庫來存儲HTML文件(或一般的文件)

目前我使用python的sqlite3,但它似乎變得非常緩慢,如果條目/文件的數量超過3000(.db文件大約是260mb然後)。除此之外,sqlite不適合多處理用例。

sqlite的模式是這樣的:

CREATE TABLE articles (url TEXT NOT NULL,published DATETIME,title TEXT, fetched TEXT NOT 
    NULL,section TEXT,PRIMARY KEY (url), FOREIGN KEY(url) references 
    contents(url)); 
CREATE TABLE contents(url TEXT NOT NULL,date DATETIME,content TEXT,PRIMARY KEY (url)); 

CREATE TABLE shares (url TEXT NOT NULL, date DATETIME,likes INTEGER NOT NULL, 
        totals INTEGER NOT NULL,clicks INTEGER, comments INTEGER NOT     
        NULL,share INTEGER NOT NULL, 
        tweets INTEGER NOT NULL,PRIMARY KEY(date,url),FOREIGN KEY (url)  
        REFERENCES articles(url)); 

和HTML文件到內容

+0

你的sqlite3模式是怎樣的? –

+0

出於好奇,爲什麼你不想將它們存儲在文件系統上? –

+0

我不想,但我認爲我必須:)將它們存儲在文件系統上是由兩個原因造成的:a)在寫入sqlite-db時,寫入文件具有多處理能力(每個進程都可以寫入)不是的(你必須以另一種表示形式收集所有獲取的html文件,列表並將它們插入數據庫中的單個語句/進程中)。這可能是一個問題,當你處理> 1000個HTML文件.. b)也許我錯了,但我不知道它是否「製造」用於存儲HTML文件(可擴展性等)..是我提到,它很快就會很慢:) – dorvak

回答

0

對於使用某個URL作爲主鍵以文檔爲中心的數據庫,並且還具有支持多個併發編寫器,你可能希望考慮通過SQLite的一個noSQL數據庫。目前有122個列表here

「很慢」對您而言意味着什麼?你確定感覺到的緩慢是數據庫嗎?

+0

也許這是由於多處理,並行連接,導致數據庫鎖,但之後插入一個單一的HTML文件花了> 20秒...我試圖恢復帶有來自sqlite的備份功能的數據庫,但是備份數據庫的速度與原始數據庫一樣慢(一個「新鮮的」和空的新創建的數據庫花費了大約<1 second -->可伸縮性問題?)。這就是爲什麼我認爲sqlite不適合存儲文件或大量文本。 – dorvak

+0

SQLite的文件鎖定方法並不適合多個併發作者。你可能會在MVCC併發性方面做得更好。例如,看看CouchDB。可伸縮性問題通常出現在現實世界的多併發編寫器場景中,而不是單個讀寫器。該插入的時間超過20秒的單個HTML文件有多大?也許你的作家正在等待文件鎖定被釋放,並且不斷重試 - 其他寫入是否正在同時進行? – Tim

+0

這是大約500kb ......似乎它正在等待一個鎖被釋放,儘管沒有其他寫入是並行嘗試。這就是爲什麼我懷疑sqlite的可伸縮性。也許我應該將所有同時下載的html文件/文本存儲在列表中,然後將它們全部寫入到數據庫的中央插入中..所以您認爲,sqlite應該足夠可擴展一般? – dorvak

0

so you think, sqlite should be scalable enough in general?

有一個在現實世界中沒有「一般」的情景。不,我認爲它不適合以文件爲中心的應用程序,其中記錄可以是500K。 SQLite沒有經過優化,無法在繁忙的多個併發寫入方案中很好地進行擴展,其中「繁忙」是一個多變量函數,涉及每秒寫入次數和正在寫入的記錄大小以及表中有多少個索引。簡而言之,磁盤密集程度越高(耗時)的寫入操作,其規模就越不好。換句話說,表中記錄越大和/或索引越重,每秒寫入次數越少。而500K的記錄確實是一個非常大的記錄。你最好用MVCC服務。

+0

好吧,我會看看CouchDB,切換到MySQL(或者繼續使用sqlite並在文件系統中寫入文件) – dorvak

相關問題