оптимальный размер таблицы в MySQL

просто железо может быть разным и будет разная скорость работы, хотелось бы как нибудь это дело вычислять

У меня логи сквида 1.2-1.5Гб за сутки (около 4-5 млн строк)
Весь лог загоняется в sqlite. Никаких проблем, главное индексы по нужным полям сделать.

индексы конечно хорошо, собственно их использую, вот только они места много отъедают

> У меня логи сквида 1.2-1.5Гб за сутки (около 4-5 млн строк)

а если не секрет, за сколько времени твоя софтина загоняет в базу эти 5 млн строк?

зафига индексы?

на среднем компе (типа Атлон 4200) около 5000строк/сек

$ gunzip -c access.log.20090120.gz | wc -l
5401354

$ time sh -c 'gunzip -c access.log.20090120.gz | bin/log2dbsql.pl'
Create new database squid-2009-5-1.db 

real    17m59.599s
user    11m4.602s
sys     0m34.446s


sqlite> select count() from main_tab;
5075953                  # кое-что отфильтровывается в процессе
sqlite> select count() from urls_tab;
14400
sqlite> select count() from users_tab;
1185

не знаю как у cyclon'а, а у меня строки вносятся в несколько таблиц.

Без индексов работает медленно, т.к. во всех таблицах проверяется уникальность строки.

Сейчас такая схема (я не слишком заморачивался, поэтому выслушаю
критику с удовольствием)

$ cat bin/schema.sql 
CREATE TABLE code_tab  (c1key INTEGER PRIMARY KEY, code_txt  TEXT UNIQUE);
CREATE TABLE from_tab  (f1key INTEGER PRIMARY KEY, from_txt  TEXT UNIQUE);
CREATE TABLE ip_tab    (i1key INTEGER PRIMARY KEY, ip_txt    TEXT UNIQUE);
CREATE TABLE mime_tab  (m1key INTEGER PRIMARY KEY, mime_txt  TEXT UNIQUE);
CREATE TABLE type_tab  (t1key INTEGER PRIMARY KEY, type_txt  TEXT UNIQUE);
CREATE TABLE urls_tab  (u1key INTEGER PRIMARY KEY, url_txt   TEXT UNIQUE);
CREATE TABLE users_tab (s1key INTEGER PRIMARY KEY, user_txt  TEXT UNIQUE);
CREATE TABLE main_tab  (main1key INTEGER PRIMARY KEY, time_f FLOAT,
 i1key INTEGER, c1key INTEGER, size_int INTEGER, t1key INTEGER, 
 u1key INTEGER, s1key INTEGER, f1key INTEGER, m1key INTEGER,
  CONSTRAINT uniqline UNIQUE 
   (time_f,i1key,c1key,size_int,t1key,u1key,s1key,f1key,m1key));

CREATE INDEX main_s1key_idx    ON main_tab  (s1key);
CREATE INDEX main_u1key_idx    ON main_tab  (u1key);
CREATE INDEX main_m1key_idx    ON main_tab  (m1key);
CREATE INDEX urls_tab_txt_idx  ON urls_tab  (url_txt);
CREATE INDEX users_tab_txt_idx ON users_tab (user_txt);

у меня 32000000 строк за 90 минут, сам лог идёт в одну таблицу, которая автоматом бьётся по 500000 строк и попутно логины пользователей, IP адерса, тип запроса, ответ подменяются на id, таблицы соответствия держаться в памяти программы (созданы отдельные таблицы в которых строиться соответствие id с логином и IP адресом и etc).

> Сейчас такая схема (я не слишком заморачивался, поэтому выслушаю
критику с удовольствием)

у меня аналогичная схема, что то более оптимального придумать не смог

> во всех таблицах проверяется уникальность строки

это чтобы уменьшить размер базы и не писать повторяющиеся запросы? Или чтобы смотреть на какие урлы юзер скока раз ходил?

и то и другое.

дроби по дням и всё. Я бы не стал делать больше сотни таблиц потому что некоторые комманды, скажем, show table status, не любят большого их кол-ва. А так мускул нормально работает даже с тыщами таблиц. Хотя, на 200тыщ таблицах myisam show tables больше суток выполнялся :).

Теоретически, есть table partitioning в каких-то версиях мускла. Но я слышал что эта фича ничего в плане скорости на тестах не дала.

> дроби по дням и всё. Я бы не стал делать больше сотни таблиц потому что некоторые комманды, скажем, show table status, не любят большого их кол-ва. А так мускул нормально работает даже с тыщами таблиц. Хотя, на 200тыщ таблицах myisam show tables больше суток выполнялся :).

+1 k delat' po dnyam. da, i eshe ya dumau luchshe tip innoDB taki sdelat' a ne myisam. + k etomu, mozhno raz v mesyac po cron'u skidyvat' statistiku v otdelnuu basu i raz v polgoda dampit' ih na vint.

А смысл по дням дробить? если к примеру в выходные ничего не было, а таблицы будут созданы... так что мне кажется вернее бить по количеству строк.

смысл в удобстве дальнейшего хранения и обработки.

innodb очень тормозен на инсертах. Даже не в разы а на порядок медленнее myisam. Но, конечно, записи пороождают блокировки. Так что смотри сам что тебе больше подходит.