Dữ liệu trong DBMS quan hệ của chúng tôi đang trở nên lớn, đã đến lúc chuyển sang NoQuery chưa?

Chúng tôi đã tạo ra một ứng dụng mạng xã hội cho mục đích eLearning. Đó là một dự án thử nghiệm mà chúng tôi đang nghiên cứu trong phòng thí nghiệm của chúng tôi. Nó đã được sử dụng trong một số nghiên cứu trường hợp trong một thời gian và dữ liệu trong DBMS quan hệ của chúng tôi (SQL Server 2008) đang trở nên lớn. Bây giờ là vài gigabyte và các bảng được kết nối với nhau rất cao. Hiệu suất vẫn tốt, nhưng khi nào chúng ta nên xem xét các lựa chọn khác? Đó có phải là vấn đề hiệu suất?

Một vài gigabyte không phải là " lớn ". Nó giống như kích thước bình thường của DB doanh nghiệp. Miễn là bạn vượt qua PK khi tham gia các bảng, nó sẽ hoạt động rất tốt, ngay cả trong tương lai (miễn là bạn không nhận được dữ liệu của TB mỗi ngày).

Hầu hết các chuyên gia làm việc trong môi trường dữ liệu lớn đều coi > ~ 5TB là khởi đầu của thuật ngữ dữ liệu lớn. Nhưng ngay cả sau đó không phải lúc nào cũng là cách tốt nhất để cài đặt cơ sở dữ liệu nosql tốt nhất tiếp theo. Bạn nên luôn luôn nghĩ về nhiệm vụ mà bạn muốn lưu trữ với dữ liệu (tổng hợp, đọc, tìm kiếm, khai thác, ..) để tìm ra các công cụ tốt nhất cho vấn đề của bạn.

tức là nếu bạn thực hiện nhiều tìm kiếm trong cơ sở dữ liệu của mình, có thể tốt hơn là chạy một cá thể / cụm solr và không chuẩn hóa dữ liệu của bạn từ một DBMS như Postgres hoặc SQL Server của bạn theo thời gian và đưa nó vào solr thay vì chỉ di chuyển dữ liệu từ sql đến nosql về sự bền bỉ và hiệu suất.

Để trả lời câu hỏi này, bạn phải trả lời loại thỏa hiệp nào bạn có thể chi trả. RDBM thực hiện ACID . Điều này là tốn kém về tài nguyên. Không có giải pháp NoQuery nào là ACID. Xem định lý CAP để đi sâu vào những ý tưởng này.

Vì vậy, bạn phải hiểu từng thỏa hiệp được đưa ra bởi mỗi giải pháp và chọn một giải pháp phù hợp nhất cho vấn đề của bạn.

Dữ liệu lớn thực sự không phải là về "nó lớn như thế nào".

Đầu tiên, vài gigabyte không lớn chút nào, nó gần như không có gì. Vì vậy, đừng tự làm phiền mình, hệ thống của bạn sẽ tiếp tục hoạt động hiệu quả trong một thời gian tôi nghĩ.

Sau đó, bạn phải nghĩ về cách bạn sử dụng dữ liệu của bạn.

• Cách tiếp cận SQL: Mọi dữ liệu đều quý giá, được thu thập và lựa chọn tốt, và trọng tâm là lưu trữ dữ liệu có giá trị cao và có cấu trúc tốt. Điều này có thể tốn kém, mọi thứ đều liên kết với nhau và tốt cho dữ liệu chức năng và hệ thống được đặt ra.
• Phương pháp tiếp cận dữ liệu lớn: Trong dữ liệu lớn, về cơ bản, bạn lưu trữ hầu hết mọi thứ, bất kể giá trị của nó là bao nhiêu và sau đó thực hiện quy trình phân tích hoạt động. Những thứ không được liên kết, chúng được sao chép. Ví dụ: giả sử tôi có một mục blog. Trong Dữ liệu lớn sẽ không có liên kết đến tác giả của nó, nhưng tác giả sẽ được nhúng vào mục blog. Cách mở rộng hơn, nhưng đòi hỏi một cách tiếp cận khác và phức tạp hơn.

Nếu ứng dụng của bạn lưu trữ dữ liệu "chức năng", tôi sẽ đề nghị bạn tiếp tục sử dụng SQL. Nếu bạn lưu trữ dữ liệu để tìm kiếm chúng sau này hoặc thực hiện báo cáo và nếu lượng dữ liệu này có thể tăng nhanh, tôi sẽ đề xuất dữ liệu lớn. Theo tôi, dữ liệu lớn rất hữu ích khi bạn đang xử lý dữ liệu thực phải được thu thập và phân tích liên tục.

Tôi đã đăng một câu trả lời khá chi tiết trên stackoverflow về thời điểm thích hợp để sử dụng cơ sở dữ liệu quan hệ so với tài liệu (hoặc NoQuery), tại đây:

Động lực sử dụng cơ sở dữ liệu quan hệ / ORM hoặc cơ sở dữ liệu tài liệu / ODM

Tóm lược:

• đối với những thứ nhỏ nhặt, hãy sử dụng bất kỳ công cụ nào bạn quen thuộc

• một vài gigabyte chắc chắn là một công cụ nhỏ: nó không lớn cho đến khi nó quá lớn để phù hợp với một cụm MySQL duy nhất với số lượng nút hợp lý (16-32), có nghĩa là có thể dữ liệu 8-16TB và vài triệu giao dịch mỗi giây (hoặc cơ sở dữ liệu dựa trên ổ cứng thông thường hơn với dữ liệu TB lên tới 100 nghìn và vài nghìn giao dịch mỗi giây).

• nếu bạn bị mắc kẹt với cơ sở dữ liệu khác (không phải MySQL Cluster), hãy lấy thêm số dặm bằng cách sử dụng phần cứng FusionIO.

• một khi bạn có dữ liệu lớn hơn vài TB và nhanh hơn hàng nghìn giao dịch mỗi giây, đây là thời điểm tốt để xem xét việc chuyển sang shending logic trong mã ứng dụng trước rồi sau đó đến NoQuery.

• Cassandra :)

Có phải đã đến lúc chuyển sang NoQuery sẽ phụ thuộc vào 2 điều:

1. Bản chất / cấu trúc dữ liệu của bạn
2. Hiệu suất hiện tại của bạn

Cơ sở dữ liệu SQL vượt trội khi dữ liệu được cấu trúc tốt (ví dụ: khi nó có thể được mô hình hóa dưới dạng bảng, bảng tính Excel hoặc một tập hợp các hàng với số cột cố định). Cũng tốt khi bạn cần thực hiện nhiều lần tham gia bảng (nghe có vẻ giống như bạn làm).

Cơ sở dữ liệu NoQuery nổi trội khi dữ liệu không có cấu trúc ngoài các cặp khóa-giá trị.

Hiệu suất khôn ngoan, bạn phải tự hỏi mình một câu hỏi: giải pháp SQL hiện tại của bạn có chậm không?

Nếu không, hãy thực hiện theo nguyên tắc " IIABDFI ".