Это он OLTP при таком подходе не тормозит, а запись в редо может.
Но конечно на таком объеме это не критично.
Запустите копирование двух пусть последовательных файлов на чистом диске одновременно.
На активных системах редо выносят на отдельные диски, чтобы не рушить эту последовательную запись, ну и они могу быть сильно нагруженными.
Т.к. ВЕСЬ DML проходит через логи.
И если у вас они не нагружены, значит больше чтений в базе.
Я там к тому, что выдвигать физические способы хранения-доступа на первый план не совсем корректно.
Есть обычные базы со своими запатентованными методами хранения-поиска…
Или, я например не уверен, что даже то же упомянутое LSM-дерево
не используется в каких-то обычных базах — почему нет?
В целом не эта рутина интересна и важна, если именно она конечно не решает проблемы, которые есть в обычных базах.
Спасибо за пример, тут конечно хорошо, что запсь на диск снапшота не влияет на работу базы, т.к. чтения идут из памяти.
Гипотетически может замедлить запись в редо(т.е. commit'ы).
База конечно небольшая, но учитывая стоимость железа конечно отличный результат.
*************************************
Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
***************************************************
Ну для того их и придумали, в памяти…
Oracle и Oracle TimesTen In-Memory Database :)
Кому не надо такой скорости хватит и обычных СУБД.
Про пользователей не совсем понятно, но по кэшу вам любой админ скажет, что в разогретой базе процент попадания в кэш идет под 100%.(тут могут быть тонкости с этими процентами, но в целом...).
Т.е. они практически ин-мемори. :)
*****************************************
Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.
**************************************************
Вот, в обычных системах точно также, особенно если вспомнить, что в IMDB может памяти не хватить.
Ну и опять же при условии адекватности софта-железа-админа :)
Конечно почти также, иначе не придумывали бы IMDB.
Может получиться, что процесс записи нагружает хранилище и
это может сказаться скорости чтений блоков.
Но всё должно быть сбалансировано под задачу.
Не понял про «неправильный» подход…
Я говорил о неправильном вашем понимании шагов, которые выполняет СУБД при DML+commit.
И всегда подчеркивал, что полную IMDB из обычной не сделаешь.
Все же от задачи зависит.
Я, например знаю систему, в которой использовали Oracle In-Memory, а потом поняли, что хватит и обычного Oracle.
Если база редко перегружается и правильно настроена, то необходимые блоки будут всегда «разогреты»(почти :) ).
типа выкрутились… :)
Этот текст уже правильный и сильно отличается от исходного, а то меня уже пугало,
что вы там собрались что-то писать про обычные базы.
Но огорчу, описанных проблем не возникает при как я писал адекватном железе, софте и админе. Чекпоинт плавненько идет не надрывая систему.
И тем не менее, то что вы написали можно отнести и к In-memory базам, когда им не хватит памяти…
Кроме того ждемс описания чудесато-шустрого процесса создания чекпоинта, т.е. снапшота.
Как это сделано в In-memory базе без рэндом записей?
Что весь кусок памяти(всю базу) на диск?
Но такое часто не поделаешь.
В каком общем случае?
Утверждение верно, почитайте про Write-ahead logging…
перед написанием следующей статьи, то что вы описали в статье всё точно также работает и в обычных базах. И запись в редо-лог и снапшоты(чекпоинты), нет только фазы загрузки базы в память на старте.
Вот этот ваш текст об обычных базах в корне не верен и заморочит не одну неокрепшую голову — «надо реально дождаться записи в табличное пространство»:
********************************************************
Breslavets
«База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. »
danikin
— в общем случае это неверноу утверждение. Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row. Причем, это не только запись в индексы, но и чтение из индексов в перемешку. И все это с рандомным перемещением головки, потому что различные row и части индекса, которые изменяются, находятся в разных местах диска.
***********************************************************************
*******************************************
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
*****************************************************
Сверху вниз читаю,…
статья понравилась, но мне непонятно зачем автор начал сравнивать in-memory с обычными, в архитектуре которых у него ну явные пробелы.
Лучше бы больше рассказал про особенности — вот про те же снимки, которые как я понял аналог наших чекпоинтов, но каким-то чудными образом меньше нагружают I/O, избегая рэндом-записи.
*******************************************************************************
6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
**********************************************************************************
Расскажите как ЧАСТО и КАК делается снимок(на диск) в вашей терминологии и как он работает?
Вот база работает, в шустрой In-memory базе (в памяти) нашлепали изменения в блоках…
И… очень интересно послушать.
Кстати в статье запись тоже производится думаю примерно также и для тех же целей — то что в статье называется снимком(чистый чекпоинт в обычных базах).
Т.е. измененная информация даже в этих in-memory базах также пишется на диск в табличные пространства как и в обычных базах(независимо от комита в конкретной транзакции), иначе после перезагрузки не будет данных :).
В целом, по статье, я вижу отличие от обычных баз только в том, что при старте такой базы она полностью «восстанавливается» в память, ну и другие структуры — хотя это неправильный подход — на физическом уровне в обычных базах может быть что угодно.
В обычных базах мы можем указать таблицы, блоки которых хотим держать по возможности в памяти.
Вам пытаются сказать, что коммерческие СУБД делают изменения таблиц-индексов ВСЕГДА в кэше(в памяти).
Запись по коммиту ведется только в редо-логи.
И запись в табличные пространства не влияет на время отклика в любом случае, так как она производится для измененных блоков во всей базе (любыми транзакциями) асинхронно от конкретной транзакции, а не как вы считаете, специально для конкретной транзакции что-то пишется в табличные пространства по коммиту.
Мы конечно говорим про нормально настроенную базу с адекватным железом и админом.
Я не вдаюсь в детали и не утверждаю обратного.
Но отмечаю, что конкретный момент увязки времени отклика и завершения процесса записи информации в базу освещен не верно.
Тут только добавляется время чтения блоков, если их нет в кэше.
Но я специально оговорил, что мы рассматриваем закешированную таблицу/индексы.
+++++++++++++++++++++++++++++++
Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row.
++++++++++++++++++++++++++++++++++++++
Даже дальше читать не стал.
Я вам говорю как это есть в коммерческих СУБД, а не то, что вам представляется.
Изменения делаются только в буфере(в памяти) страниц(копии блоков таблиц и индексов в памяти).
Также делается запись в БУФЕР(память) лога.
По коммиту буфер лога сбрасывается в лог(redo write ahead).
ВСЁ — пользователю сообщается о успешном коммите.
Причем по коммиту сбрасываются данные не только своей транзакции, а всего что было до.
Если закешировать всю таблицу, то не потребуется и чтения блоков с диска при UPDATE.
А вот запись в датафайлы НИКАК не связана с временем отклика.
Это ассинхронный процесс для обеспечения чекпоинтов, которые будут использоваться при восстановлении и обеспечивают моменты времени в которые можно считать, что все блоки из памяти были записаны на диск(датафайлы).
****************************************
Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
********************************************
Это никак не влияет на время отклика.
По коммиту все не записанные данные из буфферного пула лога(память), пишутся ПОСЛЕДОВАТЕЛЬНО в лог-файл.
По завершению процесса клиенту сообщается о завершении commit(транзакции).
База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы.
Это может произойти довольно нескоро и делается это отдельным процессом-потоком.
И еще в дерево пишутся не кусочки информации, а страницы, по специальным алгоритмам, удерживающих в памяти часто используемую информацию.
Даже для отдельных таблиц можно указать приоритет удерживания их блоков в памяти.
Я к тому, что если в сервере есть много памяти, то при желании можно сделать из обычной базы почти In-memory…
****************************************
Новые «Протоны» будут представлены в двух модификациях — средней и легкой. Первый пуск среднего по тяжести «Протона», согласно информации пресс-релиза, намечен уже на 2018 год, легкого — на 2019.
**************************************************
Но конечно на таком объеме это не критично.
Запустите копирование двух пусть последовательных файлов на чистом диске одновременно.
На активных системах редо выносят на отдельные диски, чтобы не рушить эту последовательную запись, ну и они могу быть сильно нагруженными.
Т.к. ВЕСЬ DML проходит через логи.
И если у вас они не нагружены, значит больше чтений в базе.
Я там к тому, что выдвигать физические способы хранения-доступа на первый план не совсем корректно.
Есть обычные базы со своими запатентованными методами хранения-поиска…
Или, я например не уверен, что даже то же упомянутое LSM-дерево
не используется в каких-то обычных базах — почему нет?
В целом не эта рутина интересна и важна, если именно она конечно не решает проблемы, которые есть в обычных базах.
Гипотетически может замедлить запись в редо(т.е. commit'ы).
База конечно небольшая, но учитывая стоимость железа конечно отличный результат.
Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
***************************************************
Ну для того их и придумали, в памяти…
Oracle и Oracle TimesTen In-Memory Database :)
Кому не надо такой скорости хватит и обычных СУБД.
Про пользователей не совсем понятно, но по кэшу вам любой админ скажет, что в разогретой базе процент попадания в кэш идет под 100%.(тут могут быть тонкости с этими процентами, но в целом...).
Т.е. они практически ин-мемори. :)
Если пЫонэр какой на коленках что-то наваял… да и продал… да еще и дали всё это «1C'нику админить…
Снимок можно делать реже или чаще — это никак не влияет на скорость работы IMDB. Это влияет только на скорость восстановления.
**************************************************
Вот, в обычных системах точно также, особенно если вспомнить, что в IMDB может памяти не хватить.
Ну и опять же при условии адекватности софта-железа-админа :)
Конечно почти также, иначе не придумывали бы IMDB.
Может получиться, что процесс записи нагружает хранилище и
это может сказаться скорости чтений блоков.
Но всё должно быть сбалансировано под задачу.
Не понял про «неправильный» подход…
Я говорил о неправильном вашем понимании шагов, которые выполняет СУБД при DML+commit.
И всегда подчеркивал, что полную IMDB из обычной не сделаешь.
Все же от задачи зависит.
Я, например знаю систему, в которой использовали Oracle In-Memory, а потом поняли, что хватит и обычного Oracle.
Если база редко перегружается и правильно настроена, то необходимые блоки будут всегда «разогреты»(почти :) ).
Можно сделать «почти» в каком-то варианте.
Но читать заблуждения о обычных базах тоже не хочется.
Вам не надо спешить, в том числе и со статьями.
Этот текст уже правильный и сильно отличается от исходного, а то меня уже пугало,
что вы там собрались что-то писать про обычные базы.
Но огорчу, описанных проблем не возникает при как я писал адекватном железе, софте и админе. Чекпоинт плавненько идет не надрывая систему.
И тем не менее, то что вы написали можно отнести и к In-memory базам, когда им не хватит памяти…
Кроме того ждемс описания чудесато-шустрого процесса создания чекпоинта, т.е. снапшота.
Как это сделано в In-memory базе без рэндом записей?
Что весь кусок памяти(всю базу) на диск?
Но такое часто не поделаешь.
Утверждение верно, почитайте про Write-ahead logging…
перед написанием следующей статьи, то что вы описали в статье всё точно также работает и в обычных базах. И запись в редо-лог и снапшоты(чекпоинты), нет только фазы загрузки базы в память на старте.
Вот этот ваш текст об обычных базах в корне не верен и заморочит не одну неокрепшую голову — «надо реально дождаться записи в табличное пространство»:
********************************************************
Breslavets
«База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы. »
danikin
— в общем случае это неверноу утверждение. Например, когда делается UPDATE, то надо подсчитать rows affected и вернуть это клиенту. Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row. Причем, это не только запись в индексы, но и чтение из индексов в перемешку. И все это с рандомным перемещением головки, потому что различные row и части индекса, которые изменяются, находятся в разных местах диска.
***********************************************************************
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
*****************************************************
Сверху вниз читаю,…
статья понравилась, но мне непонятно зачем автор начал сравнивать in-memory с обычными, в архитектуре которых у него ну явные пробелы.
Лучше бы больше рассказал про особенности — вот про те же снимки, которые как я понял аналог наших чекпоинтов, но каким-то чудными образом меньше нагружают I/O, избегая рэндом-записи.
6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.
**********************************************************************************
Расскажите как ЧАСТО и КАК делается снимок(на диск) в вашей терминологии и как он работает?
Вот база работает, в шустрой In-memory базе (в памяти) нашлепали изменения в блоках…
И… очень интересно послушать.
Т.е. измененная информация даже в этих in-memory базах также пишется на диск в табличные пространства как и в обычных базах(независимо от комита в конкретной транзакции), иначе после перезагрузки не будет данных :).
В целом, по статье, я вижу отличие от обычных баз только в том, что при старте такой базы она полностью «восстанавливается» в память, ну и другие структуры — хотя это неправильный подход — на физическом уровне в обычных базах может быть что угодно.
В обычных базах мы можем указать таблицы, блоки которых хотим держать по возможности в памяти.
Вам пытаются сказать, что коммерческие СУБД делают изменения таблиц-индексов ВСЕГДА в кэше(в памяти).
Запись по коммиту ведется только в редо-логи.
И запись в табличные пространства не влияет на время отклика в любом случае, так как она производится для измененных блоков во всей базе (любыми транзакциями) асинхронно от конкретной транзакции, а не как вы считаете, специально для конкретной транзакции что-то пишется в табличные пространства по коммиту.
Мы конечно говорим про нормально настроенную базу с адекватным железом и админом.
Я не вдаюсь в детали и не утверждаю обратного.
Но отмечаю, что конкретный момент увязки времени отклика и завершения процесса записи информации в базу освещен не верно.
Тут только добавляется время чтения блоков, если их нет в кэше.
Но я специально оговорил, что мы рассматриваем закешированную таблицу/индексы.
Т.е. одной записи в лог транзакций мало, надо реально дождаться записи в табличное пространство, чтобы точно понять, сколько зааффектится row.
++++++++++++++++++++++++++++++++++++++
Даже дальше читать не стал.
Я вам говорю как это есть в коммерческих СУБД, а не то, что вам представляется.
Изменения делаются только в буфере(в памяти) страниц(копии блоков таблиц и индексов в памяти).
Также делается запись в БУФЕР(память) лога.
По коммиту буфер лога сбрасывается в лог(redo write ahead).
ВСЁ — пользователю сообщается о успешном коммите.
Причем по коммиту сбрасываются данные не только своей транзакции, а всего что было до.
Если закешировать всю таблицу, то не потребуется и чтения блоков с диска при UPDATE.
А вот запись в датафайлы НИКАК не связана с временем отклика.
Это ассинхронный процесс для обеспечения чекпоинтов, которые будут использоваться при восстановлении и обеспечивают моменты времени в которые можно считать, что все блоки из памяти были записаны на диск(датафайлы).
Упомянутый вами батчинг помогает лишь отчасти. Когда у вас идут случайные изменения строк в СУБД (это типичный workload), то батчи-не-батчи, все равно каждый батч надо распихать по разным частям дерева.
********************************************
Это никак не влияет на время отклика.
По коммиту все не записанные данные из буфферного пула лога(память), пишутся ПОСЛЕДОВАТЕЛЬНО в лог-файл.
По завершению процесса клиенту сообщается о завершении commit(транзакции).
База НЕ ждет записи страниц памяти(измененных таблиц) в датафайлы.
Это может произойти довольно нескоро и делается это отдельным процессом-потоком.
И еще в дерево пишутся не кусочки информации, а страницы, по специальным алгоритмам, удерживающих в памяти часто используемую информацию.
Даже для отдельных таблиц можно указать приоритет удерживания их блоков в памяти.
Я к тому, что если в сервере есть много памяти, то при желании можно сделать из обычной базы почти In-memory…
Что там? Qt(native C++), Java…?
Новые «Протоны» будут представлены в двух модификациях — средней и легкой. Первый пуск среднего по тяжести «Протона», согласно информации пресс-релиза, намечен уже на 2018 год, легкого — на 2019.
**************************************************
На ядовитом гептиле будет опять?