Quét một tỷ hàng trong cơ sở dữ liệu cực nhanh

Lý lịch

Một cơ sở dữ liệu cục bộ chứa gần 1,3 tỷ hàng duy nhất. Mỗi hàng được liên kết gián tiếp với một vĩ độ và kinh độ cụ thể (vị trí). Mỗi hàng có một dấu ngày.

Ca sử dụng

Vấn đề như sau:

1. Người dùng đặt ngày bắt đầu / ngày kết thúc và một phạm vi các giá trị (ví dụ: 100 đến 105).
2. Hệ thống tập hợp tất cả các hàng khớp với ngày đã cho, được nhóm theo vị trí.
3. Hệ thống thực hiện xác định các vị trí, trong những ngày đó, có khả năng thống kê rơi vào phạm vi giá trị nhất định.
4. Hệ thống hiển thị tất cả các vị trí phù hợp với người dùng.

Đây là một vấn đề về tốc độ và quy mô.

Câu hỏi

Kiến trúc giải pháp ít tốn kém nhất bạn có thể tưởng tượng sẽ cho phép một hệ thống như vậy lấy kết quả cho người dùng trong vòng năm giây là gì?

Hệ thống hiện tại

Môi trường hiện tại là:

• PostgreQuery 8.4 (có thể nâng cấp; chuyển đổi cơ sở dữ liệu không phải là một tùy chọn)
• R và PL / R
• XFS
• WD VelociRaptor
• RAM 8 GB (Corsair G.Skill; 1,3 GHz)
• Lõi lõi tứ chính hãng 7 (2,8 GHz)
• Ubuntu 10.10

Nâng cấp phần cứng được chấp nhận.

Cập nhật - Cấu trúc cơ sở dữ liệu

Hàng tỷ hàng nằm trong một bảng giống như:

id | taken | location_id | category | value1 | value2 | value3

• id - Khóa chính
• lấy - Ngày được chỉ định cho hàng
• location_id - Tham chiếu đến vĩ độ / kinh độ
• thể loại - Mô tả dữ liệu
• value1 .. 3 - Các giá trị khác mà người dùng có thể truy vấn

Các takencột thường ngày liên tiếp mỗi location_id, đôi khi mỗi địa điểm có dữ liệu 1800-2010 (khoảng 77.000 ngày, nhiều trong số họ đôi khi mỗi vị trí có dữ liệu trong phạm vi ngày giống nhau).

Có bảy loại và các bảng đã được phân chia theo thể loại (sử dụng bảng con). Mỗi danh mục chứa ~ 190 triệu hàng. Trong tương lai gần, số lượng hàng trên mỗi danh mục sẽ vượt quá một tỷ.

Có khoảng 20.000 địa điểm và 70.000 thành phố. Các vị trí tương quan với thành phố theo vĩ độ và kinh độ. Chỉ định từng vị trí cho một thành phố cụ thể có nghĩa là tìm ranh giới của thành phố, đây không phải là một nhiệm vụ tầm thường.

Ý tưởng

Một số ý tưởng tôi có bao gồm:

• Tìm một dịch vụ đám mây để lưu trữ cơ sở dữ liệu.
• Tạo một sọc đột kích SSD (video tuyệt vời).
• Tạo một bảng kết hợp tất cả các vị trí theo thành phố (tính toán trước).

Cảm ơn bạn!

Điều quan trọng nhất là phải tuyệt đối chắc chắn nơi hiện tại nút cổ chai đối với một số yêu cầu đại diện nhất định vì bạn không thể chuyển đổi cơ sở dữ liệu.

Nếu bạn thực hiện quét toàn bộ bảng, bạn cần các chỉ mục thích hợp.

Nếu bạn đợi trên I / O, bạn cần thêm bộ nhớ để lưu vào bộ đệm (Jeff Atwood gần đây đã đề cập rằng 24 hệ thống Gb có thể truy cập được trên các hệ thống máy tính để bàn).

Nếu bạn đợi CPU, bạn cần xem liệu tính toán của mình có thể được tối ưu hóa hay không.

Điều này đòi hỏi một chiếc mũ DBA nhọn và chiếc mũ Hệ điều hành, nhưng nó đáng để đảm bảo bạn đang sủa đúng cây.

Làm thế nào về việc phân vùng bảng thành nhiều phần nằm trên các máy chủ khác nhau dựa trên dấu ngày? Đây là khả năng mở rộng theo chiều ngang và miễn là bạn có đủ số lượng hộp, bạn có thể viết một công cụ tổng hợp nhỏ trên đầu các thiết lập này.

Nếu bạn thấy tem ngày thay đổi quá nhiều, thì bạn có thể phân vùng dựa trên các vị trí - một lần nữa có thể mở rộng theo chiều ngang. (Hy vọng họ không thêm nhiều vĩ độ / kinh độ nữa!)

Trường hợp xấu nhất là phạm vi ngày bao gồm tất cả các ngày trong cơ sở dữ liệu của bạn.

Bạn đang tìm cách đọc 1,3 tỷ bản ghi và thực hiện một số phân tích trên mỗi bản ghi so với các giá trị được nhập, trên một máy vật lý, trong chưa đầy 5 giây. Kết quả có thể là tất cả các địa điểm hoặc không có gì - bạn không biết gì trước.

Cho những thông số này tôi sẽ nói có khả năng là không thể.

Chỉ cần nhìn vào ổ cứng của bạn: tốc độ duy trì tối đa là dưới 150MB / s. Đọc 1,3 tỷ hồ sơ sẽ mất hơn 5 giây. Thông minh về CPU, bạn sẽ không thể thực hiện bất kỳ loại phân tích thống kê nào trên 1,3 tỷ bản ghi trong 5 giây.

Hy vọng duy nhất của bạn (tm :-)) là tìm kiếm một số loại chức năng tra cứu dựa trên các giá trị được nhập bởi người dùng sẽ thu hẹp tìm kiếm (theo một vài bậc độ lớn). Bạn có thể tính toán chức năng tra cứu này nhé. Không biết thêm về các tiêu chí khớp chính xác, tôi không nghĩ ai có thể cho bạn biết cách thực hiện điều đó nhưng một ví dụ sẽ là phân vùng phạm vi của các giá trị thành một khoảng riêng biệt và tạo một tra cứu cung cấp cho bạn tất cả các bản ghi trong khoảng đó. Miễn là khoảng thời gian đủ nhỏ, bạn có thể thực hiện công việc thực sự trong đó, ví dụ: cắt tỉa các mục không khớp với giá trị đã nhập của người dùng. Về cơ bản không gian giao dịch cho thời gian.

Có thể giữ tất cả các bản ghi (hoặc ít nhất là phần quan trọng) trong bộ nhớ. Có lẽ không phải trong 8GB. Điều này ít nhất sẽ loại bỏ phần I / O của đĩa mặc dù ngay cả băng thông bộ nhớ có thể không đủ để quét qua mọi thứ trong 5 giây. Ở mức độ nào, đây là một kỹ thuật khác để tăng tốc các loại ứng dụng này (kết hợp với đề xuất trước đây của tôi).

Bạn đề cập đến việc sử dụng một dịch vụ đám mây. Có nếu bạn trả đủ CPU và cơ IO và phân vùng cơ sở dữ liệu của bạn trên nhiều máy chủ, bạn có thể bắt buộc / phân chia và chinh phục nó.

Tôi thứ hai nhận xét cho câu hỏi: PostgreSQL cung cấp các loại và công cụ chỉ mục thích hợp (chỉ mục GIST, chỉ mục GIN, Postgis, loại hình học) theo cách mà dữ liệu liên quan đến geodata và datetime có thể tìm kiếm được theo các tiêu chí đó mà không gặp nhiều vấn đề.

Nếu các truy vấn của bạn trên các tiêu chí này mất vài giây, điều đó có thể có nghĩa là không có chỉ mục nào như vậy đang được sử dụng. Bạn có thể xác nhận rằng bạn đã điều tra những điều này là phù hợp?

Nếu bạn sử dụng PostgreSQL và dữ liệu vĩ độ / kinh độ, bạn chắc chắn cũng nên sử dụng PostGIS, theo cách đó bạn có thể thêm chỉ mục không gian GiST vào cơ sở dữ liệu của mình để giúp tăng tốc mọi thứ.

Tôi có một bảng như vậy (với 350 nghìn hàng) với cấu hình nhỏ hơn nhiều so với của bạn (RAM 2 lõi và RAM 2Gb) nhưng các tìm kiếm chỉ mất chưa đến một giây.

Có lẽ bạn có thể phá vỡ một mô hình quan hệ như Essbase đã làm với kiến ​​trúc OLAP của họ: Essbase Wikipedia

Ý tôi là tạo một bảng cho mỗi thành phố, do đó kết thúc với hơn 1000 bảng. Không phải một bảng như bạn đề xuất, nhưng nhiều bảng. Lập chỉ mục mỗi bảng theo ngày và vị trí. Nhiều bảng, nhiều chỉ mục -> nhanh hơn.

Theo như ý tưởng của bạn về việc tìm kiếm một dịch vụ đám mây để lưu trữ cơ sở dữ liệu, bạn đã bắt gặp SimpleGeo chưa? Họ chỉ cắt băng khánh thành dịch vụ Lưu trữ dường như "được điều chỉnh cụ thể để lưu trữ và truy vấn dữ liệu vị trí thực sự rất nhanh" - mặc dù chi phí để lưu trữ và truy vấn đối với hơn một tỷ hàng có thể khiến phương pháp này không khả thi.

bạn đang mong đợi một chiếc xe đạp chạy trên đường cao tốc. Hiện tại bạn đang tìm kiếm một giải pháp để chỉ giải quyết vấn đề này, bạn không thấy trước vấn đề gì nếu bạn có 2 tỷ hồ sơ? khả năng mở rộng phải được giải quyết. Câu trả lời là sử dụng đơn giản cơ sở dữ liệu đối tượng. ví dụ: bộ đệm Intersystems

và tin bạn đi, tôi không đến từ các hệ thống giao nhau ;-)