Chuyển từ Cơ sở dữ liệu Quan hệ sang Dữ liệu Lớn

Question

Hiện tại tôi có một ứng dụng được lưu trữ trên Nền tảng đám mây của Google cung cấp phân tích web và cung cấp hoạt động phiên (nhấp chuột, tải xuống v.v.) và liên kết hoạt động web đó với đăng ký web.

Hiện tại, chúng tôi lưu trữ tất cả dữ liệu hồ sơ nhấp chuột và phiên trong MySQL và sử dụng truy vấn SQL để tạo cả báo cáo tổng hợp và mỗi người dùng, tuy nhiên, khi lượng dữ liệu phát triển, chúng tôi thấy chậm thực sự trong các câu trả lời truy vấn, điều này sẽ làm chậm thời gian tải trang. Khi điều tra cách chúng tôi có thể giải quyết vấn đề này, chúng tôi đã xem xét các công cụ có sẵn trên Google Cloud Platform như Dataproc và Dataflow cũng như các giải pháp NoSQL, tuy nhiên, tôi đang gặp khó khăn trong việc tìm hiểu cách chúng tôi có thể áp dụng giải pháp hiện tại của chúng tôi bất kỳ giải pháp nào trong số này.

Hiện nay, một ý tưởng sơ bộ sơ đồ dữ liệu của chúng tôi là như sau:

User table 
- id 
- name 
- email 

Profile table (web browser/device) 
- id 
- user id 
- user agent string 

Session table 
- id 
- profile id 
- session string 

Action table 
- id 
- session id 
- action type 
- action details 
- timestamp 

Dựa trên nghiên cứu của tôi, hiểu biết của tôi về những gì sẽ là giải pháp tốt nhất là nên lưu trữ dữ liệu hành động trong một giải pháp cơ sở dữ liệu NoSQL như BigTable cung cấp dữ liệu vào một giải pháp như DataProc hoặc DataFlow tạo báo cáo. Tuy nhiên, vì lược đồ hiện tại của chúng tôi là một cấu trúc quan hệ cao, dường như loại bỏ tùy chọn chuyển sang giải pháp NoSQL vì tất cả các nghiên cứu của tôi chỉ ra rằng bạn không nên di chuyển dữ liệu quan hệ đến giải pháp NoSQL.

Câu hỏi của tôi là, sự hiểu biết của tôi về cách áp dụng các công cụ này có đúng không? Hoặc có giải pháp tốt hơn? Có cần thiết phải cân nhắc chuyển từ MySQL? Và nếu không, loại giải pháp nào có sẵn cho phép chúng tôi có thể xử lý trước/tạo dữ liệu báo cáo trong nền?

Answer 1

Giả sử rằng sessions và actions giá trị bảng không được cập nhật và chỉ chèn. Cách tốt nhất là tách cơ sở dữ liệu thành hai phần. Giữ DB DB cho các bảng user và profile và sử dụng BigQuery cho actions và sessions.

Bằng cách này bạn đã sau:

• giảm thiểu số lượng thay đổi bạn phải làm trên một trong hai bên (nhập dữ liệu và khai thác)
• bạn sẽ làm giảm đáng kể chi phí lưu trữ dữ liệu
• thời gian truy vấn sẽ cải thiện đáng kể
• trước khi bạn biết điều đó, bạn sẽ ở trong lãnh thổ dữ liệu lớn và BigQuery chỉ là giải pháp cho nó

BigQuery là cách tốt nhất. Tuy nhiên, nếu bạn có quá nhiều tài nguyên và thời gian, bạn có thể xem lưu trữ nó vào NoSQL db, sau đó chạy một công việc đường ống trên đó bằng cách sử dụng DataFlow để trích xuất dữ liệu phân tích mà bạn sẽ cần lưu trữ trong cơ sở dữ liệu cho mục đích truy vấn.

Answer 2

Một vài câu hỏi/giải pháp tiềm năng:

1. hồ sơ! Nếu đó là cùng một truy vấn đập cơ sở dữ liệu, thì tối ưu hóa truy vấn của bạn hoặc lưu vào bộ nhớ cache một số kết quả cho các trang thường xuyên nhất của bạn có thể giúp giảm tải xử lý. Ditto cho cài đặt cơ sở dữ liệu, RAM, v.v.
2. Cơ sở dữ liệu của bạn lớn đến mức nào?Nếu nó nhỏ hơn 64GB, mở rộng đến một máy chủ lớn hơn, nơi cơ sở dữ liệu có thể phù hợp với RAM có thể là một chiến thắng nhanh chóng.
3. Dữ liệu của bạn đang được sử dụng như thế nào? Nếu nó hoàn toàn là dữ liệu lịch sử, bạn có khả năng có thể giảm số nhấp chuột của bạn xuống bảng tra cứu, ví dụ: hành động mỗi phiên mỗi tuần hoặc mỗi người dùng mỗi tuần. Nếu dữ liệu được đối chiếu trong 5 phút/giờ, việc tải xuống dữ liệu thô và xử lý dữ liệu như thế này cục bộ cũng có thể hoạt động.
4. Bạn có thể làm bất thường, ví dụ: kết hợp tác nhân người dùng | phiên | loại hành động | chi tiết | dấu thời gian vào một hàng, nhưng bạn có khả năng tăng yêu cầu bộ nhớ và thời gian tra cứu của mình.
5. Ngoài ra, bình thường hơn cũng có thể giúp ích. Phá vỡ chuỗi tác nhân người dùng vào bảng riêng của nó sẽ làm giảm các yêu cầu dữ liệu của bảng đó và có thể tăng tốc mọi thứ.
6. Dường như dữ liệu của bạn có thể được chia nhỏ/phân đoạn bởi người dùng, do đó, đó có thể là một tùy chọn khác.

Nói chung, cách nhanh nhất để giải quyết các câu hỏi này là thử tải khối lượng công việc cụ thể của bạn, ví dụ: bao nhiêu yêu cầu điển hình của bạn (hoặc trang tổng quan ngẫu nhiên) bạn có thể thực hiện trên máy phát triển với số lượng RAM hợp lý (hoặc quay lên máy chủ/tạo cơ sở dữ liệu thử nghiệm khác).

Ngoài ra, nếu bạn chủ yếu sử dụng cơ sở dữ liệu quan hệ, sẽ có một số phí chuyển đổi (đặc biệt là giải pháp cạnh chảy máu), vì vậy bạn cần phải chắc chắn rằng chi phí vượt quá lợi ích trước khi chuyển đổi hoặc chuyển đổi từng chút một để bạn có thể chuyển trở lại nếu nó không hoạt động. Một lần nữa, thử nghiệm giúp.

Answer 3

Nếu thực tế, không lưu trữ lượng lớn dữ liệu!

Thay vào đó, hãy tổng hợp các khối dữ liệu khi chúng đến, sau đó lưu trữ tóm tắt.

Ưu điểm:

• Có lẽ một phần mười như nhiều không gian đĩa cần thiết;
• Báo cáo có thể nhanh gấp 10 lần,
• Có thể được thực hiện trong RDBMS hiện tại.

Nhược điểm:

• Bạn không thể trang bị thêm một tóm tắt khác nhau. (OK, bạn có thể giữ nguyên dữ liệu và bắt đầu lại; điều này có thể tốt hơn.)
• Độ phức tạp của mã hơn.

Discussion trong bảng tóm tắt.