Open source models database

ibiz писал:

быстрее на порядок, 30сек против 300сек...

Это много, да.

Для начала сделай innodb_flush_logs_at_trx_commit = 2 и проверь ещё раз.

не помогло... и с памятью игрался и с другими настройками базы...
скажи, почему innodb работает медленнее myisam?

Что значит не помогло? Как-то изменилось время выполнения?

Вопрос ахтунг. Ответ: ACID.

ibiz: Попробуй теперь в таблице data сделать связку с names не по полю varchar, а по ID, причем грамотно, через FK.

Ну и для начала, в образовательных целях, explain на свой select запусти, посмотри на кошмарики, почеши затылок 300 секунд - очень много, но и 30 секунд на запрос... ну как бы это так описать... не образец скорости

Также

Код:

LEFT JOIN data ON names.name=data.name ... WHERE data.name IS NULL

...при том, что колонка name везде объявлена как NOT NULL - это для меня вообще загадка.

Надо ж в код иногда смотреть, что пишешь...

Dr.Syshalt писал:

ibiz: Попробуй теперь в таблице data сделать связку с names не по полю varchar, а по ID, причем грамотно, через FK. Ну и для начала, в образовательных целях, explain на свой select запусти, посмотри на кошмарики, почеши затылок 300 секунд - очень много, но и 30 секунд на запрос... ну как бы это так описать... не образец скорости

а я там писал, что data - внешняя независимая таблица, чтоб сделать связку, надо выбрать ид из names и вставить их в data...

Dr.Syshalt писал:

Также Код: LEFT JOIN data ON names.name=data.name ... WHERE data.name IS NULL ...при том, что колонка name везде объявлена как NOT NULL - это для меня вообще загадка. Надо ж в код иногда смотреть, что пишешь...

а как правильно выбрать из таблицы names значения name отсутствующие в data?

NOT IN

ibiz писал:

а я там писал, что data - внешняя независимая таблица, чтоб сделать связку, надо выбрать ид из names и вставить их в data...

Такое сравнение скоростей - это как закинуть Москвич и 5й BMW в грязь, смотреть, кто быстрее выберется, и делать выводы о скорости :-) Ни индексов, ничего вообще.
Я, кстати, думаю, что Москвич выберется быстрее.

Цитата:

а как правильно выбрать из таблицы names значения name отсутствующие в data?

Сабселект.

SELECT ... WHERE ... NOT IN (SELECT ...)

Dr.Syshalt писал:

Такое сравнение скоростей - это как закинуть Москвич и 5й BMW в грязь, смотреть, кто быстрее выберется, и делать выводы о скорости :-) Ни индексов, ничего вообще. Я, кстати, думаю, что Москвич выберется быстрее. Сабселект. SELECT ... WHERE ... NOT IN (SELECT ...)

NOT IN предполагает использование всего одного поля из таблицы
каких индексов, чего всего нет?
приведи примеры выборок/поиска, где по скорости innodb выигрывает у myisam

ibiz писал:

NOT IN предполагает использование всего одного поля из таблицы

Ну а тебе сколько надо?
Слушай, не выноси мозг, мне сейчас себя и работать-то заставлять приходится, а тут еще ты со своими селектами ))

Цитата:

каких индексов, чего всего нет?

Ничего нет Вообще. Посмотри уже, наконец, что тебе explain скажет на твой запрос. Знаешь, как им пользоваться?

Цитата:

приведи примеры выборок/поиска, где по скорости innodb выигрывает у myisam

Тебе yacc уже приводил бенчмарки, тебе не понравилось почему-то. А я говорю о реальном мире, а не об этом твоем игрушечном SELECT'е, который 30 секунд - это "быстро" (а на самом деле за это руки отрывают ;) ). На веб-приложениях современных innodb будет быстрее. Потому, что он развивается быстрее, чем старый MyISAM, потому что в нем нет табличных блокировок на записи. В нынешних приложениях - около половины запросов не SELECT'ы. А если у тебя 99% именно SELECT'ов, то это все из той категории "что-то делаете не так" - потому что как нехер в базу лезть каждый раз, как страница показывается - только для того, чтобы каждый раз достать одни и те же данные. За это тоже надо руки отрывать - опа, и нету. Ибо для этого кэши есть. MyISAM - для OLAP. Все. И то я бы подумал лишний раз, а то потом будешь ждать, пока админ с myisamchk собирает базу по кускам после какого слета, я так насиделся уже. Теперь вы меня понимаете, Мистер Андерсон?

Dr.Syshalt писал:

А я говорю о реальном мире, а не об этом твоем игрушечном SELECT'е, который 30 секунд - это "быстро" (а на самом деле за это руки отрывают ;) ).

ну покажи пример быстродействия, без модификации основных полей таблиц и данных, т.к. они внешнии и не подлежат изменению, а копирование занимает десятки минут...
или я верно думаю: на словах ты лев толстой, а на деле хуй простой?

ibiz: Я тебе о том, что у тебя изначально криво сделано, что такие запросы приходится делать, а ты мне опять "покажи мне SELECT на моей базе из жопы".

Если она не модифицируема, то как ты с innodb сравнивал, сказочник? Хочешь производительности - переделывай свою говнобазу, я тебе о чем говорю. Я 10 раз сказал уже, что innodb любит нормализованные данные. И на них он быстрее будет.

"Обожаю" таких лопухов - ты им что-то рассказываешь, объясняешь, а они только о понтах думают. Сам ты хуй простой, придурок. Базар фильтруй в будущем.

ibiz писал:

NOT IN предполагает использование всего одного поля из таблицы

В каком месте?

Прекрасный топег

По сути вопроса - MyISAM зачастую быстрее, но лочить таблицы в условиях какого-никакого фреймворка - это такой геморрой, что лучше уж транзакции InnoDB. Аффтор, конечно же, не задумался, что моделей в базу может вносить одновременно 10 человек?..

Цитата:

Аффтор, конечно же, не задумался, что моделей в базу может вносить одновременно 10 человек?..

моделей в базу буду вносить только я...
это простой каталог моделей а не аналог какого нибудь freeones

Цитата:

дано 3 таблицы names - действующие имена с присвоенными id user_rank - ранк пользователя data - внешняя независимая таблица по которой идет сверка и поиск отсутствующих в таблице 'names' пользователей с рейтингом больше 100 во каждой таблице записей ~10m MyISAM работает быстрее InnoDB

Проблем довольно много в этой модели и настройках. Основные это:
- InnoDB организует все данные и ключи по первичному ключу, поэтому работа с ними по ПК очень быстрая. Дополнительные индексы тоже организованы по нему - хранят значение первичного ключа как ссылку на данные. Поэтому нужно очень внимательно выбирать его тип данных, в данном случае этого не было сделано.
- Связывание таблиц по VARCHAR очень дорогая и медленная операция, но тут будет плохо любому хранилищу
- Пример запроса скорее всего создает гигантскую временную таблицу чтобы удовлетворить запрос. Поскольку первичные ключи выбраны неверно, размер данных InnoDB должен быть существенно выше, чем MyISAM, следовательно нужно прочитать гораздо больше данных с диска.
- MyISAM полагается на кеш ОС очень сильно для кеширования данных, для ключей выделяется своя отдельная структура. Поэтому без настроек MyISAM работает изначально лучше, полагаясь на кеш ОС. InnoDB использует свой внутренний кеш, который гораздо более эффективен кеша общего назначения потому что он специализирован, но о нем нужно знать и правильно выбрать размер, отталкиваясь от своих данных.
Смысл всего этого в том что если просто поставить, включить и запустить MyISAM будет быстрее, но если все сделать правильно со знанием дела InnoDB порвет его без проблем.
Пролема с блокироваками таблиц в MyISAM вообще ставит крест на его использовании при определенных типах нагрузок.

iRoot писал:

Проблем довольно много в этой модели и настройках. Основные это: - InnoDB организует все данные и ключи по первичному ключу, поэтому работа с ними по ПК очень быстрая. Дополнительные индексы тоже организованы по нему - хранят значение первичного ключа как ссылку на данные. Поэтому нужно очень внимательно выбирать его тип данных, в данном случае этого не было сделано. - Связывание таблиц по VARCHAR очень дорогая и медленная операция, но тут будет плохо любому хранилищу - Пример запроса скорее всего создает гигантскую временную таблицу чтобы удовлетворить запрос. Поскольку первичные ключи выбраны неверно, размер данных InnoDB должен быть существенно выше, чем MyISAM, следовательно нужно прочитать гораздо больше данных с диска. - MyISAM полагается на кеш ОС очень сильно для кеширования данных, для ключей выделяется своя отдельная структура. Поэтому без настроек MyISAM работает изначально лучше, полагаясь на кеш ОС. InnoDB использует свой внутренний кеш, который гораздо более эффективен кеша общего назначения потому что он специализирован, но о нем нужно знать и правильно выбрать размер, отталкиваясь от своих данных. Смысл всего этого в том что если просто поставить, включить и запустить MyISAM будет быстрее, но если все сделать правильно со знанием дела InnoDB порвет его без проблем. Пролема с блокироваками таблиц в MyISAM вообще ставит крест на его использовании при определенных типах нагрузок.

почти все верно, только задача стоит такая, чтоб сверять не по цифровому индексу поля, а по почти полнотекстовому, с этим InnoDB справляется хуже MyISAM, и никак от этого сравнения не уйти
кстати многие крупные ру-шаред-хостинги не поддерживают InnoDB в виду создаваемой им высокой нагрузки на сервер, как отвечает саппорт

ibiz писал:

почти все верно, только задача стоит такая, чтоб сверять не по цифровому индексу поля, а по почти полнотекстовому, с этим InnoDB справляется хуже MyISAM, и никак от этого сравнения не уйти кстати многие крупные ру-шаред-хостинги не поддерживают InnoDB в виду создаваемой им высокой нагрузки на сервер, как отвечает саппорт

Любая система хранения очень плохо справляется с JOIN по текстовым полям, особенно по utf8, особенно по case insensitive, просто потому что нужно произвести гораздо больше операция для этого.
От такого сравнения можно уйти довольно просто, например используя дополнительную таблицу-словарь, хеш-поле. Если действительно нужно почти полнотекстовое решение, тут может помочь метод шинглов например.
Конечно сложно судить о возможных решениях задачи не зная ее, профиль нагрузки на сервер, тип данных, их распределение и тд. Но все же при написании любой сложной системы нужно использовать инструменты правильно, тогда они будут вести себя хорошо и предсказуемо.
"ру-шаред-хостинги" вообще не аргумент

пишЫте еще

MyIsam -> InnoDB -> MyIsam конвертации делаются за пару минут, х.з. чего заморачиваться с этим вопросом.
Ну ладно если бы выбиралась база данных, можно было бы поспорить, а так тупо тип таблиц

Ну это только для очень маленьких таблиц такое верно. А разница между MyISAM и InnoDB огромна, они совершенно по разному ведут себя при разных типах нагрузок и распределении данных.
Хотя когда в базе данных 1000 записей и к ней обращаются 1 раз в час, то можно городить все что угодно, будет работать хорошо, хоть все в текстовых файлах хранить.
Заморачиваться приходится когда вдруг пошла посещаемость, а база данных лежит, бизнес тоже соответственно, тогда начинаются костыли из кеширования, репликации, шардинга и тд, а всего-то нужно было думать что делаешь.
Я с таким неоднократно встречался в своей практике, причем большинство полагает что есть волшебный ключ в конфигурации сервера "run_fast = true", который просто забыли включить, а проблема на самом деле в приложении.

Для полнотекстового сравнения тогда уж вообще надо использовать надстройки типа того же сфинкса, мускуль вообще не для того сделан по сути, чтобы по текту сравнивать и пофигу майисам там или иннодб

А насчет быстрой конвертации типа таблиц, хех, ну да, когда в таблице больше 10 миллионов записей как-то не захочется прыгать с одного типа на другой постоянно.

Цитата:

когда в таблице больше 10 миллионов записей как-то не захочется прыгать с одного типа на другой постоянно.

а кто заставляет постоянно ? Сделал дамп, развернул с другим типом в другую базу, поменял имя базы в конфиге скрипта, посмотрел быстродействие - сделал выводы. Вот и все, зачем постоянно прыгать то.