Salah satu tantangan ketika berhadapan dengan desain database baru adalah Anda tidak tahu hal-hal seperti seberapa besar tabel pada akhirnya sampai mereka benar-benar diisi dengan cukup banyak data. Tetapi jika desain harus mempertimbangkan masalah skalabilitas pada akhirnya, Anda tidak dapat menerapkannya untuk mendapatkan data tersebut hingga estimasi selesai. Salah satu cara mengatasinya adalah dengan membuat prototipe secara agresif. Gunakan perangkat keras pementasan untuk tujuan ini agar aplikasi baru dapat hidup sementara sambil menyortir detail seperti ini. Anda dapat mempertimbangkan bahwa Anda perlu memindahkan aplikasi dan mungkin mendesain ulang setelah beberapa bulan, saat Anda memiliki gagasan yang lebih baik tentang data apa yang akan muncul di dalamnya.
Cara lain untuk mengatasi masalah ayam/telur ini adalah dengan menulis generator data. Buat data sampel yang cukup dengan tangan untuk melihat seperti apa, seberapa padatnya, dan bagaimana nilainya didistribusikan. Kemudian tulis sesuatu yang mengambil statistik tersebut dan menghasilkan kumpulan data yang lebih besar yang serupa dengannya. Anda tidak akan pernah membuatnya sempurna, tetapi itu tidak harus sempurna. Menghasilkan kumpulan data raksasa, bahkan dengan beberapa kekurangan, masih merupakan cara terbaik yang tersedia untuk melakukan estimasi ukuran database. Ada begitu banyak sumber overhead yang sulit untuk diperhitungkan sehingga tabel terukur dan ukuran indeks apa pun, berdasarkan sesuatu seperti data Anda, akan jauh lebih akurat daripada pendekatan lainnya. Ada alasan mengapa saya akhirnya menjawab banyak pertanyaan tentang masalah terkait kinerja dengan menggunakan pgbench untuk membuat database dengan ukuran yang sesuai terlebih dahulu.
Pembuatan data tidak mudah. Menghasilkan stempel waktu yang realistis khususnya selalu menjengkelkan. Dan tidak peduli seberapa efisien Anda menulisnya, mereka biasanya membutuhkan waktu lebih lama dari yang Anda harapkan untuk dijalankan–dan bahkan lebih lama untuk memasukkan data yang dihasilkan ke dalam database dan diindeks dengan benar.
Dan itu terus menjadi kasus tidak peduli berapa kali Anda melakukan ini, karena bahkan jika Anda melakukan segalanya dengan benar, Hukum Murphy akan mengganggu pekerjaan yang menyakitkan. Komputer saya di rumah semuanya dibuat dari perangkat keras PC yang relatif murah. Bukan barang termurah yang tersedia – saya memiliki standar – tetapi tentu saja tidak menggunakan kualitas yang sama, saya akan merekomendasikan orang mencari di server. Masalah pembuatan data minggu ini mengingatkan mengapa perangkat keras yang lebih baik sebanding dengan biaya yang dikeluarkan untuk pekerjaan penting bisnis.
Setelah menghasilkan beberapa miliar baris data dan menonton impor itu selama 10 jam, saya tidak senang jika seluruh pekerjaan dibatalkan seperti ini:
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"
Ternyata, di suatu tempat di tengah penulisan data pengujian 250GB yang saya hasilkan, salah satu output baris rusak. Dua bit terbalik, dan data yang ditulis salah. Saya tidak tahu pasti di mana itu terjadi.
Memori adalah yang paling mungkin dicurigai. Server nyata menggunakan RAM ECC, dan untuk alasan yang bagus. Jika Anda memantau sistem dengan banyak RAM, jumlah kesalahan yang dikoreksi secara diam-diam oleh ECC dapat mengejutkan. RAM yang saya gunakan di rumah bagus, tetapi tingkat kesalahan pada memori apa pun tanpa kemampuan deteksi/koreksi kesalahan akan lebih tinggi dari yang Anda inginkan–dan tidak pernah terdeteksi kecuali jika terjadi dalam kode yang menyebabkan sistem crash. Pekerjaan pembuatan data bagus dalam mengungkap masalah ini, karena biasanya menempatkan setidaknya satu CPU di server Anda di bawah beban berat selama beberapa hari berturut-turut. Jika ada ketidakstabilan di sistem Anda, membuat sistem menjadi panas dan membiarkannya berjalan lama akan memperburuknya.
Lapisan kedua perlindungan terhadap korupsi semacam ini adalah dengan menempatkan checksum pada data yang sedang ditulis ke disk, untuk melindungi dari kesalahan penulisan dan kemudian membaca kembali data tersebut. Checksumming blok yang dilakukan oleh sistem file ZFS adalah salah satu implementasi yang lebih baik dari itu. Dalam kasus saya, apakah saya menggunakan ZFS atau tidak, mungkin tidak ada bedanya. Jika bit dibalik sebelum checksum blok terjadi, saya akan menulis data sampah – dengan checksum sampah untuk mencocokkannya – terlepas dari itu.
Langkah saya selanjutnya adalah menggunakan split utilitas untuk mengambil file raksasa saya dan memecahnya menjadi potongan-potongan kecil-beberapa jam lagi untuk menunggu itu selesai. Kemudian saya dapat memulai memuat file yang bagus sementara saya memperbaiki yang buruk.
Mengingat file yang dihasilkan masing-masing 13GB dan satu server saya memiliki RAM 16GB, meskipun saya dapat memperbaiki kesalahan ketik satu karakter ini menggunakan vi. Secara teoritis memang seharusnya begitu, tetapi saya mulai ragu mengingat berapa lama saya telah menunggu file untuk ditulis kembali setelahnya:
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
Itu adalah 7 jam yang padat saya telah menunggu hanya untuk kesalahan ketik satu karakter ini untuk diperbaiki, jadi saya bisa menyelesaikan memuat data pengujian. Seperti yang saya katakan, pembuatan data yang serius tidak pernah mudah.
