Cơ sở dữ liệu nào có thể xử lý lưu trữ hàng tỷ / nghìn tỷ bản ghi?

Chúng tôi đang xem xét việc phát triển một công cụ để thu thập và phân tích dữ liệu netflow, trong đó chúng tôi thu thập số lượng rất lớn. Mỗi ngày chúng tôi thu được khoảng ~ 1,4 tỷ hồ sơ lưu lượng trông giống như thế này ở định dạng json:

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

Chúng tôi muốn có thể thực hiện tìm kiếm nhanh (dưới 10 giây) trên tập dữ liệu, rất có thể trong các khoảng thời gian hẹp (khoảng 10 - 30 phút). Chúng tôi cũng muốn lập chỉ mục cho phần lớn các điểm dữ liệu để chúng tôi có thể thực hiện tìm kiếm trên từng điểm một cách nhanh chóng. Chúng tôi cũng muốn có một cái nhìn cập nhật về dữ liệu khi các tìm kiếm được thực hiện. Sẽ thật tuyệt khi ở lại trong thế giới nguồn mở, nhưng chúng tôi không phản đối việc xem xét các giải pháp độc quyền cho dự án này.

Ý tưởng là giữ khoảng một tháng dữ liệu, sẽ là ~ 43,2 tỷ hồ sơ. Một ước tính sơ bộ rằng mỗi bản ghi sẽ chứa khoảng 480 byte dữ liệu, sẽ tương đương với ~ 18,7 terabyte dữ liệu trong một tháng và có thể gấp ba lần so với chỉ mục. Cuối cùng, chúng tôi muốn phát triển khả năng của hệ thống này để lưu trữ hàng nghìn tỷ hồ sơ.

Chúng tôi (về cơ bản) đã đánh giá couchbase, cassandra và mongodb cho đến nay có thể là ứng cử viên cho dự án này, tuy nhiên mỗi người đề xuất những thách thức riêng của họ. Với couchbase, việc lập chỉ mục được thực hiện theo chu kỳ và không trong quá trình chèn dữ liệu để các chế độ xem không cập nhật, các chỉ mục phụ của cassandra không hiệu quả trong việc trả về kết quả vì chúng thường yêu cầu quét toàn bộ cụm để tìm kết quả và mongodb có vẻ hứa hẹn nhưng dường như khó khăn hơn để mở rộng quy mô vì nó là chủ / nô lệ / phân đoạn. Một số ứng cử viên khác mà chúng tôi dự định đánh giá là elaticsearch, mysql (không chắc điều này có áp dụng được không) và một vài cơ sở dữ liệu quan hệ theo định hướng cột. Bất kỳ đề xuất hoặc kinh nghiệm thế giới thực sẽ được đánh giá cao.

Trong một công ty tôi làm việc cho chúng tôi đang xử lý lượng dữ liệu tương tự (khoảng 10 TB dữ liệu tìm kiếm thời gian thực). Chúng tôi giải quyết vấn đề này với Cassandra và tôi muốn đề cập đến một vài ý tưởng cho phép bạn thực hiện tìm kiếm O (1) trên cơ sở dữ liệu nhiều TB. Điều này không đặc trưng cho db Cassandra, bạn cũng có thể sử dụng nó với các db khác.

Học thuyết

• Phân đoạn dữ liệu của bạn. Không có cách nào một máy chủ duy nhất sẽ tin cậy và thực tế giữ khối lượng dữ liệu như vậy.
• Hãy sẵn sàng cho các lỗi phần cứng và lỗi toàn bộ nút, sao chép dữ liệu.
• Bắt đầu sử dụng nhiều máy chủ back-end ngay từ đầu.
• Sử dụng nhiều máy chủ hàng hóa rẻ hơn, so với các máy chủ hiệu suất cao hàng đầu.
• Đảm bảo dữ liệu được phân bổ đều trên các mảnh.
• Dành nhiều thời gian lập kế hoạch truy vấn của bạn. API xuất phát từ các truy vấn và sau đó thiết kế bảng cẩn thận. Đây là nhiệm vụ quan trọng nhất và kéo dài.
• Trong Cassandra, bạn có thể thiết kế khóa cột tổng hợp và có quyền truy cập vào khóa đó trong O (1). Dành thời gian làm việc trên chúng. Điều này sẽ được sử dụng để truy cập các hồ sơ có thể tìm kiếm thay vì chỉ mục phụ.
• Tận dụng các hàng rộng. Chúng rất hữu ích để lưu trữ các sự kiện có dấu thời gian.
• Không bao giờ thực hiện quét toàn bộ hoặc trên thực tế bất kỳ thao tác nào nhiều hơn O (Nhật ký N) trên âm lượng đó. Nếu bạn yêu cầu bất cứ điều gì nhiều hơn O (Nhật ký N), hãy giảm tải các hoạt động đó cho các thuật toán Map-Giảm.

Thực hành

• Đừng dành thời gian xây dựng hình ảnh hệ điều hành hoặc cài đặt máy chủ trên các máy vật lý. Sử dụng các nhà cung cấp dựa trên đám mây để tạo mẫu nhanh. Tôi đã làm việc với Amazon EC2 và rất có thể giới thiệu nó vì tính đơn giản, độ tin cậy và tốc độ tạo mẫu của nó.
• Các máy Windows có xu hướng chậm hơn trong thời gian khởi động và chiếm nhiều tài nguyên hơn ở trạng thái Chờ. Cân nhắc sử dụng HĐH dựa trên Unix. Cá nhân, tôi thấy máy chủ Ubuntu là một hệ điều hành đáng tin cậy, nhưng hơn nữa, có một cộng đồng khá tốt tại Askubfox
• Hãy suy nghĩ về việc kết nối mạng, các nút sẽ lý tưởng gần nhau để cho phép trao đổi nhanh và trao đổi dữ liệu meta.
• Không đi vào các trường hợp cực đoan: các hàng cột thực sự rộng hoặc các họ cột (bảng) đặc biệt dài. Hiệu suất tốt nhất đạt được trong các ranh giới lành mạnh - nếu db hỗ trợ nhiều hàng N theo thiết kế, điều đó không có nghĩa là nó hoạt động tốt.
• Tìm kiếm của chúng tôi mất khoảng 3-5 giây, phần lớn là do các nút trung gian giữa UI và cơ sở dữ liệu. Xem xét làm thế nào để đưa các yêu cầu đến gần hơn với cơ sở dữ liệu.
• Sử dụng một bộ cân bằng tải mạng. Chọn một thành lập. Chúng tôi sử dụng HAProxy, đơn giản, nhưng chết nhanh. Không bao giờ có vấn đề với nó.
• Thích sự đơn giản cho các giải pháp phức tạp.
• Tìm kiếm các giải pháp nguồn mở miễn phí, trừ khi bạn được hỗ trợ bởi ngân sách quy mô của một công ty. Khi bạn đi nhiều hơn một số máy chủ, chi phí cơ sở hạ tầng có thể sẽ tăng cao.

Tôi không làm việc cho Amazon và không có quan hệ với các nhóm HAProxy và Ubuntu. Đây là một ý kiến ​​cá nhân chứ không phải là bất kỳ loại khuyến mãi.

Nếu tôi định đưa cái này vào SQL Server, tôi sẽ gợi ý một bảng như:

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

Điều này dẫn đến tổng yêu cầu lưu trữ ước tính cho một bảng duy nhất, không có chỉ số 5,5 TB nào nữa cho 43,2 hồ sơ ong (yêu cầu được chỉ định của bạn). Điều này được tính là 130 byte cho chính dữ liệu, cộng với 7 byte cho mỗi hàng trên cao, cộng với 96 byte cho mỗi trang trên không. SQL Server lưu trữ dữ liệu trong các trang 8KB, cho phép 59 hàng trên mỗi trang. Điều này tương đương với 732.203.390 trang cho một tháng dữ liệu.

SQL Server thích ghi vào đĩa theo từng đoạn 8 trang (64KB), tương đương với 472 hàng trên mỗi I / O vật lý. Với 16.203 hồ sơ lưu lượng được tạo ra mỗi giây, bạn sẽ cần tốc độ I / O tối thiểu là 34 IOps, được đảm bảo mỗi giây. Mặc dù bản thân nó không phải là một số tiền quá lớn, nhưng các I / O khác trong hệ thống (SQL Server và các loại khác) cần không bao giờ vi phạm tỷ lệ IOps cần thiết này. Do đó, bạn cần thiết kế một hệ thống có khả năng ít nhất một IOps có độ lớn hơn hoặc 340 IOps được duy trì - Tôi có xu hướng ước tính rằng bạn cần 2 IOps có độ bền cao hơn để đảm bảo thông lượng.

Bạn sẽ nhận thấy tôi không lưu trữ các địa chỉ IP ở dạng thập phân rải rác của chúng. Điều này giúp tiết kiệm một lượng lớn dung lượng lưu trữ (7 byte cho mỗi địa chỉ) và cũng giúp lập chỉ mục, truy xuất, sắp xếp và so sánh các địa chỉ IP hiệu quả hơn rất nhiều. Nhược điểm ở đây là bạn cần chuyển đổi các IP thập phân rải rác thành các số nguyên 8 byte trước khi lưu trữ chúng và quay lại các IP thập phân rải rác để hiển thị. Mã để làm như vậy là không đáng kể, tuy nhiên, tốc độ hàng của bạn sẽ thêm một lượng đáng kể chi phí xử lý cho mỗi dòng lưu lượng được xử lý - bạn có thể muốn thực hiện quy trình chuyển đổi này trên một máy tính khác với SQL Server.

Thảo luận về các chỉ số bạn yêu cầu là một vấn đề hoàn toàn riêng biệt vì bạn chưa liệt kê bất kỳ yêu cầu cụ thể nào. Thiết kế của bảng này sẽ lưu trữ các hàng luồng theo thứ tự vật lý mà SQL Server nhận được, tcp_traffic_idtrường này là duy nhất cho mỗi bản ghi và cho phép sắp xếp các hàng theo thứ tự chúng được ghi lại (trong trường hợp này rất có thể liên quan đến từng cái một đến thời điểm của sự kiện dòng chảy).

Tôi muốn giới thiệu HBase . Bạn có thể lưu trữ tất cả dữ liệu thô trong một hoặc nhiều bảng HBase, tùy thuộc vào những gì bạn cần truy vấn. HBase có thể xử lý các tập dữ liệu lớn và tự động chuyển qua các phần tách vùng.

Ngoài ra, nếu bạn thiết kế các phím hàng tốt, bạn có thể nhận được các truy vấn cực kỳ nhanh, thậm chí là O (1). Lưu ý rằng nếu bạn đang truy xuất một tập dữ liệu lớn, điều đó vẫn sẽ chậm vì việc truy xuất dữ liệu là thao tác O (n).

Vì bạn muốn truy vấn trên từng trường, tôi khuyên bạn nên tạo một bảng duy nhất cho mỗi trường. Ví dụ cho dữ liệu src_address, có một bảng trông như thế này:

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

Vì vậy, nếu bạn muốn truy vấn tất cả dữ liệu trong 1.2.3.4 bắt đầu từ 27 tháng 3 12:00 đến 27 tháng 3 12:01 sáng, bạn có thể thực hiện quét phạm vi với các hàng bắt đầu và dừng được chỉ định.

IMHO, thiết kế khóa hàng là phần quan trọng nhất khi sử dụng HBase - nếu bạn thiết kế tốt, bạn sẽ có thể thực hiện các truy vấn nhanh VÀ lưu trữ khối lượng lớn dữ liệu.

Nói điều này :

... chúng tôi không phản đối việc xem xét các giải pháp độc quyền cho dự án này

Tôi đề nghị xem xét cơ sở dữ liệu IBM Informix + cơ sở dữ liệu TimeSeries . Đối diện với những gì một số người nói, Informix vẫn còn sống và đang hoạt động rất tốt. Phiên bản cuối cùng được phát hành vào tháng trước (tháng 3/2013, phiên bản 12.10).

TimeSeries giống như một "plugin" (miễn phí) có thể xử lý các tình huống như của bạn.
Và bạn có thể sử dụng nó trong sản xuất với phiên bản miễn phí của cơ sở dữ liệu Informix ( phiên bản đổi mới-C ). (tất nhiên, chỉ để đánh giá các bộ phận kỹ thuật vì phiên bản miễn phí có nhiều tài nguyên hạn chế)

Tại đây bạn có thể kiểm tra bản PDF điểm chuẩn những gì có thể được sử dụng làm tài liệu tham khảo. Dưới đây là hai bài thuyết trình với các ví dụ kỹ thuật hơn: hướng dẫn người giả và các mẹo khác

Tôi không có kinh nghiệm cá nhân với TimeSeries , vì vậy tôi không thể đồng ý rằng đó sẽ là "giải pháp", chỉ là một gợi ý để đánh giá.

Tôi thứ hai khuyến nghị để xem Informix TimeSeries. Tài liệu của IBM tuyên bố TimeSeries có thể lưu trữ loại thông tin này trong 1/5 không gian và thực hiện nhanh gấp 5 lần so với các bảng quan hệ truyền thống.

Các lợi ích bổ sung sẽ là Giao diện bảng ảo có thể làm cho dữ liệu TimeSeries xuất hiện như các bảng quan hệ truyền thống cho người dùng cuối (đơn giản hóa việc phát triển ứng dụng trong khi vẫn nhận được các lợi ích của TimeSeries), HA đơn giản với các nút HDR hiện hỗ trợ dữ liệu TimeSeries trong phiên bản 12.1 và tích hợp dữ liệu TimeSeries vào Bộ gia tốc kho thông tin có thể được sử dụng để tăng tốc các báo cáo kho dữ liệu phức tạp và khả năng tạo nguyên mẫu một giải pháp TimeSeries trong Informix bằng cách sử dụng phiên bản Informix Developer hoặc Innovator-C miễn phí.