Спасибо, конечно, но я несколько другой области тружусь, где NoSQL до сих пор не особо применимы, а используются классические RDBMS.
Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.
Для FaceBook потерять пару комментов или отобразить их чуть позже — это фигня.
Для всего, что связано напрямую с деньгами такие вещи недопустимы.
Вот и вся разница.
Мне кажется, Вам отлично удаются маркетинговые статьи типа вот этой:
http://www.cnews.ru/news/top/2016-12-05_subd_mailru_tarantool_cherez_tri_nedeli_prevratitsya
И они вполне впечатлят каких-нибудь топ-менеджеров и принесут Вам доходы.
Но тут, по-большей части, технические специалисты и такого рода вещи, конечно, могут вызывать раздражение, так как админы и программисты в большинстве не очень любят маркетологов :)
Странно извиняться перед автором безграмотной статьи, которому ни разу не стыдно.
И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?
По 1 еще:
Надо только понимать, что реальная запись пойдет не одой операцией в 1g, а порциями, при этом не совсем понятно, какими
Т.е лучше явно написать что-то вида:
dd if=/dev/zero of=/root/testfile bs=1024k oflag=dsync
и наблюдать за ростом файла.
1. ура
2. Это все же зависит объема измененных данных в отношении всего объема БД
3. Индексы точно также лежат в кеше. Oracle вообще пофиг, что там в блоках — данные, индексы или undo. Механизм работы с ними с точки зрения кэширования совершенно одинаков.
Я верю что in-memory быстрее для какого- набора операций — вопрос, чем при этом приходится жертвовать?
4. Тогда почему ранее Вы написали, что:
>Механизма компактификации лога транзакций у дисковых СУБД нет
5. Так я тоже не фанат, я просто не лезу в то, чего не знаю, но меня задевает, когда, вот, наоборот.
6. Все так, но это вопрос грамотного тюнинга системы. И, опять же, сохранить надо не миллион изменений, а только актуальную версию измененных данных. Вот, тот же undo, перетирается по кругу, например, в зависимости от выставленного retention.
7.3 Если это не NoSQL база и есть какие-то индексы, кроме первичных ключей, то никуда от этого не денешься в плане расположения данных. Но, еще раз напишу, что базам все равно, что там в блоках — индексы, данные — алгоритм работы с ними одинаков. Не надо никуда лезть на диски, если все помещается в память.
1) есть существенная разница между блоком и записью. В одном блоке записей-то может быть немало
2) при правильном подходе работает
я согласен с 3 и дальше, но тут надо четко понимать круг решаемых задач и связанные с этим ограничения.
Т.е не пытаться сравнивать несравнимое и находить минусы там, где их нет при правильном подходе.
Можно и на grep и awr базы писать, но этот как-то не совсем же базы.
Да я не против, чтобы люди изобретали свое колесо, лучше прежних колес, особенно если за это платят.
Только хорошо бы для начала разобраться, и понимать, как работает то, что уже давно придумано.
>Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?
>типа все по щелкчу пальцев побежали и поменяли HDD на SSD
ну, сравните стоимость замены HDD небольшого объема на SSD и стоимость написания своей собственной RDMS, которая будет отличаться только в том, что скидывает данные на диски не случайным, а последовательным способом.
1. Ох, беда, совсем же не fsync.
https://romanrm.net/dd-benchmark
ключевое — oflag=dsync
2. В in-memory изменения рано или поздно также применять в слепок. Разница в том, что для in-memory надо записать все данные, а в обычных надо записать только измененные. Т.е ничего нового тут не придумали — весь вопрос в правильных настройках этой записи и требуемого времени восстановления после краша.
3. Предлагаю Вам все-таки забыть мифическую теорию, что дисковым базам нужно зачем-то лазить за чтением на диски, если объем данных влезает в кэш. И, кстати, если in-memory поддерживают транзакционную целостность, то как же они обходятся без предыдущих версий данных в памяти? И как долго эти данные хранятся в памяти и какой объем занимают? Об этом было бы интересно почитать.
4. В обычных rdbms компактификация зовется checkpoint — момент времени в прошлом, про который мы знаем, что все данные измененные ранее уже сброшены на диск и redo ранее этого момента нам уже не потребуется в случае старта после краша. Можно еще здесь, например, почитать, для обретения ясности в голове:
https://habrahabr.ru/post/164447
5. Скриптик у меня есть, но он для Oracle. И преимущество обычных БД в том, что закинуть можно только те данные, которым нужно там быть сразу для быстрой работы критичных запросов — обычно это небольшая часть общего объема. А остальное пускай на дисках остается. А InMemory таки объемы вообще не под силу.
6. В обычных БД можно настраивать частоту сброса горячих блоков. И, например, для настроек 1 минута или 10 минут — количество IOPS по записи в файлики будет отличаться на порядки.
7. Ну так уже, выяснили, что 1) rdbms совсем не обязательно лезть за данными на диск, если он в кэше. 2) количество записи в файлы совсем не равно количеству изменений этих данных в памяти 3) какое отношение B+ деревья ко всему этому — вообще непонятно.
8. Термин ACID относится в целом к субд, а не к транзакциям. И как-то, опять же, сравнивать SQL и NoSQL… Разные задачи.
9. Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)
Конечно расскажут ;) Сколько всего понаписано, а грамотно-то было всего-то немного поизучать, как правильно измерять производительность последовательной записи на диск и поменять команду cat на dd с правильными опциями. И работа такой команды будет гораздо ближе к тому, как работает запись в redo — синхронно, с ожиданием окончания каждой записи.
Ладно, пойдем дальше по статье…
>Во-вторых, дисковые СУБД должны сохранять данные таким образом, чтобы измененные данные можно было немедленно считать, в отличие от СУБД в оперативной памяти, которые не считывают с диска, за исключением случаев, когда при старте запускается восстановление. Именно поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.
Можно какую-то ссылку на первоисточник такого утверждения? О какой хотя бы особо экзотичной БД идет речь? Речь об undo? Так оно точно также в памяти может хранится очень-очень долго. А если undo нет, то как же тогда ACID и как можно сравнивать нормальную RDBMS с чем-то таки типа ускоряющего кеша, который вообще не RDBMS ни разу.
>Одна из таких структур — B/B+-дерево, ускоряющее считывание данных.
По-простому, речь идет об индексах? Но какая разница, если у нас все в памяти, последовательное обращение или случайное?
Из комментариев:
>Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
Ух… это из какой-то параллельной вселенной знания? :)
Почитайте хоть какие-то основы что-ли https://habrahabr.ru/post/132107
>По нашему опыту прогрев, скажем, Tarantool идет со скоростью 60-100Mb/s, прогрев MySQL — 2Mb/s. Соответственно, 64Gb памяти будут залиты в случае Tarantool 6-10 минут, а в случае MySQL за 9 часов. Это адок для продакшн-системы.
А написать скриптик, который сразу после старта системы пробежится полным чтением и закинет в кэш данные по таблицам-индексам квалификация не позволяет? :)
>и? как закэшированность страниц ускоряет их запись?
даю подсказку — один блок может меняться миллионы-миллиарды раз, а записать его надо будет только 1 раз :)
— В целом статью можно было бы озаглавить «я не знаю как работают RDBMS, но in-mememory DB — это круто»
:)
По существу, мне, как человеку не знающему in-memory (и немного разбирающегося в обычных БД) гораздо интереснее было бы почитать, чем еще, кроме ограниченности размера БД, жертвуют in-memory ради производительности, т.е какие дополнительные ограничения накладывают на разработчика и архитектуру системы.
Да, и говорить про использование HDD, а не SSD для небольших баз при приличной нагрузке — это как-то странно тоже.
Спасибо за статью.
В январе был две недели в Сантьяго в комнадировке, на выходных скатался на арендованной машинке до окена и в горы.
Для меня самое сложное было то, что очень мало кто говорит по английски. Захотелось срочно выучить испанский.
Это правда — речь идет про begin/end backup на уровне TS или базы данных. И используется при резервном копировании сторонними стредствами, например, dd или разрыв синхронизации копии БД на уровне дискового массива (при этом таким образом нельзя бэкапить ничего, кроме датафайлов).
Но причем тут RMAN? У него технология защиты от изменения блока совсем другая :)
Отличный инструмент!
Для меня было бы бесценно иметь отдельный режим работы приложения только по историческим view (dba_hist...) по dbid, отличающегося от dbid базы, к которой присоединяемся.
По работе приходится диагностировать проблемы без доступа к БД, только AWR/ASH отчеты и возможность запросить дамп скриптом awrextr, загрузить у себя awrload-ом во временную БД.
Речь идет о финансовых данных, биллинг мобильных операторов, карточные процессинг и т.п.
Для FaceBook потерять пару комментов или отобразить их чуть позже — это фигня.
Для всего, что связано напрямую с деньгами такие вещи недопустимы.
Вот и вся разница.
Мне кажется, Вам отлично удаются маркетинговые статьи типа вот этой:
http://www.cnews.ru/news/top/2016-12-05_subd_mailru_tarantool_cherez_tri_nedeli_prevratitsya
И они вполне впечатлят каких-нибудь топ-менеджеров и принесут Вам доходы.
Но тут, по-большей части, технические специалисты и такого рода вещи, конечно, могут вызывать раздражение, так как админы и программисты в большинстве не очень любят маркетологов :)
И я не услышал, что именно, кроме отсутствия квалификации помешало грамотно построить работу с кешэм в MySQL? За что извиняться то?
Надо только понимать, что реальная запись пойдет не одой операцией в 1g, а порциями, при этом не совсем понятно, какими
Т.е лучше явно написать что-то вида:
dd if=/dev/zero of=/root/testfile bs=1024k oflag=dsync
и наблюдать за ростом файла.
2. Это все же зависит объема измененных данных в отношении всего объема БД
3. Индексы точно также лежат в кеше. Oracle вообще пофиг, что там в блоках — данные, индексы или undo. Механизм работы с ними с точки зрения кэширования совершенно одинаков.
Я верю что in-memory быстрее для какого- набора операций — вопрос, чем при этом приходится жертвовать?
4. Тогда почему ранее Вы написали, что:
>Механизма компактификации лога транзакций у дисковых СУБД нет
5. Так я тоже не фанат, я просто не лезу в то, чего не знаю, но меня задевает, когда, вот, наоборот.
6. Все так, но это вопрос грамотного тюнинга системы. И, опять же, сохранить надо не миллион изменений, а только актуальную версию измененных данных. Вот, тот же undo, перетирается по кругу, например, в зависимости от выставленного retention.
7.3 Если это не NoSQL база и есть какие-то индексы, кроме первичных ключей, то никуда от этого не денешься в плане расположения данных. Но, еще раз напишу, что базам все равно, что там в блоках — индексы, данные — алгоритм работы с ними одинаков. Не надо никуда лезть на диски, если все помещается в память.
2) при правильном подходе работает
я согласен с 3 и дальше, но тут надо четко понимать круг решаемых задач и связанные с этим ограничения.
Т.е не пытаться сравнивать несравнимое и находить минусы там, где их нет при правильном подходе.
Можно и на grep и awr базы писать, но этот как-то не совсем же базы.
Только хорошо бы для начала разобраться, и понимать, как работает то, что уже давно придумано.
>Про закешированность страниц тоже отличный коммент с подсказкой от «папы», вы правда считаете что сказали что-то умное?
Так кто-то же должен был это сказать, развеять, так сказать, заблуждения автора.
А какие претензии к скриптам разогрева кеша баз? Первый раз про такое слышите?
>типа все по щелкчу пальцев побежали и поменяли HDD на SSD
ну, сравните стоимость замены HDD небольшого объема на SSD и стоимость написания своей собственной RDMS, которая будет отличаться только в том, что скидывает данные на диски не случайным, а последовательным способом.
https://romanrm.net/dd-benchmark
ключевое — oflag=dsync
2. В in-memory изменения рано или поздно также применять в слепок. Разница в том, что для in-memory надо записать все данные, а в обычных надо записать только измененные. Т.е ничего нового тут не придумали — весь вопрос в правильных настройках этой записи и требуемого времени восстановления после краша.
3. Предлагаю Вам все-таки забыть мифическую теорию, что дисковым базам нужно зачем-то лазить за чтением на диски, если объем данных влезает в кэш. И, кстати, если in-memory поддерживают транзакционную целостность, то как же они обходятся без предыдущих версий данных в памяти? И как долго эти данные хранятся в памяти и какой объем занимают? Об этом было бы интересно почитать.
4. В обычных rdbms компактификация зовется checkpoint — момент времени в прошлом, про который мы знаем, что все данные измененные ранее уже сброшены на диск и redo ранее этого момента нам уже не потребуется в случае старта после краша. Можно еще здесь, например, почитать, для обретения ясности в голове:
https://habrahabr.ru/post/164447
5. Скриптик у меня есть, но он для Oracle. И преимущество обычных БД в том, что закинуть можно только те данные, которым нужно там быть сразу для быстрой работы критичных запросов — обычно это небольшая часть общего объема. А остальное пускай на дисках остается. А InMemory таки объемы вообще не под силу.
6. В обычных БД можно настраивать частоту сброса горячих блоков. И, например, для настроек 1 минута или 10 минут — количество IOPS по записи в файлики будет отличаться на порядки.
7. Ну так уже, выяснили, что 1) rdbms совсем не обязательно лезть за данными на диск, если он в кэше. 2) количество записи в файлы совсем не равно количеству изменений этих данных в памяти 3) какое отношение B+ деревья ко всему этому — вообще непонятно.
8. Термин ACID относится в целом к субд, а не к транзакциям. И как-то, опять же, сравнивать SQL и NoSQL… Разные задачи.
9. Ну, хорошо, я считают, что держать маленькую highload БД на HDD — это извращение ;)
Ладно, пойдем дальше по статье…
>Во-вторых, дисковые СУБД должны сохранять данные таким образом, чтобы измененные данные можно было немедленно считать, в отличие от СУБД в оперативной памяти, которые не считывают с диска, за исключением случаев, когда при старте запускается восстановление. Именно поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.
Можно какую-то ссылку на первоисточник такого утверждения? О какой хотя бы особо экзотичной БД идет речь? Речь об undo? Так оно точно также в памяти может хранится очень-очень долго. А если undo нет, то как же тогда ACID и как можно сравнивать нормальную RDBMS с чем-то таки типа ускоряющего кеша, который вообще не RDBMS ни разу.
>Одна из таких структур — B/B+-дерево, ускоряющее считывание данных.
По-простому, речь идет об индексах? Но какая разница, если у нас все в памяти, последовательное обращение или случайное?
Из комментариев:
>Потому что все что ушло в лог транзакций, но не записалось в дерево хранится в памяти. Рано или поздно эту память надо сбросить на диск в дерево. Механизма компактификации лога транзакций у дисковых СУБД нет (см. P.S. в моей статье про компактификацию лога транзакций), поэтому, чтобы восстановление не заняло вечности надо данные таки записать в дерево на диске, не дожидаясь даже пока кончится оперативная память.
Ух… это из какой-то параллельной вселенной знания? :)
Почитайте хоть какие-то основы что-ли https://habrahabr.ru/post/132107
>По нашему опыту прогрев, скажем, Tarantool идет со скоростью 60-100Mb/s, прогрев MySQL — 2Mb/s. Соответственно, 64Gb памяти будут залиты в случае Tarantool 6-10 минут, а в случае MySQL за 9 часов. Это адок для продакшн-системы.
А написать скриптик, который сразу после старта системы пробежится полным чтением и закинет в кэш данные по таблицам-индексам квалификация не позволяет? :)
>и? как закэшированность страниц ускоряет их запись?
даю подсказку — один блок может меняться миллионы-миллиарды раз, а записать его надо будет только 1 раз :)
— В целом статью можно было бы озаглавить «я не знаю как работают RDBMS, но in-mememory DB — это круто»
:)
По существу, мне, как человеку не знающему in-memory (и немного разбирающегося в обычных БД) гораздо интереснее было бы почитать, чем еще, кроме ограниченности размера БД, жертвуют in-memory ради производительности, т.е какие дополнительные ограничения накладывают на разработчика и архитектуру системы.
Да, и говорить про использование HDD, а не SSD для небольших баз при приличной нагрузке — это как-то странно тоже.
>И посмотрите, как быстро увеличивается размер some_file.
Мда, грустно и смешно такое читать.
Если человек ничего не знает про файловый кеш, то какие можно ожидать знания по работе реальных БД?
Я бы всже же уточнил, что речь идет о чем-то DataWareHouse-подобном.
В OLTP системах все в точноти до наоборот.
В январе был две недели в Сантьяго в комнадировке, на выходных скатался на арендованной машинке до окена и в горы.
Для меня самое сложное было то, что очень мало кто говорит по английски. Захотелось срочно выучить испанский.
Но причем тут RMAN? У него технология защиты от изменения блока совсем другая :)
а можно чуточку подробнее, что имеется ввиду?
Для меня было бы бесценно иметь отдельный режим работы приложения только по историческим view (dba_hist...) по dbid, отличающегося от dbid базы, к которой присоединяемся.
По работе приходится диагностировать проблемы без доступа к БД, только AWR/ASH отчеты и возможность запросить дамп скриптом awrextr, загрузить у себя awrload-ом во временную БД.