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

Tôi cần có khả năng lưu trữ các bit dữ liệu nhỏ (khoảng 50-75 byte) cho hàng tỷ bản ghi (~ 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 tất cả các bản ghi có cùng GUID và khả năng truy cập kho dữ liệu từ .net.

Tôi là một chàng trai máy chủ SQL và tôi nghĩ SQL Server có thể làm được điều này, nhưng với tất cả những gì đã nói về BigTable, CouchDB và các giải pháp nosql khác, nó ngày càng giống một giải pháp thay thế cho RDBS truyền thống có thể là tốt nhất do tối ưu hóa cho 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 tất cả đều có thể thay đổi (cùng với bản thân 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 kho nào đá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, bạn sẽ chọn gì và tại sao?

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

• yêu cầu sẵn có nào bạn có cho điều này? Thời gian hoạt động 99,999% hay là đủ 95%?
• yêu cầu độ tin cậy nào bạn có? Việc thiếu phụ trang có khiến bạn mất 1 triệu đô la không?
• bạn có yêu cầu gì về khả năng phục hồi? Nếu bạn mất một ngày dữ liệu, nó có quan trọng không?
• yêu cầu nhất quán nào bạn có? Bài viết có cần được đảm bảo hiển thị trong lần đọc tiếp theo không?

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

Vì vậy, rõ ràng là bạn đã nới lỏng một số yêu cầu này. Có một hướng dẫn trực quan tuyệt vời 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 Hệ thống NoSQL :

Sau khi cập nhật bình luận OP

Với SQL Server, điều này sẽ được triển khai ngay lập tức:

• một phím nhóm bảng (GUID, thời gian). Có, sẽ bị phân mảnh , nhưng phân mảnh có ảnh hưởng đến quá trình đọc trước hay không và chỉ cần đọc trước cho các lần quét phạm vi quan trọng. Vì bạn chỉ truy vấn GUID và phạm vi ngày cụ thể nên việc phân mảnh sẽ không quan trọng lắm. Có, là một khóa rộng, vì vậy các trang không phải là lá sẽ có mật độ khóa kém. Có, nó sẽ dẫn đến hệ số lấp đầy kém. Và có, có thể xảy ra hiện tượng tách trang. Bất chấp những vấn đề này, với các yêu cầu, vẫn là lựa chọn khóa cụm tốt nhất.
• 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 thông qua cửa sổ trượt tự động . Tăng cường điều này bằng cách xây dựng lại phân vùng chỉ mục trực tuyến của tháng trước để loại bỏ yếu tố lấp đầy kém và phân mảnh được giới thiệu bởi phân nhóm GUID.
• cho phép nén trang. Vì các nhóm khóa được gom lại bởi GUID trước, tất cả các bản ghi của GUID sẽ nằm cạnh nhau, tạo cơ hội tốt cho việc nén trang để 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 để nhật ký theo kịp với 1K lần chèn / giây, vì vậy việc loại bỏ là điều bắt buộc.

Mỗi phân vùng và nén trang đều yêu cầu SQL Server Phiên bản Doanh nghiệp, chúng sẽ không hoạt động trên Phiên bản Tiêu chuẩn và cả hai đều khá quan trọng để đáp ứng các yêu cầu.

Một lưu ý nhỏ là, nếu các bản ghi đến 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 ở back end, tôi sẽ SENDđưa thông tin vào back end, sử dụng kết nối / giao dịch cục bộ trên Express cùng đặt với máy chủ web. Điều này mang lại một câu chuyện về tính khả dụng 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à những vấn đề bạn gặp phải đã đượ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 một người nào đó có thể hiểu rõ hơn về những thứ không-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ững thứ tương tự. Tôi thành thật nghĩ rằng chúng không liên quan trong các đợt 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 thì không quan trọng là tốc độ phát triển nhanh như thế nào, nếu chi phí ORM giết chết hiệu suất :)

Trái ngược 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à sự không phù hợp trở kháng Object-Relational, nhưng cũng là về khả năng mở rộng theo chiều ngang so với khả năng mở rộng theo chiều dọc điển hình hơn của RDBMS.

Đối với yêu cầu đơn giản về chèn nhanh và tra cứu nhanh, hầu hết mọi sản phẩm cơ sở dữ liệu đều sẽ làm được. Nếu bạn muốn thêm dữ liệu quan hệ, hoặc kết hợp, hoặc có bất kỳ ràng buộc hoặc logic giao dịch phức tạp nào bạn cần thực thi, thì bạn cần 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 không toán học, bạn sẽ muốn sử dụng cơ sở dữ liệu hướng tài liệu như MongoDB hoặc CouchDB. Lược đồ rời là bản vẽ chính trong số này; Cá nhân tôi thích MongoDB và sử dụng nó trong một số 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 là các Cửa hàng Giá trị-Khóa phân phối như BigTable hoặc Cassandra. Những điều này đặc biệt hữu ích nếu bạn muốn mở rộng cơ sở dữ liệu của mình trên nhiều máy chạy phần cứng hàng hóa. Rõ ràng là chúng cũng hoạt động tốt trên các máy chủ, nhưng không tận dụng được 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ế để mở rộng theo chiều dọc , và rõ ràng, chúng không có quan hệ và không tốt cho việc thực thi chuẩn hóa hoặc các ràng buộc. Ngoài ra, như bạn đã nhận thấy, hỗ trợ .NET có xu hướng tốt nhất.

Tất cả các sản phẩm cơ sở dữ liệu quan hệ đều hỗ trợ phân vùng có giới hạn. Chúng không linh hoạt như BigTable hoặc các hệ thống DKVS khác, chúng không phân vùng dễ dàng trên hàng trăm máy chủ, nhưng nó thực sự không giống như 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 tính bằ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ó đủ khả năng) và phân vùng trên 2 hoặc 3 hoặc 5 đĩa vật lý nếu 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 công ty và có tiền để chi tiêu cho phần cứng và tối ưu hóa cơ sở dữ liệu tốt, tôi sẽ gắn bó với SQL Server ngay bây giờ. Nếu bạn đang thiếu đồng xu và cần chạy điều này trên phần cứng điện toán đá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).

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

36 tỷ, 3 tỷ mỗi tháng, tức là khoảng 100 triệu mỗi ngày, 4,16 triệu một giờ, ~ 70 nghìn hàng mỗi phút, 1,1 nghìn hàng mỗi giây được đưa vào hệ thống, theo cách duy trì trong 12 tháng, giả sử không có thời gian ngừng hoạt động.

Những con số đó không phải là không thể bởi một biên độ 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 kỹ xem đó có thực sự là số lượng mà bạn muốn - 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 khá quan trọng mà bạn chưa đề cập là làm lão hóa dữ liệu cũ hơn - việc xóa không miễn phí.

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

Tôi cũng gợi ý rằng bạn sẽ cần một ngân sách phần cứng rất phù hợp 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à theo một số phỏng đoán gần đúng, giả sử rất ít lập chỉ mục chung khôn ngoan, khoảng 2,7TB dữ liệu.

Trong trại SQL Server, điều duy nhất 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 để phân tích dữ liệu và chạy các truy vấn song song với nó để cung cấp tốc độ cao cho các bộ dữ liệu lớn.

"Tôi cần có khả năng lưu trữ các bit dữ liệu nhỏ (khoảng 50-75 byte) cho hàng tỷ bản ghi (~ 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 tất cả các bản ghi có cùng một 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 có thể xảy ra trong SQL Server, bởi vì tôi đã thực hiện 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 nhớ rằng đâ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, đó là lưu trữ các bit thông tin bằng GUID và truy xuất bằng GUID một cách nhanh chóng.

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

Vì vậy, câu chuyện ngắn, tôi đã lấy ký tự thứ 8 (tức là ở đâu đó ở giữa) từ chuỗi GUID và SHA1 băm nó và ép kiểu 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 lệnh gọi khi nhận dữ liệu trở lại.

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

Bài viết sau đây thảo luận về việc nhập và sử dụng bảng 16 tỷ hàng trong Microsoft SQL. http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table .

Từ bài báo:

Dưới đây là một số mẹo chắt lọc từ kinh nghiệm của tôi:

• Bạn càng có nhiều dữ liệu trong bảng có chỉ mục được phân nhóm xác định, thì việc nhập các bản ghi chưa được sắp xếp vào đó càng trở nên chậm hơn. Tại một số điểm, nó trở nên quá chậm để trở nên thực tế.
• Nếu bạn muốn xuất bảng của mình sang tệp nhỏ nhất có thể, hãy đặt nó ở định dạng gốc. Điều này hoạt động tốt nhất với các bảng chứa hầu hết các cột số vì chúng được trình bày gọn gàng hơn trong các trường nhị phân hơn là dữ liệu ký tự. Nếu tất cả dữ liệu của bạn là chữ và số, bạn sẽ không thu được nhiều bằng cách xuất nó ở định dạng gốc. Không cho phép giá trị rỗng trong các trường số có thể thu gọn dữ liệu hơn nữa. Nếu bạn cho phép một trường là giá trị rỗng, biểu diễn nhị phân của trường sẽ chứa tiền tố 1 byte cho biết có bao nhiêu byte dữ liệu sẽ theo sau.
• Bạn không thể sử dụng BCP cho hơn 2.147.483.647 bản ghi vì biến bộ đếm BCP là một số nguyên 4 byte. Tôi không thể tìm thấy bất kỳ tham chiếu nào về điều này trên MSDN hoặc Internet. Nếu bảng của bạn bao gồm
  hơn 2.147.483.647 bản ghi, bạn sẽ phải xuất nó thành nhiều phần
  hoặc viết quy trình xuất của riêng bạn.
• Việc xác định một chỉ mục được phân cụm trên một bảng được mô phỏng trước sẽ tốn rất nhiều dung lượng đĩa. Trong thử nghiệm của tôi, nhật ký của tôi đã phát nổ gấp 10 lần
  kích thước bảng ban đầu trước khi hoàn thành.
• Khi nhập một số lượng lớn bản ghi bằng cách sử dụng câu lệnh BULK INSERT, hãy bao gồm tham số BATCHSIZE và chỉ định số lượng
  bản ghi cần cam kết tại một thời điểm. Nếu bạn không bao gồm tham số này,
  toàn bộ tệp của bạn sẽ được nhập dưới dạng một giao dịch duy nhất, điều này
  yêu cầu nhiều không gian nhật ký.
• Cách nhanh nhất để đưa dữ liệu vào bảng có chỉ mục được phân cụm là sắp xếp trước dữ liệu. Sau đó, bạn có thể nhập nó bằng cách sử dụng
  câu lệnh BULK INSERT với tham số ORDER.

Có một sự thật bất thường dường như bị bỏ qua.

" Về cơ bản sau khi chèn 30 triệu hàng trong một ngày, tôi cần tìm nạp tất cả các hàng có cùng một GUID (có thể là 20 hàng) và chắc chắn rằng tôi sẽ lấy lại được tất cả "

Chỉ cần 20 cột, chỉ mục không phân cụm trên GUID sẽ hoạt động tốt. Bạn có thể phân cụ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 như thế nào?

• Đây có phải là sự chèn hàng loạt theo một lịch trình nhất định (mỗi phút, mỗi giờ, v.v.) không?
• 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 mặt của phương trình.

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 vào năm 2010, nhưng bây giờ nó là một người chơi chính trong năm 2017. Đây là 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 tiêu chuẩn sẽ hoạt động 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ổng hợp. Dữ liệu từ một bảng đượ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 khóa phân phối bảng đã xác định, vì vậy bạn dựa vào sức mạnh phân tán của CPU.

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

Bạn có thể thử sử dụng Cassandra hoặc HBase, mặc dù bạn sẽ cần đọc về cách thiết kế các họ cột theo trường hợp sử dụng của bạn. Cassandra cung cấp ngôn ngữ truy vấn riêng 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 bằng Apache Drill từ Map-R, một dự án Mã nguồn mở. Ngôn ngữ truy vấn của Drill là Tuân thủ SQL (các từ khóa trong khoan có cùng ý nghĩa với chúng trong SQL).

Với nhiều bản ghi mỗi năm, bạn cuối cùng sẽ hết dung lượng. Tại sao không lưu trữ hệ thống tệp như xfs hỗ trợ 2 ^ 64 tệp và sử dụng các hộp nhỏ hơn. Bất kể những người ưa thích muốn có được như thế nào hay số tiền cuối cùng người ta sẽ bỏ ra để có được một hệ thống với bất kỳ cơ sở dữ liệu SQL NoSQL nào .. mà nhiều hồ sơ này thường được thực hiện bởi các công ty điện và trạm thời tiết / nhà cung cấp như Bộ Môi trường, những người kiểm soát nhỏ hơn các đài trong cả nước. Nếu bạn đang làm việc gì đó như lưu trữ áp suất .. nhiệt độ..tốc độ gió .. độ ẩm, v.v. và hướng dẫn là vị trí..bạn vẫn có thể chia dữ liệu theo năm / tháng / ngày / giờ. Giả sử bạn lưu trữ 4 năm dữ liệu trên mỗi ổ cứng. Sau đó, bạn có thể để nó chạy trên một Nas nhỏ hơn có gương, nơi nó cũng sẽ cung cấp tốc độ đọc tốt hơn và có nhiều điểm gắn kết .. dựa trên năm khi nó được tạo ra. Bạn có thể chỉ cần tạo một giao diện web cho các tìm kiếm Vì vậy, kết xuất vị trí1 / 2001/06/01 // nhiệt độ và vị trí1 / 2002/06/01 // nhiệt độ sẽ chỉ kết xuất nội dung của nhiệt độ hàng giờ trong ngày đầu tiên của mùa hè trong 2 năm đó (24h * 2) 48 tệp nhỏ so với việc tìm kiếm cơ sở dữ liệu với hàng tỷ bản ghi và có thể hàng triệu tệp đã được chi tiêu. Cách nhìn đơn giản về mọi thứ .. 1,5 tỷ trang web trên thế giới có Chúa mới biết có bao nhiêu trang mỗi trang Nếu một công ty như Google phải chi hàng triệu trên 3 tỷ lượt tìm kiếm để trả tiền cho những siêu máy tính này thì họ sẽ bị phá sản. Thay vào đó, họ có hóa đơn điện ... vài triệu máy tính. Và lập chỉ mục caffein ... chứng minh trong tương lai ... tiếp tục bổ sung thêm. Và đúng vậy, khi lập chỉ mục chạy SQL có ý nghĩa thì tuyệt vời Xây dựng siêu máy tính cho các tác vụ tồi tệ với những thứ cố định như thời tiết ... thống kê, v.v. để các công nghệ có thể khoe khoang hệ thống của họ xử lý xtb trong x giây ... lãng phí tiền có thể đã chi tiêu ở một nơi khác ..

Lưu trữ 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 nhanh hơn thế.

Bạn có thể sử dụng MongoDB và sử dụng hướng dẫn làm phím 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ỉ có trên một máy vì bạn chọn bằng phím sharding.

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