Поиск  Пользователи  Правила 
Закрыть
Логин:
Пароль:
Забыли свой пароль?
Войти
 
Страницы: 1
RSS
MySQL (4096 таблиц)
 
Вобщем приспичило создать в одной из БД 4 тысячи таблиц. Это нормально? Ничего плохого не случится?
И как смотрят на это мускуль и постгресс?
И что будет работать быстрее: мускуль или постгресс?
(соединение с БД и несколько сотен запросов; 2 поля, оба - строки (16 и 32 символа))


--я нуб в БД  
 
ставь MySQL - четверку
 
Цитата
MySQL manual пишет:

Если в каталоге присутствует большое количество файлов, то операции открытия, закрытия и создания будут медленными. Выполнение значительного количества команд SELECT на большом количестве разных таблиц приводит к небольшим непроизводительным затратам при заполненном табличном кэше, поскольку для открытия одной таблицы требуется закрыть другую. Чтобы сократить эту перегрузку, следует увеличить табличный кэш.
 
а ограничения на размер БД нету никакого у мускуля? я слышал про 2 гига?
 
ограничение накладывает файловая системы, где расположены таблицы. Для FAT 32 это будет 2 гига. Для нормальных файловых систем (NTFS, юниксовские файловые системы) , ограничений нет или они недостежимы в этой жизни.
 
вот ссылка:
http://dev.mysql.com/doc/mysql/ru/table-size.html
 
sankus, немного не то: размер таблицы больше 10 метров навряд ли поднимется
я про размер БД
за ссылку спасибо

Phoenix,
> Если в каталоге присутствует большое
> количество файлов, то операции открытия,
> закрытия и создания будут медленными.
4096 - большое количество? это зависит от файловой системы?
 
Ща тебе объясню, о чём здесь толкуют.

В MySql каждой базе данных соответствует 1 директория.
Каждой таблице соответствует, как правило 3 файла в этой директории базы данных.

Т.е в этой директории будет 4000 * 3 = 12000 файлов.

MySql пофигу, сколько у тебя там таблиц, а вот насколько быстро твоя ОС будет находить файл в этой директории? Что он есть, что его нет?


А вообще к MySql прилагаются benchmark тесты, вот, смотри:
Описание:
This test is for testing how long it takes to create tables, make a count(*) from them and finally drop the tables.
Результат:
[root@MishaStrij sql-bench]# ./test-create
Testing server MySQL 3.23.49 log at 2005-06-08 20:07:55

Testing the speed of creating and dropping tables
Testing with 10000 tables and 10000 loop count

Testing create of tables
Time for create_MANY_tables (10000): 157 wallclock secs ( 2.22 usr  0.26 sys +  0.00 cusr  0.00 csys =  2.48 CPU)

Accessing tables
Time to select_group_when_MANY_tables (10000): 39 wallclock secs ( 0.61 usr  0.16 sys +  0.00 cusr  0.00 csys =  0.77 CPU)

Testing drop
Time for drop_table_when_MANY_tables (10000): 15 wallclock secs ( 0.29 usr  0.09 sys +  0.00 cusr  0.00 csys =  0.38 CPU)

Testing create+drop
Time for create+drop (10000): 14 wallclock secs ( 1.97 usr  0.26 sys +  0.00 cusr  0.00 csys =  2.23 CPU)
Time for create_key+drop (10000): 14 wallclock secs ( 1.69 usr  0.21 sys +  0.00 cusr  0.00 csys =  1.90 CPU)
Total time: 239 wallclock secs ( 6.78 usr  0.98 sys +  0.00 cusr  0.00 csys =  7.76 CPU)

Система:
AMD 1600, ext3, Linux kernel 2.4.18-3, MySql 3.23.49-log

А вообще, что за задача такая, где не обойтись несколькими таблицами?

 
>А вообще, что за задача такая, где не обойтись несколькими таблицами?

Просто я буду делать select из одной таблицы(заранее знаю, какой), а остальные трогать не нужно(таблицы однотипные)

это же будет быстрее, чем искать в одной огромной таблице?

думаю остановиться на 250 таблицах, спасибо, вопрос снят
 
Цитата
nerezus пишет:
это же будет быстрее, чем искать в одной огромной таблице?
удивлюсь, если быстрее окажется, скорее всего это кривость.
 
есть bdb и innodb технологии (в mysql) -- там один (или сколько захочешь) для данных, т.е. реально в одном файле много таблиц храниться, а поддержку больших файлов можно врубить призапуске (параметром)...
Страницы: 1
Читают тему