Друзья, честно говоря этим топиком и последующим я хотел поднять у сообщество интерес к тебе Баз Данных. Различных Баз, не обязательно мускула. Чтобы люди делились решениями различных проблем, делились опытом, и найденными задокументированными и незадокументированными фитчами той или иной СУРБД. Я напишу еще пару статей, в который расскажу с чем пришлось сталкиваться мне в течение профессионального опыта. Посмотрите как мало статей в блоге MySQL. А сколькие из нас с ней работают? Притом здесь, как я понимаю много PHP-иков и Джавистов на сайте. А потом возникают вопросы, почему приложения медленно работают, почему запросы медленно выполняются, и что нужно делать. Или Вы, опытный программист, приходите в новую солидную фирму, и Вам дают проект на саппорт, который был написан кое как. Притом ядро этого проекта, архитектура базы настолько корявы, а заказчик не хочет выделять дополнительное время и деньги, чтобы его полностью переписать… И вы сидите и копаетесь в этой куче… А все почему, потому что до вас его писали кое как, не думая, да, я понимаю, что гораздо проще жаловаться на соринку в чужом глазу, не замечая бревна в своём. Но все же. Основные подводные и надводные камни при работе с базами данных должен знать любой программист, который с ними работает.
Вот я и хочу возродить такой интерес, как среди авторов, так и среди читателей.
Я не гонюсь за высокой кармой и хабросилой, мне главное чтобы хватало для того чтобы писать и ставить плюсы тем, чье мнение мне показалось интересным и тем, кто, в частности, помог мне советом.
Но мы обратно скатываемся на холливар, где, одни люди начинают ругать других…
Эта статья была написана ранее (позавчера), чем моя вчерашняя по tips and tricks, но позже (только сейчас попала на главную). Тогда у меня была нулевая карма. Но я сейчас уберу эту просьбу из тела топика.
Договорились, значит я продолжу писать на эту тему. Уже и идея есть о чем писать. И код, просмотренный за последнее время, дает много поводов и примеров написать о том как писать не следует :-) Да и с отпуском у меня все таки не сложилось как оказалось :-(
Да, это, пожалуй, интересное решение по поводу смены PRIMARY KEY, нужно обязательно будет попробовать. После таких решений, порой, еще долго винишь себя, почему сам не предложил этого. Но Вам большое спасибо! И плюсы естественно :-)
Наконец вернулся домой. И могу Вам ответить. На самом деле я работаю PHP программистом, а не Java. И использую другие ORM нежели Hibernate. Я использовал Propel, Doctrine и т.д.
Не в этом дело. Просто не всегда следует использовать продукт как есть as is. Yahoo, например, использует symfony PHP framework, который юзает ORM Propel (кстати, мне нравится как Symfony так и Propel :-)) для своей answers.yahoo.com/ со 135 миллионами пользователей habrahabr.ru/blogs/symfony/25040/. Но они переписывали какие-то части под себя, оптимизировали. На самом деле ОРМ нужен не во всех проэктах, например, в небольших точно не нужен, лишние трудности. А большой проект, который будет писаться и поддерживаться несколько лет разными программистами, возможно в разных странах… Тут гораздо удобней поддерживать код, написанный с помошью ОРМ.
Да, в мускуле порой творят странные вещи, порой даже такие, о которых не знают и его «авторы». Но я показал вам то, что я вижу когда делаю EXPLAIN запроса. И этот эксплейн показывает мне, что с добавлением «order by null» — Using filesort ушел. Честно говоря в этом случае я больше верю своим глазам. Когда прийду домой поищу в интернете есть ли ссылки в Интернете на что-то подобное.
Извините, все кому не получается сразу ответить. Я когда домой прийду обязательно напишу свое мнение по поводу ORM и больших проектов. По поводу Ваших предложений относительно возможных решений, поставленной задачи.
Просто последний рабочий день перед отпуском, а работы выше крыши :-(
И надо все успеть именно сегодня…
Наблюдал его на объемах данных порядка 2 млн. записей. Тип — варчар(255). Выделенный сервер БД, 16 ГБ оперативной памяти. Про процессор врать не буду — не помню.
Это решение у нас тогда не прижилось т.к. в некоторых значения был замечен очень высокий уровень коллизий. После исследования было обнаружено, что GROUP BY берет 2^32 как максимальное число для группировки. Не помню какая тогда стояла версия мускула на продакшене, т.к. было это пол года назад. 5.0*. Но потом оказалось, что если приводить тип к BINARY, то и это можно обойти
>А фраза трактовалась скорее всего так: если первый запрос воспользовался индексами n..., то они >теперь в кеше :)
я думал это понятно :-) Впредь буду осторожней выбирать выражения.
И в остальном с Вами согласен.
Вот я и хочу возродить такой интерес, как среди авторов, так и среди читателей.
Я не гонюсь за высокой кармой и хабросилой, мне главное чтобы хватало для того чтобы писать и ставить плюсы тем, чье мнение мне показалось интересным и тем, кто, в частности, помог мне советом.
Но мы обратно скатываемся на холливар, где, одни люди начинают ругать других…
Не в этом дело. Просто не всегда следует использовать продукт как есть as is. Yahoo, например, использует symfony PHP framework, который юзает ORM Propel (кстати, мне нравится как Symfony так и Propel :-)) для своей answers.yahoo.com/ со 135 миллионами пользователей habrahabr.ru/blogs/symfony/25040/. Но они переписывали какие-то части под себя, оптимизировали. На самом деле ОРМ нужен не во всех проэктах, например, в небольших точно не нужен, лишние трудности. А большой проект, который будет писаться и поддерживаться несколько лет разными программистами, возможно в разных странах… Тут гораздо удобней поддерживать код, написанный с помошью ОРМ.
Просто последний рабочий день перед отпуском, а работы выше крыши :-(
И надо все успеть именно сегодня…
dev.mysql.com/tech-resources/articles/getting-started-with-bazaar-for-mysql.html
А потом не забудьте написать об этом статью :-)
Но зачастую все такие эксперименты остаются экспериментами и на продакшн сервер их не поставишь :-(
* maxshopen просто описался в лишнем нуле :-)
Это решение у нас тогда не прижилось т.к. в некоторых значения был замечен очень высокий уровень коллизий. После исследования было обнаружено, что GROUP BY берет 2^32 как максимальное число для группировки. Не помню какая тогда стояла версия мускула на продакшене, т.к. было это пол года назад. 5.0*. Но потом оказалось, что если приводить тип к BINARY, то и это можно обойти
как-то так
mysql> SELECT tag, COUNT(*) AS count, crc32(tag), BINARY crc32(tag)
-> FROM tags
-> GROUP BY BINARY crc32(tag)
-> ORDER BY count DESC
-> LIMIT 10
->;
+————+——-+————+——————-+
| tag | count | crc32(tag) | BINARY crc32(tag) |
+————+——-+————+——————-+
| spanish | 4576 | 874050868 | 874050868 |
| vocab | 4103 | 1178479308 | 1178479308 |
| vocabulary | 2786 | 2147483647 | 2425997691 |
| french | 2247 | 2147483647 | 2943733342 |
| english | 2087 | 746783232 | 746783232 |
| science | 1957 | 1729573288 | 1729573288 |
| latin | 1411 | 1421320458 | 1421320458 |
| chapter | 1274 | 2147483647 | 4186027310 |
| history | 1171 | 666529867 | 666529867 |
| words | 939 | 1904025228 | 1904025228 |
+————+——-+————+——————-+
но было уже поздно, и мы воспользовались другим решением.
кстати, заодно и ссылку нашел, которая косвенно подтверждает мои слова.
www.mysqlperformanceblog.com/2008/03/07/speeding-up-group-by-if-you-want-aproximate-results/#comment-272067