|
|
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
Подумал я, что логичней будет тут этот вопрос задать..) Недавно пришлось восстанавливать базу с ~50k таблиц, столкнулся с некоторыми граблями, например myisamchk *.MYI затыкался с диагностикой "Arguments line too long" (мб переврал, но суть такая), ну это ладно, это я обошёл... Хуже то, что база с таким количеством таблиц стала довольно неповоротливой и тормозной. Вероятно, в немалой степени из-за тормозов файловой системы, ls -l | wc -l для этой директории со 150к файлов отрабатывал секунд по 15. Насколько я помню из документации, MySQL поддерживает фишку с использованием сырого раздела вместо файловой системы под хранилище данных. Возможно, в таком случае этот вариант предпочтительней. Вот и хотелось бы узнать у тех, кто этим пользовался, насколько шустро оно бегает для баз с подобным количеством таблиц? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 19:13 |
|
||
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
Вопрос-то, кстати, был о том, что делать, если база _должна_ содержать столько таблиц?Перепроектировать наконец по уму. Учитывая этосли говорится, что пользоваться базой будут 2-3 клиента, а потом оказывается, что десятки тысячмогу лишь сказать, что врядли заводить на каждого клиента по паре баз было разумным решением.Спасает ли от этого использование не файловой системы, а raw partition под хранилище?Врядли в подобной ситуации поможет что-то отличное от перепроектирования. Или запаса оперативки, превышающего объём БД раза в два-три. Могу ошибаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 22:08 |
|
||
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
Нет, стоп... Какая связь между количеством таблиц в базе и количеством оперативки? То есть она, несомненно, есть, но вряд ли такова, что если вся база целиком в память не влазит -- уже ничего не поможет. Кстати база-то вся весила метров 100-120, так что влазить она влазит, по идее. И прошу заметить, вопрос не о том, кто виноват, и даже не что делать... Вопрос о влиянии способа хранения информации базы на физическом носителе: использования файловой системы ОС, и собственных возможностей MySQL хранения на неформатированном разделе: есть ли выигрыш от второго для базы с большим количеством таблиц? Значителен ли он, или составляет единицы процентов? Поясню ситуацию: я не разработчик этой базы, я админ хостинга, где она размещается. По понятным причинам я не занимаюсь перепроектированием всех размещённых на серверах БД. В случае грубых ошибок, препятствующих корректной работе базы, или сильно её замедляющей, я могу указать на эти проблемы разработчикам. Но нельзя исключать, что в какой-то момент мне потребуется разместить базу с, скажем, 50к таблиц. Поэтому я пытаюсь выяснить, есть ли какие-то варианты для MySQL для работы с такой базой, или же сразу смотреть что-то другое, в таком случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 22:52 |
|
||
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
Ну раз такие помидоры, то мне бы самому было интересно услышать, что поэтому поводу скажут гуру. По поводу оперативки - там ведь не одна база на сервере и не один хостящийся. Так что база всё время в оперативке не находится. А разница, где будут лежать файлы, имхо, значительной не будет (к сожалению, не располагаю сведениями об использовании неформатированных разделов изнутри - однако не думаю, что это поможет). Собственно, у вас есть уникальная возможность убедиться в этом лично или же опровергнуть данное умозрительное заключение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.01.2005, 23:13 |
|
||
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
здесь про MySQL Масштабируемость и ограничения Управляет очень большими базами данных. Компания MySQL AB. использует MySQL для работы с несколькими базами данных, которые содержат 50 миллионов записей, кроме того, нам известны пользователи, использующие MySQL для работы с 60000 таблицами, включающими около 5000000000 строк. Для каждой таблицы разрешается иметь до 32 индексов. Каждый индекс может содержать от 1 до 16 столбцов или частей столбцов. Максимальная ширина индекса 500 бит (это значение может быть изменено при компиляции MySQL). Для индекса может использоваться префикс поля CHAR или VARCHAR. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2005, 14:34 |
|
||
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
Эти тормоза - от файловой системы. Логичней было бы поиграться настройками FS (типа noatime), попробовать другие FS. Я например слышал хорошие отзывы о UFS на солярке для большого числа баз/таблиц. Сейчас у вас на каждую таблицу создается 3 файла. Если попробуете innodb, будет создаваться 1 файл (.frm) на каждую таблицу. так что стоит попробовать. Кроме того конечно увеличить max_file_cache насколько это возможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2005, 14:47 |
|
||
|
База с большим количеством таблиц
|
|||
|---|---|---|---|
|
#18+
Это-то понятно, что тормоза из-за файловой системы) Кстати, ФС как раз UFS, правда не на солярке, а на фре... Насчёт применения же innodb для сокращения количества файлов... Ну станет их в 3 раза меньше, это не слишком принципиально, я хотел выяснить, есть ли результат от замены хранения данных в файловой системе на использование собственного формата хранения MySQL на выделенном разделе (без ФС)... Похоже, придётся действительно проверять самому, но мб у кого-то есть опыт такого использования, всё же?) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.01.2005, 16:02 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=32870231&tid=1854413]: |
0ms |
get settings: |
5ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
32ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 201ms |
| total: | 300ms |

| 0 / 0 |
