Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 46
Меня всегда смущает mysql и «большие объемы данных» стоящие рядом…
Скажите это Facebook :)
И гуглю за одно.
Facebook не использует нативную репликацию (свои механизмы уровнем выше).
Facebook не использует сложные структуры и связи между таблицами, фактически, просто key-value хранилище.
Называть это «Facebook использует MySQL» у меня язык не поворачивается.
Facebook не использует сложные структуры и связи между таблицами, фактически, просто key-value хранилище.
Называть это «Facebook использует MySQL» у меня язык не поворачивается.
А что он делает тогда с MySQL? :)
Использует зачем-то. Так же как и php, который там конвертится в C++, а потом компилится. Странные они в этом фейсбуке.
Судя по тому что рассказывал их человек на Highload++ они поначалу взяли мускуль и стали дорабатывать напильником под свои нужды, с тех под прошло много лет. Теперь это такой мутант что папа с мамой не узнают. Репликацию они уж точно свою приделали.
В то же время, через MySQL проходит почти всё взаимодействие пользователей[1]: likes, shares, status updates, alerts, requests, etc.
[1]: http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/
[1]: http://gigaom.com/cloud/facebook-shares-some-secrets-on-making-mysql-scale/
И?
> And, Callaghan noted, the HBase engineering team at Facebook is quite a bit larger than the MySQL engineering team, suggesting that tuning HBase to meet Facebook’s needs is more resource-intensive process than is tuning MySQL at this point.
Про внутреннюю структуру подробнее по моей ссылке. Тут больше лирики, чем информации.
> And, Callaghan noted, the HBase engineering team at Facebook is quite a bit larger than the MySQL engineering team, suggesting that tuning HBase to meet Facebook’s needs is more resource-intensive process than is tuning MySQL at this point.
Про внутреннюю структуру подробнее по моей ссылке. Тут больше лирики, чем информации.
Facebook не использует сложные структуры и связи между таблицами, фактически, просто key-value хранилище.Вашей ссылке уже больше, чем полтора года, кстати. Кроме key-value там так же упоминается и хранение графа.
Facebook не использует нативную репликацию (свои механизмы уровнем выше).Facebook использует нативную репликацию, расширенную доп. запросами (команды очистки кеша и др.). В дополнение к ней они используют всякие хитрости для обхода ограниений репликации в один поток, вроде page prefetching на слейве.
Если бы они выкинули всю нативную репликацию и реляционность, то, и вправду, смысла в MySQL не было бы.
А что бы Вы поставили рядом с «Большие объемы данных» вместо MySQL?
PostgreSQL хотя бы.
Вот вчера немного копал тему «MySQL vs. PostgreSQL», и там история говорит что изначально MySQL делался для скорости, а PostgreSQL для поддержки большего количества фич и соответствия стандартам. Поэтому если говорим о больших объемах данных, подразумевая скорость работы с большими объемами данных, то в этом вопросе как раз MySQL смотрится получше.
хм… а где эта самая 5.6.5 версия mysql-я?
dev.mysql.com/downloads/mysql#downloads во вкладке Development Releases. На мастере конечно milestone не поставишь, а вот на слейвах вполне
Кстати она достаточно стабильно работает.
Статье не хватает более подробного описания буферного кэша и работы с ним, принципа разбиения страниц на блоки, принципа расположения блоков на ФС, принципа освобождения блоков в страницах и повторной записи в них, ну и других теоретических основ :)
Ещё интересно было бы посмотреть на Galera replication. Насколько она способна помочь в случае высокой нагрузки.
Удивлены не увидев innodb_flush_log_at_trx_commit — на некоторых БД результат на порядок может улучшить, реально, при чем достаточно даже 2-ки бывает.
к сожалению это нарушает ACID :) поэтому рекомендовать такое значение у меня мышка не поворачивается :)
A и D нарушит, однако начали-то Вы статью с уровней изоляции, которые прямое отношение имеют к C и I :)
А чем READ_COMMITTED нарушает согласованность и изолированность?
Вы намекаете на использование READ COMMITTED, это все же не одно и то же что REPEATABLE READ.
Да, т.к. для большинства задач REPEATABLE READ не нужен. Скорее его удобно включать непосредственно в транзакции требующей такой уровень изолированности. Но ACID READ COMMITTED не нарушает.
для большинства задач REPEATABLE READ не нужен.Для многих задач и innodb_flush_log_at_trx_commit=2 не создаст проблем. Если 2-ка родит проблему, то вряд ли она будет самой большой проблемой при таком фэиле.
А чем READ_COMMITTED нарушает согласованность и изолированность? ACID READ COMMITTED не нарушает.InnoDB supports each of the transaction isolation levels described here using different locking strategies. You can enforce a high degree of consistency with the default REPEATABLE READ level, for operations on crucial data where ACID compliance is important. Or you can relax the consistency rules with READ COMMITTED or even READ UNCOMMITTED
2-ка нарушает D пусть и на 1 секунду, что касаемо I то если верить английской вики это
Isolation property ensures that the concurrent execution of transactions results in a system state that could have been obtained if transactions are executed serially i.e. one after the other.
Под это определение кмк только Serializable. A Repeatable reads и Read committed по сути на равных. У первого phantom reads у второго non-repeatable reads :)
Isolation property ensures that the concurrent execution of transactions results in a system state that could have been obtained if transactions are executed serially i.e. one after the other.
Под это определение кмк только Serializable. A Repeatable reads и Read committed по сути на равных. У первого phantom reads у второго non-repeatable reads :)
2-ка нарушает D пусть и на 1 секунду,innodb_flush_log_at_trx_commit=2 не сильно больше (если кэш на диск часто скидывается, а обычно это именно так), да и вообще — дело в принципе же, а не в размере и частоте:)
При большом количестве мелких транзакций скорее всего будет выигрыш в производительности для не RO транзакций :)
С 2-кой? Будет вплоть до разницы на порядок.
В практических задачах это очень заметно на грабберах и/или во время импорта сложных данных в базу.
В практических задачах это очень заметно на грабберах и/или во время импорта сложных данных в базу.
Добавил UPD. в пост. Будет возможность проверю во время активной фазы не очень критического процесса.
спасибо за upd, хотя конечно немного отжигаете:)
Более точно было бы сказать, что это может привести к сильному росту производительности при частых апдейтах (а не к потере данных:) — выглядит как чистый негатив), а так же указать, что потеря данных возможна только в случае внезапной проблемы на сервере (при 2-ке данные пишутся в кэш диска, кэш ОС, поэтому что бы они утерялись — должно произойти что-то весьма эпическое).
Настройка эта очень популярна на битриксе, в т.ч. она рекомендуется разработчиками, импорт больших данных реально ускоряет.
Более точно было бы сказать, что это может привести к сильному росту производительности при частых апдейтах (а не к потере данных:) — выглядит как чистый негатив), а так же указать, что потеря данных возможна только в случае внезапной проблемы на сервере (при 2-ке данные пишутся в кэш диска, кэш ОС, поэтому что бы они утерялись — должно произойти что-то весьма эпическое).
Настройка эта очень популярна на битриксе, в т.ч. она рекомендуется разработчиками, импорт больших данных реально ускоряет.
я насколько помню у них repetable read по дефолту т.к. репликация была на базе sql запросов, а не построчная в первой версии.
>>Чем длиннее ваш запрос или транзакция, тем больше «старых» данных продолжает накапливать MySQL и есть основания предполагать, что происходит это с активным использованием основного пула памяти.
я ошибаюсь или MySQL — блокировочник? Он не накапливает данные, как это делают упомянутые Вами версионники оракл и постгр, он блокирует модификацю данных для получения согласованного результата. По этой причине и запись блокирует чтение и чтение блокирует запись. В оракле, постгре нет такого понятия как блокировки по чтению, они накапливают версии, скорее этим обуславливается преимущество этих СУБД, о котором вы упоминаете, нежели уровень изоляции транзакции по умолчанию. К слову, надо заметить, что ораклиный и постгровский read commited, за счет такой реализации, не в полной мере вписывается в стандарт ansi
Я ошибаюсь или действительно в MySQL открытая неявно транзакция закрывается сразу же после выполнения стейтмента? Если нет, то в чем разница блокировок, кинутых запросом в read commited и в repeatable read? Могу ошибаться, полагая, что стратегия блокирования на этих уровнях одинакова, разница лишь в том, что в read commited блокировки отпускаются сразу при завершении работы стейтмента, а в read commmited они отпускаются лишь при завершении транзакции. Если у нас транзакция закрывается сразу после выполнения запроса, разница, как бы, получается, не особо и проглядывается.
я ошибаюсь или MySQL — блокировочник? Он не накапливает данные, как это делают упомянутые Вами версионники оракл и постгр, он блокирует модификацю данных для получения согласованного результата. По этой причине и запись блокирует чтение и чтение блокирует запись. В оракле, постгре нет такого понятия как блокировки по чтению, они накапливают версии, скорее этим обуславливается преимущество этих СУБД, о котором вы упоминаете, нежели уровень изоляции транзакции по умолчанию. К слову, надо заметить, что ораклиный и постгровский read commited, за счет такой реализации, не в полной мере вписывается в стандарт ansi
Я ошибаюсь или действительно в MySQL открытая неявно транзакция закрывается сразу же после выполнения стейтмента? Если нет, то в чем разница блокировок, кинутых запросом в read commited и в repeatable read? Могу ошибаться, полагая, что стратегия блокирования на этих уровнях одинакова, разница лишь в том, что в read commited блокировки отпускаются сразу при завершении работы стейтмента, а в read commmited они отпускаются лишь при завершении транзакции. Если у нас транзакция закрывается сразу после выполнения запроса, разница, как бы, получается, не особо и проглядывается.
Мы говорим про InnoDB. В MyIsam совсем нет транзакций.
Вы можете легко проверить что ошибаетесь :) открываете одну транзакцию с REPETABLE READ берёте 1-у запись из таблицы. В другой транзакции делаете вставку в эту таблицу, коммит и затем в первой делаете чтение последней записи из таблицы.
Таблица в первой транзакции не изменилась. На практике при большом количестве длинных транзакций и определённой модификации данны, БД просто влипает в селектах при REPETABLE READ, т.к. фиксируется версия любой таблицы задетой в транзакции. Транзакция закрывается в конце транзакции, у нас например OpenSessionInView что делает все операции во время одного HTTP запроса одной транзакцией.
Вы можете легко проверить что ошибаетесь :) открываете одну транзакцию с REPETABLE READ берёте 1-у запись из таблицы. В другой транзакции делаете вставку в эту таблицу, коммит и затем в первой делаете чтение последней записи из таблицы.
Таблица в первой транзакции не изменилась. На практике при большом количестве длинных транзакций и определённой модификации данны, БД просто влипает в селектах при REPETABLE READ, т.к. фиксируется версия любой таблицы задетой в транзакции. Транзакция закрывается в конце транзакции, у нас например OpenSessionInView что делает все операции во время одного HTTP запроса одной транзакцией.
А зачем при уровне изоляции read commited накапливать версии?? И откуда у вас информация что MySQL блокировочник? вы можете легко проверить свои домыслы установив mysql и открыв 2-е сессии.
>>А зачем при уровне изоляции read commited накапливать версии??
Чтобы обеспечить согласованность результата на время выполнения запроса, если данные, которые попадают в выборку в это самое время меняются другой транзакцией.
>>И откуда у вас информация что MySQL
Всю жизнь считал что это так.
Однако ж, похоже, я очень заблуждался. >>>
Прям таки разрыв шаблона
Спасибо!
Чтобы обеспечить согласованность результата на время выполнения запроса, если данные, которые попадают в выборку в это самое время меняются другой транзакцией.
>>И откуда у вас информация что MySQL
Всю жизнь считал что это так.
Однако ж, похоже, я очень заблуждался. >>>
Прям таки разрыв шаблона
Спасибо!
>>открываете одну транзакцию
Сессию или транзакцию? Если транзакцию открывать явно то да, ясно. Я говорил о неявных транзакциях — тех, которые открываются не start transaction, а которые система сама система, для выполнения стайтмента, если транзакция явно не открыта. Или я бред говорю, и такого нет в MySQL?
В случае же с явными транзакциями тут тонкий вопрос. Транзакцию явно открывают вполне для определенных целях. Да, дотошный программист самостоятельно установит нужный ему уровень изоляции. Но может и забыть, и на старуху бывает… И если приложение протестировано в одном уровне изоляции, приложение прошло проверку временем, то смена уровня изоляции может оказаться очень черевата для таких явно открытых тразнакций. Такое решение требует тщательного тестирования, а тестирование конкурирующих процессов весьма не просто организоываать.
>>Вы можете легко проверить что ошибаетесь
К сожалению не могу, в ареоле моего обитания нет ни одного инстанса MySQL. Но тема мне очень интересна.
Сессию или транзакцию? Если транзакцию открывать явно то да, ясно. Я говорил о неявных транзакциях — тех, которые открываются не start transaction, а которые система сама система, для выполнения стайтмента, если транзакция явно не открыта. Или я бред говорю, и такого нет в MySQL?
В случае же с явными транзакциями тут тонкий вопрос. Транзакцию явно открывают вполне для определенных целях. Да, дотошный программист самостоятельно установит нужный ему уровень изоляции. Но может и забыть, и на старуху бывает… И если приложение протестировано в одном уровне изоляции, приложение прошло проверку временем, то смена уровня изоляции может оказаться очень черевата для таких явно открытых тразнакций. Такое решение требует тщательного тестирования, а тестирование конкурирующих процессов весьма не просто организоываать.
>>Вы можете легко проверить что ошибаетесь
К сожалению не могу, в ареоле моего обитания нет ни одного инстанса MySQL. Но тема мне очень интересна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Практическая оптимизация и масштабируемость MySQL InnoDB на больших объёмах данных