Việc đặt tên bảng september_2010 có thể chấp nhận và hiệu quả đối với các tập dữ liệu lớn phụ thuộc vào thời gian không?

Question

Tôi cần lưu trữ khoảng 73.200 bản ghi mỗi ngày bao gồm 3 điểm dữ liệu: id, ngày và số nguyên.

Một số thành viên trong nhóm của tôi khuyên bạn nên tạo bảng bằng tháng như tên bảng (september_2010), trong khi những người khác đang đề xuất có một bảng với rất nhiều dữ liệu trong nó ...

Bất kỳ đề xuất về cách đối phó với điều này Số lượng dữ liệu? Cảm ơn.

========== Cảm ơn tất cả các phản hồi.

Answer 1

Tôi khuyên bạn nên chống đó. Tôi gọi đây là antipatternDải siêu dữ liệu. Nó tạo ra nhiều sự cố:

• Bạn cần nhớ tạo bảng mới mỗi năm nếu ứng dụng của bạn bị hỏng.
• Truy vấn tổng hợp chống lại tất cả các hàng bất kể năm nào khó hơn.
• Cập nhật ngày có khả năng có nghĩa là di chuyển hàng từ bảng này sang bảng khác.
• Sẽ khó hơn để đảm bảo tính duy nhất của các giả trên nhiều bảng.

Đề xuất của tôi là giữ nó trong một bảng cho đến khi và trừ khi bạn đã chứng minh rằng kích thước của bảng đang trở thành vấn đề chính hãng và bạn không thể giải quyết nó theo cách khác (ví dụ: bộ nhớ đệm, lập chỉ mục, phân vùng).

Answer 2

Phụ thuộc vào những tìm kiếm bạn cần thực hiện. Nếu thường bị hạn chế bởi ngày tháng, việc chia tách là tốt.

Nếu bạn chia nhỏ, hãy xem xét đặt tên cho các bảng như foo_2010_09 để các bảng sẽ sắp xếp chữ và số.

Answer 3

Có vẻ như chỉ nên giữ mọi thứ trong một bảng. Nó sẽ làm cho việc thu hồi dễ dàng hơn nhiều trong tương lai để duy trì 1 bảng, trái với 12 bảng mỗi năm. Với 73.200 bản ghi mỗi ngày, bạn sẽ mất gần 4 năm để đạt được 100.000.000 bản ghi vẫn còn trong khả năng của MySQL.

Answer 4

nền tảng DB của bạn là gì?

Trong SQL Server 2K5 + bạn có thể phân vùng vào ngày.

Tệ, tôi không nhận thấy thẻ. @thetaiko là đúng mặc dù và điều này là tốt trong khả năng của MySQL để đối phó với điều này.

Answer 5

Tôi sẽ nói điều đó phụ thuộc vào cách dữ liệu được sử dụng. Nếu hầu hết các truy vấn được thực hiện trên dữ liệu hoàn chỉnh, nó sẽ là một chi phí để luôn luôn tham gia các bảng trở lại với nhau một lần nữa. Nếu bạn hầu hết thời gian chỉ cần một phần dữ liệu (theo ngày), bạn nên phân đoạn các bảng thành các phần nhỏ hơn.

Để đặt tên, tôi sẽ thực hiện tablename_yyyymm.

Chỉnh sửa: Để chắc chắn bạn cũng nên suy nghĩ về một lớp khác giữa DB và ứng dụng của bạn để xử lý các bảng được phân đoạn tùy thuộc vào một số ngày nhất định. Mà sau đó có thể nhận được khá phức tạp.

Answer 6

Tuyệt đối không.
Nó sẽ làm hỏng mối quan hệ giữa các bảng.
Quan hệ bảng được xây dựng dựa trên trường giá trị, không phải tên bảng.

Đặc biệt đối với bảng này rất rằng sẽ tăng chỉ 300MB/năm

Answer 7

Một số thành viên trong nhóm của tôi khuyên bạn nên tạo bảng bằng tháng như tên bảng (september_2010), trong khi những người khác đang đề xuất có một bảng với rất nhiều dữ liệu trong nó ...

Đừng nghe đối với họ. Bạn đã lưu trữ một con dấu ngày, những tháng khác nhau làm cho nó là một ý tưởng tốt để chia dữ liệu theo cách đó? Động cơ sẽ xử lý các tập dữ liệu lớn hơn tốt, do đó, chia tách theo tháng không có gì ngoài việc tách riêng dữ liệu một cách giả tạo.

Answer 8

vì vậy trong 100 ngày bạn có 7,3 M hàng, khoảng 25 triệu mỗi năm hoặc lâu hơn. 25 triệu hàng không còn nữa. MySQL có thể xử lý các bảng với hàng triệu hàng. Nó thực sự phụ thuộc vào phần cứng của bạn và các loại truy vấn của bạn và tần suất truy vấn.

Nhưng bạn sẽ có thể phân vùng bảng đó (nếu MySQL hỗ trợ phân vùng), những gì bạn mô tả là một phương pháp phân vùng SQL Server cũ. Sau khi xây dựng các bảng hàng tháng, bạn xây dựng một khung nhìn kết hợp chúng lại với nhau để trông giống như một bảng lớn ... mà về bản chất phân vùng là gì nhưng tất cả đều nằm trong phạm vi phủ đầy và được tối ưu hóa hoàn toàn.

Answer 9

Thông thường điều này tạo ra nhiều rắc rối hơn giá trị của nó, nó bảo trì nhiều hơn, truy vấn của bạn cần logic hơn và thật khó để lấy dữ liệu từ nhiều hơn một khoảng thời gian.

Chúng tôi lưu trữ 200 triệu bản ghi dựa trên thời gian trong một bảng (MyISAM) và truy vấn vẫn rất nhanh. Bạn chỉ cần đảm bảo có chỉ mục trên cột thời gian/ngày và truy vấn của bạn sử dụng chỉ mục (ví dụ: truy vấn lộn xộn xung quanh với DATE_FORMAT hoặc tương tự trên cột ngày có thể sẽ không sử dụng chỉ mục.

Một điều rất đau đớn với số lượng bản ghi lớn như vậy là khi bạn phải xóa dữ liệu cũ, quá trình này có thể mất nhiều thời gian (10 vì lý do đó chúng tôi đã partitioning các bảng và sử dụng một time_dimension (xem ví dụ bảng time_dimension một chút xuống here) bảng quan hệ để quản lý các giai đoạn thay vì sim cột ngày/datetime/chuỗi hoặc varchars đại diện cho ngày tháng.

Answer 10

Tôi khuyên bạn nên bỏ năm và chỉ có một bảng mỗi tháng, được đặt tên theo tháng. Lưu trữ dữ liệu của bạn hàng năm bằng cách đổi tên tất cả các bảng $ MONTH_ $ YEAR và tạo lại các bảng tháng. Hoặc, vì bạn đang lưu trữ dấu thời gian với dữ liệu của mình, chỉ cần tiếp tục thêm vào cùng một bảng. Tôi giả sử thực tế là bạn đang đặt câu hỏi ngay từ đầu, việc tách riêng dữ liệu của bạn theo tháng phù hợp với yêu cầu báo cáo của bạn. Nếu không, thì tôi khuyên bạn nên giữ tất cả trong một bảng và lưu trữ định kỳ các bản ghi lịch sử khi hiệu suất trở thành một vấn đề.

Answer 11

Tôi đồng ý với ý tưởng này làm phức tạp cơ sở dữ liệu của bạn một cách không cần thiết. Sử dụng một bảng duy nhất. Như những người khác đã chỉ ra, nó không đủ dữ liệu để cảnh báo việc xử lý không liên quan. Trừ khi bạn sử dụng SQLite, cơ sở dữ liệu của bạn sẽ xử lý nó tốt.

Tuy nhiên, điều này cũng phụ thuộc vào cách bạn muốn truy cập. Nếu các mục cũ thực sự chỉ có cho mục đích lưu trữ, thì mẫu lưu trữ là một tùy chọn.Nó phổ biến cho các hệ thống phiên bản để có dữ liệu được sử dụng không thường xuyên được tách ra. Trong trường hợp của bạn, bạn chỉ muốn tất cả mọi thứ> 1 năm để di chuyển ra khỏi bảng chính. Và đây là một nhiệm vụ quản trị cơ sở dữ liệu, không phải là một hành vi ứng dụng. Ứng dụng sẽ chỉ tham gia danh sách hiện tại và danh sách _archive, nếu có. Một lần nữa, điều này phụ thuộc rất nhiều vào trường hợp sử dụng. Các mục cũ có cần thiết không? Có quá nhiều dữ liệu để xử lý thường xuyên không?

Answer 12

Phản ứng đầu tiên của tôi là: Aaaaaaaaahhhhhhhhh !!!!!!

Tên bảng không được nhúng giá trị dữ liệu. Bạn không nói những gì các dữ liệu có nghĩa là, nhưng giả sử vì lợi ích của đối số đó là, tôi không biết, nhiệt độ đọc. Chỉ cần cố gắng viết một truy vấn để tìm tất cả các tháng trong đó nhiệt độ trung bình tăng so với tháng trước. Bạn sẽ phải lặp qua các tên bảng. Tệ hơn nữa, hãy tưởng tượng cố gắng tìm tất cả các khoảng thời gian 30 ngày - tức là thời gian có thể vượt qua các ranh giới tháng - nơi nhiệt độ tăng lên trong khoảng thời gian 30 ngày trước đó. Thật vậy, chỉ cần lấy một hồ sơ cũ sẽ đi từ một hoạt động tầm thường - "select * where id = anything" - sẽ trở thành một hoạt động phức tạp yêu cầu bạn phải có chương trình tạo tên bảng từ ngày trên bay. Nếu bạn không biết ngày, bạn sẽ phải quét qua tất cả các bảng tìm kiếm mỗi bảng cho bản ghi mong muốn. Kinh quá.

Với tất cả dữ liệu trong một bảng được chuẩn hóa đúng cách, các truy vấn như trên khá tầm thường. Với các bảng riêng biệt cho mỗi tháng, chúng là một cơn ác mộng.

Chỉ cần làm cho phần ngày của chỉ mục và hình phạt về hiệu suất của việc có tất cả các bản ghi trong một bảng phải rất nhỏ. Nếu kích thước của bảng thực sự trở thành một vấn đề hiệu suất, tôi có thể hiểu thấu đáo làm một bảng cho dữ liệu lưu trữ với tất cả các công cụ cũ và một cho dữ liệu hiện tại với mọi thứ bạn truy xuất thường xuyên. Nhưng đừng tạo ra hàng trăm bảng. Hầu hết các công cụ cơ sở dữ liệu có cách để phân vùng dữ liệu của bạn trên nhiều ổ đĩa bằng cách sử dụng "không gian bảng" hoặc tương tự. Sử dụng các tính năng phức tạp của cơ sở dữ liệu nếu cần thiết, thay vì hack cùng một mô phỏng thô.