Làm thế nào để lưu trữ 7,3 tỷ hàng dữ liệu thị trường (được tối ưu hóa để đọc)?

Tôi có một tập dữ liệu gồm dữ liệu 1 phút của 1000 cổ phiếu kể từ năm 1998, tổng số đó khoảng (2012-1998)*(365*24*60)*1000 = 7.3 Billioncác hàng.

Hầu hết (99,9%) thời gian tôi sẽ chỉ thực hiện các yêu cầu đọc .

Cách tốt nhất để lưu trữ dữ liệu này trong db là gì?

• 1 bảng lớn có 7,3B hàng?
• 1000 bảng (một bảng cho mỗi ký hiệu chứng khoán) với 7,3 triệu hàng mỗi bảng?
• bất kỳ khuyến nghị của công cụ cơ sở dữ liệu? (Tôi dự định sử dụng Amazon RDS 'MySQL)

Tôi không quen với các tập dữ liệu lớn như vậy, vì vậy đây là một cơ hội tuyệt vời để tôi học hỏi. Tôi sẽ đánh giá cao rất nhiều sự giúp đỡ và lời khuyên của bạn.

Biên tập:

Đây là hàng mẫu:

'XX', 20041208, 938, 43.7444, 43.7541, 43.735, 43.7444, 35116.7, 1, 0, 0

Cột 1 là ký hiệu chứng khoán, cột 2 là ngày, cột 3 là phút, còn lại là giá mở-cao-thấp-đóng cửa, khối lượng và 3 cột số nguyên.

Hầu hết các truy vấn sẽ giống như "Cho tôi biết giá của AAPL từ 12:15 đến 12:52 ngày 12 tháng 4 năm 2012"

Về phần cứng: Tôi dự định sử dụng Amazon RDS vì vậy tôi linh hoạt về điều đó

Cho chúng tôi biết về các truy vấn và môi trường phần cứng của bạn.

Tôi sẽ rất muốn sử dụng NoSQL , sử dụng Hadoop hoặc một cái gì đó tương tự, miễn là bạn có thể tận dụng tính năng song song.

Cập nhật

Được rồi, tại sao?

Trước hết, hãy lưu ý rằng tôi đã hỏi về các truy vấn. Bạn không thể - và chúng tôi chắc chắn không thể - trả lời những câu hỏi này nếu không biết khối lượng công việc như thế nào. (Tình cờ tôi sẽ sớm có một bài báo về vấn đề này, nhưng tôi không thể liên kết nó vào hôm nay.) Nhưng quy mô của vấn đề khiến tôi nghĩ đến việc chuyển khỏi Cơ sở dữ liệu cũ lớn vì

• Kinh nghiệm của tôi với các hệ thống tương tự cho thấy việc truy cập sẽ là tuần tự lớn (tính toán một số loại phân tích chuỗi thời gian) hoặc khai thác dữ liệu rất linh hoạt (OLAP). Dữ liệu tuần tự có thể được xử lý tuần tự tốt hơn và nhanh hơn; OLAP có nghĩa là tính toán rất nhiều và rất nhiều chỉ số, sẽ tốn nhiều thời gian hoặc nhiều không gian.

• Tuy nhiên, nếu bạn đang làm những gì có hiệu quả lớn đối với nhiều dữ liệu trong thế giới OLAP, thì cách tiếp cận theo hướng cột có thể là tốt nhất.

• Nếu bạn muốn thực hiện các truy vấn ngẫu nhiên, đặc biệt là so sánh chéo, hệ thống Hadoop có thể hiệu quả. Tại sao? Bởi vì

  • bạn có thể khai thác tốt hơn tính song song trên phần cứng hàng hóa tương đối nhỏ.
  • bạn cũng có thể triển khai độ tin cậy cao và dự phòng tốt hơn
  • nhiều vấn đề trong số đó tự nhiên trở thành mô hình MapReduce.

Nhưng thực tế là, cho đến khi chúng tôi biết về khối lượng công việc của bạn, chúng tôi không thể nói điều gì dứt khoát.

Vì vậy, cơ sở dữ liệu dành cho các tình huống mà bạn có một lược đồ phức tạp lớn liên tục thay đổi. Bạn chỉ có một "bảng" với đầy đủ các trường số đơn giản. Tôi sẽ làm theo cách này:

Chuẩn bị một cấu trúc C / C ++ để giữ định dạng bản ghi:

struct StockPrice
{
    char ticker_code[2];
    double stock_price;
    timespec when;
    etc
};

Sau đó tính sizeof (StockPrice [N]) trong đó N là số lượng bản ghi. (Trên hệ thống 64-bit) Nó chỉ nên có vài trăm hợp đồng biểu diễn và phù hợp với ổ cứng 50 đô la.

Sau đó, cắt một tệp với kích thước đó và mmap (trên linux, hoặc sử dụng CreateFileMapping trên windows) nó vào bộ nhớ:

//pseduo-code
file = open("my.data", WRITE_ONLY);
truncate(file, sizeof(StockPrice[N]));
void* p = mmap(file, WRITE_ONLY);

Truyền con trỏ mmaped tới StockPrice * và chuyển dữ liệu của bạn vào trong mảng. Đóng mmap và bây giờ bạn sẽ có dữ liệu của mình trong một mảng nhị phân lớn trong một tệp có thể được mmaped lại sau.

StockPrice* stocks = (StockPrice*) p;
for (size_t i = 0; i < N; i++)
{
    stocks[i] = ParseNextStock(stock_indata_file);
}
close(file);

Giờ đây, bạn có thể mmap lại nó ở chế độ chỉ đọc từ bất kỳ chương trình nào và dữ liệu của bạn sẽ sẵn sàng:

file = open("my.data", READ_ONLY);
StockPrice* stocks = (StockPrice*) mmap(file, READ_ONLY);

// do stuff with stocks;

Vì vậy, bây giờ bạn có thể coi nó giống như một mảng cấu trúc trong bộ nhớ. Bạn có thể tạo nhiều loại cấu trúc dữ liệu chỉ mục khác nhau tùy thuộc vào "truy vấn" của bạn là gì. Kernel sẽ xử lý việc trao đổi dữ liệu đến / từ đĩa một cách minh bạch nên nó sẽ cực kỳ nhanh.

Nếu bạn mong đợi có một mẫu truy cập nhất định (ví dụ: ngày liền kề), tốt nhất là sắp xếp mảng theo thứ tự đó để nó sẽ chạm vào đĩa một cách tuần tự.

Tôi có một tập dữ liệu gồm dữ liệu 1 phút của 1000 cổ phiếu [...] hầu hết (99,9%) thời gian tôi sẽ chỉ thực hiện các yêu cầu đọc .

Lưu trữ một lần và đọc nhiều lần dữ liệu số dựa trên thời gian là một trường hợp sử dụng được gọi là "chuỗi thời gian". Các chuỗi thời gian phổ biến khác là dữ liệu cảm biến trong Internet of Things, thống kê giám sát máy chủ, sự kiện ứng dụng, v.v.

Câu hỏi này đã được đặt ra vào năm 2012, và kể từ đó, một số công cụ cơ sở dữ liệu đã phát triển các tính năng đặc biệt để quản lý chuỗi thời gian. Tôi đã có kết quả tuyệt vời với InfluxDB , có nguồn mở, được viết bằng Go và được MIT cấp phép.

InfluxDB đã được tối ưu hóa đặc biệt để lưu trữ và truy vấn dữ liệu chuỗi thời gian. Nhiều hơn thế so với Cassandra , thường được quảng cáo là tuyệt vời để lưu trữ chuỗi thời gian:

Tối ưu hóa cho chuỗi thời gian liên quan đến sự cân bằng nhất định. Ví dụ:

Cập nhật dữ liệu hiện có là điều hiếm khi xảy ra và cập nhật gây tranh cãi không bao giờ xảy ra. Dữ liệu chuỗi thời gian chủ yếu là dữ liệu mới không bao giờ được cập nhật.

Chuyên nghiệp: Hạn chế quyền truy cập vào các bản cập nhật cho phép tăng hiệu suất truy vấn và ghi

Con: Chức năng cập nhật bị hạn chế đáng kể

Trong các điểm chuẩn có nguồn mở ,

InfluxDB vượt trội hơn MongoDB trong cả ba bài kiểm tra với thông lượng ghi lớn hơn 27 lần, trong khi sử dụng ít dung lượng đĩa hơn 84 lần và mang lại hiệu suất tương đối đồng đều khi nói đến tốc độ truy vấn.

Các truy vấn cũng rất đơn giản. Nếu các hàng của bạn trông giống như vậy <symbol, timestamp, open, high, low, close, volume>, với InfluxDB, bạn có thể chỉ lưu trữ hàng đó, sau đó truy vấn dễ dàng. Giả sử, trong 10 phút dữ liệu cuối cùng:

SELECT open, close FROM market_data WHERE symbol = 'AAPL' AND time > '2012-04-12 12:15' AND time < '2012-04-13 12:52'

Không có ID, không có khóa và không có liên kết để thực hiện. Bạn có thể làm rất nhiều tổng hợp thú vị . Bạn không phải phân vùng bảng theo chiều dọc như với PostgreSQL hoặc sắp xếp lược đồ của bạn thành các mảng giây như với MongoDB . Ngoài ra, InfluxDB nén thực sự tốt, trong khi PostgreSQL sẽ không thể thực hiện bất kỳ quá trình nén nào đối với loại dữ liệu bạn có .

Được rồi, vì vậy câu trả lời này hơi khác với các câu trả lời khác, nhưng ... đối với tôi cảm giác như nếu bạn có dữ liệu trong hệ thống tệp (có lẽ là một tệp trên mỗi tệp) với kích thước bản ghi cố định, bạn có thể nhận được dữ liệu thực sự dễ dàng: đưa ra một truy vấn cho một kho và phạm vi thời gian cụ thể, bạn có thể tìm đến đúng nơi, tìm nạp tất cả dữ liệu bạn cần (bạn sẽ biết chính xác bao nhiêu byte), chuyển đổi dữ liệu thành định dạng bạn cần (có thể rất nhanh chóng tùy thuộc vào định dạng lưu trữ của bạn) và bạn đi vắng.

Tôi không biết gì về bộ nhớ Amazon, nhưng nếu bạn không có bất cứ thứ gì như quyền truy cập tệp trực tiếp, về cơ bản bạn có thể có các đốm màu - bạn cần cân bằng các đốm màu lớn (ít bản ghi hơn, nhưng có thể đọc nhiều dữ liệu hơn bạn cần mỗi thời gian) với các đốm màu nhỏ (nhiều bản ghi hơn cung cấp nhiều chi phí hơn và có thể nhiều yêu cầu hơn để nhận chúng, nhưng ít dữ liệu vô ích hơn được trả lại mỗi lần).

Tiếp theo, bạn thêm bộ nhớ đệm - ví dụ, tôi khuyên bạn nên cung cấp cho các máy chủ khác nhau các kho lưu trữ khác nhau để xử lý - và bạn có thể hầu như chỉ phục vụ từ bộ nhớ. Nếu bạn có đủ bộ nhớ trên đủ máy chủ, hãy bỏ qua phần "tải theo yêu cầu" và chỉ tải tất cả các tệp khi khởi động. Điều đó sẽ đơn giản hóa mọi thứ, với chi phí khởi động chậm hơn (rõ ràng là ảnh hưởng đến chuyển đổi dự phòng, trừ khi bạn có đủ khả năng để luôn có hai máy chủ cho bất kỳ cổ phiếu cụ thể nào, điều này sẽ hữu ích).

Lưu ý rằng bạn không cần phải lưu trữ ký hiệu cổ phiếu, ngày hoặc phút cho mỗi bản ghi - bởi vì chúng ẩn trong tệp bạn đang tải và vị trí trong tệp. Bạn cũng nên xem xét độ chính xác bạn cần cho mỗi giá trị và cách lưu trữ hiệu quả - bạn đã đưa ra 6SF trong câu hỏi của mình, bạn có thể lưu trữ trong 20 bit. Có thể lưu trữ ba số nguyên 20 bit trong bộ nhớ 64 bit: đọc nó dưới dạng long(hoặc bất kỳ giá trị số nguyên 64 bit nào của bạn) và sử dụng che / dịch chuyển để đưa nó trở lại ba số nguyên. Tất nhiên, bạn sẽ cần biết quy mô để sử dụng - mà bạn có thể mã hóa trong 4 bit dự phòng, nếu bạn không thể làm cho nó không đổi.

Bạn chưa nói ba cột số nguyên khác như thế nào, nhưng nếu bạn cũng có thể sử dụng 64 bit cho ba cột đó, bạn có thể lưu trữ toàn bộ bản ghi trong 16 byte. Đó chỉ là ~ 110GB cho toàn bộ cơ sở dữ liệu, không thực sự nhiều lắm ...

CHỈNH SỬA: Điều khác cần xem xét là có lẽ cổ phiếu không thay đổi vào cuối tuần - hoặc thực sự là qua đêm. Nếu thị trường chứng khoán chỉ mở cửa 8 giờ mỗi ngày, 5 ngày mỗi tuần, thì bạn chỉ cần 40 giá trị mỗi tuần thay vì 168. Tại thời điểm đó, bạn có thể chỉ có khoảng 28GB dữ liệu trong tệp của mình ... nghe có vẻ vậy nhỏ hơn rất nhiều so với bạn có thể nghĩ ban đầu. Có nhiều dữ liệu trong bộ nhớ là rất hợp lý.

CHỈNH SỬA: Tôi nghĩ rằng tôi đã bỏ qua phần giải thích tại sao cách tiếp cận này phù hợp ở đây: bạn đã có một khía cạnh rất dễ đoán cho một phần lớn dữ liệu của mình - mã chứng khoán, ngày và giờ. Bằng cách thể hiện mã đánh dấu một lần (dưới dạng tên tệp) và để ngày / giờ hoàn toàn ẩn ở vị trí của dữ liệu, bạn đang loại bỏ toàn bộ công việc. Nó hơi giống sự khác biệt giữa a String[]và a Map<Integer, String>- biết rằng chỉ mục mảng của bạn luôn bắt đầu từ 0 và tăng lên theo gia số 1 cho đến chiều dài của mảng cho phép truy cập nhanh và lưu trữ hiệu quả hơn.

Tôi hiểu rằng HDF5 được thiết kế đặc biệt để lưu trữ chuỗi thời gian dữ liệu chứng khoán như một ứng dụng tiềm năng. Các chuyên gia xếp chồng đã chứng minh rằng HDF5 tốt cho một lượng lớn dữ liệu: nhiễm sắc thể , vật lý .

Đây là một nỗ lực để tạo Máy chủ Dữ liệu Thị trường trên cơ sở dữ liệu Microsoft SQL Server 2012 sẽ tốt cho phân tích OLAP, một dự án mã nguồn mở miễn phí:

http://github.com/kriasoft/market-data

Đầu tiên, không có 365 ngày giao dịch trong năm, với 52 ngày nghỉ lễ (104) = giả sử 250 x số giờ thực tế trong ngày thị trường được mở như ai đó đã nói và sử dụng ký hiệu làm khóa chính không phải là ý kiến ​​hay vì các ký hiệu thay đổi, hãy sử dụng k_equity_id (số) với ký hiệu (char) vì các ký hiệu có thể giống như A này hoặc GAC-DB-B.TO, thì bạn có trong bảng dữ liệu thông tin giá, vì vậy ước tính của bạn là 7,3 tỷ lệ được tính là rất lớn vì nó chỉ có khoảng 1,7 triệu hàng trên mỗi biểu tượng trong 14 năm.

k_equity_id k_date k_minute

và đối với bảng EOD (sẽ được xem gấp 1000 lần so với dữ liệu khác)

k_equity_id k_date

Thứ hai, không lưu trữ dữ liệu OHLC theo phút của bạn trong cùng một bảng DB và bảng EOD (cuối ngày), vì bất kỳ ai muốn xem pnf hoặc biểu đồ đường, trong khoảng thời gian một năm, đều không quan tâm đến thông tin phút.

Hãy để tôi khuyên bạn nên xem qua apache solr , mà tôi nghĩ sẽ lý tưởng cho vấn đề cụ thể của bạn. Về cơ bản, trước tiên bạn sẽ lập chỉ mục dữ liệu của mình (mỗi hàng là một "tài liệu"). Solr được tối ưu hóa để tìm kiếm và hỗ trợ nguyên bản các truy vấn phạm vi về ngày tháng. Truy vấn danh nghĩa của bạn,

"Give me the prices of AAPL between April 12 2012 12:15 and April 13 2012 12:52"

sẽ dịch sang một cái gì đó như:

?q=stock:AAPL AND date:[2012-04-12T12:15:00Z TO 2012-04-13T12:52:00Z]

Giả sử "cổ phiếu" là tên cổ phiếu và "ngày" là "Trường ngày" được tạo từ cột "ngày" và "phút" trong dữ liệu đầu vào của bạn khi lập chỉ mục. Solr cực kỳ linh hoạt và tôi thực sự không thể nói đủ điều tốt về nó. Vì vậy, ví dụ: nếu bạn cần duy trì các trường trong dữ liệu gốc, bạn có thể tìm cách tạo động "DateField" như một phần của truy vấn (hoặc bộ lọc).

Tôi nghĩ rằng bất kỳ RDBMS lớn nào cũng sẽ xử lý điều này. Ở cấp độ nguyên tử, một bảng có phân vùng chính xác có vẻ hợp lý (phân vùng dựa trên việc sử dụng dữ liệu của bạn nếu được sửa - đây có thể là ký hiệu hoặc ngày tháng).

Bạn cũng có thể xem xét việc xây dựng các bảng tổng hợp để truy cập nhanh hơn ở cấp độ nguyên tử. Ví dụ: nếu dữ liệu của bạn là ngày, nhưng bạn thường nhận lại dữ liệu ở cấp độ wekk hoặc thậm chí theo tháng, thì điều này có thể được tính trước trong bảng tổng hợp. Trong một số cơ sở dữ liệu, điều này có thể được thực hiện thông qua một chế độ xem được lưu trong bộ nhớ cache (nhiều tên khác nhau cho các giải pháp DB khác nhau - nhưng về cơ bản thì chế độ xem của nó trên dữ liệu nguyên tử, nhưng khi chạy chế độ xem được lưu trong bộ nhớ cache / cứng thành một bảng tạm thời cố định - được truy vấn cho các truy vấn kết hợp tiếp theo . Điều này có thể được bỏ trong khoảng thời gian để giải phóng bộ nhớ / không gian đĩa).

Tôi đoán chúng tôi có thể giúp bạn nhiều hơn với một số ý tưởng về việc sử dụng dữ liệu.

Bạn nên so sánh các giải pháp chậm với một mô hình bộ nhớ được tối ưu hóa đơn giản. Giải nén nó phù hợp với một máy chủ ram 256 GB. Một ảnh chụp nhanh vừa vặn với 32 K và bạn chỉ cần lập chỉ mục nó theo vị trí trên ngày giờ và cổ phiếu. Sau đó, bạn có thể tạo các ảnh chụp nhanh chuyên biệt, vì mở của một thường bằng với đóng của trước đó.

[sửa] Bạn nghĩ tại sao sử dụng cơ sở dữ liệu (rdbms hoặc nosql) là hợp lý? Dữ liệu này không thay đổi và nó nằm gọn trong bộ nhớ. Đó không phải là một trường hợp sử dụng mà một dbms có thể thêm giá trị.

Nếu bạn có phần cứng, tôi khuyên bạn nên sử dụng MySQL Cluster . Bạn nhận được giao diện MySQL / RDBMS mà bạn đã quá quen thuộc, đồng thời ghi nhanh và song song. Đọc sẽ chậm hơn MySQL thông thường do độ trễ của mạng, nhưng bạn có lợi thế là có thể song song các truy vấn và đọc do cách MySQL Cluster và công cụ lưu trữ NDB hoạt động.

Đảm bảo rằng bạn có đủ máy MySQL Cluster và đủ bộ nhớ / RAM cho mỗi máy - MySQL Cluster là một kiến ​​trúc cơ sở dữ liệu hướng bộ nhớ nhiều.

Hoặc Redis , nếu bạn không bận tâm đến giao diện khóa-giá trị / NoSQL cho việc đọc / ghi của bạn. Đảm bảo rằng Redis có đủ bộ nhớ - đọc và ghi siêu nhanh, bạn có thể thực hiện các truy vấn cơ bản với nó (mặc dù không phải RDBMS) nhưng cũng là một cơ sở dữ liệu trong bộ nhớ.

Giống như những người khác đã nói, biết thêm về các truy vấn bạn sẽ chạy sẽ có ích.

Bạn sẽ muốn dữ liệu được lưu trữ trong một bảng / cơ sở dữ liệu cột . Các hệ thống cơ sở dữ liệu như Vertica và Greenplum là cơ sở dữ liệu dạng cột và tôi tin rằng SQL Server hiện cho phép các bảng dạng cột. Chúng cực kỳ hiệu quả choSELECT từ các tập dữ liệu rất lớn. Chúng cũng hiệu quả trong việc nhập các tập dữ liệu lớn.

Một cơ sở dữ liệu cột miễn phí là MonetDB .

Nếu trường hợp sử dụng của bạn là đọc các hàng đơn giản mà không cần tổng hợp, bạn có thể sử dụng cụm Aerospike. Nó nằm trong cơ sở dữ liệu bộ nhớ với sự hỗ trợ của hệ thống tệp để hoạt động bền bỉ. Nó cũng được tối ưu hóa SSD.

Nếu trường hợp sử dụng của bạn cần dữ liệu tổng hợp, hãy sử dụng cụm Mongo DB với phân biệt phạm vi ngày. Bạn có thể dữ liệu năm câu lạc bộ trong các phân đoạn.