Cách xử lý truy vấn của 500M + mục

8

Cấu trúc dữ liệu của tôi là như sau:

date: <timestamp>
filter_a: <integer> -> range [0, 1000]
filter_b: <integer> -> range [0, 1000]
filter_c: <integer> -> range [0, 86400]
filter_d: <integer> -> range [0, 6]
group: <string>
second_group: <integer>
variable_a: <float>
variable_b: <float>
variable_c: <float>
a couple more no very important

Tôi cần thực hiện các truy vấn sau:

Đầu tiên:

Lọc dữ liệu bằng date, filter_a, filter_b, filter_cvà những người khác

Thứ hai, với dữ liệu được lọc:

đếm tất cả hồ sơ
lấy trung bình của variable_a, variable_bvàvariable_c
có độ lệch chuẩn của variable_a, variable_bvàvariable_c
nhận phần tư của variable_a, variable_bvàvariable_c
dữ liệu nhóm theo grouphoặc second_groupvà tổng hợp (Đếm, Trung bình, Std, ..)

Số lượng người dùng của hệ thống là khoảng 10 hoặc 15, nhưng số lượng mặt hàng rất lớn, hiện tại là 70 triệu nhưng sẽ là 500 triệu trong vài tuần và sẽ là 1000 triệu trong khoảng một năm.

Số lượng truy vấn ít, không quá 10 người dùng đồng thời, vấn đề của tôi là làm thế nào để xử lý các truy vấn đó với lượng dữ liệu khổng lồ này.

Tôi đã thử những gì cho đến nay?

Tôi đã bắt đầu với mongodb, lúc đầu thì nhanh nhưng nó trở nên chậm khi tính các tứ phân với 10M +. Nó được cải thiện khi tôi thêm chỉ mục nhưng nó không giúp ích gì nhiều khi tôi phải truy vấn tất cả dữ liệu. Tôi bắt đầu sử dụng mongodb vì dữ liệu rất năng động nhưng may mắn là định dạng dữ liệu "sẽ không thay đổi nữa".
Như filter_avà filter_bcó thể được nhìn thấy như các nút, tôi đã thử neo4j. Tôi rất thích nó neo4j rất nhiều nhưng đồ thị của tôi có RẤT NHIỀU cạnh nên các truy vấn không nhanh lắm.
Cuối cùng, vì định dạng dữ liệu sẽ không thay đổi và nó chỉ là một bộ sưu tập / bảng nên không cần tham gia trong SQL, tôi đã kiểm tra postgresql. Các thử nghiệm của tôi đã nhanh hơn với postgresql, nhưng tôi sợ nó không thể mở rộng đúng quy mô trong tương lai.

Tôi cần những gì?

Postgresql là một lựa chọn tốt cho trường hợp này?
Có một loại cơ sở dữ liệu nào tôi có thể sử dụng? cái nào là tốt nhất cho trường hợp này?
Tôi có thể làm gì khác để cải thiện nó?

Biên tập

Khoảng 1 triệu yếu tố được chèn mỗi ngày và "không nên thay đổi" theo thời gian.
Tốc độ ghi không quan trọng
Yêu cầu khó là đọc / tổng hợp nhanh

Cảm ơn!

— Andres
nguồn

1

Làm thế nào về các khung nhìn được lập chỉ mục trong SQL Server / các khung nhìn di căn trong Oracle? Đó là một tổng hợp đang chạy của bảng cơ sở để bảng cơ sở được sửa đổi, chỉ mục cũng được sửa đổi nhanh chóng. Sau đó, bạn luôn có thể truy vấn các tập hợp đã được tính toán cho bạn.

— Ali Razeghi

@AliRazeghi lượt xem được lập chỉ mục là ý tưởng tốt. Dù sao trước tiên tôi muốn chọn cơ sở dữ liệu / thiết kế tốt nhất trước khi tự tối ưu hóa các truy vấn

— Andres

1

Để tối ưu hóa hoàn toàn trong Postgres, tôi muốn nói rằng các chỉ mục BRIN có thể giúp đỡ ở đây, nhưng tôi chưa làm gì ngoài việc đọc về chúng. postgresql.org/docs/9.5/static/brin-intro.html

— Erik Darling

1

Cá nhân tôi đã thừa hưởng một hàng tỷ tỷ báo cáo DB trên máy chủ OLTP mà không cần nhiều bộ nhớ. May mắn thay, các phần được yêu cầu nhiều nhất của nó là một '3 tuần qua' nhưng việc quét bảng không phải là chưa từng thấy. Thành thật bằng cách sử dụng nén, phân vùng, loại bỏ phân vùng, sơ đồ phân vùng, tối ưu hóa bộ đệm SAN và loại bỏ các chỉ mục không sử dụng, chúng tôi có hiệu suất rất tốt trên MS SQL 2008 Ent. 1 tỷ sẽ không quá khó đối với PGQuery. Mỗi hàng rộng bao nhiêu hoặc khoảng bao nhiêu bạn nghĩ mỗi hàng sẽ chiếm bao nhiêu và sẽ có bao nhiêu chỉ mục cho mỗi bảng hoặc quá trình nhập?

— Ali Razeghi

2

@Andres tốt phụ thuộc vào công cụ db của nó và kích thước tối đa của mỗi hàng là gì để chúng tôi có thể tính toán. Ví dụ PostgreSQL có varchar và chỉ cần char, char rất dễ tính toán, varchar chúng ta phải đoán độ dài trung bình. Nếu chúng ta có thể biết loại trường đó là gì (trừ khi đó là Mongo hoặc thứ gì đó lưu trữ nó trong tài liệu với định dạng riêng của nó), khoảng bao nhiêu ký tự chúng ta mong đợi trong mỗi và # chỉ mục với các cột. RAM 8GB có vẻ như quá thấp để có thể rút nó ra khỏi bộ nhớ một cách hiệu quả mặc dù đặc biệt nếu RAM đó được chia sẻ với các bảng và tài nguyên khác trên máy chủ.

— Ali Razeghi

5

Thay vì dựa vào cơ sở dữ liệu quan hệ để thực hiện các tính toán thống kê này trên dữ liệu chuỗi thời gian, tôi khuyên bạn nên chuyển công việc toán học và xử lý hậu kỳ này bên ngoài cơ sở dữ liệu sang ứng dụng khách.

Sử dụng ngôn ngữ kịch bản như Python hoặc Ruby, bạn có thể giải quyết vấn đề bằng cách truy vấn "khối" dữ liệu trong một khoảng thời gian có độ rộng cố định, tính toán tóm tắt thống kê trung gian và sau đó kết hợp các kết quả qua nhiều khối, khi bạn lặp trên toàn bộ lịch sử. Một số biện pháp thống kê khó kết hợp giữa các khối, nhưng một số thứ như Average () chỉ cần sum () và Count () trên mỗi chunk, O (1) so với O (chunkize), do đó, việc hợp nhất chunk có thể mở rộng tốt.

— Jpierc
nguồn

Tôi đã thử một cái gì đó như thế bằng cách sử dụng python / gấu trúc . tính toán nhanh hơn (một vài giây) nhưng truy xuất tất cả dữ liệu chậm. Có lẽ tốt hơn chunksizecó thể giúp đỡ. +1

— Andres

1

Vì dữ liệu của bạn không thay đổi và nó chỉ được nối thêm, tôi sẽ lưu trữ dữ liệu bất cứ nơi nào bạn muốn; Amazon S3 chẳng hạn, nhưng mọi cơ sở dữ liệu đọc nhanh sẽ ổn. Không có chỉ số. Cơ sở dữ liệu / FS bạn chọn phải có tùy chọn đọc dữ liệu theo nhóm: ví dụ: bạn có thể có một tệp mỗi ngày với các bản ghi 1M của mình.

Sau đó, tôi sẽ sử dụng Spark để lọc / phân tích. Đó là cụm dựa trên, bạn có thể mở rộng nó theo nhu cầu của bạn.

— Sư Tử
nguồn

Tôi đồng ý, tôi đã tách dữ liệu của mình mỗi ngày. Tôi cũng đã suy nghĩ về HDFS và HBase

— Andres

0

Phản hồi phụ thuộc vào cách bạn sẽ sử dụng dữ liệu sau này. Nếu để xử lý tốt hơn hãy sử dụng Cassandra, nếu để phân tích tốt hơn hãy sử dụng Hive.

— Tạo mẫu Artemy
nguồn

Tôi hiểu tổ ong không thể là sự lựa chọn tốt nhất cho real time. Tôi có lầm không?

— Andres

1

Có, HBase dành cho đọc / ghi thời gian thực. Nhưng Cassandra cũng có thể làm như vậy. Nhưng tôi nghĩ HBase tốt hơn.

— Tạo mẫu Artemy

0

Loại tình huống này rất lý tưởng cho việc lưu trữ dữ liệu, sử dụng các kỹ thuật được hoàn thiện bởi Ralph Kimball và cộng sự, trên các nền tảng như SQL Server (ứng dụng tôi quen thuộc nhất). Chúng được thiết kế dành riêng cho loại kịch bản này trong tâm trí: một lượng lớn các bản ghi dữ liệu tương đối tĩnh, mà bạn cần tính toán tổng hợp của loại này. KhôngKỹ thuật quan hệ sẽ phù hợp để lưu trữ dữ liệu được triển khai đúng cách trong các ứng dụng loại này, mặc dù một số chắc chắn sẽ tốt hơn các ứng dụng khác nếu tổ chức của bạn đơn giản không đủ khả năng cấp phép cho các gói phần mềm (như Dịch vụ phân tích máy chủ SQL) triển khai chúng. Ngoài ra còn có một đường cong học tập để thực hiện các ngôn ngữ như MDX được thiết kế riêng cho loại truy cập dữ liệu này. Nếu kho dữ liệu là một lựa chọn khả thi cho tổ chức của bạn, thì đừng lãng phí thời gian tìm kiếm một giải pháp quan hệ; đây không phải là một vấn đề cơ sở dữ liệu quan hệ Tôi có thể đăng một số tài liệu tham khảo cơ bản cho Kimball, v.v. và các liên kết đến SSAS và MDX (xin lỗi tôi không thể giúp với Oracle và các đối thủ khác mà tôi không quen thuộc) nếu cần. Tôi hy vọng điều đó sẽ giúp.

— SQLServerSteve
nguồn