Comments 39
При выключении сервера по питанию база отправится в страну вечной охоты?
Читаем внимательно статью. Для режима 0 и 6 добавляем скрипт, который… читаем выше.
При отключении по питанию ваши rc скрипты отрабатывать не будут, все просто умрет.
Для этого делается бэкап и пишется бинарь. Если питание внезапно исчезает (что случается в нормальных дата-центрах крайне редко). Поднимаем последний бэкап и накатываем бинарный лог. Самое большее, что в таком случае мы теряем это транзакцию за последнюю секунду, т.к. у нас стоит innodb_flush_log_at_trx_commit = 2.
Читал внимательно. Я про неконтролируемую потерю питания и отсутствие резервирования.
Мне кажется, Blackhole будет ещё быстрее.
А бинарные логи можно складировать в /dev/null
А бинарные логи можно складировать в /dev/null
Не понял, а разве не тоже самое делает MEMORY storage engine MySql? Вы не сравнивали производительность MEMORY storage engine и вашего решения?
Кстати, при использовании MEMORY storage engine есть возможность установить master-slave репликацию на нормальные таблицы, где все будет делаться уже на уровне самой БД и там уже можно будет играться со скоростью/надежностью.
memory внутри это myisam, что накладывает свои ограничения и проблемы в т.ч бесполезность binlog
конечно, но можно ведь репликацировать данные на обычные таблицы. В целом, если автор рассматривал оба варианта хотелось увидеть разницу в производительности и функциональности. Если не рассматривал, то почему?
туда куда будет происходить репликация — должно быть хранилище которое тоже может переварить такую скорость.
имхо изначально достаточно было поставить raid1 и два SSD.
имхо изначально достаточно было поставить raid1 и два SSD.
Не рассматривал MEMORY, т.к. это не транзакционная таблица, как было написано в пред.коменте.
А схему MEMORY -> реплика в InnoDB это неудачное решение. Первичное хранилище должно поддерживать транзакции.
Кроме того, MEMORY плохо работает с ф-ми агрегации (заметно хуже, чем MyISAM). Возможно это было исправлено. Но в MySQL 5.1 агрегаторы SORT и GROUP BY существенно снижали скорось выборки.
А схему MEMORY -> реплика в InnoDB это неудачное решение. Первичное хранилище должно поддерживать транзакции.
Кроме того, MEMORY плохо работает с ф-ми агрегации (заметно хуже, чем MyISAM). Возможно это было исправлено. Но в MySQL 5.1 агрегаторы SORT и GROUP BY существенно снижали скорось выборки.
Чтобы не быть голословным проверил на MySQL 5.5
time mysql -u root test_001 -e 'select sql_no_cache count(*) from table_10m_2 group by level'
InnoDB 0m2.536s
Memory 0m0.106s
time mysql -u root test_001 -e 'select sql_no_cache * from table_10m_2 order by level desc limit 10'
InnoDB 0m0.013s
Memory 0m0.215s
time mysql -u root test_001 -e 'explain select sql_no_cache * from table_10m_2 order by level desc limit 10'
+----+-------------+-------------+-------+---------------+-------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+-------+---------------+-------+---------+------+------+-------------+
| 1 | SIMPLE | table_10m_2 | index | NULL | level | 5 | NULL | 10 | Using index |
+----+-------------+-------------+-------+---------------+-------+---------+------+------+-------------+
time mysql -u root test_001 -e 'explain select sql_no_cache * from table_10m_2_m order by level desc limit 10'
+----+-------------+---------------+------+---------------+------+---------+------+--------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------+------+---------------+------+---------+------+--------+----------------+
| 1 | SIMPLE | table_10m_2_m | ALL | NULL | NULL | NULL | NULL | 349228 | Using filesort |
+----+-------------+---------------+------+---------------+------+---------+------+--------+----------------+
time mysql -u root test_001 -e 'select sql_no_cache * from table_10m_2 order by level desc limit 9000000,100'
InnoDB 0m3.529s
Memory 0m0.293s
time mysql -u root test_001 -e 'select sql_no_cache count(*) as c from table_10m_2 group by level
having c >= 1000 order by level desc limit 10'
InnoDB 0m0.436s
Memory 0m0.102s
Все запросы работаю прекрасно, кроме сортировки. Memory почему-то не использует ключ (level). Директивы FORCE INDEX или USE INDEX картины не меняют.
time mysql -u root test_001 -e 'select sql_no_cache count(*) from table_10m_2 group by level'
InnoDB 0m2.536s
Memory 0m0.106s
time mysql -u root test_001 -e 'select sql_no_cache * from table_10m_2 order by level desc limit 10'
InnoDB 0m0.013s
Memory 0m0.215s
time mysql -u root test_001 -e 'explain select sql_no_cache * from table_10m_2 order by level desc limit 10'
+----+-------------+-------------+-------+---------------+-------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------+-------+---------------+-------+---------+------+------+-------------+
| 1 | SIMPLE | table_10m_2 | index | NULL | level | 5 | NULL | 10 | Using index |
+----+-------------+-------------+-------+---------------+-------+---------+------+------+-------------+
time mysql -u root test_001 -e 'explain select sql_no_cache * from table_10m_2_m order by level desc limit 10'
+----+-------------+---------------+------+---------------+------+---------+------+--------+----------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------------+------+---------------+------+---------+------+--------+----------------+
| 1 | SIMPLE | table_10m_2_m | ALL | NULL | NULL | NULL | NULL | 349228 | Using filesort |
+----+-------------+---------------+------+---------------+------+---------+------+--------+----------------+
time mysql -u root test_001 -e 'select sql_no_cache * from table_10m_2 order by level desc limit 9000000,100'
InnoDB 0m3.529s
Memory 0m0.293s
time mysql -u root test_001 -e 'select sql_no_cache count(*) as c from table_10m_2 group by level
having c >= 1000 order by level desc limit 10'
InnoDB 0m0.436s
Memory 0m0.102s
Все запросы работаю прекрасно, кроме сортировки. Memory почему-то не использует ключ (level). Директивы FORCE INDEX или USE INDEX картины не меняют.
Такой громкий заголовок:
Ускоряем MySQL insert/update в 5-10 разИ далее статья исключительно про то, как переместить файлы с данными БД с харда на ram-диск. Оно вроде как всё правда и нет обмана, но чувствуется какая-то… хм, разочарованность)
В операционных системах UNIX существует раздел файловой системы, который физически находится в оперативной памяти, но позволяет работать с ним как с обычным дисковым накопителемТакое даже в msdos было.
Поэтому и оговорка — «немного теории». Можно считать, что это напоминалка.
> И далее статья исключительно про то, как переместить файлы с данными БД с харда на ram-диск. Оно вроде как всё правда и нет обмана, но чувствуется какая-то… хм, разочарованность)
Если вы ожидали, что вам покажут, как преодолеть законы физики, то, конечно, я вас разочаровал.
Если вы ожидали, что вам покажут, как преодолеть законы физики, то, конечно, я вас разочаровал.
Очень громкое название для такой статьи.
1. Если оптимально настроить БД она и так будет вся в оперативке. Или почти вся. Тот же innodb_buffer_pool_size не зря доступен для редактирования.
2.
Ну а так спасибо, интересное решение. Никогда постараюсь не применять его на практике, но все ж имеет место быть)
1. Если оптимально настроить БД она и так будет вся в оперативке. Или почти вся. Тот же innodb_buffer_pool_size не зря доступен для редактирования.
2.
Как таковых транзакций здесь у нас нет и на скорость это не влияет.— в InnoDB каждая операция транзакция, если не указано иное, или я путаю?
Ну а так спасибо, интересное решение. Никогда постараюсь не применять его на практике, но все ж имеет место быть)
> Если оптимально настроить БД она и так будет вся в оперативке. Или почти вся. Тот же innodb_buffer_pool_size не зря доступен для редактирования.
Не будет. Можете проверить сами. Даже если innodb_buffer_pool_size поставите больше размера БД. Операции записи будут регулярно работать с диском.
> в InnoDB каждая операция транзакция, если не указано иное, или я путаю
Да, здесь вы правы. В любом случае и там и там флаш транзакций был 1 раз в секунду.
Не будет. Можете проверить сами. Даже если innodb_buffer_pool_size поставите больше размера БД. Операции записи будут регулярно работать с диском.
> в InnoDB каждая операция транзакция, если не указано иное, или я путаю
Да, здесь вы правы. В любом случае и там и там флаш транзакций был 1 раз в секунду.
Вероятно, если хочется использовать такое решение, то следует озадачиться еще и такими вопросами:
Что будет, если шаред память уйдет в своп?
Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее? В принципе, этот вопрос должен был быть рассмотрен в такой статье т.к. подходит по тематике.
плюс озвученные выше.
Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз. В частности, существуют неплохие решения, которые хранят и оперируют с данными on-memory, а для записи на диск делают fork и в отдельном процессе пишут — желательно попеременно в два файла. Тут надо отметить, что в современных архитектурах/нормальных_ОС fork не копирует данные, а использует copy-on-write идиому, поэтому реально копироваться будет мало данных. Я не большой спец по базам, и конкретную бд посоветовать не могу, но по идее такие решения есть — надо поискать.
Что будет, если шаред память уйдет в своп?
Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее? В принципе, этот вопрос должен был быть рассмотрен в такой статье т.к. подходит по тематике.
плюс озвученные выше.
Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз. В частности, существуют неплохие решения, которые хранят и оперируют с данными on-memory, а для записи на диск делают fork и в отдельном процессе пишут — желательно попеременно в два файла. Тут надо отметить, что в современных архитектурах/нормальных_ОС fork не копирует данные, а использует copy-on-write идиому, поэтому реально копироваться будет мало данных. Я не большой спец по базам, и конкретную бд посоветовать не могу, но по идее такие решения есть — надо поискать.
> Что будет, если шаред память уйдет в своп?
Просто начнет медленнее работать. Поэтому ставим мониторилку свободного места.
> Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Здесь либо данные пойдут в своп, либо вылезет ошибка из-за нехватки места. Поэтому ставим мониторилку свободного места.
> Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее?
Так то все действия в операционной системе — это работа с памятью. Про скорость — не понял фишки вопроса.
> Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз.
Я могу посоветовать — mongoDB :) Отличная база. Реплицируется до бесконечности, не теряя скорости (работал на проекте, где был 1 млрд. запросов к базе в сутки). Но она не поддерживает транзакции.
Просто начнет медленнее работать. Поэтому ставим мониторилку свободного места.
> Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Здесь либо данные пойдут в своп, либо вылезет ошибка из-за нехватки места. Поэтому ставим мониторилку свободного места.
> Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее?
Так то все действия в операционной системе — это работа с памятью. Про скорость — не понял фишки вопроса.
> Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз.
Я могу посоветовать — mongoDB :) Отличная база. Реплицируется до бесконечности, не теряя скорости (работал на проекте, где был 1 млрд. запросов к базе в сутки). Но она не поддерживает транзакции.
она не поддерживает транзакции.
поддерживает вообще-то, да при этом приходится танцевать с бубном, но даже финансовые транзакции вполне на монге делают. Это намного лучше чем риск потерять транзакцию за последнею секунду (например, миллиардный перевод).
Про это я читал. Это псевдо-транзакции без уровня изоляций. Такое можно реализовать и на обычном массиве в любом языке. Поэтому такое решение для финансовых компаний будет странным. Зачем рисковать деньгами, используя костыли, когда можно взять нормальную реплику на SSD. trx_auto_commit ставится = 1 и все, никаких потерь последней секунды.
Это псевдо-транзакции без уровня изоляций. Такое можно реализовать и на обычном массиве в любом языке.
Вообще-то, там обычные транзакции с блокированием записей и максимальным уровнем изоляции, монга гарантирует Atomicity, Consistency и блокирование параллельных транзакций.
Зачем рисковать деньгами, используя костыли, когда...
Странно это слышать, после того как вы предложили свой костыль и велосипед для финансовых транзакций. Вообще-то, нормальный бизнес не будет экономить на спичках, а просто возьмет несколько серверов с SSD дисками и настроит разделение и репликацию данных.
можно взять нормальную реплику на SSD. trx_auto_commit ставится = 1 и все
А не проще просто писать сразу на SSD с кешированием данных средствами mysql?
> Вообще-то, там обычные транзакции с блокированием записей и максимальным уровнем изоляции, монга гарантирует Atomicity, Consistency и блокирование параллельных транзакций.
Не уверен, что это правда. Но это приятно, что такое потенциально у них появилось. В любом случае изучу тему.
Кстати, а что у них с dead-lock?
> Странно это слышать, после того как вы предложили свой костыль и велосипед для финансовых транзакций.
Я костыль для финансовых компаний не предлагал и не никогда не буду ибо это опасно. Это вы тему подняли.
Ставить SSD и нормальные транзакции — абсолютно логично, что мое решение тут вообще никак не нужно будет. Смысл ставить SSD и работать с шарой?
Не уверен, что это правда. Но это приятно, что такое потенциально у них появилось. В любом случае изучу тему.
Кстати, а что у них с dead-lock?
> Странно это слышать, после того как вы предложили свой костыль и велосипед для финансовых транзакций.
Я костыль для финансовых компаний не предлагал и не никогда не буду ибо это опасно. Это вы тему подняли.
Ставить SSD и нормальные транзакции — абсолютно логично, что мое решение тут вообще никак не нужно будет. Смысл ставить SSD и работать с шарой?
Про фишку вопроса.
Традиционный способ: insert работает с памятью, память в другом потоке пишется на диск.
Ваш способ: insert работает с памятью, но пишет бинлог на другой диск.
И там и тут insert работает с памятью. В первом случае это кэш, во втором это шаред. Все операции с диском в обеих случаях выполняются в другом потоке/процессе и не должны мешать друг другу. Т.е., я просто не вижу откуда может взяться такая производительность. Может быть небольшая разница, за счет разной имеплементации этих механизмов памяти. Если разница получилась значительной — это скорей всего значит, что там где вышло медленно — там скорей всего вы просто что-то недонастроили.
Традиционный способ: insert работает с памятью, память в другом потоке пишется на диск.
Ваш способ: insert работает с памятью, но пишет бинлог на другой диск.
И там и тут insert работает с памятью. В первом случае это кэш, во втором это шаред. Все операции с диском в обеих случаях выполняются в другом потоке/процессе и не должны мешать друг другу. Т.е., я просто не вижу откуда может взяться такая производительность. Может быть небольшая разница, за счет разной имеплементации этих механизмов памяти. Если разница получилась значительной — это скорей всего значит, что там где вышло медленно — там скорей всего вы просто что-то недонастроили.
Sign up to leave a comment.
Ускоряем MySQL insert/update в 5-10 раз