Câu hỏi Lưu trữ dữ liệu tốt nhất cho hàng tỷ hàng


Tôi cần để có thể lưu trữ các bit dữ liệu nhỏ (khoảng 50-75 byte) cho hàng tỷ hồ sơ (~ 3 tỷ / tháng trong một năm).

Yêu cầu duy nhất là chèn nhanh và tra cứu nhanh cho tất cả các bản ghi với cùng GUID và khả năng truy cập kho dữ liệu từ .net.

Tôi là một máy chủ SQL và tôi nghĩ rằng SQL Server có thể làm điều này, nhưng với tất cả các cuộc nói chuyện về BigTable, CouchDB, và các giải pháp nosql khác, nó nghe nhiều hơn và giống như một thay thế cho một RDBS truyền thống có thể là tốt nhất do tối ưu hóa cho các truy vấn phân tán và mở rộng quy mô. Tôi đã thử cassandra và các thư viện .net hiện không biên dịch hoặc là tất cả có thể thay đổi (cùng với chính cassandra).

Tôi đã xem xét nhiều kho dữ liệu nosql có sẵn, nhưng không thể tìm thấy một cửa hàng đáp ứng nhu cầu của tôi như một nền tảng sẵn sàng sản xuất mạnh mẽ.

Nếu bạn phải lưu trữ 36 tỷ bản ghi nhỏ, phẳng để chúng có thể truy cập từ .net, cái gì sẽ chọn và tại sao?


76
2018-05-08 16:11


gốc


Vâng, số của tôi là chính xác. Hiện tại chúng tôi có rất nhiều dữ liệu được đưa vào hệ thống, nhưng chúng tôi tổng hợp và chỉ lưu trữ tổng số để chúng tôi mất dữ liệu mỗi bản ghi và chỉ duy trì tổng số dữ liệu hàng giờ. Do yêu cầu kinh doanh, chúng tôi muốn duy trì mỗi bản ghi vì nó đã xảy ra ban đầu và đó là 3Bil hàng / tháng. - Jody Powlette
Bạn đã nêu ra một số câu hỏi hay. Câu trả lời là: 95% thời gian là đủ - dữ liệu đã bị trì hoãn một số lượng biến vì vậy tôi sẽ cần phải đồng bộ hóa nó lên sau khi thực tế anyway để được xuống trong một thời gian ngắn không phải là một đối phó breaker. Mất chèn hoặc thậm chí hàng ngàn chèn không phải là kết thúc của thế giới. Mất dữ liệu của một ngày sẽ khá tệ. Tính nhất quán cũng không quan trọng. Về cơ bản sau khi chèn 30Mil hàng trong một ngày, tôi cần phải lấy tất cả các hàng với cùng một GUID (có thể 20 hàng) và được hợp lý chắc chắn tôi muốn có được tất cả trở lại. - Jody Powlette
Bạn có đổ 30M hàng một ngày trong các công việc hàng ngày theo lịch trình / hàng giờ, hoặc họ đi vào một thông lượng liên tục tại một thời điểm? - Remus Rusanu
Dữ liệu đến từ một trang FTP ... các tệp đến liên tục và tôi có một quá trình phân tích các tệp và hiện tại nó tạo dữ liệu tổng hợp và chèn các giá trị tổng hợp (có thể là 1000 hàng) làm giao dịch. Quy trình mới sẽ cần phải chèn hàng trăm nghìn hàng từ mỗi tệp đến, có thể sử dụng chèn hàng loạt sẽ là cách hiệu quả nhất để thực hiện. - Jody Powlette
Điều đó nghe giống như một công việc ETL cho SSIS và SQL Server. Họ giữ kỷ lục thế giới về ETL, với tốc độ tải lên trên 2TB / giờ: blogs.msdn.com/sqlperf/archive/2008/02/27/etl-world-record.aspx - Remus Rusanu


Các câu trả lời:


Lưu trữ ~ 3.5TB dữ liệu và chèn khoảng 1K / giây 24x7 và cũng truy vấn ở tốc độ không được chỉ định, có thể với SQL Server, nhưng có nhiều câu hỏi hơn:

  • bạn có yêu cầu nào về điều này? 99,999% thời gian hoạt động hoặc đủ 95%?
  • bạn có yêu cầu về độ tin cậy nào? Có thiếu một chèn chi phí bạn $ 1M?
  • bạn có yêu cầu phục hồi nào? Nếu bạn mất một ngày dữ liệu, điều đó có quan trọng không?
  • bạn có yêu cầu nhất quán nào? Có viết cần phải được đảm bảo để được hiển thị trên lần đọc tiếp theo?

Nếu bạn cần tất cả các yêu cầu nêu trên, tải trọng bạn đề xuất sẽ tốn hàng triệu phần cứng và cấp phép trên hệ thống quan hệ, bất kỳ hệ thống nào, bất kể mánh lới quảng cáo nào bạn thử (sharding, partitioning etc). Một hệ thống nosql, theo định nghĩa của họ, không đáp ứng tất cả các những yêu cầu này.

Vì vậy, rõ ràng bạn đã thư giãn một số yêu cầu này. Có một hướng dẫn trực quan tốt đẹp so sánh các dịch vụ nosql dựa trên mô hình 'chọn 2 trong số 3' tại Hướng dẫn trực quan cho các hệ thống NoSQL:

nosql comparisson

Sau khi cập nhật nhận xét OP

Với SQL Server, điều này sẽ thực hiện thẳng về phía trước:

  • một cụm bảng duy nhất (GUID, thời gian). Có, sẽ nhận được phân mảnh, nhưng là phân mảnh ảnh hưởng đến đọc-aheads và đọc-aheads là cần thiết chỉ cho quét phạm vi đáng kể. Vì bạn chỉ truy vấn GUID cụ thể và phạm vi ngày, phân mảnh sẽ không quan trọng nhiều. Có, là một chìa khóa rộng, vì vậy các trang không phải lá sẽ có mật độ khóa kém. Có, nó sẽ dẫn đến yếu tố lấp đầy nghèo. Và có, phân chia trang có thể xảy ra. Mặc dù có những vấn đề này, với các yêu cầu, vẫn là lựa chọn quan trọng nhất của nhóm.
  • phân vùng bảng theo thời gian để bạn có thể thực hiện xóa hiệu quả các bản ghi đã hết hạn, qua một cửa sổ trượt tự động. Augment này với một phân vùng chỉ mục trực tuyến xây dựng lại của tháng trước để loại bỏ các yếu tố điền nghèo và phân mảnh giới thiệu bởi các nhóm GUID.
  • cho phép nén trang. Vì các nhóm khóa được nhóm bởi GUID đầu tiên, tất cả các bản ghi của GUID sẽ nằm cạnh nhau, cho nén trang một cơ hội tốt để triển khai nén từ điển.
  • bạn sẽ cần một đường dẫn IO nhanh cho tệp nhật ký. Bạn quan tâm đến thông lượng cao, không phải độ trễ thấp cho nhật ký để theo kịp với 1K chèn / giây, vì vậy tước là phải.

Việc phân vùng và nén trang mỗi yêu cầu một SQL Server Enterprise Edition, chúng sẽ không hoạt động trên Standard Edition và cả hai đều khá quan trọng để đáp ứng các yêu cầu.

Là một lưu ý phụ, nếu các hồ sơ đến từ một trang trại máy chủ Web front-end, tôi sẽ đặt Express trên mỗi máy chủ web và thay vì INSERT ở mặt sau, tôi sẽ SEND thông tin cho phần cuối, sử dụng kết nối / giao dịch cục bộ trên Express cùng với máy chủ web. Điều này mang đến một câu chuyện có sẵn tốt hơn nhiều cho giải pháp.

Vì vậy, đây là cách tôi sẽ làm điều đó trong SQL Server. Tin tốt là các vấn đề bạn sẽ gặp phải cũng được hiểu rõ và các giải pháp được biết đến. điều đó không nhất thiết có nghĩa là điều này tốt hơn những gì bạn có thể đạt được với Cassandra, BigTable hoặc Dynamo. Tôi sẽ cho ai đó biết nhiều hơn về những thứ không có-sql-ish để tranh luận về trường hợp của họ.

Lưu ý rằng tôi chưa bao giờ đề cập đến mô hình lập trình, hỗ trợ .NET và như vậy. Tôi thành thật nghĩ rằng họ không liên quan trong việc triển khai lớn. Chúng tạo ra sự khác biệt rất lớn trong quá trình phát triển, nhưng một khi được triển khai nó không quan trọng sự phát triển nhanh như thế nào, nếu chi phí ORM giết chết hiệu suất :)


94
2018-05-08 17:27



Tôi nóng liên kết trang web của Nathan, nhưng đây không phải là trang trước slashdot;) - Remus Rusanu
@RemusRusanu: nhìn vào di chuyển dba.se. Chỉ để chuẩn bị cho bạn :-) Và +1 - gbn


Trái với niềm tin phổ biến, NoSQL không phải là về hiệu suất, hoặc thậm chí khả năng mở rộng. Nó chủ yếu là về việc giảm thiểu cái gọi là trở kháng đối xứng-quan hệ, mà còn về ngang khả năng mở rộng so với tiêu biểu hơn theo chiều dọc khả năng mở rộng của một RDBMS.

Đối với yêu cầu đơn giản về chèn nhanh và tra cứu nhanh, hầu như mọi sản phẩm cơ sở dữ liệu đều sẽ làm. Nếu bạn muốn thêm dữ liệu quan hệ, hoặc tham gia, hoặc có bất kỳ logic giao dịch phức tạp hoặc các ràng buộc nào bạn cần thực thi, thì bạn muốn có một cơ sở dữ liệu quan hệ. Không có sản phẩm NoSQL nào có thể so sánh được.

Nếu bạn cần dữ liệu schemaless, bạn muốn đi với một cơ sở dữ liệu hướng tài liệu như MongoDB hoặc CouchDB. Giản đồ lỏng lẻo là điểm thu hút chính của các lược đồ này; Cá nhân tôi thích MongoDB và sử dụng nó trong một vài hệ thống báo cáo tùy chỉnh. Tôi thấy nó rất hữu ích khi các yêu cầu dữ liệu liên tục thay đổi.

Tùy chọn NoSQL chính khác được phân phối Các kho khóa-giá trị như BigTable hoặc Cassandra. Đây là đặc biệt hữu ích nếu bạn muốn mở rộng cơ sở dữ liệu của bạn trên nhiều máy chạy phần cứng hàng hóa. Họ làm việc tốt trên máy chủ quá, rõ ràng, nhưng không tận dụng lợi thế của phần cứng cao cấp cũng như SQL Server hoặc Oracle hoặc cơ sở dữ liệu khác được thiết kế cho theo chiều dọc mở rộng quy mô và rõ ràng là chúng không quan hệ và không tốt cho việc thực thi bình thường hóa hoặc các ràng buộc. Ngoài ra, như bạn đã nhận thấy, hỗ trợ .NET có khuynh hướng nổi bật nhất.

Tất cả các sản phẩm cơ sở dữ liệu quan hệ hỗ trợ phân vùng của một loại hạn chế. Chúng không linh hoạt như BigTable hoặc các hệ thống DKVS khác, chúng không dễ dàng phân vùng trên hàng trăm của máy chủ, nhưng nó thực sự không có vẻ như đó là những gì bạn đang tìm kiếm. Chúng khá tốt trong việc xử lý số lượng bản ghi trong hàng tỷ, miễn là bạn lập chỉ mục và chuẩn hóa dữ liệu đúng cách, chạy cơ sở dữ liệu trên phần cứng mạnh mẽ (đặc biệt là SSD nếu bạn có thể đủ khả năng) và phân vùng trên 2 hoặc 3 hoặc 5 đĩa vật lý cần thiết.

Nếu bạn đáp ứng các tiêu chí trên, nếu bạn đang làm việc trong môi trường doanh nghiệp và có tiền để chi tiêu cho phần cứng và tối ưu hóa cơ sở dữ liệu, tôi sẽ gắn bó với SQL Server ngay bây giờ. Nếu bạn đang pinching đồng xu và cần phải chạy điều này trên phần cứng máy tính đám mây Amazon EC2 cấp thấp, bạn có thể muốn chọn Cassandra hoặc Voldemort thay thế (giả sử bạn có thể làm việc với .NET).


15
2018-05-08 17:25





Rất ít người làm việc ở quy mô nhiều tỷ hàng, và hầu hết lần tôi thấy một yêu cầu như thế này trên tràn ngăn xếp, dữ liệu không có nơi gần với kích thước nó đang được báo cáo.

36 tỷ, 3 tỷ mỗi tháng, tức là khoảng 100 triệu đồng mỗi ngày, 4,16 triệu đồng một giờ, ~ 70 nghìn hàng mỗi phút, 1,1k hàng một giây đến vào hệ thống, một cách bền vững trong 12 tháng, giả sử không có thời gian.

Những con số đó không phải là không thể bởi một lề dài, tôi đã thực hiện các hệ thống lớn hơn, nhưng bạn muốn kiểm tra lại rằng đó thực sự là số lượng bạn có ý nghĩa - rất ít ứng dụng thực sự có số lượng này.

Về mặt lưu trữ / truy xuất và một khía cạnh quan trọng mà bạn không đề cập đến là việc già hóa dữ liệu cũ hơn - việc xóa không phải là miễn phí.

Công nghệ thông thường là xem xét phân vùng, tuy nhiên, việc tra cứu / truy xuất là GUID dựa trên sẽ dẫn đến hiệu suất kém, giả sử bạn phải nhận được mọi giá trị khớp trong toàn bộ khoảng thời gian 12 tháng. Bạn có thể đặt một chỉ số nhóm trên cột GUID sẽ nhận được cụm dữ liệu liên quan của bạn để đọc / ghi, nhưng với số lượng và tốc độ chèn, phân mảnh sẽ quá cao để hỗ trợ và nó sẽ rơi xuống sàn.

Tôi cũng sẽ đề nghị rằng bạn sẽ cần một ngân sách phần cứng rất tốt nếu đây là một ứng dụng nghiêm túc với tốc độ phản hồi kiểu OLTP, đó là bởi một số phỏng đoán gần đúng, giả sử rất ít chi phí chỉ mục khôn ngoan, khoảng 2,7 TB dữ liệu.

Trong trại SQL Server, điều duy nhất mà bạn có thể muốn xem là phiên bản kho dữ liệu song song mới (madison) được thiết kế nhiều hơn để loại bỏ dữ liệu và chạy các truy vấn song song với nó để cung cấp tốc độ cao so với các datamarts lớn.


11
2018-05-08 17:10



Trong các tập dữ liệu hàng tỷ tin sinh học không phải là hiếm. Nhưng chúng thường được xử lý trong một thời trang hoàn toàn trực tuyến từ các tệp phẳng. - Erik Garrison
@Erik: để xử lý luồng (nghĩa là chỉ cần phát hiện một số điều kiện nhất định, nhưng không cần phải lưu trữ dữ liệu để truy vấn sau này), chẳng hạn như StreamInsight tốt hơn bất kỳ cơ sở dữ liệu nào microsoft.com/sqlserver/2008/en/us/r2-complex-event.aspx - Remus Rusanu


"Tôi cần để có thể lưu trữ các bit dữ liệu nhỏ (khoảng 50-75 byte) cho hàng tỷ hồ sơ (~ 3 tỷ / tháng trong một năm).

Yêu cầu duy nhất là chèn nhanh và tra cứu nhanh cho tất cả các bản ghi với cùng GUID và khả năng truy cập kho dữ liệu từ .net. "

Tôi có thể nói với bạn từ kinh nghiệm rằng điều này là có thể trong SQL Server, bởi vì tôi đã làm nó vào đầu năm 2009 ... và nó vẫn hoạt động cho đến ngày nay và khá nhanh.

Bảng được phân vùng trong 256 phân vùng, hãy ghi nhớ đây là phiên bản SQL 2005 ... và chúng tôi đã làm chính xác những gì bạn đang nói, và đó là để lưu trữ bit thông tin của GUID và truy xuất bằng GUID một cách nhanh chóng.

Khi tôi rời khỏi, chúng tôi có khoảng 2-3 tỷ bản ghi và việc thu thập dữ liệu vẫn khá tốt (1-2 giây nếu nhận được thông qua giao diện người dùng, hoặc ít hơn nếu sử dụng RDBMS) mặc dù chính sách lưu giữ dữ liệu sắp được khởi tạo.

Vì vậy, dài câu chuyện ngắn, tôi lấy char thứ 8 (tức là một nơi nào đó ở giữa ish) từ chuỗi GUID và SHA1 băm nó và cast như int nhỏ (0-255) và được lưu trữ trong phân vùng thích hợp và sử dụng cùng một chức năng gọi khi nhận được dữ liệu trở lại.

ping tôi nếu bạn cần thêm thông tin ...


2
2018-03-27 19:24





Có một thực tế không bình thường mà dường như bị bỏ qua.

"Về cơ bản sau khi chèn 30Mil hàng trong một ngày, tôi cần phải lấy tất cả các hàng với cùng một GUID (có thể 20 hàng) và được hợp lý chắc chắn tôi muốn có được tất cả trở lại"

Chỉ cần 20 cột, một chỉ mục không nhóm trên GUID sẽ hoạt động tốt. Bạn có thể nhóm trên một cột khác để phân tán dữ liệu trên các phân vùng.

Tôi có một câu hỏi liên quan đến việc chèn dữ liệu: Nó được chèn vào như thế nào?

  • Đây có phải là một số lượng lớn chèn vào một lịch trình nhất định (mỗi phút, mỗi giờ, vv)?
  • Dữ liệu này được lấy từ nguồn nào (tệp phẳng, OLTP, v.v ...)?

Tôi nghĩ rằng những điều này cần phải được trả lời để giúp hiểu một khía cạnh của phương trình.


1
2018-05-09 00:18





Bài viết sau bàn về việc nhập và sử dụng 16 tỷ


1
2018-04-24 19:48





Amazon Redshift là một dịch vụ tuyệt vời. Nó không có sẵn khi câu hỏi ban đầu được đăng trong năm 2010, nhưng bây giờ nó là một cầu thủ lớn vào năm 2017. Nó là một cơ sở dữ liệu dựa trên cột, được phân nhánh từ Postgres, vì vậy các thư viện kết nối SQL và Postgres chuẩn sẽ làm việc với nó.

Nó được sử dụng tốt nhất cho mục đích báo cáo, đặc biệt là tập hợp. Dữ liệu từ một bảng duy nhất được lưu trữ trên các máy chủ khác nhau trong đám mây của Amazon, được phân phối bởi các distkeys bảng đã định nghĩa, do đó bạn dựa vào sức mạnh CPU phân tán.

Vì vậy, các lựa chọn SELECT và đặc biệt là tổng hợp SELECT nhanh như chớp. Việc tải dữ liệu lớn nên được thực hiện tốt nhất với lệnh COPY từ các tệp csv của Amazon S3. Những hạn chế là DELETE và UPDATE chậm hơn bình thường, nhưng đó là lý do tại sao Redshift không phải là cơ sở dữ liệu xuyên quốc gia, mà là một nền tảng kho dữ liệu.


0
2018-02-08 00:31





Bạn có thể thử sử dụng Cassandra hoặc HBase, mặc dù bạn sẽ cần phải đọc về cách thiết kế các họ hàng cột theo trường hợp sử dụng của bạn. Cassandra cung cấp ngôn ngữ truy vấn của riêng nó nhưng bạn cần sử dụng các API Java của HBase để truy cập dữ liệu trực tiếp. Nếu bạn cần sử dụng HBase thì tôi khuyên bạn nên truy vấn dữ liệu với Apache Drill từ Map-R, đó là một dự án mã nguồn mở. Ngôn ngữ truy vấn của Drill là SQL-Compliant (các từ khóa trong khoan có ý nghĩa tương tự như chúng sẽ có trong SQL).


0
2017-08-07 05:21





Lưu trữ các bản ghi trong các tệp nhị phân thuần túy, một tệp cho mỗi GUID, sẽ không nhận được bất kỳ nhanh hơn điều đó.


-2
2018-05-08 16:18



Bạn có thực sự mong đợi điều này để hoạt động tốt không? - ChaosPandion
Yea, tạo hàng tỷ tệp trên hệ thống tệp có thể tàn phá một số hệ thống tệp. Tôi đã phạm sai lầm khi làm một cái gì đó như thế này, nhưng chỉ với 1 triệu và tôi đã lấy khá nhiều hệ thống xuống để cố mở một cái vỏ vào một trong những thư mục đó. Ngoài ra, trừ khi bạn đang tìm kiếm dựa trên một guid, cơ chế truy vấn phải hoạt động như thế nào? - Rob Goodwin
Thật khó để đoán làm thế nào điều này sẽ thực hiện mà không biết có bao nhiêu GUID duy nhất được mong đợi :) Nhưng là không nhận được bất kỳ đơn giản hơn chỉ bằng văn bản cho các tập tin đồng bằng. Và chèn nhanh cùng với tra cứu của GUID là yêu cầu duy nhất. - Thomas Kjørnes
Nó có thể làm việc nhưng bạn phải giới hạn số lượng tệp cho mỗi thư mục. Bạn phải tạo một thư mục mới cho mỗi tệp n. Bạn có thể sử dụng chuỗi con của guid làm tên thư mục. - TTT
có, có một giới hạn về số lượng inodes cho rất nhiều hệ thống tập tin và tôi nhớ đã nhấn giới hạn đó trên redhat hệ thống tập tin mặc định .... giới hạn là khoảng 1.000.000 tập tin hoặc lâu hơn. - Dean Hiller


Bạn có thể sử dụng MongoDB và sử dụng guid làm khóa sharding, điều này có nghĩa là bạn có thể phân phối dữ liệu của mình trên nhiều máy nhưng dữ liệu bạn muốn chọn chỉ trên một máy vì bạn chọn bằng khóa phân tích.

Sharding trong MongoDb chưa được sản xuất sẵn sàng.


-2
2018-05-10 07:32