2011-07-24 2 views
9

Tôi hiện đang xây dựng một hệ thống GIS có lưu lượng truy cập cao sử dụng python trên giao diện web. Hệ thống chỉ đọc được 99%. Vì lợi ích của hiệu suất, tôi đang xem xét sử dụng bộ đệm ẩn được tạo ra từ bên ngoài của thông tin GIS được tối ưu hóa được đọc trước và được lưu trữ trong cơ sở dữ liệu SQLite trên mỗi máy chủ web riêng lẻ. Trong ngắn hạn nó sẽ được sử dụng như là một bộ nhớ cache chỉ đọc phân phối mà không cần phải nhảy qua mạng. Cửa hàng OLTP kết thúc sau sẽ là postgreSQL nhưng sẽ xử lý ít hơn 1% các yêu cầu.SQLite có phù hợp để sử dụng làm bộ đệm chỉ đọc trên máy chủ web không?

Tôi đã xem xét sử dụng Redis nhưng tập dữ liệu khá lớn và do đó nó sẽ đẩy chi phí hành chính và chi phí bộ nhớ lên các máy ảo mà máy chủ này đang được lưu trữ. Memcache không phù hợp vì nó không thể thực hiện các truy vấn.

Tôi có bị truy cập các sự cố đồng thời đọc với SQLite không?

Đây có phải là cách tiếp cận hợp lý không?

+1

này cũng có thể là trường hợp đầu tiên mà tôi từng thấy nơi SQLite * là * cách tiếp cận hợp lý nhất. – Crashworks

+0

Các bảng SQLite được cập nhật định kỳ với dữ liệu từ cơ sở dữ liệu postreSQL trung tâm? – Tim

+0

Không - chúng sẽ đến từ một cơ sở dữ liệu ngoại tuyến riêng biệt và được tạo ra khi và khi thay đổi dữ liệu nguồn có khả năng là hàng quý. Sau đó, chúng sẽ được tải lên máy chủ web, các tệp được hoán đổi và sau đó các phiên bản mod-wsgi được khởi động lại. Về cơ bản - không viết, chỉ các tệp được hoán đổi. –

Trả lời

4

Ok sau nhiều nghiên cứu và thử nghiệm hiệu suất, SQLite phù hợp với điều này. Nó có yêu cầu đồng thời tốt trên dữ liệu tĩnh. SQLite chỉ trở thành một vấn đề nếu bạn đang viết cũng như đọc nặng.

biết thêm thông tin ở đây:

http://www.sqlite.org/lockingv3.html

+0

Cảm ơn bạn đã đăng câu trả lời khi bạn tìm thấy câu trả lời. – Crashworks

-3

nếu trường hợp sử dụng chỉ là bộ nhớ cache tại sao bạn không sử dụng một cái gì đó như http://memcached.org/.

Bạn có thể tìm thấy các ràng buộc memcached cho python trong kho pypi.

Một tùy chọn khác là bạn sử dụng chế độ xem vật lý trong hậu kỳ, bằng cách này bạn sẽ giữ mọi thứ đơn giản và có mọi thứ ở một nơi.

http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views

+5

Các poster ban đầu cho biết: "Memcache không thích hợp vì nó không thể làm các truy vấn phạm vi." – Crashworks

+1

Memcached không phù hợp như đã nêu. Tôi thực sự đề xuất các khung nhìn vật chất nhưng được tạo ra từ một Postgres kết thúc vào một tệp dữ liệu SQLite, mất khoảng 4 giờ kể cả tất cả các phép tính tiếp tục. Tôi không muốn đặt nó vào một động cơ DB duy nhất vì tôi sẽ phải mở rộng quy mô hơn là mở rộng quy mô đó là tốn kém. Một khi nơi là một trong tất cả các quả trứng của bạn trong một giỏ. Lưu lượng mạng có thể đắt hơn (so với CPU <-> bộ nhớ <-> đĩa). –