2009-03-24 13 views
5

Dường như có một sự thúc đẩy lớn đối với các cơ sở dữ liệu dựa trên khóa/giá trị, mà tôi tin là memcache.Cơ sở dữ liệu dựa trên khóa-giá trị, ai đó có thể giải thích cho tôi cách sử dụng chúng một cách thiết thực?

Giá trị thường là một số loại tập hợp hoặc tệp xml có thể chứa nhiều dữ liệu có ý nghĩa hơn?

Nếu có, thường nhanh hơn để deserialize dữ liệu sau đó để làm traditinally JOINS và chọn trên bảng trả về một tập kết quả dựa trên hàng?

Trả lời

3

Như với hầu hết mọi thứ, "nó phụ thuộc". Nếu các tham gia là tương đối không quan trọng (có nghĩa là, một số lượng nhỏ các phép nối trên dữ liệu có khóa), và bạn đang lưu trữ dữ liệu đặc biệt phức tạp, có thể tốt hơn là chỉ cần gắn bó với truy vấn phức tạp hơn.

Đó cũng là vấn đề mới mẻ. Trong nhiều trường hợp, mục đích của nhiều lần tham gia là tập hợp dữ liệu rất khác nhau; đó là, dữ liệu thay đổi rộng rãi trong độ tươi tương đối của nó. Nó có thể thêm đáng kể phức tạp và chi phí để giữ bảng cặp khóa-giá trị được đồng bộ hóa khi một lát nhỏ dữ liệu trên một số lượng lớn các cặp được cập nhật. Hệ thống phức tạp thường có thể được coi là một hình thức chi phí hiệu suất; thời gian, rủi ro và chi phí để thực hiện thay đổi đối với một hệ thống phức tạp mà không ảnh hưởng đến hiệu suất thường lớn hơn nhiều so với một hệ thống đơn giản.

Giải pháp tốt nhất luôn là mã hoạt động đơn giản như bạn có thể. Trong hầu hết trường hợp, tôi muốn nói điều này có nghĩa là tạo ra một thiết kế cơ sở dữ liệu chuẩn hóa hoàn toàn và tham gia vào crap. Chỉ xem lại thiết kế của bạn sau khi hiệu suất trở thành một vấn đề rõ ràng. Khi bạn phân tích vấn đề, nó cũng sẽ rõ ràng là nơi những vấn đề nằm và những gì cần phải được thực hiện để sửa chữa chúng. Nếu nó giảm sự tham gia, thì cũng vậy. Bạn sẽ biết khi nào bạn cần biết.

+0

Tôi hoàn toàn không đồng ý với "..hãy tham gia vào đó." phần. Kinh nghiệm của tôi nói với tôi tham gia nên được thực hiện một cách hợp lý. Quá nhiều bình thường hóa hầu như luôn luôn là một điều xấu. –

2

Tôi không có nhiều kinh nghiệm với khóa/giá trị dbs, vì vậy hãy lấy những gì tôi nói với một hạt muối.

Với điều đó đã nói, điều đầu tiên tôi nên chỉ ra là memcached không phải là khóa/giá trị cơ sở dữ liệu. Một cơ sở dữ liệu ngụ ý một số loại lưu trữ liên tục, mà memcached không phải là. Memcached được dự định là một cửa hàng tạm thời để lưu một truy vấn vào cơ sở dữ liệu thực tế.

Ngoài ra, sự hiểu biết của tôi là bạn sẽ không thể thay thế RDBMS bằng cơ sở dữ liệu khóa/giá trị. Chúng có xu hướng tốt nhất cho dữ liệu phi cấu trúc hoặc dữ liệu khác mà bạn có thể không biết tất cả các thuộc tính cần được lưu trữ. Nếu bạn cần lưu trữ dữ liệu có cấu trúc cao, bạn không thể làm tốt hơn nhiều so với RDBMS truyền thống.

6

gì đã xảy ra là một số thực sự, thực sự, REALLY các trang web lớn như Google và Amazon chiếm một teeny, ngách nhỏ nơi lưu trữ dữ liệu của họ và yêu cầu thu hồi rất khác nhau để bất cứ ai khác mà một phương pháp mới lưu trữ/truy xuất dữ liệu được gọi cho. Tôi chắc rằng những người này biết họ đang làm gì, họ rất giỏi những gì họ làm.

Tuy nhiên, điều này được chọn và báo cáo và bị biến dạng thành "cơ sở dữ liệu quan hệ không thể xử lý dữ liệu cho web". Ngoài ra, độc giả bắt đầu nghĩ "hey, nếu cơ sở dữ liệu quan hệ không đủ tốt cho Amazon và Google, chúng không đủ tốt cho tôi."

Những suy luận này đều sai: 99,9% của tất cả các cơ sở dữ liệu (bao gồm cả cơ sở dữ liệu phía sau trang web) không có trong cùng một công viên bóng như Amazon và Google - không phải trong một vài đơn vị độ lớn. Đối với 99,9% này, không có gì thay đổi, cơ sở dữ liệu quan hệ vẫn hoạt động tốt.

+0

Amen, anh trai! :-) – ObiWanKenobi

+0

Vì vậy, các ứng dụng web của tôi sẽ làm việc tốt với MySQL và (có thể) Memcached? –

+0

Tôi sẽ tưởng tượng như vậy, vâng. Tôi không biết gì về Memcached, nhưng chỉ cần google, tôi thấy nó đơn giản là một cơ chế cho các giá trị "nhớ" một lần được lấy ra từ cơ sở dữ liệu trong một phiên, thay vì lặp đi lặp lại quay lại cơ sở dữ liệu để lấy chúng. Nó không liên quan gì đến cơ sở dữ liệu khóa/giá trị AFAICT. Bộ nhớ đệm như vậy có thể hợp lý nếu được sử dụng một cách khôn ngoan: không sử dụng nó cho dữ liệu có khả năng đã thay đổi kể từ lần truy cập cuối cùng (trừ khi bạn không quan tâm đến nó). –

1

Họ có thể là dữ liệu có cấu trúc phức tạp cần deserialization. Chúng cũng có thể là các bản ghi kích thước cố định đơn giản, giống như RDBMS của bạn. Một phần của lợi ích là bạn có thể tự mình đưa ra quyết định đó. Khi bạn tối ưu hóa cơ sở dữ liệu của mình, bạn không bị giới hạn bởi những gì SQL có thể làm.

Cách bạn yêu cầu làm cho âm thanh như tham gia hoặc quá trình deserialization sẽ luôn là nút cổ chai. Nhưng trong bất kỳ cơ sở dữ liệu nào, mọi thứ không bao giờ đơn giản như vậy. Bạn cũng có thể đặt dữ liệu không chuẩn hóa trong RDBMS của mình, hoặc viết một giao diện RDBMS trên cơ sở dữ liệu khóa-giá trị, nếu bạn thực sự muốn.

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