MySQL: data untuk pengujian Mati wunderbare Welt von Isotopp

Database


Di tempat saya bekerja, perdebatan tentang menghasilkan data uji terus berlanjut. Saat ini kami tidak mengganti atau memodifikasi data produksi apa pun untuk digunakan dalam lingkungan pengujian, dan kami tidak menghasilkan data pengujian.

Ini aman dan legal, karena data produksi diberi token. Artinya, data PII dan PCI digantikan oleh pemegang token yang dapat digunakan oleh aplikasi untuk mengakses data yang sebenarnya dilindungi melalui layanan akses khusus yang dilindungi. Hanya lingkaran orang yang sangat terbatas yang berurusan dengan data di balik layanan yang dilindungi.

Menggunakan data produksi dalam database pengujian juga cepat, karena kami menyalin data secara paralel dengan kecepatan baris, atau membuat snapshot yang dapat ditulis tersedia pada pengalihan tulis (“copy-on-write” di era SSD). .

Mari kita asumsikan sejenak bahwa kita ingin mengubahnya dan

  • Saat kami menyalinnya ke database pengujian, kami menyembunyikan data produksi
  • Kurangi jumlah data yang digunakan dalam database pengujian sambil mempertahankan integritas referensial
  • Hasilkan kumpulan data uji dari berbagai ukuran alih-alih menggunakan data produksi, menjaga integritas referensial serta beberapa properti statistik dasar.

Katakanlah kita membuat salinan database produksi dalam pengaturan pengujian. Kami kemudian menyiapkan salinan itu dengan mengubah item data apa pun yang ingin kami sembunyikan, misalnya dengan menggantinya sha("secret" + original value)atau tanda alternatif lainnya.

kris@localhost [kris]> select sha(concat("secret", "Kristian Köhntopp"));
+---------------------------------------------+
| sha(concat("secret", "Kristian Köhntopp"))  |
+---------------------------------------------+
| 9697c8770a3def7475069f3be8b6f2a8e4c7ebf4    |
+---------------------------------------------+
1 row in set (0.00 sec)

Mengapa kita menggunakan fungsi hash atau setara moral untuk ini? Tentu saja kami ingin menjaga integritas referensial. Jadi setiap kejadian Kristian Köhntopp akan diganti 9697c8770a3def7475069f3be8b6f2a8e4c7ebf4nilai yang dapat diprediksi dan stabil, bukan angka acak 17 pada kejadian pertama dan nomor acak lainnya, 25342selanjutnya.

Dalam hal kerja database, itu berarti bahwa setelah menyalin data, itu sedang berjalan update Di setiap baris, buat entri binlog untuk setiap perubahan. Jika kolom yang kita ubah diindeks, indeks yang berisi kolom tersebut harus diperbarui. Jika kolom yang kita ubah adalah primary key, lokasi fisik record dalam tabel juga akan berubah, karena InnoDB mengelompokkan data pada primary key.

Singkatnya, sementara menyalin data cepat, menyembunyikan data jauh lebih mahal dan tidak akan berjalan pada perangkat keras apa pun dengan kecepatan tinggi.

Di awal sejarah perusahaan, sekitar 15 tahun yang lalu, seorang rekan bekerja untuk membuat database pengujian yang lebih kecil dengan memilih subset data produksi sambil menjaga integritas referensial tetap utuh. Dia gagal.

Banyak orang lain mencoba kemudian, kami memiliki proyek yang telah melakukan ini setiap 3-5 tahun. Mereka juga gagal.

Setiap upaya selalu memilih database kosong atau semua data produksi.

Mengapa demikian?

Mari kita coba model sederhana: kita punya pengguna, kita punya hotel, dan mereka menjalin hubungan, akomodasi.

“Chris” tinggal di sebuah hotel bernama “Casa”. Kami memilih Kris dalam kumpulan data uji dari produksi serta “Casa”. Orang lain tinggal di Casa, jadi mereka juga memasuki set tes, tetapi mereka juga tinggal di hotel lain, jadi hotel ini juga masuk, dan seterusnya, di antara dua meja. Setelah 3 refleksi, 6 transfer, kami telah memilih seluruh basis data produksi ke dalam set pengujian.

Data produksi kami saling berhubungan, dan menjaga integritas referensial dari data produksi kami berarti bahwa memilih satu pada akhirnya akan memilih semua.

Membatasi periode waktu dapat membantu: kami hanya memilih data dari minggu lalu atau lebih. Tapi ini memiliki implikasi lain, misalnya dalam distribusi data. Selain itu, data produksi kami sangat bervariasi berdasarkan waktu terkait operasi ketersediaan – banyak pemesanan terjadi dalam seminggu terakhir.

Menghasilkan data sampah cepat, tetapi masih lebih lambat daripada menyalin. Ini karena menyalin data dari mesin produksi dapat menyalin file biner dengan direktori yang telah ditentukan, sementara menghasilkan data sampah sama dengan mengimpor file mysqldump. Data harus diurai dan lebih buruk lagi, semua indeks harus dibangun.

Meskipun kita dapat menyalin data pada ratusan megabyte per detik, hingga ke kisaran gigabyte per detik, mengimpor data dalam satu digit megabyte per detik hingga puluhan megabyte per detik. Banyak tergantung pada ketersediaan RAM dan kecepatan disk, serta pada jumlah indeks dan urutan data input dengan kunci utama.

Menghasilkan data non-sampah juga sulit dan lambat.

Anda harus memiliki daftar batasan integritas referensial yang ditentukan atau disimpulkan dari skema. Di tempat kerja, desain kami berukuran besar, jauh lebih besar daripada satu database atau layanan – pengguna di layanan pengguna (layanan pengguna uji, dengan data pengguna uji) harus dirujuk dalam layanan reservasi (layanan reservasi uji dengan reservasi uji). ke hotel dalam uji ketersediaan dan uji toko hotel.

Ini berarti membuat dan memelihara dunia kedua yang statis, atau membuatnya, di seluruh layanan, dari awal, untuk setiap pengujian. Salah satunya adalah penurunan produktivitas (mempertahankan alam semesta yang koheren adalah banyak pekerjaan), yang lain lambat.

Namun, kompatibilitas bukan satu-satunya persyaratan. Kompatibilitas baik-baik saja jika Anda ingin menguji kode validasi (tetapi nama pengujian saya bukan utf8, mereka dari subset heksadesimal ASCII!).

Tetapi jika Anda ingin berbicara tentang kinerja, persyaratan tambahan muncul:

  • Ukuran data.

    Jika data produksi Anda 2 TB, tetapi set pengujian Anda adalah 200 GB, itu tidak 10x lebih cepat secara linier. Hubungan ini non-linear: pada perangkat keras, data produksi mungkin terbatas pada IO karena set kerja tidak muat di memori, sedangkan data uji bisa muat WSS di memori. Data produksi yang dihasilkan disk membaca sebanding dengan beban, data uji dijalankan dari memori dan tidak membaca I/O setelah pemanasan – model kinerja yang sama sekali berbeda diterapkan. Pengujian kinerja pada data pengujian tidak memiliki nilai prediktif untuk kinerja produksi.

  • Distribusi data

    Data produksi dan akses ke data produksi tunduk pada pola akses data yang sebagian besar tidak diketahui dan tidak didokumentasikan, dan juga berubah. Beberapa pengguna adalah paus yang melakukan perjalanan 100 kali lebih banyak dari biasanya. Pengguna lain sering bepergian dan melakukan perjalanan 10 kali lebih banyak dari biasanya. Sejumlah pengguna satu kali dan hanya muncul sekali dalam kumpulan data. Apa hubungan antara koleksi ini dan bagaimana pengaruhnya terhadap akses data?

Sebagai contoh:

Majalah komputer Jerman c’t memiliki tolok ukur praktis pada tahun 2006 yang menjelaskan akses permintaan web ke toko persewaan DVD. Peserta harus menulis toko persewaan DVD menggunakan teknologi pilihan mereka, yang ditentukan dalam output yang diperlukan dan permintaan URL yang ditemui dalam percobaan. MySQL, di mana saya bekerja sebagai konsultan, ingin berpartisipasi, dan untuk ini saya memasukkan template yang disediakan ke toko online menggunakan MySQL dan mengatur toko dan database yang sesuai.

Saya tidak masuk 10 besar.

Itu karena saya menggunakan toko web nyata dengan asumsi nyata tentang perilaku pengguna, termasuk cache dan lainnya.

Data uji yang digunakan dihasilkan dan permintaan didistribusikan secara merata: setiap DVD di toko DVD simulasi memiliki kemungkinan yang sama untuk disewa, dan setiap pengguna menyewa DVD dalam jumlah yang sama. Cache apa pun yang Anda masukkan ke dalam toko akan meluap dan pergi ke perontokan, atau harus memiliki memori yang cukup untuk menampung seluruh toko dalam cache.

Toko persewaan DVD asli memiliki 100 judul populer dan berekor panjang. Cache membantu. Dalam pengujian, cache mematikan kinerja.

Majalah komputer Jerman lainnya memiliki tolok ukur basis data lain yang pada dasarnya membuat sistem yang sedang diuji dengan beban yang sangat tinggi. Sayangnya, di sini beban tidak merata, tetapi beberapa kunci sering digunakan, sementara banyak kunci tidak pernah diminta. Sebenarnya generator beban memiliki banyak utas dan setiap utas menggunakan kunci “sendiri” di database – string 1 ke id 1 di tabel dan seterusnya.

Ini menerapkan sejumlah hotkey tertentu, dan menunggu beberapa kunci dengan sangat cepat, tetapi sebenarnya tidak mensimulasikan kendala apa pun secara akurat. Jika Anda melatih sistem dengan beban produksi yang lebih tinggi, itu akan memiliki daya total sekitar 100 kali lebih banyak.

Menghasilkan data yang disamarkan atau disimulasikan untuk pengujian 100 kali lebih mahal secara komputasi daripada menduplikasi data produksi. Jika data produksi sudah tokenized, keuntungan juga dipertanyakan dibandingkan dengan usaha yang dikeluarkan.

Menghasilkan data uji yang valid secara komputasi mahal, terutama dalam arsitektur layanan mikro di mana integritas referensial harus dipertahankan melintasi batas layanan.

Data pengujian yang valid belum tentu berguna dalam pengujian, terutama dalam hal pengujian kinerja. Pengujian kinerja juga bergantung secara khusus pada pola akses data, ukuran set kerja, dan distribusi kecepatan akses yang memengaruhi waktu penguncian.

Pada akhirnya, lingkungan pengujian yang sebenarnya selalu produksi, dan dalam pengalaman profesional pribadi saya, mengamankan pengujian dalam produksi jauh lebih berharga daripada menghasilkan lingkungan pengujian yang terperinci.



Source link

Tinggalkan Balasan

Alamat email Anda tidak akan dipublikasikan. Ruas yang wajib ditandai *