> Традиционный способ: insert работает с памятью, память в другом потоке пишется на диск.
Кэш должен куда-то сброситься. В моем случае вместо «пишется на диск» пишется в шару.
> И далее статья исключительно про то, как переместить файлы с данными БД с харда на ram-диск. Оно вроде как всё правда и нет обмана, но чувствуется какая-то… хм, разочарованность)
Если вы ожидали, что вам покажут, как преодолеть законы физики, то, конечно, я вас разочаровал.
> Вообще-то, там обычные транзакции с блокированием записей и максимальным уровнем изоляции, монга гарантирует Atomicity, Consistency и блокирование параллельных транзакций.
Не уверен, что это правда. Но это приятно, что такое потенциально у них появилось. В любом случае изучу тему.
Кстати, а что у них с dead-lock?
> Странно это слышать, после того как вы предложили свой костыль и велосипед для финансовых транзакций.
Я костыль для финансовых компаний не предлагал и не никогда не буду ибо это опасно. Это вы тему подняли.
Ставить SSD и нормальные транзакции — абсолютно логично, что мое решение тут вообще никак не нужно будет. Смысл ставить SSD и работать с шарой?
Про это я читал. Это псевдо-транзакции без уровня изоляций. Такое можно реализовать и на обычном массиве в любом языке. Поэтому такое решение для финансовых компаний будет странным. Зачем рисковать деньгами, используя костыли, когда можно взять нормальную реплику на SSD. trx_auto_commit ставится = 1 и все, никаких потерь последней секунды.
> Что будет, если шаред память уйдет в своп?
Просто начнет медленнее работать. Поэтому ставим мониторилку свободного места.
> Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Здесь либо данные пойдут в своп, либо вылезет ошибка из-за нехватки места. Поэтому ставим мониторилку свободного места.
> Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее?
Так то все действия в операционной системе — это работа с памятью. Про скорость — не понял фишки вопроса.
> Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз.
Я могу посоветовать — mongoDB :) Отличная база. Реплицируется до бесконечности, не теряя скорости (работал на проекте, где был 1 млрд. запросов к базе в сутки). Но она не поддерживает транзакции.
> Если оптимально настроить БД она и так будет вся в оперативке. Или почти вся. Тот же innodb_buffer_pool_size не зря доступен для редактирования.
Не будет. Можете проверить сами. Даже если innodb_buffer_pool_size поставите больше размера БД. Операции записи будут регулярно работать с диском.
> в InnoDB каждая операция транзакция, если не указано иное, или я путаю
Да, здесь вы правы. В любом случае и там и там флаш транзакций был 1 раз в секунду.
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 картины не меняют.
Не рассматривал MEMORY, т.к. это не транзакционная таблица, как было написано в пред.коменте.
А схему MEMORY -> реплика в InnoDB это неудачное решение. Первичное хранилище должно поддерживать транзакции.
Кроме того, MEMORY плохо работает с ф-ми агрегации (заметно хуже, чем MyISAM). Возможно это было исправлено. Но в MySQL 5.1 агрегаторы SORT и GROUP BY существенно снижали скорось выборки.
Для этого делается бэкап и пишется бинарь. Если питание внезапно исчезает (что случается в нормальных дата-центрах крайне редко). Поднимаем последний бэкап и накатываем бинарный лог. Самое большее, что в таком случае мы теряем это транзакцию за последнюю секунду, т.к. у нас стоит innodb_flush_log_at_trx_commit = 2.
Кэш должен куда-то сброситься. В моем случае вместо «пишется на диск» пишется в шару.
Если вы ожидали, что вам покажут, как преодолеть законы физики, то, конечно, я вас разочаровал.
Не уверен, что это правда. Но это приятно, что такое потенциально у них появилось. В любом случае изучу тему.
Кстати, а что у них с dead-lock?
> Странно это слышать, после того как вы предложили свой костыль и велосипед для финансовых транзакций.
Я костыль для финансовых компаний не предлагал и не никогда не буду ибо это опасно. Это вы тему подняли.
Ставить SSD и нормальные транзакции — абсолютно логично, что мое решение тут вообще никак не нужно будет. Смысл ставить SSD и работать с шарой?
Просто начнет медленнее работать. Поэтому ставим мониторилку свободного места.
> Что будет, если размер базы вырастет и станет больше размера шаред памяти?
Здесь либо данные пойдут в своп, либо вылезет ошибка из-за нехватки места. Поэтому ставим мониторилку свободного места.
> Запись на диск кэшируется. Т.е., запись на диск — это тоже работа с памятью. За счет чего так выходит, что работа с шаред памятью оказалась быстрее?
Так то все действия в операционной системе — это работа с памятью. Про скорость — не понял фишки вопроса.
> Если база помещается в памяти, то возможно, стоит посмотреть не в сторону mysql, а в сторону каких-нибудь других баз.
Я могу посоветовать — mongoDB :) Отличная база. Реплицируется до бесконечности, не теряя скорости (работал на проекте, где был 1 млрд. запросов к базе в сутки). Но она не поддерживает транзакции.
Не будет. Можете проверить сами. Даже если innodb_buffer_pool_size поставите больше размера БД. Операции записи будут регулярно работать с диском.
> в InnoDB каждая операция транзакция, если не указано иное, или я путаю
Да, здесь вы правы. В любом случае и там и там флаш транзакций был 1 раз в секунду.
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 картины не меняют.
А схему MEMORY -> реплика в InnoDB это неудачное решение. Первичное хранилище должно поддерживать транзакции.
Кроме того, MEMORY плохо работает с ф-ми агрегации (заметно хуже, чем MyISAM). Возможно это было исправлено. Но в MySQL 5.1 агрегаторы SORT и GROUP BY существенно снижали скорось выборки.
«бинарные логи можно складировать в /dev/null » = отключить бинарные логи. Так будет еще быстрее :)
«отсутствие резервирования» — об этом написано.