Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 73
Нужная статья, таких надо больше. Коротко и по делу.
Ничего полезного в статье нет. Это для тех что ли, кто не знает английский и не может прочитать сухие технические данные из документации?
А нужные статьи с подходом «практика» и сравнением движков уже написаны.
А нужные статьи с подходом «практика» и сравнением движков уже написаны.
Все уже где-то когда-то написано. Мне полезно было ознакомиться с сегодняшним состоянием дел с MySQL. А в документацию лезть некогда. Кто знает — читает заголовок и пропускает.
Разве не удобно когда у тебя на одной странице описаны основные характеристики движков мускула? Или легче для этого перерыть десяток отдельных страниц документации?
Я согласен. Это неплохо, но в целом вместо перевода/пересказа/etc было бы гораздо интереснее прочитать личный опыт (это касается всех тем, не только MySQL).
Отличная шпаргалка, в закладки.
Очень содержательный комментарий, надо таких больше. Коротко и по делу.
А минусы-то забыли…
за подборку спасибо
Движек. реплекация, улучшеный
ДвижОк реплИкация, улучшенНый поправьте в статье, режет глаз.
Вообще с орфографией не очень :(, проверить бы текст хотя бы Вордом.
Движек. реплекация, улучшеный
ДвижОк реплИкация, улучшенНый поправьте в статье, режет глаз.
Вообще с орфографией не очень :(, проверить бы текст хотя бы Вордом.
Пустые заявления. Аргументируйте, или еще лучше напишите запись в блоге. Мне искренне интересно.
collations? кластер? partitioning? raw disk? memory engine?
По аналогии с этим топиком habrahabr.ru/blogs/linux/64957/ захотелось создать тему «Мифы и заблуждения, касающиеся MySQL» (спешл фор постгре юсерс)
Я люблю постгресс за возможность поиска по массивам и хэшам, хранящихся в ячейках таблиц.
Это позволяет гораздо удобнее работать с объектами — сохранять и восстанавливать их в/из БД.
Это позволяет гораздо удобнее работать с объектами — сохранять и восстанавливать их в/из БД.
Потому что нет проблем с ibdata.
Пользую обе базы.
MY — простая база, есть на всех хостингах. Часто заказывается клиентом при разработках.
PG — для серьезных проектов. И работать мне с ним на порядок приятней, один только CLI чего стоит по удобству. (работаю в шеле)
MY — простая база, есть на всех хостингах. Часто заказывается клиентом при разработках.
PG — для серьезных проектов. И работать мне с ним на порядок приятней, один только CLI чего стоит по удобству. (работаю в шеле)
Юзайте DB2 Express-C! (он намного быстрее, чем MySQL и фишек больше).
Тогда уж Oracle, он удобней в администрировании, да и спецов на поддержку больше
Хорошо что хоть не MSSQL предлагаете. И вообще, чего по реляционным базам всё, давайте переходить на объектные :)
Ну во первых MSSQL круче DB2 на порядки по простоте, удобству и кое-где по скорости (с Oracle не сравнивал).
Я его не предлагаю только потому, что он Win-only (и лимита на размер бесплатной базы).
Я его не предлагаю только потому, что он Win-only (и лимита на размер бесплатной базы).
Что касается object и document DB — напишите статью, будет оч. интересно, особенно если с опытом на большом объёме.
Выглядят они неплохо, но сам не пробовал.
Помню статью «давайте откажемся от реляционных баз», которую писали замучанные MySQL авторы какого-то стартапа.
У них индексы создавались несколько часов, локи, etc. Ну да, от такой базы мы и сами отказались.
Выглядят они неплохо, но сам не пробовал.
Помню статью «давайте откажемся от реляционных баз», которую писали замучанные MySQL авторы какого-то стартапа.
У них индексы создавались несколько часов, локи, etc. Ну да, от такой базы мы и сами отказались.
Хорошо что хоть не MSSQL предлагаете. И вообще, чего по реляционным базам всё, давайте переходить на объектные :)
4 Gb ограничение на размер бесплатной базы и 1 Gb на память.
медленная при чтение по ключу
Исправьте пожалуйста.
Исправьте пожалуйста.
Чего ж про falcon так мало? А federated? Руки устали копировать?
Да и вообще практической ценности никакой, кто бы там что не говорил про «удобство», любой может это за 10 минут накопировать из мануала. Про механизмы надо читать подробно, понимать их сущность, как они работают, а не по этим столбикам выбирать «при проектировании». Ладно бы ещё полная таблица была, а тут и то, незаконченные огрызки.
Да и вообще практической ценности никакой, кто бы там что не говорил про «удобство», любой может это за 10 минут накопировать из мануала. Про механизмы надо читать подробно, понимать их сущность, как они работают, а не по этим столбикам выбирать «при проектировании». Ладно бы ещё полная таблица была, а тут и то, незаконченные огрызки.
webiteam.ru/2009/03/mysql-storage-engines/
Я бы не сказал, что InnoDB — самый лучший для больших таблиц и самый быстрый.
Особенность механизма хранения индексов в InnoDB может как ускорить работу с базой, так и подвесить намертво самоё мощное железо.
Вот пример, как упал сервис Яндекса из-за InnoDB — softwaremaniacs.org/blog/2008/02/22/why-offline-crashed/
Дело в том, что он перестраивает индексы по порядку, собственно это и даёт скорость. Но если у вас вставляется множество данных с случайным ключом, те же сессии, это подвешивает жёсткий диск намертво.
И не говорите, что это ошибка конкретно этих программистов, многие из популярных скриптов, CMS, форумов и пр. тоже стартуют сессию на каждого посетителя.
P.S. вообщем, к выбору движка надо подходить с умом и для каждого проекта решать этот вопрос индивидуально.
У MyISAM есть уникальные преимущества (тот же полнотекстовый поиск), а дополнительные возможности более мощной InnoDB и тем более PostgreSQL, Microsoft Server, Oracle, DB2 далеко не всегда нужны.
Особенность механизма хранения индексов в InnoDB может как ускорить работу с базой, так и подвесить намертво самоё мощное железо.
Вот пример, как упал сервис Яндекса из-за InnoDB — softwaremaniacs.org/blog/2008/02/22/why-offline-crashed/
Дело в том, что он перестраивает индексы по порядку, собственно это и даёт скорость. Но если у вас вставляется множество данных с случайным ключом, те же сессии, это подвешивает жёсткий диск намертво.
И не говорите, что это ошибка конкретно этих программистов, многие из популярных скриптов, CMS, форумов и пр. тоже стартуют сессию на каждого посетителя.
P.S. вообщем, к выбору движка надо подходить с умом и для каждого проекта решать этот вопрос индивидуально.
У MyISAM есть уникальные преимущества (тот же полнотекстовый поиск), а дополнительные возможности более мощной InnoDB и тем более PostgreSQL, Microsoft Server, Oracle, DB2 далеко не всегда нужны.
Иногда имеет смысл некоторые таблицы переводить в MyISAM.
>> Вот пример, как упал сервис Яндекса из-за InnoDB — softwaremaniacs.org/blog/2008/02/22/why-offline-crashed/
Сервис упал не из-за ИнноДб, а из-за криворукости программистов.
1. Primary key — md5-хеш — иначе как долбоебизмом это я назвать не могу
2. На индексе была одна выборка с join'ом четырех таблиц, одна из которых — самая здоровенная таблица базы
Кстати, собственно Салагаев ни в чём ИнноДб не обвиняет, а пишет о своих косяках и к чему они привели.
Сервис упал не из-за ИнноДб, а из-за криворукости программистов.
1. Primary key — md5-хеш — иначе как долбоебизмом это я назвать не могу
2. На индексе была одна выборка с join'ом четырех таблиц, одна из которых — самая здоровенная таблица базы
Кстати, собственно Салагаев ни в чём ИнноДб не обвиняет, а пишет о своих косяках и к чему они привели.
1. Да все использует md5 или что-то подобное для генерации идентификатора сессии. А что Вы предлагаете? Автоинкрементный ключ? Так это потенциальная дыра в безопасности. Ключ обязательно должен быть случайным.
2. База упала не из-за сложной выборки, а из-за множественных вставок записей в БД.
И повторюсь это не ошибка конкретных программистов, например, вся тройка форумов рунета PHPbb, IPB, vBulletin стартует сессию на каждого гостя и их разработчики не считают это решение криворуким.
2. База упала не из-за сложной выборки, а из-за множественных вставок записей в БД.
И повторюсь это не ошибка конкретных программистов, например, вся тройка форумов рунета PHPbb, IPB, vBulletin стартует сессию на каждого гостя и их разработчики не считают это решение криворуким.
Стартовать сессии для гостей хранящиеся_в_БД — простите бред.
Тем более — на главной Яндекса. Насколько я понял — Салагаев просто не ожидал такого поведения (сохранения сессий в БД) от Джанго.
ИнноДб — здесь не причём абсолютно. Хватит уже распространять мифы. Для кластерных индексов в любой_бд — будет строиться дерево.
Как готовить сессии:
1. если необходимо хранить какую то временную информацию для гостей — целесообразно сохранять данные сессии в куки.
Зачем это нужно? Вот пример:
Допустим, что пользователь залогинился на вашем сайте. После авторизации вы можете добавить его username и email в cookies сессии, что сделает эту информацию доступной везде — без необходимости подключения к базе данных.
2. Сохранение данных о сессии в базу данных
Пока информация хранящаяся в cookies пользователя содержит ID сессии, вы не имеете возможности проверить его, в отличие от варианта когда данные сессии хранятся в базе данных. Для приложений, которые не требуют высокого уровня безопасности, проверка ID сессии не является обязательной, однако, если ваше приложение требует высокого уровня безопасности, то проверка становится обязательной.
Если данные сессии находятся в базе данных, то каждый раз, когда в cookies пользователя обнаруживается рабочая сессия, осуществляется запрос к базе данных — с целью сравнить ID сессий. Если ID сессии не совпадают, то сессия разрушается. ID сессии никогда не обновляется, он может быть лишь сгенерированным, когда сессия создается.
Тем более — на главной Яндекса. Насколько я понял — Салагаев просто не ожидал такого поведения (сохранения сессий в БД) от Джанго.
ИнноДб — здесь не причём абсолютно. Хватит уже распространять мифы. Для кластерных индексов в любой_бд — будет строиться дерево.
Как готовить сессии:
1. если необходимо хранить какую то временную информацию для гостей — целесообразно сохранять данные сессии в куки.
Зачем это нужно? Вот пример:
Допустим, что пользователь залогинился на вашем сайте. После авторизации вы можете добавить его username и email в cookies сессии, что сделает эту информацию доступной везде — без необходимости подключения к базе данных.
2. Сохранение данных о сессии в базу данных
Пока информация хранящаяся в cookies пользователя содержит ID сессии, вы не имеете возможности проверить его, в отличие от варианта когда данные сессии хранятся в базе данных. Для приложений, которые не требуют высокого уровня безопасности, проверка ID сессии не является обязательной, однако, если ваше приложение требует высокого уровня безопасности, то проверка становится обязательной.
Если данные сессии находятся в базе данных, то каждый раз, когда в cookies пользователя обнаруживается рабочая сессия, осуществляется запрос к базе данных — с целью сравнить ID сессий. Если ID сессии не совпадают, то сессия разрушается. ID сессии никогда не обновляется, он может быть лишь сгенерированным, когда сессия создается.
Другими словами хранение сессий в БД необходимо там, и только там, где необходима высокая безопасность. Для того, чтобы злоумышленник — укравший кукис пользователя не мог, например, списать средства со счета пользователя.
Для этого и сохраняются сессии в бд и сверяются с кукис. И если, изменился айпи и, опционально, браузер — запрашивается дополнительная авторизация.
Более того, данную информацию целесообразно шифровать.
Рекомендую посмотреть на реализацию класса сессий в движке codeigniter (PHP): www.code-igniter.ru/user_guide/libraries/sessions.html
Там есть и шифрование, и опциональное сохранение в БД с синхронизацией и flashsdata для временных данных.
MD5 для ключа — кстати, вполне оправдано. Здесь я был не прав.
Для этого и сохраняются сессии в бд и сверяются с кукис. И если, изменился айпи и, опционально, браузер — запрашивается дополнительная авторизация.
Более того, данную информацию целесообразно шифровать.
Рекомендую посмотреть на реализацию класса сессий в движке codeigniter (PHP): www.code-igniter.ru/user_guide/libraries/sessions.html
Там есть и шифрование, и опциональное сохранение в БД с синхронизацией и flashsdata для временных данных.
MD5 для ключа — кстати, вполне оправдано. Здесь я был не прав.
Миф говорите, прочтите документацию по InnoDB:
Т.е. при вставки записи со случайным ключом, БД будет перестраивать файл, при этом если файл большой, то движок активно будет использовать swap. В отличие от MyISAM, который новые записи просто добавляет в конец файла. В каком случае нагрузка на жёсткий диск будет больше вообщем понятно.
И это касается всех таблиц, где в качестве Primary Key используется случайное (неавтоинкрементное) число, а не только сессий, их просто для примера привел.
… and new rows are inserted in the ascending order of the primary key.
… и новые строки вставляются отсортированными по первичному ключу.
Т.е. при вставки записи со случайным ключом, БД будет перестраивать файл, при этом если файл большой, то движок активно будет использовать swap. В отличие от MyISAM, который новые записи просто добавляет в конец файла. В каком случае нагрузка на жёсткий диск будет больше вообщем понятно.
И это касается всех таблиц, где в качестве Primary Key используется случайное (неавтоинкрементное) число, а не только сессий, их просто для примера привел.
Это абсолютно верное поведение кластерных индексов, соответствующее стандарту SQL.
Кластерные индексы медленнее на вставке и быстрее на селектах.
Если разработчик этого не знает — это не проблема движка, это проблема разработчика.
Если необходимо избежать данного поведения достаточно было сделать автоинкрементное поле integer — primary, а значения хэша хранить в отдельном поле, по которому построить уникальный secondary index.
Именно это написано в мануале — Clustered and Secondary Indexes: www.dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html
Какая то неинтересная дискуссия. Предлагаю закрыть.
Кластерные индексы медленнее на вставке и быстрее на селектах.
Если разработчик этого не знает — это не проблема движка, это проблема разработчика.
Если необходимо избежать данного поведения достаточно было сделать автоинкрементное поле integer — primary, а значения хэша хранить в отдельном поле, по которому построить уникальный secondary index.
Именно это написано в мануале — Clustered and Secondary Indexes: www.dev.mysql.com/doc/refman/5.1/en/innodb-index-types.html
Какая то неинтересная дискуссия. Предлагаю закрыть.
crc32(md5("..."))
пару лет назад таблицы с авторизацией\сессиями перевел с MyISAM на InnoDB
работать стали раза в два быстрее, так как убрались локи…
пару месяцев назад таблицы с авторизацией\сессиями перевел с и InnoDB на Memory
итого полумертвый сервер(load 600%/800%) стал почти что idle ( 100%/800% )
а полгига памяти мне не жалко
работать стали раза в два быстрее, так как убрались локи…
пару месяцев назад таблицы с авторизацией\сессиями перевел с и InnoDB на Memory
итого полумертвый сервер(load 600%/800%) стал почти что idle ( 100%/800% )
а полгига памяти мне не жалко
Мой опыт:
MyISAM (~150Гб). 5 лет жёсткой эксплуатации, проблем — нет. Ничего не ломалось и не падало.
MyISAM (~150Гб). 5 лет жёсткой эксплуатации, проблем — нет. Ничего не ломалось и не падало.
Вы понимаете, что Вы лишили аргументов всех фанатов InnoDB и PostgreSQL :)
Это только мой опыт.
Думаю, что у тех кто использует InnoDB, PostgreSQL, Microsoft Server, Oracle, DB2 и т.д. — свой :-)
Думаю, что у тех кто использует InnoDB, PostgreSQL, Microsoft Server, Oracle, DB2 и т.д. — свой :-)
Почему-то пишут что MyISAM упадёт обязательно, и что надо в кроне держать команду проверки целостности.
А у вас лично какой опыт?
у вас лично, как он, myisam. Падает?
у вас лично, как он, myisam. Падает?
На заборе тоже написано…
Напишите статью по этому поводу, что мол MyISAM отличный движок. А то пока видел обратное — MyISAM не любит отключения питания, временами портится без видимых причин, восстановить не сложно, но требует ручного вмешательства. Не буду же я проверять на себе, лучше доверюсь чужому опыту. И поверю тем, кто написал об этом, а не кто промолчал :)
MyISAM — не лучше и не хуже :) там просто другие принципы.
Это всёравно, что сравнивать BMW, Audi и т.д. у них есть что-то общее, но разные технологии. Где-то нужна скорость, а где-то проходимость… Высокий или низкий клиренс…
Все стремятся к чему-то оптимальному, вот и технологии разные. Ещё нужно учитывать разные войны патентов и т.д.
Это всёравно, что сравнивать BMW, Audi и т.д. у них есть что-то общее, но разные технологии. Где-то нужна скорость, а где-то проходимость… Высокий или низкий клиренс…
Все стремятся к чему-то оптимальному, вот и технологии разные. Ещё нужно учитывать разные войны патентов и т.д.
Прямо видели как портится без видимых причин? Вам повезло, мне за 10 лет работы с myisam не удалось это увидеть.
Номер бага можете привести, я хочу посмотреть?
Номер бага можете привести, я хочу посмотреть?
>макс. записей: 2^32
Из документации
There is a limit of 2^32 (~4.295E+09) rows in a MyISAM table. If you build MySQL with the --with-big-tables option, the row limitation is increased to (2^32)^2 (1.844E+19) rows. Binary distributions for Unix and Linux are built with this option.
Из документации
There is a limit of 2^32 (~4.295E+09) rows in a MyISAM table. If you build MySQL with the --with-big-tables option, the row limitation is increased to (2^32)^2 (1.844E+19) rows. Binary distributions for Unix and Linux are built with this option.
Помню, что в версии 3.23 можно создавать таблицы до 8 миллионов терабайтов (2 ^ 63 bytes)!
А, сейчас уже 5 версия!!!
А, сейчас уже 5 версия!!!
ну так 2^32 это же не объем данных, а кол-во записей.
Да и врядли где-то будет использоваться база с объемом в 8 миллионов террабайтов :-D
Да и врядли где-то будет использоваться база с объемом в 8 миллионов террабайтов :-D
Статья ни о чем.
Перевод документации, причем неполный, а в конце, так вообще абзац на каждый тип.
А подводные камни? И вообще:
Например тип MERGE:
1. Только на основе таблиц MyISAM — про это — ни слова. Разве это не важно? А почему только на основе такого типа?
2. цитирую: «не отслеживаются изменения в структуре исходных таблиц (таблица будет поломана)» — Что значит поломана? Что значит не отслеживаются? К чему это приводит? Как это исправить?
3. цитирую: «Рекомендации: «удобная» (ре)организация таблиц» — если честно, данная рекомендация ставит в тупик.
Тема «сисек» — не раскрыта.
Перевод документации, причем неполный, а в конце, так вообще абзац на каждый тип.
А подводные камни? И вообще:
Например тип MERGE:
1. Только на основе таблиц MyISAM — про это — ни слова. Разве это не важно? А почему только на основе такого типа?
2. цитирую: «не отслеживаются изменения в структуре исходных таблиц (таблица будет поломана)» — Что значит поломана? Что значит не отслеживаются? К чему это приводит? Как это исправить?
3. цитирую: «Рекомендации: «удобная» (ре)организация таблиц» — если честно, данная рекомендация ставит в тупик.
Тема «сисек» — не раскрыта.
> InnoDB — самый быстрый из всех известных движков для БД
> основанных на дисках
Можно источник цитатов?
Мои тесты НА ЗАПИСЬ показывают прямо противоположный результат. InnoDB отстает от того же PostgreSQL 8.3 при большом потоке параллельных записей (в том числе — проводимых пачками) в несколько раз. Кроме того, в InnoDB в зачаточном состоянии управление sync-ами, да и просто процессом сброса страниц на диск. Даже Percona Patches тут мало помогает.
Что касается чтения, то, возможно, на чтение по первичному ключу InnoDB и правда несколько быстрее, чем тот же Постгрес (это я не проверял), однако мне кажется, что для подобных целей все же лучше использовать нереляционные СУБД. На сложных запросах (всякая там статистика и т.д.) планировщик MySQL попросту не справляется, тут уже движок таблиц мало влияет.
> основанных на дисках
Можно источник цитатов?
Мои тесты НА ЗАПИСЬ показывают прямо противоположный результат. InnoDB отстает от того же PostgreSQL 8.3 при большом потоке параллельных записей (в том числе — проводимых пачками) в несколько раз. Кроме того, в InnoDB в зачаточном состоянии управление sync-ами, да и просто процессом сброса страниц на диск. Даже Percona Patches тут мало помогает.
Что касается чтения, то, возможно, на чтение по первичному ключу InnoDB и правда несколько быстрее, чем тот же Постгрес (это я не проверял), однако мне кажется, что для подобных целей все же лучше использовать нереляционные СУБД. На сложных запросах (всякая там статистика и т.д.) планировщик MySQL попросту не справляется, тут уже движок таблиц мало влияет.
# двоичные логи пишуться
// исправьте, что-ли
// исправьте, что-ли
# SELECT (*) FROM table работает гораздо медленнее, чем MyISAM — создавайте триггеры если нужно
имелся ввиду COUNT?
# бэкап простым копирование файлов невозможен
Буквально на днях восстанавливал из бэкапа такую БД: был полный бэкап каталога с данными mysql. Скопировал каталог на свою девелоперскую машину. Начал запускать mysql — ругается на размер чего-то (походу файлов innodb), поменял конфиг — запустился. Сделал дамп и восстановил на серваке.
имелся ввиду COUNT?
# бэкап простым копирование файлов невозможен
Буквально на днях восстанавливал из бэкапа такую БД: был полный бэкап каталога с данными mysql. Скопировал каталог на свою девелоперскую машину. Начал запускать mysql — ругается на размер чего-то (походу файлов innodb), поменял конфиг — запустился. Сделал дамп и восстановил на серваке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Краткий обзор движков таблиц MySQL