Thời báo: SQL hay NoQuery?


33

Tôi không quan tâm đến sự khác biệt chung giữa SQL và NoQuery (hoặc sự khác biệt truyền thống của chúng).

Tôi hiện đang xem xét việc thay đổi lưu trữ của chuỗi thời gian nội bộ của chúng tôi. Chúng đều chứa dữ liệu tài chính từ một số nguồn khác nhau. Hiện tại, chúng tôi đang lưu trữ dữ liệu của mình trong cơ sở dữ liệu độc quyền. Nó rất nhiều NoQuery, có ngôn ngữ truy vấn riêng.

Tôi quan tâm đến đầu vào của cộng đồng: Bạn sẽ lưu trữ dữ liệu trong cơ sở dữ liệu SQL như thế nào? Có những ưu điểm gì khi sử dụng SQL qua NoQuery, đặc biệt cho chuỗi thời gian? Tôi có điên không khi xem xét việc lưu trữ này trong SQL?

Tập dữ liệu của chúng tôi bao gồm hàng triệu chuỗi thời gian, với khoảng 10% trong số này chứa hàng triệu bản ghi mỗi. Chuỗi thời gian được sắp xếp theo thứ bậc: / Thị trường / Công cụ / Giá trị / Tần suất, trong đó:

  • Thị trường là một sàn giao dịch chứng khoán, vv, về cơ bản là một bộ sưu tập các công cụ, thường là các công cụ tương tự.
  • Nhạc cụ là một nhạc cụ. Đây có thể là một chỉ số (Brent thô), vốn chủ sở hữu (GOOG), v.v.
  • Giá trị là một trong nhiều loại dữ liệu cho một công cụ. Đây có thể là một gần, cao, thấp, vv
  • Tần số là tần số của một giá trị chuỗi thời gian cụ thể. Hàng tuần, hàng ngày, hàng tháng, đánh dấu, tùy ý, vv

Làm thế nào dữ liệu sẽ được lưu trữ trong một db SQL? Một bảng lớn (có thể được phân vùng bởi một cái gì đó), một bảng cho mỗi thị trường hoặc công cụ, một bảng cho mỗi chuỗi thời gian.

Cảm ơn bạn trước.


1
Tất cả các chuỗi thời gian có chứa cùng một siêu dữ liệu (tức là các cột) không?
Jack Douglas

1
Âm thanh giống như một kho dữ liệu ... Xem phần này trên SO: stackoverflow.com/q/2684462/27535
gbn

@ jack-douecraft: Bạn có yêu cầu đề xuất lưu trữ dữ liệu theo định hướng cột không?
Nicolas

3
@Nicolas Không có dự đoán của tôi là RDBMS SQL truyền thống sẽ phù hợp với dữ liệu của bạn bởi vì a) sẽ dễ truy vấn hơn, b) âm lượng không có âm thanh lớn (hàng tỷ hàng?) C) / hoặc các tính năng OLAP tiêu chuẩn. Tôi đã hỏi về siêu dữ liệu để xác định bạn cần bao nhiêu bảng. Nếu mỗi chuỗi thời gian có siêu dữ liệu duy nhất, bạn cần hàng triệu bảng có vẻ không phải là ý tưởng hay trên RDBMS thông thường, nhưng tôi không nghĩ bạn cần điều đó, phải không?
Jack Douglas

2
@Nicolas bạn đã xem xét trình kết nối Hadoop mới cho SQL Server . Nhìn bề ngoài, kịch bản của bạn có vẻ phù hợp.
Mark Storey-Smith

Câu trả lời:


26

Nói chung, đối với một tập dữ liệu có cấu trúc như vậy, tôi nghi ngờ bạn có thể viết một định dạng dữ liệu tùy chỉnh nhanh hơn cho hầu hết các hoạt động hàng ngày (tức là dữ liệu nhỏ kéo từ thời gian tùy ý). Lợi ích của việc chuyển sang một công cụ DB tiêu chuẩn có thể có trong một số tính năng bổ sung, ví dụ như các truy vấn đặc biệt, nhiều truy cập, sao chép, tính khả dụng, v.v ... Việc thuê trợ giúp để duy trì một kho lưu trữ dữ liệu dựa trên tiêu chuẩn cũng dễ dàng hơn.

Nếu tôi được yêu cầu thiết lập cơ sở dữ liệu để lưu trữ dữ liệu đó, tôi sẽ làm như sau:

Lược đồ đề xuất

(1) Dữ liệu cốt lõi được đặt vào nhiều (1000)) các bảng riêng lẻ, mỗi bảng chứa hai cột:

  1. thời gian: có thể là kiểu dữ liệu SQL DATETIME hoặc kiểu số từ một số epoch (đây là khóa chính)
  2. value: gõ như phù hợp với dữ liệu của bạn. Tôi sẽ mặc định là float chính xác duy nhất, tuy nhiên loại dữ liệu điểm cố định có thể phù hợp hơn cho các giao dịch tài chính. Điều này có lẽ là không được hiểu.

Các bảng này sẽ trở nên khá lớn và bạn có thể muốn phân vùng chúng theo cách thủ công theo (ví dụ) năm. Nhưng bạn sẽ phải kiểm tra hiệu năng hệ thống và điều chỉnh cho phù hợp.

Các bảng này cần tên duy nhất và có một vài tùy chọn. Chúng có thể là con người có thể đọc được (ví dụ: nyse_goog_dailyhighs_2010) hoặc (sở thích của tôi) ngẫu nhiên. Dù bằng cách nào, một tập hợp các bảng siêu dữ liệu là bắt buộc và tên bảng ngẫu nhiên ngăn các nhà phát triển suy luận bất cứ điều gì vào tên mà không có nghĩa là được suy ra.

(2) Dữ liệu meta được lưu trữ trong các bảng riêng biệt, theo yêu cầu của ứng dụng :

Cần có một bảng hoặc bộ bảng bổ sung để theo dõi siêu dữ liệu. Các bảng này sẽ chứa dữ liệu về trao đổi, công cụ, giá trị, tần suất, phạm vi ngày, xuất xứ (dữ liệu đến từ đâu), cộng với bất cứ thứ gì bạn cần. Chúng được ánh xạ tới tên bảng dữ liệu.

Nếu có đủ dữ liệu, việc tra cứu này thực sự có thể cung cấp tên bảng và tên cơ sở dữ liệu, cho phép một loại bảo vệ dữ liệu tự thực hiện (nếu đó là cách sử dụng đúng thuật ngữ). Nhưng tôi sẽ giữ nó trong dự trữ.

Sau đó, ở lớp ứng dụng, tôi sẽ truy vấn các bảng siêu dữ liệu để xác định vị trí của dữ liệu của mình và sau đó thực hiện các truy vấn tương đối đơn giản trên các bảng dữ liệu lớn để lấy dữ liệu của tôi.

Ưu điểm:

  • Kinh nghiệm (tương đối hạn chế) của tôi là cơ sở dữ liệu thường có thể xử lý một số lượng lớn các bảng nhỏ dễ dàng hơn một số lượng nhỏ các bảng lớn. Cách tiếp cận này cũng cho phép bảo trì dễ dàng hơn (ví dụ: xóa dữ liệu cũ, xây dựng lại bảng bị hỏng, tạo / tải lại từ bản sao lưu, thêm một thực thể mới). Điều này hoàn toàn tách rời các loại dữ liệu khác nhau, nếu (ví dụ) bạn có dữ liệu ở các mức khác nhau hoặc yêu cầu các loại dữ liệu khác nhau.

  • Khái niệm bảng mỏng này cũng sẽ cho phép truy cập đĩa nhanh cho những gì tôi nghi ngờ là truy vấn phổ biến nhất, một phạm vi dữ liệu liền kề từ một thực thể duy nhất. Hầu hết các ứng dụng dữ liệu là I / O đĩa giới hạn, vì vậy điều này đáng để xem xét. Như một nhà bình luận đã ngụ ý, đây là một ứng dụng lý tưởng cho cơ sở dữ liệu hướng theo cột, nhưng tôi vẫn chưa tìm thấy một sản phẩm hướng cột nào đủ để tôi đặt cược sự nghiệp của mình. Lược đồ này trở nên khá gần.

Nhược điểm:

  • Khoảng một nửa dung lượng ổ đĩa của bạn được dành riêng để lưu trữ tem thời gian, khi thực sự 100 hoặc 1000 bảng sẽ có cùng dữ liệu chính xác trong cột dấu thời gian. (Trong thực tế đây là một yêu cầu nếu bạn muốn thực hiện các phép nối bảng dễ dàng).

  • Lưu trữ tên bảng và thực hiện tra cứu động đòi hỏi rất nhiều sự phức tạp của ứng dụng và các thao tác chuỗi, loại này làm cho tôi co rúm lại. Nhưng nó vẫn có vẻ tốt hơn so với các lựa chọn thay thế (thảo luận dưới đây).

Cân nhắc:

  • Hãy cẩn thận làm tròn trong lĩnh vực thời gian của bạn. Bạn muốn các giá trị của mình đủ tròn để kích hoạt các phép nối (nếu phù hợp), nhưng đủ chính xác để không mơ hồ.

  • Hãy cẩn thận về múi giờ và thời gian tiết kiệm ánh sáng ban ngày. Đây là những khó khăn để kiểm tra. Tôi sẽ thực thi một yêu cầu UTC trên kho lưu trữ dữ liệu (có thể khiến tôi không phổ biến) và xử lý các chuyển đổi trong ứng dụng.

Biến thể:

Một số biến thể mà tôi đã xem xét là:

Gấp dữ liệu: Nếu các mốc thời gian cách đều nhau, thì hãy sử dụng một cột dấu thời gian và (ví dụ) 10 cột dữ liệu. Dấu thời gian bây giờ đề cập đến thời gian của cột dữ liệu đầu tiên và các cột dữ liệu được giả định cách đều nhau giữa dấu thời gian đó và cột tiếp theo. Điều này giúp tiết kiệm rất nhiều dung lượng lưu trữ trước đây được sử dụng để lưu trữ dấu thời gian, với chi phí truy vấn đáng kể và / hoặc độ phức tạp của ứng dụng. Phạm vi tiếp giáp, các truy vấn thực thể duy nhất hiện yêu cầu truy cập đĩa ít hơn.

Đa luồng: Nếu biết nhiều chuỗi thời gian sử dụng cùng một chuỗi thời gian, thì hãy sử dụng một dấu thời gian và (ví dụ) 10 cột dữ liệu như được mô tả ở trên. Nhưng bây giờ mỗi cột đại diện cho một chuỗi thời gian khác nhau. Điều này đòi hỏi phải cập nhật bảng siêu dữ liệu, đây không phải là tra cứu tên bảng và tên cột. Không gian lưu trữ được giảm. Truy vấn vẫn đơn giản. Tuy nhiên, phạm vi liền kề, các truy vấn thực thể đơn lẻ hiện yêu cầu truy cập đĩa nhiều hơn đáng kể.

Bảng Mega: Đưa khái niệm "đa plexing" đến mức cực đoan và đặt tất cả dữ liệu vào một bảng duy nhất, một lần chuỗi thời gian trên mỗi cột. Điều này đòi hỏi một lượng lớn truy cập đĩa cho phạm vi liền kề, các truy vấn thực thể đơn lẻ và là một cơn ác mộng bảo trì. Ví dụ: thêm một thực thể mới bây giờ yêu cầu lệnh MODIFY TABLE trên bảng nhiều TB.

Để thảo luận thêm về định dạng này, hãy xem các câu trả lời khác nhau trong: Quá nhiều cột trong MySQL

Bảng được chuẩn hóa hoàn toàn: Thay vì sử dụng nhiều bảng 2 cột, bạn có thể sử dụng bảng một, ba cột, trong đó các cột là thời gian, dữ liệu và giá trị. Bây giờ các bảng siêu dữ liệu của bạn chỉ cần tra cứu các giá trị ID, thay vì các tên tab hoặc tên cột, cho phép đẩy nhiều logic hơn vào các truy vấn SQL, thay vì lớp ứng dụng.

Khoảng 2/3 Dung lượng hiện được sử dụng với các cột chuẩn hóa, do đó, điều này sẽ sử dụng rất nhiều dung lượng đĩa.

Bạn có thể sử dụng một thứ tự khóa chính là (dataid, dấu thời gian) cho các truy vấn thực thể đơn lẻ, liền kề nhanh. Hoặc, bạn có thể sử dụng thứ tự khóa chính là (dấu thời gian. Dataid) để chèn nhanh hơn.

Tuy nhiên, ngay cả sau khi xem xét các biến thể này, kế hoạch cho sự phát triển tiếp theo của tôi là rất nhiều bảng, mỗi cột có hai cột. Điều đó, hoặc phương pháp sẽ sớm được đăng bởi một người khôn ngoan hơn tôi :).


Cảm ơn bạn rất nhiều vì câu trả lời của bạn. Bạn đã nêu ra một số điểm rất hợp lệ. Tôi hoàn toàn đồng ý với việc lưu trữ trong UTC. Tôi đang thực thi ý tưởng rằng tất cả dữ liệu được gửi đến các mặt trận (web, máy tính để bàn và thiết bị di động) trong UTC. Chúng tôi có khách hàng đa quốc gia và HĐH phải chịu trách nhiệm thực hiện chuyển đổi thời gian. Tôi có một công ty DBA làm việc trên toàn bộ tập dữ liệu của chúng tôi và tự hỏi những gì người khác sẽ nghĩ ra. Cảm ơn một lần nữa.
Nicolas

Trong khi các chuyên gia tư vấn DBA làm việc nhắm mục tiêu cài đặt SQL Server, tôi sẽ tiếp tục thử nghiệm với thiết lập BigData.
Nicolas

Có thể đây là một giải pháp tốt nhưng ứng dụng "chuỗi thời gian" thực sự sẽ hỗ trợ chức năng "phóng to dữ liệu" và cơ sở dữ liệu không thể giúp được điều đó. Cơ sở dữ liệu chuỗi thời gian là nhiều hơn về "phóng to" và "thu nhỏ" thông minh.
Roman Pokrovskij

1

Sử dụng MongoDB, bạn có thể tạo các bộ sưu tập nhanh chóng. Nhìn vào việc sắp xếp dữ liệu của bạn vào các cơ sở dữ liệu riêng biệt và các bộ sưu tập trong các cơ sở dữ liệu đó. Xem xét dung lượng bộ nhớ bạn cần cố gắng giữ mỗi phân đoạn trong bộ nhớ hệ thống - nếu bạn cần truy xuất nhanh. Ngớ ngẩn để gắn bó với một giải pháp trong nhà, nếu có một cái gì đó tươi hơn ngoài kia sẽ phát triển theo các dòng bạn cần. Âm thanh như một sáng kiến ​​tốt.


2
Làm thế nào bạn sẽ lưu trữ chuỗi thời gian trong Mongo? Mỗi tài liệu là một serie thời gian? hoặc giá trị của dấu thời gian cụ thể?
RockScience

Để thực hiện điều này một cách hiệu quả đối với dữ liệu không định kỳ hoặc thậm chí định kỳ, tốt nhất là phân bổ trước các khối dữ liệu. Mỗi đoạn sẽ là một tài liệu với một lượng nhỏ dữ liệu sổ sách, một mảng có kích thước cố định cho các giá trị của bạn và một mảng có kích thước cố định cho thời gian của bạn. Sau đó, bạn sẽ lưu trữ siêu dữ liệu của mình cho chuỗi trong một tài liệu riêng biệt. Trong tài liệu siêu dữ liệu này, hãy duy trì một tài liệu lồng nhau nhỏ sẽ đóng vai trò là người giữ sổ sách cho các phân đoạn dữ liệu của bạn, tức là theo dõi chỉ số mảng hiện tại và phân đoạn _id.
RYS
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.