Ứng dụng sẽ liên tục (khoảng mỗi giây) thu thập vị trí của người dùng và lưu trữ chúng.

Dữ liệu này được cấu trúc. Trong cơ sở dữ liệu quan hệ, nó sẽ được lưu trữ dưới dạng: | user | timestamp | latitude | longitude |

Tuy nhiên, có quá nhiều dữ liệu. Sẽ có 60 × 60 × 24 = 86.400 hồ sơ cho mỗi người dùng, hàng ngày. Ngay cả với 1000 người dùng, điều này có nghĩa là 86.400.000 hồ sơ hàng ngày.

Và nó không chỉ là 86.400.000 hồ sơ hàng ngày. Bởi vì những hồ sơ này sẽ được xử lý và các phiên bản được xử lý của chúng cũng sẽ được lưu trữ. Vì vậy, nhân số đó với khoảng 2.

Tôi dự định sử dụng dữ liệu như thế nào

Về cơ bản, tôi có kế hoạch tạo ra các phiên bản hạt thô của dữ liệu vị trí để tiêu thụ dễ dàng hơn. Đó là:

1. Sắp xếp các dấu thời gian wrt dữ liệu nhận được.
2. Sắp xếp theo danh sách này theo thứ tự, xác định xem vị trí có thay đổi đáng kể không (bằng cách kiểm tra xem vĩ độ và kinh độ thay đổi bao nhiêu)
3. Biểu thị các thay đổi vị trí không đáng kể dưới dạng một mục nhập trong đầu ra (do đó, đầu ra là phiên bản chi tiết thô hơn của dữ liệu vị trí).
4. Lặp lại quá trình này trên đầu ra, bằng cách yêu cầu thay đổi kinh độ và vĩ độ thậm chí còn lớn hơn để thay đổi đáng kể. Do đó, đầu ra được sản xuất từ ​​đầu ra trước sẽ thậm chí còn thô hơn.
5. Lặp lại toàn bộ quá trình nhiều như cần thiết.
6. Tổng hợp một loạt các nghị quyết và gửi chúng cho người dùng. Ngoài ra, lưu trữ tất cả các độ phân giải của dữ liệu để tiêu thụ sau này.

Tôi nên sử dụng gì để lưu trữ dữ liệu này? Tôi nên sử dụng cơ sở dữ liệu quan hệ hoặc giải pháp NoQuery? Những điều khác tôi nên xem xét khi thiết kế ứng dụng này?

Một số lựa chọn thay thế để lưu trữ dữ liệu này:

1. Hàng đợi tin nhắn (có thể được phân phối), như Apache Kafka

Điều này sẽ được tối ưu hóa để viết và đọc một luồng dữ liệu. Đó là lý tưởng để thu thập các luồng dữ liệu ở định dạng dễ xử lý, nhưng nó thường không thể được truy vấn ngoại trừ bằng cách đọc toàn bộ luồng. Vì vậy, đây sẽ là cho mục đích lưu trữ, hoặc một bước trung gian trên đường đến lớp xử lý.

2. Cơ sở dữ liệu quan hệ)

Bạn chỉ có thể ghi nó vào cơ sở dữ liệu và khi âm lượng vượt quá khả năng của DB để xử lý, bạn có thể hủy cơ sở dữ liệu (= có nhiều tập hợp dữ liệu nằm trên các máy chủ cơ sở dữ liệu khác nhau). Lợi ích: bạn có thể sử dụng DB quan hệ và không phải học bất cứ điều gì mới. Nhược điểm: tất cả các mã xử lý DB phải nhận thức được phần nào của cuộc sống dữ liệu, các truy vấn tổng hợp phải được thực hiện trong phần mềm ứng dụng.

3. Cơ sở dữ liệu NoQuery phân tán, như Cassandra.

Bạn ghi dữ liệu của mình vào cơ sở dữ liệu NoQuery phân tán và nó sẽ tự động phân chia dữ liệu cho bạn. Cassandra cho phép bạn thực hiện các truy vấn trên toàn cụm, yêu cầu ít mã ứng dụng hơn để lấy lại dữ liệu. Lợi ích: phù hợp tự nhiên hơn với số lượng lớn dữ liệu, nhược điểm: sẽ đòi hỏi chuyên môn cụ thể và hiểu biết sâu sắc về cơ chế hoạt động của các hệ thống này để đạt được hiệu suất tốt và làm cho dữ liệu có thể truy vấn theo nhu cầu của bạn. NoQuery không phải là một bản sửa lỗi hiệu năng kỳ diệu, nó là một tập hợp các sự đánh đổi phải được hiểu là được điều hướng.

4. Hadoop / tập tin

Dữ liệu được thêm vào các tệp được phân phối tự động trên các máy chủ bởi nền tảng Hadoop, được xử lý trên các máy chủ đó bằng các công cụ như M / R hoặc Apache Spark và cuối cùng được truy vấn (dưới dạng tệp) bằng cách sử dụng công cụ SQL Hadoop như Hive hoặc Impala.

Chọn loại nào?

Sự đánh đổi giữa các lựa chọn thay thế này rất phức tạp và chúng phụ thuộc rất nhiều vào cả cách viết và kiểu đọc của bạn, vì vậy người duy nhất có thể quyết định những sự đánh đổi này là bạn. Nếu bạn thiếu thời gian để xây dựng một sự hiểu biết sâu sắc về các lựa chọn thay thế này, thì chỉ cần sử dụng một DB quan hệ và tìm ra một giải pháp shending khi bạn đi cùng. Trong tất cả khả năng, YAGNI .

Nhìn vào yêu cầu của bạn sâu hơn một chút. Có một cách để tạo ảo giác về vị trí theo dõi mỗi giây.

Nếu bạn có một ứng dụng biết vị trí GPS hiện tại của bạn và ghi nó vào cơ sở dữ liệu, tại sao bạn sẽ tiếp tục viết vị trí đó nếu nó không thay đổi? Ngay cả khi bạn yêu cầu dữ liệu, nếu người dùng đã ngủ trong 7 giờ, bạn có thể lập trình điền vào các khe thời gian bị thiếu với một vị trí trùng lặp để thực hiện các phép tính hoặc ánh xạ hoặc bất cứ điều gì khác bạn cần làm.

Nếu bạn theo dõi vị trí mỗi giây, bạn có phải lưu trữ những dữ liệu này mãi mãi không? Bạn có thể lưu trữ các bản ghi vào cơ sở dữ liệu khác để ngăn bảng hiện tại quá lớn. Hoặc thậm chí bạn có thể giữ hồ sơ khi có sự thay đổi vị trí. Điều này là phổ biến trong kho dữ liệu.

Dữ liệu của bạn là một chuỗi các chuỗi thời gian. Bạn đã đưa ra các bộ số (hai cho mỗi người dùng) phát triển theo thời gian. Thông thường, bạn KHÔNG tìm kiếm bất kỳ loại lưu trữ quan hệ nào, mà là lưu trữ RRD. Các kho lưu trữ này tập trung rất nhiều vào việc giảm công việc I / O của nhiều lần ghi nhỏ bằng cách đệm nó.

Lưu trữ quan hệ là một dị giáo cho khối lượng thời gian này. Tuy nhiên, được cảnh báo rằng sự phát triển của RRD không được hỗ trợ nhiều về mặt khai thác lập trình so với SQL. Bạn có thể đang xem xét công việc tích hợp nghiêm túc, nhưng hầu như không thể tránh khỏi yêu cầu của bạn.