Оптимизация - из 400 таблиц -> одну

[Апокалипсис]

Оптимизация - из 400 таблиц -> одну

Здравствуйте.
Ситуация такая. Есть крупный проект наподобии Яндекс Маркета.
В базе 400 таблиц. В каждой таблице от 1 до 2000 записей. В итоге около 200 000 записей и уже тормозит.
Майадмин открывает базу с этими таблицами за 15 сек.
Вообщем приняли решение переписывать проект и сделать из 400 таблиц - 1.

Сейчас все таблицы price_ имеют такую структуру:
[sql]
CREATE TABLE `price9` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(255) DEFAULT NULL,
`companyid` int(11) DEFAULT NULL,
`marked` tinyint(4) DEFAULT NULL,
`retail` float DEFAULT NULL,
`wholesale` float DEFAULT NULL,
`borntime` int(11) DEFAULT NULL,
`url` varchar(255) NOT NULL DEFAULT '',
`picture` varchar(255) NOT NULL DEFAULT '',
PRIMARY KEY (`id`),
KEY `name_3` (`name`),
FULLTEXT KEY `name` (`name`),
FULLTEXT KEY `name_2` (`name`)
) ENGINE=MyISAM ;
[/sql]

Опредление чему принадлежит таблица идёт след образом:
телевизоры price5
холодильники price10
моб. телефоны price200
Планируется все товары хранить в 1 таблице сделать поле id товара. Назначить каждому товару id и цеплять так.

Вопрос таков:
1. Правильно ли я мыслю?
2. Какую посоветуете структуру (планируемое число записей 1 000 000) ?

 

[Mols]

хм... А что тормозит у Вас ? Я лично не понял. 400 таблиц это конечно сложно назвать грамотной организацией... но не факт, что проблема именно в этом. И зачем три раза ключ на поле `name` ?

 

[Апокалипсис]

Тормозят запросы.
Сильнее всех тормозят UPDATE и DELETE и SELECT
Про поиск - молчу
Структура неудачная да - всё равно её нужно переписывать.
Чем сейчас и занимаюсь.
Вот ещё не определился как будет лучше...
А что имел ввиду тот автор делая столько ключей - я ещё не вкурил

 

[Krishna]

Апокалипсис
В MyISAM каждая таблица представляется отдельным файлом. И, хотя с точки зрения организации архитектуры 400 таблиц это кривизна, но с точки зрения скорости выполнения запросов - можно с очень высокой степенью вероятности утверждать, что от простого объединения 400 таблиц в одну таблицу (читай в один большой файл) прироста производительности не будет.

Майадмин открывает базу с этими таблицами за 15 сек.

Очень странно. Либо сервер совсем никакущий, либо какие-то проблемы с файловой системой, возможно железо...
Для сравнения - у меня на сервере майадмин открывает базу с 77 таблицами меньше чем за одну секунду.

Какой размер базы в мегабайтах?
Какой сервер используется и крутится ли на нём что-то еще?
В общем, нужно провести полный анализ ситуации, а не надеяться на изменения к лучшему, которые ни с того, ни с сего произойдут после слияния таблиц в одну.

 

[fixxxer]

>В MyISAM каждая таблица представляется отдельным файлом

В соответствующим образом настроенном InnoDB - тоже.

Как там открывает какой-то-чего-то-админ - это не показатель. Если одновременный поиск по таблицам не нужен - не вижу смысла сливать в кучу. Если бы было не 400, а 40000, то тут конечно уже начались бы проблемы с количеством открытых файлов и ФС, угу.

 

[Krishna]

А что имел ввиду тот автор делая столько ключей - я ещё не вкурил

Ну, это вот точно излишество:

FULLTEXT KEY `name` ( `name` ) ,
FULLTEXT KEY `name_2` ( `name` )

 

[fixxxer]

ох, там MyISAM... и куча апдейтов-инсертов небось... и таблички лочаится целиком - если будет все в одной, то вообще п-ц. пробуй сразу InnoDB.

 

[Krishna]

Как там открывает какой-то-чего-то-админ - это не показатель.

Нет, это вполне показатель наличия серьёзных проблем на сервере. Чем они вызваны - совсем другой вопрос.

 

[Апокалипсис]

Объем базы пока что ~ 200 метров.~ 1200 файлов
Сервер:
2 Xeonа 1.8Ггц
1.5 гб Рам
Крутятся на сервере малопосещаемые проекты.
Этот посещают 7 - 10 к в сутки

 

[Krishna]

fixxxer
откуда в каталоге товаров куча апдейтов/инсертов? ИМХО, преждевременное утверждение, предлагаю подождать новых подробностей от топикстартера

 

[Апокалипсис]

Ну, это вот точно излишество:

FULLTEXT KEY `name` ( `name` ) ,
FULLTEXT KEY `name_2` ( `name` )

соглсасен я ещё не разбирался что там, подозреваю что для поиска. Только сегодня взял проект. В кратком ТЗ - оптимизация - а именно слив 400 таблиц в 1

 

[fixxxer]

fulltext в жопу, словарик/стеммер и по id-ам. ну или sphinx заюзать

-~{}~ 02.11.07 19:09:

а вообще, конечно, для начала берем селекты и смотрим explain

 

[Krishna]

Апокалипсис
Ну, 200 метров это немного для мускула.
Кстати, какая версия? и какой my.cnf?
Нужно смотреть SHOW FULL PROCESSLIST и смотреть какие запросы тормозят более остальных.
+ можно попробовать запустить slow_query_log - т.к. думаю самые медленные будут выполняться более 1 секунды..

Еще стоит посмотреть закладку Состояние в Myadmin (под рутом) - какие переменные имеют критические значения в статистике mysql.

-~{}~ 02.11.07 19:11:

fulltext в жопу

Опять же, обосновать?

 

[Апокалипсис]

Вот я тут не припомню... сколько mysql может макс открытых файлов держать?
там что то 400 что ли ?
блин инет тупит ужасно

а вообще, конечно, для начала берем селекты и смотрим explain

да это я всё потестирую. Просто вот теоретически хотелось бы узнать в правильном направлении копать..

-~{}~ 02.11.07 19:13:

Кстати, какая версия? и какой my.cnf?

версия последняя 5.1
конфиг сейчас посмотрю

-~{}~ 02.11.07 19:18:

Конфиг:
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
max_connections=100
query_cache_size=100M
table_cache=256
tmp_table_size=77M
thread_cache_size=8

#*** MyISAM Specific options
myisam_max_sort_file_size=100G
myisam_max_extra_sort_file_size=100G
myisam_sort_buffer_size=154M
key_buffer_size=256M
read_buffer_size=64K
read_rnd_buffer_size=256K
sort_buffer_size=1M

-~{}~ 02.11.07 19:20:

Просто планируется до 1 000 000 записей - но если при 200 000 уже идут тормоза то вот задумались об оптимизации

 

[Krishna]

Ну, на самом деле, самые "нереальные" тормоза в случае MyISAM могут быть действительно из-за блокировок при конкурирующих чтениях/записи.
В общем, начинать надо с processlist и поиска тормозящиъ запросов.
Конфиг, кстати, самопальный - лучше заменить на medium.cnf.
В нём query_cache_size можно поставить 50 метров.
Кстати, еще неплохо посмотреть что пишет top по поводу использования оперативной памяти. Чрезмерно большие значения буфферов могли привести к тому, что мускул отожрав памяти начал принуждать систему использовать своп.

 

[Апокалипсис]

Ну, на самом деле, самые "нереальные" тормоза в случае MyISAM могут быть действительно из-за блокировок при конкурирующих чтениях/записи.

Вот это и подозревается

Ладно за выходные всё замерю - перемерю посмотрю - и напишу о результатах.

 

[Alexandre]

параллельно тряси начальство на память, на 4Гб

InnoDB - лучше использовать - это факт. Будет лочится не вся таблица, а только ее часть.
переделывать ли 400->1 это еще вопрос. Все зависит от логики выборки.

10к посетителей - не так уж и много. Проблемы могут быть как в БД, так и с железом,
ну и скрипт отдачи может быть кривой.

 

[Gas]

Только для innodb нужно учитывать что fulltext работать не будет и крутить настройки не key_buffer_size, а своих переменных. К тому же стоит всё таки проверить в чём проблема, из-за локов (тогда innodb самый простой способ ускорить) или нет.

Ну, на самом деле, самые "нереальные" тормоза в случае MyISAM могут быть действительно из-за блокировок при конкурирующих чтениях/записи.

блокировки на myisam легко возникают и при одних долгих select'ах, без инсертов. К тому-же для myisam обещают Concurrent Inserts.
Вообще-то таблица каталога обычно редко обновляется, а 1M записей на select'ах не должно быть проблемой ни для myisam, ни для innodb при правильных ключах и если сканится не вся таблица.

 

[Krishna]

блокировки на myisam легко возникают и при одних долгих select'ах, без инсертов.

Никогда не сталкивался. И откуда там берутся блокировки?

 

[Gas]

И откуда там берутся блокировки?

и при одних долгих select'ах

не всегда приложения пишутся оптимально и с ростом количества записей/посещаемости может начать проседать скорость выборок, вот тебе и локи на table-level locking engine.