20 Tỷ hàng/tháng - Hbase/Hive/Greenplum/Cái gì?

Question

Tôi muốn sử dụng trí tuệ của bạn để chọn giải pháp phù hợp cho hệ thống kho dữ liệu. Dưới đây là một số chi tiết để hiểu rõ hơn vấn đề:

Dữ liệu được tổ chức trong cấu trúc lược đồ hình sao với một thực tế BIG và ~ 15 thứ nguyên.
20B thực tế hàng mỗi tháng
10 chiều với hàng trăm hàng (hơi thứ bậc)
5 kích thước với hàng ngàn hàng
2 chiều với ~ 200K hàng
2 kích thước lớn với hàng 50M-100M

Hai truy vấn điển hình chạy với DB này

Thành viên hàng đầu trong dimq:

select top X dimq, count(id) 
from  fact 
where  dim1 = x and dim2 = y and dim3 = z 
group by dimq 
order by count(id) desc 

Các biện pháp chống lại một tuple:

select count(distinct dis1), count (distinct dis2), count(dim1), count(dim2),... 
from  fact 
where  dim1 = x and dim2 = y and dim3 = z 

Câu hỏi:

1. nền tảng tốt nhất để thực hiện truy vấn như vậy
   
2. là gì Những loại cứng đồ cần thiết
   

3. đâu nó có thể được lưu trữ (EC2?)

   
   (xin vui lòng bỏ qua nhập khẩu và các vấn đề tải vào lúc này)
   

Tnx,
A-ghê.

Answer 1

Tôi không thể nhấn mạnh điều này đủ: Nhận nội dung nào đó độc đáo với các công cụ báo cáo có sẵn.

20 tỷ hàng mỗi tháng đặt bạn vào lãnh thổ VLDB, vì vậy bạn cần phân vùng. Các thứ nguyên bản số thấp cũng sẽ gợi ý rằng các chỉ số bitmap sẽ là một chiến thắng hiệu suất.

• Hãy quên đi các hệ thống điện toán đám mây (Hive, Hbase) cho đến khi họ có hỗ trợ SQL trưởng thành. Đối với kho dữ liệu ứng dụng bạn muốn một cái gì đó mà hoạt động với các công cụ báo cáo thông thường . Nếu không, bạn sẽ tự thấy mình vĩnh viễn giả mạo viết và duy trì các chương trình báo cáo đặc biệt.

• Khối lượng dữ liệu có thể quản lý với một DBMS thường hơn như Oracle - Tôi biết một major European telco rằng tải 600GB mỗi ngày thành một cơ sở dữ liệu Oracle. Tất cả các thứ khác là những thứ bằng nhau, đó là hai đơn đặt hàng có số lượng lớn hơn lớn hơn khối lượng dữ liệu của bạn, vì vậy shared disk architectures vẫn còn có khoảng không cho bạn. Một kiến ​​trúc shared-nothing như Netezza hoặc Teradata có lẽ sẽ nhanh hơn vẫn nhưng những khối lượng là không phải ở một mức độ mà là ngoài một hệ thống chia sẻ đĩa thông thường . Mặc dù vậy, hãy nhớ rằng các hệ thống này là tất cả khá tốn kém.

• Cũng xin lưu ý rằng MapReduce là not an efficient query selection algorithm. Nó là về cơ bản là một cơ chế để phân phối các lực lượng brute-force . Greenplum không có một MapReduce back-end, nhưng một mục đích được xây dựng chia sẻ không có gì động cơ sẽ được nhiều hơn nữa hiệu quả và nhận được nhiều công việc làm cho ít hơn phần cứng.

Tôi nhận thấy đây là Teradata hoặc Netezza có thể là công cụ lý tưởng cho công việc nhưng chắc chắn là đắt nhất. Oracle, Sybase IQ hoặc thậm chí SQL Server cũng sẽ xử lý khối lượng dữ liệu có liên quan nhưng sẽ chậm hơn - chúng là kiến ​​trúc đĩa được chia sẻ nhưng vẫn có thể quản lý loại dữ liệu này. Xem This posting để biết tóm tắt về các tính năng liên quan đến VLDB trong Oracle và SQL Server, và lưu ý rằng Oracle cũng vừa giới thiệu Exadata storage platform.

Gói dung lượng dự phòng của tôi cho thấy có thể 3-5 TB hoặc hơn mỗi tháng bao gồm các chỉ mục cho Oracle hoặc SQL Server. Có lẽ ít hơn trên Oracle với các chỉ mục bitmap, mặc dù một lá chỉ mục có ROWID 16 byte trên oracle so với tham chiếu trang 6 byte trên SQL Server.

Sybase IQ sử dụng rộng rãi các chỉ mục bitmap và được tối ưu hóa cho truy vấn kho dữ liệu. Mặc dù kiến ​​trúc chia sẻ đĩa, nó rất hiệu quả cho kiểu truy vấn này (IIRC nó là kiến ​​trúc định hướng cột ban đầu). Điều này có lẽ sẽ tốt hơn so với Oracle hoặc SQL Server vì nó là chuyên biệt cho loại công việc này.

Greenplum có thể là một lựa chọn rẻ hơn nhưng tôi chưa bao giờ thực sự sử dụng nó vì vậy tôi không thể nhận xét về hiệu quả hoạt động của nó trong thực tế.

Nếu bạn có 10 kích thước chỉ với vài trăm hàng, hãy xem xét hợp nhất chúng thành một đơn junk dimension sẽ làm mỏng bảng thực tế của bạn bằng cách hợp nhất mười khóa thành một. Bạn vẫn có thể thực hiện phân cấp trên một kích thước rác và điều này sẽ gõ 1/2 hoặc nhiều hơn kích thước của bảng thực tế của bạn và loại bỏ rất nhiều đĩa sử dụng bởi các chỉ mục.

Tôi đặc biệt khuyên bạn nên sử dụng thứ gì đó phát độc đáo với mặt cắt hợp lý của các công cụ báo cáo. Điều này có nghĩa là giao diện người dùng SQL. Các hệ thống thương mại như Crystal Reports cho phép báo cáo và phân tích được thực hiện bởi những người có bộ kỹ năng SQL có thể đạt được dễ dàng hơn. Thế giới nguồn mở cũng đã tạo ra BIRT, Jasper Reports và Pentaho..Hive hoặc HBase đặt bạn vào kinh doanh xây dựng một giao diện tùy chỉnh, mà bạn thực sự không muốn trừ khi bạn sẵn sàng dành 5 năm tiếp theo viết các trình định dạng báo cáo tùy chỉnh bằng Python.

Cuối cùng, lưu trữ ở đâu đó bạn có thể dễ dàng nhận nguồn cấp dữ liệu nhanh từ hệ thống sản xuất của bạn. Điều này có thể có nghĩa là phần cứng của riêng bạn trong trung tâm dữ liệu của riêng bạn. Hệ thống này sẽ bị ràng buộc I/O; nó thực hiện xử lý đơn giản trên khối lượng lớn dữ liệu. Điều này có nghĩa là bạn sẽ cần các máy có hệ thống con đĩa nhanh. Các nhà cung cấp dịch vụ đám mây có xu hướng không hỗ trợ loại phần cứng này vì nó là một đơn đặt hàng có cường độ đắt hơn loại hộp 1U dùng một lần theo truyền thống được sử dụng bởi những trang phục này. Fast Disk I/O không phải là sức mạnh của kiến ​​trúc đám mây.

Answer 2

Một giải pháp thay thế cho số lượng người dùng thấp sẽ là một cụm (beowulf). 20K mua cho bạn 50 nettop với 500G mỗi cái. Đó là khoảng 3KW công suất đỉnh. Hoặc 4 tháng lưu trữ đám mây.

Answer 3

NXC, bạn có chắc chắn về 600 tỷ hàng mỗi ngày không? Ngay cả khi một hàng sẽ chỉ là một byte, đó là 600 GB dữ liệu hàng ngày. Giả sử một 100 byte hợp lý hơn mỗi hàng, chúng tôi đang nói về 60 TB dữ liệu mỗi ngày, 1,8 PB mỗi tháng. Tôi thực sự nghi ngờ bất cứ ai đang bơm nhiều dữ liệu đó thông qua Oracle.

Other Sources dường như xác nhận rằng Oracle trở nên khá khó xử lý khi khối lượng dữ liệu đạt đến con số TB 2 chữ số.

Answer 4

Đọc trang web của Monash: http://www.dbms2.com/ Anh ấy viết về cơ sở dữ liệu lớn.

Có thể bạn có thể sử dụng Oracle Exadata (http://www.oracle.com/solutions/business_intelligence/exadata.html và http://kevinclosson.wordpress.com/exadata-posts/) hoặc có thể bạn có thể sử dụng Hadoop. Hadoop là miễn phí.

Answer 5

Tôi đã thành công lớn với vertica. Tôi hiện đang tải bất cứ nơi nào từ 200 triệu đến 1 tỷ hàng trong một ngày - trung bình khoảng 9 tỷ hàng mỗi tháng - mặc dù tôi đã tăng cao tới 17 tỷ trong một tháng. Tôi có gần 21 kích thước và các truy vấn chạy nhanh chóng. Chúng tôi đã chuyển từ hệ thống cũ hơn khi chúng tôi không có cửa sổ thời gian để thực hiện tải dữ liệu.

chúng tôi đã làm một thử nghiệm rất đầy đủ và nghiên cứu các giải pháp khác nhau - và thực tế đã xem xét mọi thứ trên thị trường. Trong khi cả Teradata và Netezza đều phù hợp với chúng tôi, chúng đơn giản là quá đắt đối với chúng tôi. Vertica đánh bại cả hai trên tỷ lệ giá/hiệu suất. Đó là bằng cách một cơ sở dữ liệu cột.

Hiện có khoảng 80 người dùng - và dự kiến ​​sẽ tăng lên khoảng 900 vào cuối năm tới khi chúng tôi bắt đầu triển khai hoàn toàn.

Chúng tôi đang sử dụng rộng rãi các dịch vụ ASP.NET/dundas/reporting cho báo cáo. Nó cũng chơi tốt với các giải pháp báo cáo của bên thứ ba - mặc dù chúng tôi chưa thử.

Bằng cách này, bạn sẽ sử dụng gì để tải dữ liệu? Chúng tôi đang sử dụng informatica và đã rất hài lòng với nó. SSIS đẩy chúng tôi lên tường.

Answer 6

Tôi tò mò những gì bạn đã chọn cuối cùng. Câu hỏi của bạn là vào cuối năm 2008. Hiện nay tình hình khác với HBase, Greenplum, lợn, vv cho SQL giống như truy cập.

Answer 7

Sử dụng HBase và jasperserver hbase reporting pluging, có thể tạo báo cáo tốt. Độ trễ thấp OLAP có thể được tạo trong HBase. Điều này sẽ làm việc giống như SQL. Plugin Jasperserver HBase cung cấp ngôn ngữ truy vấn Hbase, đó là một lệnh mở rộng HBase scan.