2011-09-21 27 views
7

Tôi phát hiện mongodb cách đây vài tháng, và sau khi đọc post, tôi nghĩ mongodb thực sự nhanh hơn mysql, vì vậy tôi quyết định xây dựng băng ghế riêng của mình, vấn đề là tôi không có kết quả tương tự như tác giả của bài viết trên, đặc biệt là để quering cơ sở dữ liệu: mongodb có vẻ chậm hơn so với các bảng MyISAM. bạn có thể có một cái nhìn để mã python của tôi, có thể có cái gì đó sai trong nó:MongoDB không nhanh hơn MySQL?

from datetime import datetime 
import random 
import MySQLdb 
import pymongo 

mysql_db=MySQLdb.connect(user="me",passwd="mypasswd",db="test_kv") 
c=mysql_db.cursor() 

connection = pymongo.Connection() 
mongo_db = connection.test 
kvtab = mongo_db.kvtab 

nb=1000000 
thelist=[] 
for i in xrange(nb): 
    thelist.append((str(random.random()),str(random.random()))) 
t1=datetime.now() 

for k,v in thelist: 
    c.execute("INSERT INTO key_val_tab (k,v) VALUES ('" + k + "','" + v + "')") 

dt=datetime.now() - t1 
print 'MySQL insert elapse :',dt 

t1=datetime.now() 
for i in xrange(nb): 
    c.execute("select * FROM key_val_tab WHERE k='" + random.choice(thelist)[0] + "'") 
    result=c.fetchone() 

dt=datetime.now() - t1 
print 'MySQL select elapse :',dt 


t1=datetime.now() 

for k,v in thelist: 
    kvtab.insert({"key":k,"value":v}) 

dt=datetime.now() - t1 
print 'Mongodb insert elapse :',dt 
kvtab.ensure_index('key') 
t1=datetime.now() 
for i in xrange(nb): 
    result=kvtab.find_one({"key":random.choice(thelist)[0]}) 

dt=datetime.now() - t1 
print 'Mongodb select elapse :',dt 

Ghi chú:

  • cả MySQL và MongoDB đang trên locahost.
  • cả MySQL và MongoDB có cột 'chìa khóa' lập chỉ mục

MySQL Bảng:

CREATE TABLE IF NOT EXISTS `key_val_tab` (
    `k` varchar(24) NOT NULL, 
    `v` varchar(24) NOT NULL, 
    KEY `kindex` (`k`) 
) ENGINE=MyISAM DEFAULT CHARSET=latin1; 

phiên bản là:

  • MySQL: 5.1.41
  • MongoDB: 1.8 .3
  • python: 2.6.5
  • pymongo: 2.0.1
  • Linux: Ubuntu 2.6.32 32bits với PAE
  • Phần cứng: máy tính để bàn core i7 2,93 Ghz

Kết quả (đối với 1 triệu chèn/Lựa chọn):

MySQL insert elapse : 0:02:52.143803 
MySQL select elapse : 0:04:43.675914 
Mongodb insert elapse : 0:00:49.038416 -> mongodb much faster for insert 
Mongodb select elapse : 0:05:10.409025 -> ...but slower for quering (thought was the opposite) 
+3

Đối với một, MongoDB thích kiến ​​trúc 64 bit. Tôi sẽ không đưa nhiều cổ phiếu vào một điểm chuẩn bởi một người không có kinh nghiệm với một trong những hệ thống được chuẩn hóa. – ceejayoz

+0

đó là lý do tại sao tôi hỏi một số trợ giúp! – Eric

+9

@ceejayoz Nếu bạn phải rất có kinh nghiệm để làm cho nó đi nhanh, sau đó nó sẽ được làm chậm cho hầu hết người dùng. Tôi muốn nói tiêu chuẩn được thực hiện bởi người dùng thiếu kinh nghiệm có thể chỉ là hữu ích ... –

Trả lời

6
MySQL insert elapse : 0:02:52.143803 
Mongodb insert elapse : 0:00:49.038416 -> mongodb much faster for insert 

Mongodb chèn nhanh hơn nhiều vì mongodb chèn tất cả dữ liệu vào ram và sau đó định kỳ tuôn ra dữ liệu vào đĩa.

MySQL select elapse : 0:04:43.675914 
Mongodb select elapse : 0:05:10.409025 -> ...but slower for quering (thought was 

Bạn có thể đạt được hiệu suất tốt nhất với mongodb khi bạn sẽ nhúng/không chuẩn hóa dữ liệu của mình. Trong nhiều tình huống mongodb cho phép chúng ta tránh tham gia vì nhúng/không chuẩn hóa.

Và khi bạn chỉ chèn dữ liệu vào một bộ sưu tập/bảng và đọc lại theo chỉ mục mongodb không được nhanh hơn, tốc độ đọc phải giống nhau nếu so sánh với cơ sở dữ liệu sql.

BTW: Trong mongodb 2.0 indexes nhanh hơn 25%, vì vậy tôi đoán 2.0 sẽ hoạt động nhanh hơn sau đó mysql.

+6

chèn nhanh hơn vì nó không làm những gì MySQL làm. an toàn = true chèn là một chút chậm hơn (bit thường vẫn nhanh hơn so với MySQL) và nhân rộng viết hoặc fsync viết chậm hơn vẫn còn. Điểm là, so sánh như thế này là vấn đề. Họ làm những điều cực kỳ khác nhau. –

+0

Tôi đồng ý với bạn, nhưng tôi không so sánh, tôi vừa nói tại sao trong Mongodb chuẩn của mình nhanh hơn. Bởi vì mặc định safe = false và nó có nghĩa là trên tuôn ra mỗi phút. –

27

Thở dài. Những loại điểm chuẩn, và tôi sử dụng thuật ngữ lỏng lẻo trong trường hợp này, thường bị phá vỡ ngay từ đầu. MySQL không phải là một cơ sở dữ liệu "chậm" hơn MongoDB. Một là một cơ sở dữ liệu quan hệ, một kho lưu trữ tài liệu NoSQL khác. Họ sẽ/nên nhanh hơn trong các khu vực chức năng mà họ đã được thiết kế để trang trải. Trong trường hợp của MySQL (hoặc bất kỳ RDBMS) và MongoDB chồng chéo này không phải là lớn như nhiều người cho rằng đó là. Đó là loại tương tự của táo bị hỏng và cam so sánh bạn nhận được với Redis vs MongoDB thảo luận.

Có quá nhiều biến (yêu cầu chức năng ứng dụng, tài nguyên phần cứng, đồng thời, cấu hình, khả năng mở rộng, v.v.) để xem xét bất kỳ điểm chuẩn hoặc bài viết nào kết thúc bằng "MongoDB nhanh hơn MySQL" hoặc ngược lại là kết quả tổng quát điểm vô dụng.

Nếu bạn muốn làm điểm chuẩn đầu tiên hãy xác định một bộ yêu cầu chức năng và quy tắc kinh doanh nghiêm ngặt và sau đó triển khai chúng hiệu quả nhất có thể trên cả hai giải pháp kiên trì. Kết quả sẽ là một là nhanh hơn khác và trong hầu hết các trường hợp, cách tiếp cận nhanh hơn có một số nhược điểm có liên quan mà vẫn có thể làm cho các giải pháp chậm hơn khả thi hơn tùy thuộc vào yêu cầu.

Tất cả điều này là bỏ qua rằng điểm chuẩn ở trên không mô phỏng bất kỳ loại kịch bản thế giới thực nào. Sẽ không có nhiều ứng dụng thực hiện chèn thông lượng tối đa mà không có bất kỳ loại luồng/đồng thời nào (tác động đến hiệu suất trên hầu hết các giải pháp lưu trữ đáng kể).

Cuối cùng, so sánh các chèn như thế này cũng hơi bị hỏng. MongoDB có thể đạt được thông lượng chèn tuyệt vời với lửa và quên chèn số lượng lớn hoặc có thể được đơn đặt hàng của cường độ chậm hơn với fsynced, nhân rộng viết. Điều ở đây là MongoDB cung cấp cho bạn một sự lựa chọn nơi MySQL không (hoặc ít hơn). Vì vậy, ở đây so sánh chỉ có ý nghĩa của các yêu cầu kinh doanh cho phép lửa và quên loại viết (mà đun sôi xuống, "Tôi hy vọng nó hoạt động, nhưng không lớn nếu nó không")

TL; DR stop doing simple tiêu chuẩn thông lượng. Chúng hầu như luôn vô dụng.

+2

+1 cho một câu trả lời tuyệt vời, tôi chỉ muốn thêm rằng MySQL cung cấp rất nhiều công cụ lưu trữ - một trong số đó là TokuDB sử dụng cây fractal để đạt được tốc độ chèn tuyệt vời. –

+1

Vì lợi ích của việc tiết lộ đầy đủ, tôi muốn thêm ở đây rằng tôi là một người hâm mộ MongoDB rất lớn. Nhưng nó không phải là viên đạn cơ sở dữ liệu ma thuật cho tất cả mọi thứ, cũng không phải 10gen tuyên bố nó được. –

+1

Tôi hoàn toàn đồng ý với bạn, tuy nhiên nó thường thiếu kiến ​​thức xác định mức độ phổ biến của một phần mềm nhất định. Một người đọc rằng MongoDB làm [chèn số lượng QPS] nhiều hơn [chèn một cái gì đó hoàn toàn không liên quan đến MongoDB] và tất cả một mạng internet đột ngột bị ô nhiễm với "X tốt hơn Y", được đánh giá bởi những người không có kinh nghiệm làm việc thực tế. Công cụ thích hợp cho đúng công việc phải là câu thần chú của bất kỳ lập trình viên nào. –

2

Thật sai khi nhìn vào thời gian thực thi và ước lượng chất lượng cơ sở dữ liệu. Mỗi yêu cầu bao gồm ít nhất 3 phần:

  • yêu cầu chuẩn bị (client side),
  • yêu cầu thực hiện (server),
  • đáp ứng chuẩn bị (client side)

Bằng dữ liệu kinh nghiệm của tôi Convertion cho MongoDB => python mất nhiều thời gian hơn so với MySQL => python.

Ngoài ra, bạn nên sử dụng các chỉ mục trong cả hai cơ sở dữ liệu. MongoDB hoạt động tốt chỉ khi bạn có các chỉ mục trên các trường mà bạn sử dụng cho các truy vấn. Nói về MySQL, tôi nghĩ tốt hơn là nên kiểm tra hiệu suất trên innoDB, MyISAM không hỗ trợ các giao dịch, khóa ngoại, trình kích hoạt và đối với tôi, nó hơi lỗi thời một chút.

+2

Vì tôi muốn sử dụng python, tôi quan tâm đến cơ sở dữ liệu + python, không chỉ cơ sở dữ liệu. – Eric