Tìm kiếm hạt mịn trên một tập dữ liệu lớn

Tôi có khoảng 4 triệu hồ sơ mỗi ngày và phải giữ giá trị trực tuyến 7 năm, vì vậy chúng tôi đang xem xét 10,2 tỷ hồ sơ mà tôi cần để có thể tìm kiếm thông qua. Người dùng đang mong đợi rằng tìm kiếm sẽ đủ nhanh cho giao diện người dùng, kết quả sau 3-5 giây

Do chính trị nằm ngoài tầm kiểm soát của tôi, tôi không thể sử dụng giải pháp cơ sở dữ liệu ngoài kệ vì điều đó có nghĩa là tôi sẽ phải cung cấp cơ sở dữ liệu cho nhóm khác để quản lý (không hỏi) có nghĩa là tôi mất khả năng tối ưu hóa phần cứng và phần mềm vì họ có dịch vụ một kích cỡ phù hợp cho tất cả các cơ sở dữ liệu và tính phí (nội bộ) theo GB. Tôi chắc chắn rằng tôi sẽ nhận được ý kiến ​​đề nghị tôi đưa ra quan điểm, tôi đã có và quản lý hiểu những gì họ đang yêu cầu tôi làm là vô lý.

Tôi đã xem việc sử dụng Lucene là mấu chốt của giải pháp của mình. Lưu trữ dữ liệu thực tế được phân vùng theo loại và theo ngày trong các tệp phẳng. Sau đó, sử dụng tài liệu Lucene để lập chỉ mục một số trường được tìm kiếm theo, với trường "Được lưu trữ" duy nhất là id của bản ghi (để tôi có thể đọc nó từ tệp phẳng)

Tôi không chính xác bám vào Lucene hoặc ổ cứng, nhưng theo sự hiểu biết của tôi, sẽ có IO / thời gian tìm kiếm ban đầu để tìm kiếm chỉ mục, sau đó khi tôi có tất cả ID tài liệu Lucene, tôi đọc các tài liệu sẽ phát sinh thêm IO / tìm kiếm thời gian, sau đó tôi đọc bản ghi thực tế từ căn hộ ... Tôi không thể tưởng tượng được, với kích thước của tập dữ liệu, rằng điều này sẽ rất nhanh, điều mà tôi hơi lo lắng?

Lucene có kích thước tài liệu tối đa là 2,1 tỷ mỗi chỉ mục, vì vậy tôi sẽ yêu cầu nhiều chỉ số ở đây.

Liệu cách tiếp cận này, trên mặt của nó, trông giống như nó có thể làm việc?

Dữ liệu tôi đang lưu trữ là dữ liệu hành động sự kiện. Hầu hết các truy vấn sẽ được nhóm theo id sự kiện và nhận chi tiết hành động sự kiện cuối cùng cho một sự kiện cụ thể. Một số truy vấn sẽ phân tích các sự kiện tập hợp lớn và các hành động sự kiện riêng lẻ của chúng.

Bạn chưa nói dữ liệu lớn như thế nào, các lĩnh vực riêng lẻ lớn như thế nào hoặc ngân sách bạn có.

Bất kể bạn chọn hệ thống lập chỉ mục nào, hãy xem xét việc ném phần cứng vào vấn đề. Bạn không cần phải tìm kiếm các đĩa cho bất cứ điều gì. Lập chỉ mục tất cả dữ liệu, sử dụng sơ đồ rất nhanh để duyệt qua (có thể là danh sách hoặc cây được sắp xếp). Lưu chỉ mục trên đĩa, nhưng sau đó lưu toàn bộ chỉ mục vào RAM. Bạn có thể cần hàng chục, thậm chí hàng trăm gigabyte RAM để làm điều đó.

Nếu các trường riêng lẻ lớn hoặc kích thước thay đổi, hãy xem xét lập chỉ mục băm của chúng.

Giá cho máy chủ để làm điều đó có thể đáng sợ.

Bỏ qua tất cả các chi tiết kỹ thuật đây là một vấn đề tổ chức / quản lý và cần được giải quyết bởi ban quản lý của tổ chức của bạn.

Người quản lý của bạn phải sẵn sàng giải quyết vấn đề ở tầng trên và / hoặc khiến người dùng của anh ta nêu vấn đề ở mức cao.

Ở cấp độ của bạn kết hợp hoặc yêu cầu một ước tính để làm điều này với phần cứng của Oracle và Oracle. Sau đó, đưa ra một ước tính thực tế cho một cụm Hadoop.

Mặc dù sự cường điệu này, các cụm này không hề rẻ (Bạn có thể cần một cái gì đó như 18 nút bộ xử lý với bộ nhớ 64GB và đĩa 4 x 2 TB trải rộng trên ba giá đỡ sau đó thêm 4 nút cho danh mục, v.v.). Đừng đánh giá thấp ; nếu bạn thắng bạn sẽ phải thực hiện nó

Vì vậy, trước tiên, hãy nêu rõ vấn đề theo các yêu cầu của nó:

1. Hệ thống sẽ lưu trữ tối thiểu 4 triệu hồ sơ mỗi ngày.
2. Hệ thống sẽ cung cấp giao diện tìm kiếm cho người dùng
   2.1 Khả năng tìm kiếm sẽ trả về kết quả trong tối đa 3 giây
3. Hệ thống sẽ có khả năng tìm kiếm tối thiểu 10,2 tỷ hồ sơ
4. Hệ thống sẽ sử dụng cơ sở dữ liệu được thiết kế tùy chỉnh
   4.1 Hệ thống sẽ được tối ưu hóa phần cứng và phần mềm cho cơ sở dữ liệu được phát triển

Có thể có các yêu cầu phi chức năng bổ sung, cũng như chi tiết về mức độ lớn của các hồ sơ cá nhân, có thể liên quan đến tình huống của bạn.

Câu trả lời ngắn gọn là bạn có một vấn đề yêu cầu. Nếu bạn xem xét các yêu cầu này, ba trong số chúng (ba đầu tiên) áp dụng chính xác cho hệ thống để xác định chức năng và hành vi của nó. Yêu cầu cuối cùng không phải là một yêu cầu hợp lệ từ quan điểm thuần túy, nhưng tôi đã thấy những loại yêu cầu này được đưa vào tuyên bố công việc.

Vì vậy, cách giải quyết vấn đề này là ước tính chi phí của yêu cầu thứ 4, đưa ra ba yêu cầu còn lại. Một khi bạn làm điều đó, trình bày đó là chi phí giải pháp của bạn. Quản lý sẽ hoảng loạn và ngay lập tức hỏi bạn tại sao vấn đề không thể được giải quyết với giá cả hợp lý. Đó là điểm khởi đầu cho cuộc thảo luận của bạn về những gì cần phải xảy ra. Có một sự thay thế giá cả phải chăng có sẵn và sẵn sàng để trình bày.

Điều này trái ngược với những gì bạn đang làm ngay bây giờ, giả sử ba người kia không thể được đáp ứng cho người cuối cùng. Quản lý không hiểu điều đó, bởi vì tất cả những gì họ thấy là dấu hiệu đồng đô la.

Nếu tôi ở trong đôi giày của bạn, tôi sẽ bắt đầu với việc triển khai cuốn sách rất hợp lý, không sử dụng gì ngoài RDBMS thông thường, được nhúng trong ứng dụng, để họ không cảm thấy như họ phải hỗ trợ một cái gì đó. SQLite, H2 hoặc bất kỳ cơ sở dữ liệu nhúng thay thế nào cũng nên làm: Không có tệp phẳng đặc biệt, không có chỉ mục kỳ lạ, không có gì: chỉ là một ứng dụng đơn giản của các thực tiễn tiêu chuẩn để giải quyết vấn đề, trong phần lớn coi nhẹ tính mênh mông của dữ liệu. (Tất nhiên, tôi sẽ chọn một số nguyên đủ lớn làm khóa và đó là tất cả, khá nhiều.)

Trong khi làm việc với nó, một vài ý tưởng có thể sẽ xảy ra với tôi, như làm thế nào để làm cho nó hoạt động nhanh hơn mà không cần dùng đến bất cứ điều gì kỳ lạ.

Sau đó, tôi sẽ kiểm tra điều này để xem nó hoạt động như thế nào và tôi sẽ chứng minh kết quả, cùng với giải pháp làm việc, với "quyền hạn được" trong tổ chức của bạn.

1. Có khả năng việc triển khai đơn giản của bạn sẽ thực hiện trong các ràng buộc cần thiết, vì vậy bạn sẽ ổn ngay tại đó, không cần phải làm gì khác, không lãng phí tài nguyên.

2. Nếu hiệu suất của việc triển khai đơn giản ở bên ngoài, nhưng không quá xa, các ràng buộc bắt buộc, "quyền hạn" có thể nói "tốt, điều này đủ gần, chúng tôi không muốn làm gì khác về nó, vì vậy đó là những gì nó sẽ được. " Một lần nữa, không có tài nguyên lãng phí.

3. Nếu hiệu suất của việc triển khai đơn giản ở bên ngoài, nhưng trong cùng một mức độ lớn, của các ràng buộc cần thiết, tôi sẽ bảo họ chỉ mua phần cứng tốt hơn, lớn hơn, nhanh hơn. Hầu hết các cơ hội là họ sẽ làm điều đó và trường hợp đóng cửa.

4. Nếu họ không muốn mua phần cứng tốt hơn, lớn hơn, nhanh hơn, thì tôi khuyên họ nên suy nghĩ lại về yêu cầu của mình để không sử dụng RDBMS lớn, có thể mở rộng. Nếu họ hợp lý, và bạn đã cho thấy rằng bạn cũng hợp lý, rất có thể họ sẽ suy nghĩ lại về điều đó.

5. Nếu quyền hạn không muốn theo bất kỳ con đường hợp lý nào, và thay vào đó họ muốn bạn đóng vai trò là một pháp sư, thì và chỉ sau đó tôi mới bắt đầu lo lắng về các giải pháp kỳ lạ. Nhiều cơ hội là, mọi thứ sẽ không đạt đến điểm đó. Nhưng ngay cả khi họ làm, số lượng công việc bạn sẽ làm vô ích cho đến thời điểm đó sẽ tương đối nhỏ, và cũng đáng để đánh cược rằng nó có thể chỉ đủ.

Suy nghĩ từ phía trước ...

Nếu bạn tách các loại tra cứu của mình trong UI, bạn có thể có các ràng buộc hợp lý hơn.

Có vẻ như một loại tra cứu là dữ liệu hành động sự kiện gần đây về một sự kiện, cho phép bạn cách ly theo thời gian trong tìm kiếm dữ liệu của mình. Điều này có lẽ cung cấp một tập hợp dữ liệu nhỏ hơn nhiều, với khả năng người dùng mong đợi rằng nó sẽ được truy xuất sớm.

Các loại tra cứu khác, trong đó tập dữ liệu lớn hoặc tìm kiếm khung thời gian cũ cần được hoàn thành có thể được cung cấp một giao diện người dùng khác (hoặc một số giao diện người dùng), với một công cụ quay vòng đẹp để biểu thị ... suy nghĩ ngay bây giờ. Vì điều này có thể được người dùng hiểu là một tập hợp các yêu cầu tốn nhiều công sức hơn, sự kiên nhẫn có thể được mong đợi một cách hợp lý. Và tất nhiên, thực tế cần thiết.

Tôi không biết liệu bạn có khả năng tác động đến thiết kế trước không, nhưng nếu bạn có thể truyền đạt những hạn chế mà bạn đang làm việc, hy vọng những người xử lý tương tác người dùng sẽ phản hồi bằng sự hiểu biết (ít nhất là một số).