Apakah ada alasan Anda tidak membuat tabel anak sehingga Anda dapat menyimpan satu nilai floating point per baris, bukan array?
Katakanlah Anda menyimpan seribu larik 300 elemen setiap hari. Itu 300.000 baris per hari, atau 109,5 juta per tahun. Tidak ada yang perlu disindir, tetapi dalam kemampuan MySQL atau RDBMS lainnya.
Komentar Anda:
Tentu, jika pesanannya signifikan, Anda menambahkan kolom lain untuk pesanan itu. Inilah cara saya mendesain tabel:
CREATE TABLE VectorData (
trial_id INT NOT NULL,
vector_no SMALLINT UNSIGNED NOT NULL,
order_no SMALLINT UNSIGNED NOT NULL,
element FLOAT NOT NULL,
PRIMARY KEY (trial_id, vector_no),
FOREIGN KEY (trial_id) REFERENCES Trials (trial_id)
);
-
Total ruang untuk deretan data vektor:300x(4+2+2+4) =3600 byte. Ditambah direktori catatan InnoDB (barang internal) sebesar 16 byte.
-
Total ruang jika Anda membuat serial array Java 300 float =1227 byte?
Jadi Anda menghemat sekitar 2400 byte, atau 67% dari ruang dengan menyimpan array. Tetapi misalkan Anda memiliki ruang 100GB untuk menyimpan database. Menyimpan array serial memungkinkan Anda untuk menyimpan 87,5 juta vektor, sedangkan desain yang dinormalisasi hanya memungkinkan Anda untuk menyimpan 29,8 juta vektor.
Anda mengatakan Anda menyimpan beberapa ratus vektor per hari, jadi Anda akan mengisi partisi 100GB itu hanya dalam 81 tahun, bukan 239 tahun.
Berikan komentar Anda:Kinerja INSERT adalah masalah penting, tetapi Anda hanya menyimpan beberapa ratus vektor per hari.
Sebagian besar aplikasi MySQL dapat mencapai ratusan atau ribuan sisipan per detik tanpa sihir yang berlebihan.
Jika Anda membutuhkan kinerja yang optimal, berikut beberapa hal yang perlu diperhatikan:
- Transaksi eksplisit
- Sintaks INSERT multi-baris
- INSERT DELAYED (jika Anda masih menggunakan MyISAM)
- MUAT INFILE DATA
- ALTER TABLE DISABLE KEYS, lakukan penyisipan, ALTER TABLE ENABLE KEYS
Cari frasa "mysql inserts per second" di mesin pencari favorit Anda untuk membaca banyak artikel dan blog yang membicarakan hal ini.
