• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            woaidongmao

            文章均收錄自他人博客,但不喜標題前加-[轉貼],因其丑陋,見諒!~
            隨筆 - 1469, 文章 - 0, 評論 - 661, 引用 - 0
            數(shù)據(jù)加載中……

            SQLite與其他數(shù)據(jù)庫的速度比較

            執(zhí)行程序總結一系列的測試程序已經(jīng)被運行去測量SQLite 2.7.6PostgreSQL 7.1.3,和 MySQL 3.23.41 的相對性能。以下是根據(jù)實驗得出的一些總結:

            SQLite 2.7.6 是非常快的,有時可以比安裝RedHat 7.2 上的預置的PostgreSQL 7.1.3 10倍甚至20倍。
            SQLite 2.7.6
            總是很快, 有時比MySQL 3.23.41 2倍多。
            SQLite
            執(zhí)行CREATE INDEX or DROP TABLE時不像其它數(shù)據(jù)庫那樣快。但這不是什么問題,因為這些是很少運用的操作。
            如果你把 multiple 操作聚集到一個單獨的事物項,SQLite可以更快些。

            但以下幾點是值得注意的:

            這些測試程序不是在測量多用戶使用時數(shù)據(jù)庫的性能,也不是在測量包含multiple的最優(yōu)化復雜查詢。
            這些測試是在一個相對小的數(shù)據(jù)庫里完成的(大約14兆字節(jié))。 它們沒有測試數(shù)據(jù)庫引擎的大小對程序運行速度的影響有多大。

            測試環(huán)境測試所用的平臺是一個具有1GB內存的1.6GHz Athlon和一個IDE驅動硬盤。操作系統(tǒng)是具有一個stock內核的RedHat Linux 7.2 。使用的PostgreSQL MySQL服務器被RedHat 7.2 中的默認程序所傳送。(PostgreSQL 7.1.3 版和MySQL3.23.41版)所使用的引擎自始至終沒有被調整過。需要特別注意的是,RedHat 7.2 中默認的MYSQL配置不支持處理事物項,這一點使MYSQL的速度大大增加。但SQLite還是有能力完成大部分的測試的。

            我被告知,RedHat 7.3 中預設的PostgreSQL配置是非常落后的(它必須在具有 8MB RAM 的機器上工作)。 and that PostgreSQL則可以通過調整一些配置來運行的快些。 Matt Sergeant 報道說他已經(jīng)調整了他的PostgreSQL裝置,并且像下面所顯示的一樣重新進行測試。他的結果顯示 PostgreSQLMySQL運行速度一樣。如想查看結果,訪問:http://www.sergeant.org/sqlite_vs_pgsync.htmlSQLite實在同樣的配置下被測試的,它是用 -O6 optimization -DNDEBUG=1 交叉編寫,這樣使許多SQLite代碼中的"assert()"語句 無法運行。

            所有的測試都是在一個靜止的機器上進行的。所有的測試時由一個簡單的TCL文稿編排程序產生和運行的。 A copy of this Tcl script can be found in the你可以在源文件目錄文件SQLite source tree in the filetools/speedtest.tcl中發(fā)現(xiàn)TCL文稿編排程序的副本. 所有測試中的時間都是以精確到秒的背景時鐘來計算的.SQLite有兩個單獨的時間值. 第一個時間值在一個完整磁盤同步化打開的默認裝置里.同步話打開后,為了確保重要數(shù)據(jù)已被真正的寫入磁盤驅動表面,SQLite在關鍵的時候執(zhí)行fsync()系統(tǒng)調用. 在數(shù)據(jù)庫更新過程中,當操作系統(tǒng)崩潰時或者計算機突然斷電時,為了保證數(shù)據(jù)庫的完整性,同步化是非常有必要的.第二個時間值是當同步化關閉的時候.關閉同步化, SQLite有時會運行的快些,但如果系統(tǒng)崩潰或者突然斷電數(shù)據(jù)庫將會受到損失. 通常來說,同步化的SQLite的時間是為了和PostgreSQL(因為他也是同步化的)比較,異步化的SQLite是為了和也是異步化的MySQL引擎比較.


            測試 1: 1000 INSERTs

            CREATE TABLE t1(a INTEGER, b INTEGER, c VARCHAR(100));

            INSERT INTO t1 VALUES(1,13153,'thirteen thousand one hundred fifty three');
            INSERT INTO t1 VALUES(2,75560,'seventy five thousand five hundred sixty');
            ... 995 lines omitted
            INSERT INTO t1 VALUES(998,66289,'sixty six thousand two hundred eighty nine');
            INSERT INTO t1 VALUES(999,24322,'twenty four thousand three hundred twenty two');
            INSERT INTO t1 VALUES(1000,94142,'ninety four thousand one hundred forty two');

            PostgreSQL:

               4.373

            MySQL:

               0.114

            SQLite 2.7.6:

               13.061

            SQLite 2.7.6 (nosync):

               0.223



            因為沒有一個中央服務器來控制訪問,SQLite必須先關閉再打開數(shù)據(jù)庫文件,這樣高速緩存器就失去了作用。在這個測試中,每個 SQL語句都是一個獨立的事務元,所以數(shù)據(jù)庫文件必須被打開和關閉,高速緩存必須刷新1000次。盡管這樣,異步版本的SQLite還是和MYSQL一樣快。但同步版本的卻是非常慢。SQLite在每個同步事務元后調用fsync(),因而確保了磁盤表面所有的數(shù)據(jù)都是安全的。13秒的測試時間大部分都被用于磁盤I/O

             

            posted on 2009-06-19 16:04 肥仔 閱讀(1520) 評論(0)  編輯 收藏 引用 所屬分類: 數(shù)據(jù)庫

            99久久无色码中文字幕人妻| 国产福利电影一区二区三区久久老子无码午夜伦不 | 18岁日韩内射颜射午夜久久成人| 99久久精品国产免看国产一区| 99久久久国产精品免费无卡顿| 热久久国产精品| 波多野结衣久久精品| 久久99精品久久久久久久不卡| 99久久国产综合精品成人影院| 少妇久久久久久被弄到高潮 | 精品乱码久久久久久夜夜嗨| 无码八A片人妻少妇久久| 久久精品国产91久久综合麻豆自制 | 99久久人妻无码精品系列蜜桃| 久久99久久无码毛片一区二区| 色偷偷88888欧美精品久久久| 精品久久久久久无码国产| 99久久夜色精品国产网站| 久久久久国产精品麻豆AR影院| 蜜臀av性久久久久蜜臀aⅴ麻豆| 国内精品伊人久久久久影院对白 | 日韩久久久久中文字幕人妻| 97久久天天综合色天天综合色hd| 国产精品久久久久久久久软件| 国产精品成人久久久久三级午夜电影| 精产国品久久一二三产区区别| 国产精品成人无码久久久久久 | 97久久精品人人做人人爽| 久久亚洲国产成人精品性色| 久久一区二区三区免费| 国产精品成人99久久久久| 国产精品久久久久影院色| 久久久久女人精品毛片| 亚洲AV日韩精品久久久久久| 久久香综合精品久久伊人| 一本大道久久东京热无码AV| 久久亚洲欧洲国产综合| 亚洲&#228;v永久无码精品天堂久久 | 亚洲日本va午夜中文字幕久久 | 成人免费网站久久久| 久久精品国产亚洲AV无码麻豆|