Một trong những thách thức khi xử lý một thiết kế cơ sở dữ liệu mới là bạn không biết những thứ như bảng sẽ lớn như thế nào cho đến khi chúng thực sự được cung cấp với một lượng dữ liệu hợp lý. Nhưng nếu thiết kế có liên quan đến khả năng mở rộng cuối cùng, bạn không thể triển khai thiết kế để lấy dữ liệu đó cho đến khi hoàn thành ước tính. Một cách để giải quyết vấn đề này là tích cực tạo mẫu thử. Sử dụng phần cứng dàn cho mục đích này để các ứng dụng mới có thể tồn tại tạm thời trong khi sắp xếp các chi tiết như thế này. Bạn có thể chỉ cần xác định rằng bạn sẽ cần phải di chuyển ứng dụng và có thể thiết kế lại ứng dụng sau một vài tháng, khi bạn có ý tưởng tốt hơn về dữ liệu nào sẽ hiển thị trong đó.
Một cách khác để giải quyết vấn đề gà / trứng này là viết một trình tạo dữ liệu. Tạo đủ dữ liệu mẫu bằng tay để xem dữ liệu đó trông như thế nào, mật độ ra sao và các giá trị của nó được phân phối như thế nào. Sau đó, viết một cái gì đó lấy các số liệu thống kê đó và tạo ra một tập dữ liệu lớn hơn tương tự như nó. Bạn sẽ không bao giờ khiến điều đó trở nên hoàn hảo, nhưng không nhất thiết phải như vậy. Tạo tập dữ liệu khổng lồ, ngay cả khi có một số sai sót, vẫn là cách tốt nhất hiện có để ước tính kích thước cơ sở dữ liệu. Có rất nhiều nguồn chi phí khó có thể giải thích được rằng bất kỳ kích thước bảng và chỉ mục nào được đo lường, dựa trên thứ gì đó giống như dữ liệu của bạn, sẽ chính xác hơn bất kỳ cách tiếp cận nào khác. Có một lý do khiến tôi phải trả lời nhiều câu hỏi về các mối quan tâm liên quan đến hiệu suất bằng cách sử dụng pgbench để tạo cơ sở dữ liệu có kích thước thích hợp trước.
Tuy nhiên, việc tạo dữ liệu không hề dễ dàng. Đặc biệt, việc tạo dấu thời gian thực tế luôn gây khó chịu. Và cho dù bạn nghĩ mình đã viết chúng hiệu quả đến đâu, chúng thường mất nhiều thời gian hơn bạn mong đợi – và thậm chí lâu hơn để đưa dữ liệu kết quả vào cơ sở dữ liệu và được lập chỉ mục đúng cách.
Và điều đó vẫn tiếp tục xảy ra cho dù bạn đã làm điều này bao nhiêu lần, bởi vì ngay cả khi bạn làm mọi thứ đúng Luật Murphy sẽ xâm phạm khiến công việc trở nên khó khăn bất chấp. Tất cả các máy tính ở nhà của tôi đều được xây dựng từ phần cứng PC tương đối rẻ. Không phải thứ rẻ nhất hiện có – tôi có tiêu chuẩn – nhưng chắc chắn không sử dụng cùng chất lượng mà tôi khuyên mọi người nên tìm kiếm trong một máy chủ. Vấn đề tạo dữ liệu của tuần này nhắc nhở về lý do tại sao phần cứng tốt hơn lại đáng giá bao nhiêu cho công việc quan trọng của doanh nghiệp.
Sau khi tạo vài tỷ dòng dữ liệu và xem quá trình nhập đó trong 10 giờ, tôi không hài lòng khi toàn bộ công việc bị hủy bỏ như thế này:
psql:load.sql:10: ERROR: invalid input syntax for type timestamp: "201^Q-04-14 12:17:55"
CONTEXT: COPY testdata, line 181782001, column some_timestamp: "201^Q-04-14 12:17:55"
Hóa ra, ở đâu đó khi đang ghi 250GB dữ liệu thử nghiệm mà tôi đã tạo, một trong những đầu ra của dòng đã bị hỏng. Hai bit bị lật và dữ liệu ghi ra bị sai. Tôi không biết chắc điều đó đã xảy ra ở đâu.
Trí nhớ là thứ đáng nghi ngờ nhất. Máy chủ thực sử dụng RAM ECC và vì lý do chính đáng. Nếu bạn theo dõi một hệ thống có nhiều RAM, số lượng lỗi được ECC âm thầm sửa chữa có thể gây sốc. Bộ nhớ RAM tôi sử dụng ở nhà tốt, nhưng tỷ lệ lỗi trên bất kỳ bộ nhớ nào không có khả năng phát hiện / sửa lỗi sẽ cao hơn mức bạn có thể muốn – và không bao giờ được phát hiện trừ khi chúng xảy ra trong mã dẫn đến sự cố hệ thống. Công việc tạo dữ liệu rất tốt trong việc giải quyết những vấn đề này, vì nó thường đặt ít nhất một CPU trên máy chủ của bạn dưới tải nặng trong những ngày có thể xảy ra liên tiếp. Nếu có bất kỳ sự bất ổn nào trong hệ thống của bạn, việc làm nóng hệ thống và để nó hoạt động trong một thời gian dài sẽ làm cho hệ thống trở nên trầm trọng hơn.
Lớp bảo vệ thứ hai chống lại kiểu tham nhũng này là đặt tổng kiểm tra trên dữ liệu đang được ghi vào đĩa, để bảo vệ khỏi lỗi ghi và sau đó đọc lại dữ liệu. Tổng kiểm tra khối được thực hiện bởi hệ thống tệp ZFS là một trong những cách triển khai tốt hơn. Trong trường hợp của tôi, việc tôi có sử dụng ZFS hay không có thể không tạo ra bất kỳ sự khác biệt nào. Nếu các bit bị lật trước khi tổng kiểm tra khối xảy ra, tôi sẽ ghi dữ liệu rác ra ngoài – với tổng kiểm tra rác để khớp với nó – bất kể.
Bước tiếp theo của tôi là sử dụng split tiện ích để lấy tệp khổng lồ của tôi và chia nó thành nhiều phần nhỏ hơn – một vài giờ nữa để đợi quá trình đó hoàn thành. Sau đó, tôi có thể bắt đầu tải các tệp tốt trong khi sửa tệp xấu.
Với các tệp kết quả là 13GB mỗi tệp và một máy chủ của tôi có RAM 16 GB, mặc dù tôi có thể sửa lỗi đánh máy một ký tự này bằng cách sử dụng vi. Về mặt lý thuyết thì đúng như vậy, nhưng tôi bắt đầu nghi ngờ vì đã đợi bao lâu để tệp được viết lại sau đó:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
21495 gsmith 20 0 8542m 8.3g 1544 R 98 53.0 419:56.70 vi datafile-ag
Đó là 7 giờ chắc chắn tôi đã đợi chỉ để sửa lỗi chính tả một ký tự này để tôi có thể hoàn tất việc tải dữ liệu thử nghiệm. Giống như tôi đã nói, việc tạo dữ liệu nghiêm túc không bao giờ là dễ dàng.
