kalim

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:" не выйдет, картинку пользователь выбирает сам. Если бы это было возможно, то я бы разместил файл в каталоге расширения и не парился с выгрузкой из сети.

Про кеширование прочту, спасибо