Wordpress MU ( http://mu.wordpress.org/ ) - это движок, который ставится на сайт и позволяет всем посетителям сайта создать свой блог.

Вот из официального описания:


Было замечено, что для каждого создаваемого блога создается по 8 таблиц. Это означает, что при 10 блогах в базе будут 80 таблиц. При 100 блогах - будет 800 таблиц. Такое количество таблиц меня немного пугает, т.к. боюсь сильного снижения производительности.

Вот имена создаваемых таблиц:
 wp_х_categories
 wp_х_comments
 wp_х_link2cat
 wp_х_links
 wp_х_options
 wp_х_post2cat
 wp_х_postmeta
 wp_х_posts

где X - это порядковый номер блога.

На мой взгляд было бы намного эффективнее всё записи с разных блогах хранить в одной таблице. Насколько верны мои опасения при тысячах блогах? 
1 000 блогов - 8 000 таблиц
100 000 - 800 000 таблиц (<-кажется страшной цифрой.)

вообще это зависит от файловой системы. MyISAM на всякую таблицу делает 3 файла - .frm .myd  и .myi . То есть на 8000 таблиц будет 24 тыщщи файлов. Мы делали свои тесты года 3 назад на линуксе ext3 и у нас начинались проблемы примерно с 10000 таблиц. 

Wowa, в теории для MyISAM таблиц как раз эффективней будет работать со многочисленными таблицами, чем с одной огромной, т.к. в MyISAM не поддерживаются транзакции и при записи лочится вся таблица. Но есть нюанс, который следует учитывать Drawbacks to Creating Many Tables in the Same Database

Имхо, при грамотно настроенном сервере ничего страшного не будет. Даже если будет зарегистрировано 10000 блогов, я очень сомневаюсь, что пользователи одновременно будут обращаться ко всем 10000 блогам (в лучшем случае ко 100).

Сейчас более менее нормально живёт сервер со 100 тысячью таблицами. table cache выставлен в 130 тысяч. На такой базе нельзя говорить show table status;, немного тормозит show tables like 'something%'. Flush tables аналогично выполняется несколько минут.
Overhead'а на open/close не замечаем, так что table_cache работает.

Для блогов, думаю, это идеальный вариант.
Всё-таки на таблицах(е) в десятки миллионов строк (для случая, когда все блоги в одной таблице) будет невозможно выполнять частые, а тем более одновременные insert'ы/select'ы.

Ещё можете подумать над тем, чтобы разносить таблицы по разным директориям, может быть даже по разным базам на одном и том же сервере.
Ну и конечно железка должна быть соответствующая, если вы собираетесь обслуживать 10000 блогов. Да и когда ваш проект перевалит за 1000ый не ботом-сгенерённый блог, вы уже заработаете на второй сервер 

Добавлено через 47 секунд

какие?

появлялись периодические тормоза. 



если не секрет а что в ulimit -n и fs.file-max?

Добавлено через 2 минуты и 37 секунд


ну неправда. вполне себе insert-ятся даже на myisam. А есть еще innodb

ulimit - соответствующий, кол-во таблиц * 3
fs.file-max - эмм, на порядок больше, можно считать анлим



Что у вас инсертится? Можете пример привести? Дефинишн, кол-во строк, кол-во запросов в секунду.
Последовательно - да, параллельно (тут говорили про 10000 блогов, то есть в пик это пусть 1% - 100 запросов) - нет.
Плюс если таблицы будут не fixed, то точно умрёт, тут даже думать не о чем. 

Пример - сбор инфо с датчиков. Таблица _не_ fixed. Сейчас примерно 50 миллионов строк. 5 датчиков, каждый примерно 5 insert в сек. Машина amd 64 4000+, 2 гига памяти.

Хм..хорошие показатели. 
А delay_key_write в mysql - включён/выключен для этой таблицы?
insert'ы в конец таблицы всегда делаются? если да, то это немного объясняет живучесть   (грубо говоря, только insert, или бывают delete/replace/insert_on_duplciate_key_update, портящие целостность?)
Много ли обращений на чтение из этой таблицы?
Ради интереса просто, если не сложно.