Ladycharm
В blob у меня хранится строка, длинною в 256 символов (вернее, цифр) и ужатая COMPRESS(). Если буду хранить ее несжатой, то таблица увеличится в 2,5 раза.
Разнести все по разным таблицам - это светлая идея, на мой взгляд.
Только 2.5 млн записей - это легкий тест. В продакшен будет намного больше. Если дойдет до этого... Так что хочу сделать все, чтобы максимально оптимизировать все.
CREATE TABLE `compkey3_all` ( `id` int(11) NOT NULL, `hash` varchar(32) NOT NULL, `userpage` int(11) NOT NULL, `aspect_ratio` int(3) NOT NULL, `ban_micro` tinyint(1) NOT NULL DEFAULT '0', `sumkey` smallint(3) NOT NULL DEFAULT '-1', `sumkey2` smallint(3) NOT NULL DEFAULT '-1', `sumkey3` smallint(3) NOT NULL DEFAULT '-1', `sumkey4` smallint(3) NOT NULL DEFAULT '-1', `data` blob NOT NULL, `url` varchar(100) NOT NULL, PRIMARY KEY (`id`), KEY `aspect_ratio` (`aspect_ratio`,`sumkey`,`sumkey2`,`sumkey3`,`sumkey4`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8
ID в запросах менял, чтобы не попасть на кешированный.
mysql> EXPLAIN SELECT `url`, `id` FROM `compkey3_all` WHERE `id` IN (1132, 1121788, 2052549, 509293, 15327, 58768, 1392430, 70563, 1760542, 1508491, 855960, 1917756, 937399, 353284, 2538159, 2408333, 2440320, 850478, 975793, 397821, 1179823, 487267, 1840621, 947858, 1415031, 962665, 2018237, 410593, 2548717, 808541, 98786, 421398, 1508731, 1627583, 1838721, 1738314, 499018, 2392849, 1324458, 484759, 1697525, 2406728, 692130, 2474748, 648260, 1673936, 2074852, 1997629, 11970, 722991); +----+-------------+--------------+-------+---------------+---------+---------+------+------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+--------------+-------+---------------+---------+---------+------+------+-------------+ | 1 | SIMPLE | compkey3_all | range | PRIMARY | PRIMARY | 4 | NULL | 50 | Using where | +----+-------------+--------------+-------+---------------+---------+---------+------+------+-------------+ 1 row in set (0.00 sec)
mysql> SHOW PROFILES; | Query_ID | Duration | Query | 1 | 0.80887575 | SELECT `url`, `id` FROM `compkey3_all` WHERE `id` IN (1511, 1621588, 2072749, 589293, 85327, 57788, 1392430, 70563, 1768742, 1508491, 875960, 1117756, 937179, 713284, 1538159, 2478133, 2440320, 750478, 155793, 357821, 1119823, 489567, 1840621, 947858, 1515031, 962665, 2019237, 410593, 2548717, 80454 |
Такой запрос выполняется за 0,5...2 сек.
База данных лежит на USB-HDD. На скрине его параметры. Основной жесткий диск примерно 2 раза быстрее. И производительность базы на нем тоже примерно 2 раза лучше (как понимаете, это не погоды не делает).
Один сайт на virtualbox. HDD ничем не занят, идет только 1 запрос.
Я через phpmyadmin порой смотрю время выполнения запросов. Он пошуршит венчестером секунды 3, а потом родит "время выполнения запроса 0,25 секунд". Вот поэтому и смотрю реальное время.
Надо сказать, OPTIMIZE TABLE дал эффект. Выборки стали раз в 5-10 быстрее. Но при больших выборках все ровно более 1 сек...
Единственное, что "недоговорил", это то, что время выполнения запросов измеряю через PHP скрипт (записал текущее время, запустил запрос, сравнил время).
Виртуалка - VirtualBox с Debian и сетевым интерфейсом типа мост, запущенный на хостовой Windows7.
Ничего там в IO не упирается. Запускал весь проект на сервере (просто ставил debian на свой комп "нативно"), все работает примерно так же. Криво спроектирована БД - не исключено, не эксперт я...
i4e
Может база лежит на SSD? Моя на HDD
Dinozavr
Все на виртуалке крутится пока что. Дело до паблика еще не дошло.
- 2Гб оперативной памяти
- 1 ядро от Intell Core i5 3700 МГц
- Debian + apache2 + .....
LEOnidUKG
1. Ok. попробую запустить и почитаю что это делает
2. Пользователь пока что один (запросы идет по одному). Но потом сделаю InnoDB
3. Не получится в MEMORY, есть поле BLOB с бинарными данными 90-150 байт. Но на RAM диске работало очень быстро (проект будет расти, в памяти держать не выйдет)
4. Кеш запросов не поможет. Каждый раз ID разные.
kxk
Про сфинкс почитаю. Хотя мне кажется это не мой случай. Тут не поиск, в просто выборка по ID.
primari key - это уже индекс, как я понимаю. Другой индекс по этому полю строить по идеи не нужно.
По category_id не понял. Видимо, это не мой случай. Все записи в таблице относятся к одной категории, так сказать. Их нельзя разделить по какому-то признаку, облегчающему выборку.
vkusnoserver, А для него нужен выделенный сервер со специальным демоном?
Или на PHP хостинг ставится?
Кешируется 1 раз на сессию. Если закрыть и открыть браузер снова, то картинка начнет грузиться по-новой.
Интегрировать через "data:" не выйдет, картинку пользователь выбирает сам. Если бы это было возможно, то я бы разместил файл в каталоге расширения и не парился с выгрузкой из сети.
Про кеширование прочту, спасибо
