2009-11-08 33 views
5

Tôi đang phát triển một ứng dụng sẽ lưu trữ một số lượng lớn các bản ghi. Các bản ghi này sẽ giống như (URL, ngày, tiêu đề, nguồn, {dữ liệu tùy chọn ...})Tôi nên sử dụng cơ sở dữ liệu nào để lưu trữ hồ sơ và tôi nên sử dụng nó như thế nào?

Vì đây là ứng dụng phía máy khách, tôi không muốn sử dụng máy chủ cơ sở dữ liệu, tôi chỉ muốn thông tin được lưu trữ trong các tệp.

Tôi muốn các tệp có thể đọc được từ nhiều ngôn ngữ khác nhau (ít nhất là python và C++), vì vậy ngôn ngữ cụ thể như dưa chuột của python không nằm trong trò chơi.

Tôi thấy hai khả năng: sqlite và BerkeleyDB. Do trường hợp sử dụng của tôi rõ ràng là không quan hệ, tôi bị cám dỗ đi với BerkeleyDB, tuy nhiên tôi không thực sự biết cách sử dụng nó để lưu trữ hồ sơ của mình, vì nó chỉ lưu trữ cặp khóa/giá trị.

Lý do của tôi có đúng không? Nếu vậy, làm thế nào tôi nên sử dụng BDB để lưu trữ hồ sơ của tôi? Bạn có thể liên kết tôi với thông tin liên quan không? Hoặc tôi thiếu một giải pháp tốt hơn?

+0

Cảm ơn tất cả các bạn vì những câu trả lời rất hữu ích của bạn! Lựa chọn một trong những tốt nhất là thực sự khó khăn: -/ –

Trả lời

5

Tôi thấy hai khả năng: sqlite và BerkeleyDB. Vì trường hợp sử dụng của tôi là rõ ràng không quan hệ, tôi bị cám dỗ để đi với BerkeleyDB, tuy nhiên tôi không thực sự biết cách sử dụng nó để lưu trữ hồ sơ của mình vì nó chỉ lưu trữ các cặp khóa/giá trị .

Điều bạn mô tả chính xác là những gì quan hệ, kể cả khi bạn chỉ cần một bảng. SQLite có thể sẽ làm việc này rất dễ dàng.

CHỈNH SỬA: Mô hình quan hệ không liên quan gì đến mối quan hệ giữa các bảng. Quan hệ là tập hợp con của sản phẩm Descartes của các bộ khác. Ví dụ, sản phẩm Descartes của các số thực, số thực, và số thực (Có, tất cả ba giống nhau) tạo ra không gian tọa độ 3d, và bạn có thể xác định mối quan hệ trên không gian đó với công thức, nói x*y = z. mỗi tập hợp tọa độ có thể có (x0,y0,z0) hoặc là trong mối quan hệ nếu chúng thỏa mãn công thức đã cho, nếu không thì không.

Cơ sở dữ liệu quan hệ sử dụng khái niệm này với một vài yêu cầu bổ sung. Thứ nhất, và quan trọng nhất, kích thước của mối quan hệ phải là hữu hạn. Mối quan hệ sản phẩm được đưa ra ở trên không đáp ứng yêu cầu đó, bởi vì có vô số 3-tuple thỏa mãn công thức.Có một số cân nhắc khác có liên quan nhiều hơn đến những gì thực tế hoặc hữu ích trên các máy tính thực sự giải quyết các vấn đề thực tế.

Cách suy nghĩ tốt hơn về vấn đề là suy nghĩ về nơi mà mỗi loại cơ chế kiên trì cụ thể hoạt động tốt hơn cơ chế khác. Bạn đã nhận ra rằng một giải pháp quan hệ có ý nghĩa khi bạn có nhiều bộ dữ liệu riêng biệt (bảng) phải hỗ trợ các mối quan hệ giữa chúng (ràng buộc khóa ngoài), hầu như không thể thực thi với một kho khóa-giá trị. Một lợi thế thực sự khác cho quan hệ là cách nó làm cho các truy vấn phong phú, đặc biệt có thể với việc sử dụng các chỉ mục thích hợp. Đây là kết quả của lớp cơ sở dữ liệu thực sự hiểu dữ liệu mà nó đại diện.

Cửa hàng khóa-giá trị có bộ lợi thế riêng. Một trong những điều quan trọng hơn là cách mà các cửa hàng khóa-giá trị mở rộng. Không phải hệ quả là memcached, couchdb, hadoop tất cả sử dụng bộ nhớ khóa-giá trị, vì dễ dàng phân phối tra cứu khóa-giá trị trên nhiều máy chủ. Một khu vực khác lưu trữ khóa-giá trị hoạt động tốt là khi khóa hoặc giá trị bị mờ, chẳng hạn như khi mục được lưu trữ được mã hóa, chỉ để chủ sở hữu có thể đọc được.


Để lái xe về nhà thời điểm này, rằng một cơ sở dữ liệu quan hệ hoạt động tốt ngay cả khi bạn chỉ không cần nhiều hơn một bảng, hãy xem xét những điều sau đây (không phải gốc)

SELECT t1.actor1 
FROM workswith AS t1, 
    workswith AS t2, 
    workswith AS t3, 
    workswith AS t4, 
    workswith AS t5, 
    workswith AS t6 
WHERE t1.actor2 = t2.actor1 AND 
     t2.actor2 = t3.actor1 AND 
     t3.actor2 = t4.actor1 AND 
     t4.actor2 = t5.actor1 AND 
     t5.actor2 = t6.actor1 AND 
     t6.actor2 = "Kevin Bacon"; 

nào, rõ ràng sử dụng một bảng duy nhất: workswith để tính toán mọi diễn viên có số thịt xông khói là 6

+0

Bạn có thể xây dựng? Đối với tôi quan hệ chỉ thực sự có ý nghĩa nếu bạn có nhiều bảng với các mối quan hệ giữa chúng ... –

1

Còn khoảng MongoDB thì sao? Tôi chưa thử nó, nhưng nó có vẻ thú vị.

+0

Trông thú vị ... Dường như không thực sự trưởng thành. –

2

BerkeleyDB là tốt, cũng nhìn vào * hóa thân DBM (ví dụ: GDBM). Câu hỏi lớn đặt ra là: bạn cần tìm kiếm những gì? Bạn có cần tìm kiếm theo URL đó, theo một dải URL hoặc ngày bạn liệt kê không?

Cũng có thể giữ các nhóm bản ghi dưới dạng tệp đơn giản trong hệ thống tệp cục bộ, được nhóm theo ngày hoặc cụm từ tìm kiếm, & c.

Trả lời câu hỏi "tìm kiếm" là khởi đầu lớn nhất.

Đối với điều quan trọng/giá trị, bạn cần đảm bảo rằng chính KEY cũng được xác định là dành cho tra cứu của bạn. Ví dụ: nếu bạn cần tìm kiếm theo ngày đôi khi và những người khác theo tiêu đề, bạn sẽ cần duy trì hàng "bản ghi" và sau đó có thể có 2 hoặc nhiều hàng "chỉ mục" tham chiếu đến bản ghi gốc. Bạn có thể lập mô hình gần như mọi thứ trong kho khóa/giá trị.

+0

"Bạn có thể lập mô hình gần như mọi thứ trong kho khóa/giá trị". Bạn có thể giới thiệu điều gì đó để đọc về điều này không? Tôi có thể thấy rằng mô hình này rất chung chung, nhưng đọc một vài ví dụ sẽ hữu ích. –

+1

Tôi có thể thấy những gì tôi có thể tìm thấy, nhưng những điều cơ bản về truyền thống của một cửa hàng DB cơ bản có hiệu quả là một kho khóa/giá trị trong cơ chế này hoặc cơ chế khác. Một bảng heap chỉ là các hàng được ghi vào một khóa/giá trị với hàng là giá trị và khóa ROWID được tạo ra của các loại. Chỉ mục không hợp chất trên bảng như vậy liệt kê các giá trị của chỉ mục làm khóa và ROWID làm giá trị. Chắc chắn nó sẽ phức tạp hơn thế nhưng * không có gì không thể được giải quyết mà không có một mức độ khác biệt * áp dụng ở đây. Tôi sẽ bình luận lại nếu tôi có thể tìm thấy một vài bài viết. – Xailor

2

Cá nhân tôi sẽ sử dụng sqlite. Nó đã luôn luôn chỉ làm việc cho tôi (và cho những người khác tôi làm việc với). Khi ứng dụng của bạn phát triển và bạn đột nhiên muốn làm điều gì đó phức tạp hơn một chút, bạn sẽ không phải viết lại.

Mặt khác, tôi đã nhìn thấy nhiều nhận xét khác nhau về danh sách dev của Python về Berkely DB cho thấy nó ít tuyệt vời hơn; bạn chỉ có quyền truy cập kiểu dict (nếu bạn muốn chọn phạm vi ngày hoặc tiêu đề nhất định thay vì URL); và nó thậm chí không nằm trong thư viện chuẩn của Python 3.

+0

"nó thậm chí không nằm trong bộ thư viện chuẩn của Python 3". Không biết điều đó, đó là một điểm rất tốt, cảm ơn! –

+0

Vui lòng kiểm tra. Tôi đã có một cái nhìn và tôi có thể nhìn thấy (g | n) dbm hỗ trợ, nhưng tôi nghĩ rằng đó là khác nhau, phải không? Có lẽ cuộc thảo luận tôi nhớ trong danh sách dev có liên quan đến việc bỏ nó. –

1

Nếu bạn chỉ sử dụng một trường đơn lẻ để tra cứu các bản ghi, một kho khóa-giá trị đơn giản sẽ là một lựa chọn tốt. Lưu trữ trường đơn (hoặc bất kỳ ID duy nhất nào) làm khóa của bạn, tuần tự hóa từng bản ghi dưới dạng một chuỗi (sử dụng JSON hoặc tương tự) và lưu chuỗi đó làm giá trị. Berkeley DB chắc chắn là một lựa chọn hợp lý cho một cửa hàng khóa-giá trị, nhưng có rất nhiều lựa chọn thay thế để lựa chọn: http://en.wikipedia.org/wiki/Dbm

Nếu bạn muốn tìm kiếm hồ sơ theo một số trường, SQLite có thể dễ dàng nhất cho mục đích phát triển. Bạn sẽ viết các truy vấn trong SQL nhưng bạn sẽ không phải duy trì một máy chủ cơ sở dữ liệu. Tất cả các máy móc đa khóa đã được viết cho bạn.

Nếu bạn thực sự muốn tránh SQL hoặc bóp mỗi bit hiệu suất ra của lưu trữ dữ liệu của bạn, bạn muốn truy cập đa-key, hãy xem xét một lớp logic thêm trên đầu trang của một cửa hàng giá trị khóa. Có thể xây dựng hành vi giống như cột trên các cửa hàng khóa-giá trị bằng cách tuần tự hóa các bản ghi của bạn và chèn các giá trị "cột" của mỗi bản ghi làm khóa bổ sung có giá trị chứa khóa "chính" của bản ghi. (Bạn đang sử dụng hiệu quả kho khóa-giá trị như cả từ điển bản ghi và từ điển chỉ mục để tìm những bản ghi đó.) App Engine của Google thực hiện một việc như thế này. Bạn có thể tự làm điều này hoặc sử dụng một trong các cơ sở dữ liệu hướng tài liệu khác nhau sẽ làm điều đó cho bạn. Đối với một số đọc thú vị, hãy thử googling "nosql". http://www.google.com/search?&q=nosql

+1

P.S. Thỏa thuận với Berkeley DB trong việc phân phối python đơn giản là các thư viện nội bộ của bdb đã thay đổi thường xuyên hơn các nhà phát triển Python muốn theo kịp. Nó không phải là Berekeley DB là xấu, chỉ bất tiện để tích hợp trực tiếp vào bản phát hành python. Bạn vẫn có thể nhận được các ràng buộc python bdb như một mô-đun riêng biệt. –

0

Ok, vậy bạn nói chỉ lưu trữ dữ liệu ..? Bạn thực sự chỉ cần một DB để thu hồi, tra cứu, tóm tắt, vv Vì vậy, để lưu trữ, chỉ cần sử dụng các tệp văn bản đơn giản và nối thêm các dòng. Nén dữ liệu nếu bạn cần, sử dụng delims giữa các lĩnh vực - chỉ là về bất kỳ ngôn ngữ sẽ có thể đọc các tập tin như vậy. Nếu bạn muốn lấy, sau đó tập trung vào nhu cầu truy xuất của bạn, theo ngày, theo khóa, khóa nào, vv Nếu bạn muốn phía máy khách đơn giản, thì bạn cần db khách hàng đơn giản. SQLite dễ dàng hơn BDB, nhưng nhìn vào những thứ như Sybase Advantage (rất nhanh và miễn phí cho khách hàng địa phương nhưng không phải mã nguồn mở) hoặc VistaDB hay firebird ... nhưng tất cả sẽ yêu cầu cấu hình/thiết lập/bảo trì cục bộ. Nếu bạn đi XML địa phương cho một số lượng lớn 'các bản ghi sẽ cung cấp cho bạn một số kích thước tập tin không cần thiết cồng kềnh ..!

Các vấn đề liên quan