Tabel Penggabungan MySQL - lalu lintas tinggi dan data dalam jumlah besar

Pekerjaan saya saat ini menggunakan MySQL (MyISAM) khusus untuk semua penyimpanan data. Saat ini kami memiliki lebih dari 300 server web dan sekitar 150 database. Sayangnya saya harus menulis struktur tabel untuk mendukung lebih dari 100 juta baris dalam jangka waktu 30 hari. Idenya adalah:

  1. Sisipan bervolume tinggi (tidak ada pembaruan atau penghapusan dan selalu berada di akhir tabel)
  2. 1 baris dipilih
  3. Data yang lebih lama dari 30 hari akan dibuang

Solusi terbaik tampaknya adalah menggabungkan tabel untuk setiap hari menjadi tabel Gabung untuk pilihan. Memang akan ada data duplikat, tetapi SELECT hanya akan menarik baris terbaru berdasarkan stempel waktu dan bidang int. Jelas memiliki 30 meja tidaklah ideal tetapi begitu pula kehidupan.

Apakah ada kelemahan yang melekat pada pendekatan ini? Apakah ada cara lain untuk melakukan pendekatan ini yang saya lewatkan (kita terjebak di 5.0)? Apakah penguncian tabel akan menjadi masalah besar saat melakukan ALTER TABLE pada tabel gabungan saat tabel hari baru dibuat? Saat ini kami memiliki struktur rotasi tabel, tetapi jika kami menggunakan satu tabel, harus memilih data yang kami inginkan dari tabel lama ke tabel baru akan sangat lambat karena mendekati 100 juta baris.

Ada teknologi lain di luar sana untuk mencapai hal ini dengan cara yang elegan, namun tim penjualan kami telah menjual solusinya dan kami tidak memiliki banyak waktu.

Masukan apa pun akan dihargai.

Struktur:

CREATE TABLE `merge_test_1` (
   `date_stamp` long NOT NULL,
   `hash` char(32) NOT NULL,
   `p_id` mediumint(8) unsigned NOT NULL,
   `a_id` mediumint(8) unsigned NOT NULL,
   `b_id` mediumint(8) unsigned NOT NULL,
   PRIMARY KEY  (`hash`,`p_id`,`date_stamp`)
 ) ENGINE=MyISAM

Contoh kueri

SELECT b_id,a_id FROM merge_test WHERE hash='1' AND p_id=1
ORDER BY date_stamp DESC LIMIT 1

mysql database merge
person methodin    schedule 27.09.2010    source sumber

Jawaban (2)


arrow_upward
0
arrow_downward

Jika saya memahami inti dari pertanyaan ini bahwa pengindeksan tidak akan membuahkan hasil karena penyisipan bervolume tinggi, dan, pencarian berdasarkan MAX(id) tidak memenuhi kriteria Anda... " SELECT hanya akan menarik baris terbaru berdasarkan stempel waktu dan bidang int."

Sudahkah Anda menguji menggunakan tampilan untuk tujuan ini? Tampaknya masuk akal untuk menang.

E.g.

CREATE TABLE lotsofdata (
id INT UNSIGNED AUTO_INCREMENT,
int_val INT UNSIGNED,
the_timestamp TIMESTAMP,
PRIMARY KEY(id));
--
CREATE VIEW FROM 
SELECT id,int_val,the_timestamp 
FROM lotsofdata
WHERE the_timestamp = MAX(the_timestamp)
AND MAX(int_val)
LIMIT 0,1;

Semoga membantu. Jika Anda dapat memberikan struktur tabel dan contoh kueri, saya ingin membantu. Saya hanya perlu beberapa hal yang lebih spesifik.

person randomx    schedule 27.09.2010
comment
Saya seharusnya menyatakan bahwa grup DBA kami sangat membatasi apa yang dapat kami lakukan dan Tampilan tidak didukung. Posting yang diedit dengan contoh struktur dan kueri. - person methodin; 28.09.2010

arrow_upward
0
arrow_downward

Saya tahu Anda telah menerima jawaban Views dan saya tahu Anda menyebutkan bahwa Anda masih terjebak di 5.0 ... tapi saya masih berpikir ada gunanya menyebutkan partisi, yang dari apa yang saya kumpulkan, akan menyelesaikan semua masalah Anda.
Menjatuhkan mematikan data lama semudah membuang salah satu tabel terpisah... dan jauh lebih cepat daripada melakukan "hapus dari tabel_besar di mana stempel waktu ‹ x"
dan jika Anda memastikan kueri Anda memangkas partisi dengan benar, pembacaan akan dilakukan dengan cepat juga.

Sebenarnya saya memutakhirkan ke 5.1 karena saya memiliki situasi yang sangat mirip dan merasa mempartisi menjadi satu-satunya solusi nyata.

person Strahd_za    schedule 05.11.2010