Что происходит при апдейте и удалении? Например, удаляется строка из БД. Или, например, обновляется поле и увеличивается его размер. Я уже как минимум третий раз в различных видах задаю этот вопрос. Ответа нет.
Тут столько троллей, что я уже и не знаю, какие статьи писать. Лучше подожду, пока от нагрузки у уважаемых седовласых авторитетов RDBMS все встанет раком и они сами тихо под подушкой, никому не говоря, начнут юзать IMDB :-)
В одинаковых условиях мы сравнивали in-memory СУБД, например, вот тут http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html
Там многие популярные IMDB участвуют. Наш Tarantool самый быстрый. Ну и что скажете вы? Тест же провели вы сами, значит верить ему нельзя. Троль всегда найдет как затроллить.
Добавить к тем же условиям MySQL? Ну можно. Он будет минимум в 10 раз медленнее по моеиу опыту (даже если все-все-все будет сидеть в памяти, без единой операции к диску). Но мой опыт же для вас не авторитет и мое умение настраивать RDBMS для вас тоже не акторитет. Поэтому ссылаюсь на признанных профессионалов в этой области (MariaDB). Да, условия теста у нас и у них разные. Т.е. они в целом похожи — рандомно селектим и апдейдим в таблицу, но не вот тебя прям одно и тоже.
Далее еще нюанс. Делать бенчи, чтобы для вас лично показать, что IMDB сильно быстрее чем RDBMS на сходной нагрузки и далее долго и нудно убеждать вам, что условия разные и настроили мы RDBMS на максимальную производительность. Зачем? Чтобы что? Чтобы вы перешли на IMDB. Вы перейдете сами, если поймете, что ваше решение не справляется и вы никак не можете его ускорить. Однако, если на вашей нагрузке лошадь выгоднее автомобиля, то предлагаю ничего не менять, никуда не смотреть и быть довольным лошадью, пока она не перестанет справляться :-)
«выгружая наименее используемые блоки из кэша» — что приводит к рандомной записи на диск. Которой в IMDB нет.
«Механизма компактификации лога транзакций» — уже выше обсуждали, что тут неверно поняли друг друга, разное понимание терминалогии. Под компактификацией в IMDB понимается постоянный сброс полностью всего снимка всей базы данных, который снимает необходимость при восстановлении читать все логи, сделанные раньше снимка. Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.
«Не надо вам про обычные базы пока статью писать.» — это статья про IMDB. Но сравниваю с RDBMS. Чтобы было понятно тем кто сейчас на них сидит. Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.
Теперь насчет кластеров. На моем опыте все делается на уровне приложения. Кластеризация на уровне СУБД (как это сделано в couchbase) приводит к излишним тормозам и головняку. Обыяно кластеризуем так, что разделяет разные независимые куски на разные базы и храним их на разных серверах. Рассказывать детали, чем платится и какие ограничения пока не хочу. Сначала все надо в более менее обоснованную статью выдать, сведя все факты, иначе вы выльете поток говна и троллинга, не разобравшись :-)
Вопрос: что происходит с освобожденной памятью внутри этого дерева? Как она переиспользуется? С какой стоимостью происходит выделение в ней? (линейный поиск?). Если она никак не переиспользуется, то память в конечном итоге при интенсивной работы базы данных кончится, причем не поможет даже перезагрузка, потому что на диске в вашем случае дамп будет выглядеть также как в памяти. Если она переиспользуется, то это линейный поиск и медленная работа базы данных. И то и другое — плохо.
Цель дампа (снимка) в том, чтобы быстрее стратовать после перезагрузки. Если у вас есть только логи, то они могут проигрываться долго, потому что в них, скажем, обновления одного и того же элемента данных могут присутствовать много раз, а в снимке — только один раз — финальное значение.
https://en.wikipedia.org/wiki/Solid-state_drive: Время случайного доступа 0.1ms (1e-4)
https://en.wikipedia.org/wiki/Dynamic_random-access_memory: Время случайного доступа 50ns (5e-9)
Разница даже 5 порядков.
Вы говорите от NVM https://en.wikipedia.org/wiki/NVM_Express. Они подороже чем SSD диски, но побыстрее. Там проблемы случайного доступа почти нет.
Правда, странно вы меряете случайный доступ — 512КБ блоками. Если мерять 4К блоками, то результат будет в несколько раз скромнее у конкретно Samsung 950 Pro: http://www.anandtech.com/show/9702/samsung-950-pro-ssd-review-256gb-512gb/7
Ну и давайте вспомним тот факт, что RDBMS медленнее IMDB, даже если все сидит в кэшах (т.е. тут уже не важно какой диск под базой, пусть это даже супербыстрый флеш).
В качестве иллюстрации могу привести пример теста MariaDB — одной из самых прогрессивных с точки зрения производительности RDBMS на текущий момент (это заоптимизированный форк MySQL, ее авторы — создатели MySQL, ушли оттуда и организовали свою компанию после того как Oracle купил MySQL), по крайней мере среди open source. Этот тест провели сами создатели этой СУБД, т.е. мы можем надеяться, что СУБД настроена на максимальную пиковую производительности. Вот подробности про тест: https://mariadb.org/10-1-mio-qps/. Он показывает миллион запросов в секунду на дорогущей машине IBM Power8 с 20 ядрами и 160 хардварными потоками (читай, на самом деле, как с 160 ядрами). А вот тест IMDB Tarantool, который показывает миллион запросов в секунду на одноядерном виртуальном амазоновском сервере за $5 в месяц: https://gist.github.com/danikin/a5ddc6fe0cedc6257853 (кстати, исходник открыт — можете повтоить своими руками, причем бесплатно — ибо этот сервер попадает под free tier у Амазона).
Отличие, грубо говоря, в 160 раз. Можно тут долго спорить о реальной параллельности ядер у Power8 (хотя 20 честных ядер там точно есть), а также о том, на каком железе работают сервисs Амазона, но, в целом, отличие очевидно. Заметьте, это достаточно честный бенч в том смысле, что в обоих случаях вендо выжал максимум из своего детища, максимально хорошо его настроив.
Вы, Роберт, простите, теоретик. Давайте перейдем в область практики. Я у вас попросил вариант структуры в студию. Его все еще нет.
Насчет placement new и т.д., вы, очевидно, забыли, что структура изменяется. Из нее удаляются куски, добавляются новые, изменяются старые. Что делать с дырками? Оставлять как есть и просто выделять память в конец? Вариант структуры, которая не меняется, я привел выше — отсортированный вектор.
P.S.
Если вы сделаете в Тарантул pull-request, который мы примем и который бы поменял там все структуры таким образом, чтобы они копировались в среднем со скоростью 5Gb/s для баз данных в 256Gb, и которые при этом не занимали бы больше памяти, чем имеющиеся, то я вам тут же заплачу 3 миллиона рублей.
P.P.S.
Даже если допустить, что сделать структуры данных применимые для Тарантула, которые можно копировать со скоростью 5Gb/сек, то минута простоя и удвоенное потребление памяти — это все равно не вариант.
Ну если вам от этого спать спокойней, то, да перестанет )))
А когда, сверх того, постоянная память будет адресоваться напрямую процессором и при этом каждое изменение (каждый байт) будет моментально и синхронно персистить с латентностью текущей RAM, то и ваши любимые дисковые СУБД полетят в помойку — достаточно будет взять любую библиотеку структур данных, например, плюсовую STL и использовать ее как персистентную базу данных.
Насчет SSD — там такая же проблема как с HDD, но не в тех масштабах. На 2 порядка быстрее HDD, но все еще на 4 порядка медленнее памяти.
Есть сравнительные тесты Tarantool с другими СУБД в памяти: http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html, https://medium.com/@rvncerr/tarantool-vs-competitors-racing-in-microsoft-azure-ebde9c5d619#.ispbmmius. С дисковыми СУБД сравнений нет — там и так понятно, что выигрышь на несколько порядков.
Только лучше не копирование файлов, а копирование из /dev/zero, потому что копирование файла это чтение с диска и запись, а копирование из /dev/zero в файл — это только запись. Запускал. Один файл — 100Mb/s, два файла — по 50Mb/s. Это Linux. Там достаточно оптимально все устроено с точки зрения шаринга ресурсов диска.
Все верно говорите. По сути, есть два параллельных процесса записи на диск, каждый из которых пишет строго последовательно — запись в REDO и запись снимка. Запись снимка можно вести на «всех парах», потому что запись в REDO обычно редко потребляет больше нескольких % от максимальной производительности диска.
Это означает, что в вышеуказанных коммерческих системах размеры кэшей или буферных пулов задраны настолько высоко, что для данного паттерна нагрузки то, что я написал выше никогда не случается.
Еще раз повторюсь. Если вся база влезла в кэш, то тогда все хорошо. В противном случае аналог снимка (флаг грязных страниц) будет не успевать отрабатывать целиком, пока будут приезжать новые грязные страницы, и в этот момент придется задерживать клтиента пока не завершится флаш. Если вы считаете, что не придется, то куда тогда будут применяться изменения, если память кончилась? Только в REDO?
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
Я уже понял, что я кривовато сформулировал. И уважаемая бородатая общественность — любители старых добрых баз — тут же прицепилась к этому. Ну что ж, каждый получает удовольствие по своему.
Вы забыли добавить, что еще при адекватных пользователях, которые не создают нагрузку в 100K запросов в секунду :-)
Ибо, если пользователи не такие адекватные, то проблем не возникает только лишь при соответствующей настройке базы, чтобы она все грязные страница флашила путем последовательнорго обхода всей базы, чтобы не упираться в рандомную запись, а это значит, что пока она обходит должно быть место в памяти для хранения всех грязных страниц, что, в свою очередь, при равномерно распределенной нагрузке по всей базе почти неизбежно означает, что нужно в памяти хранить всю копию базы. Я этот тезив в том или ином виде повторяю уже Nый раз, и в ответ слышу лишь про магические хорошие настройки и тд без конкретнго объяснения физике процесса как узкая труба становится широкой.
in-memory базам хватает памяти. Они просто не работают, когда кончается память. Это не повод для гордости. Но это обратная строна медали, с которой надо мириться заранее при проектировании приложения. Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
Вест кусок, да на диск. Описал тут в деталах в одном из коментов. И это можно делать часто, ибо это происходит линейно, диск не нагружая, оставляя много IOPS'ов для REDO.
Там многие популярные IMDB участвуют. Наш Tarantool самый быстрый. Ну и что скажете вы? Тест же провели вы сами, значит верить ему нельзя. Троль всегда найдет как затроллить.
Добавить к тем же условиям MySQL? Ну можно. Он будет минимум в 10 раз медленнее по моеиу опыту (даже если все-все-все будет сидеть в памяти, без единой операции к диску). Но мой опыт же для вас не авторитет и мое умение настраивать RDBMS для вас тоже не акторитет. Поэтому ссылаюсь на признанных профессионалов в этой области (MariaDB). Да, условия теста у нас и у них разные. Т.е. они в целом похожи — рандомно селектим и апдейдим в таблицу, но не вот тебя прям одно и тоже.
Далее еще нюанс. Делать бенчи, чтобы для вас лично показать, что IMDB сильно быстрее чем RDBMS на сходной нагрузки и далее долго и нудно убеждать вам, что условия разные и настроили мы RDBMS на максимальную производительность. Зачем? Чтобы что? Чтобы вы перешли на IMDB. Вы перейдете сами, если поймете, что ваше решение не справляется и вы никак не можете его ускорить. Однако, если на вашей нагрузке лошадь выгоднее автомобиля, то предлагаю ничего не менять, никуда не смотреть и быть довольным лошадью, пока она не перестанет справляться :-)
«Механизма компактификации лога транзакций» — уже выше обсуждали, что тут неверно поняли друг друга, разное понимание терминалогии. Под компактификацией в IMDB понимается постоянный сброс полностью всего снимка всей базы данных, который снимает необходимость при восстановлении читать все логи, сделанные раньше снимка. Снимок всей базы у RDBMS не делается, потому что RDBMS не хранится вся в памяти.
«Не надо вам про обычные базы пока статью писать.» — это статья про IMDB. Но сравниваю с RDBMS. Чтобы было понятно тем кто сейчас на них сидит. Я понимаю, что тут сидят все профи по RDBMS. Вопрос только в том до каких нагрузок эти профи их разгоняли и во что эти профи упирались. Если вы на их нагрузках они ни во что не упирались, то не надо думать, что вы супер-профи и все про RDBMS знаете, все адекватно настроили и сидите на вершине мира, и не надо думать, что те, кто уже сидят на IMDB — полные мудаки и не пробовали различные варианты ускорить RDBMS прежде чем перейти на IMDB. Призываю вас сконцентрироваться на том, что для вас новое и познавать, вместо того, чтобы цепляться к каждой букве, строить неверные выводы и триумфировать на этом.
Теперь насчет кластеров. На моем опыте все делается на уровне приложения. Кластеризация на уровне СУБД (как это сделано в couchbase) приводит к излишним тормозам и головняку. Обыяно кластеризуем так, что разделяет разные независимые куски на разные базы и храним их на разных серверах. Рассказывать детали, чем платится и какие ограничения пока не хочу. Сначала все надо в более менее обоснованную статью выдать, сведя все факты, иначе вы выльете поток говна и троллинга, не разобравшись :-)
Цель дампа (снимка) в том, чтобы быстрее стратовать после перезагрузки. Если у вас есть только логи, то они могут проигрываться долго, потому что в них, скажем, обновления одного и того же элемента данных могут присутствовать много раз, а в снимке — только один раз — финальное значение.
https://en.wikipedia.org/wiki/Solid-state_drive: Время случайного доступа 0.1ms (1e-4)
https://en.wikipedia.org/wiki/Dynamic_random-access_memory: Время случайного доступа 50ns (5e-9)
Разница даже 5 порядков.
Вы говорите от NVM https://en.wikipedia.org/wiki/NVM_Express. Они подороже чем SSD диски, но побыстрее. Там проблемы случайного доступа почти нет.
Правда, странно вы меряете случайный доступ — 512КБ блоками. Если мерять 4К блоками, то результат будет в несколько раз скромнее у конкретно Samsung 950 Pro: http://www.anandtech.com/show/9702/samsung-950-pro-ssd-review-256gb-512gb/7
Ну и давайте вспомним тот факт, что RDBMS медленнее IMDB, даже если все сидит в кэшах (т.е. тут уже не важно какой диск под базой, пусть это даже супербыстрый флеш).
В качестве иллюстрации могу привести пример теста MariaDB — одной из самых прогрессивных с точки зрения производительности RDBMS на текущий момент (это заоптимизированный форк MySQL, ее авторы — создатели MySQL, ушли оттуда и организовали свою компанию после того как Oracle купил MySQL), по крайней мере среди open source. Этот тест провели сами создатели этой СУБД, т.е. мы можем надеяться, что СУБД настроена на максимальную пиковую производительности. Вот подробности про тест: https://mariadb.org/10-1-mio-qps/. Он показывает миллион запросов в секунду на дорогущей машине IBM Power8 с 20 ядрами и 160 хардварными потоками (читай, на самом деле, как с 160 ядрами). А вот тест IMDB Tarantool, который показывает миллион запросов в секунду на одноядерном виртуальном амазоновском сервере за $5 в месяц: https://gist.github.com/danikin/a5ddc6fe0cedc6257853 (кстати, исходник открыт — можете повтоить своими руками, причем бесплатно — ибо этот сервер попадает под free tier у Амазона).
Отличие, грубо говоря, в 160 раз. Можно тут долго спорить о реальной параллельности ядер у Power8 (хотя 20 честных ядер там точно есть), а также о том, на каком железе работают сервисs Амазона, но, в целом, отличие очевидно. Заметьте, это достаточно честный бенч в том смысле, что в обоих случаях вендо выжал максимум из своего детища, максимально хорошо его настроив.
Вы, Роберт, простите, теоретик. Давайте перейдем в область практики. Я у вас попросил вариант структуры в студию. Его все еще нет.
Насчет placement new и т.д., вы, очевидно, забыли, что структура изменяется. Из нее удаляются куски, добавляются новые, изменяются старые. Что делать с дырками? Оставлять как есть и просто выделять память в конец? Вариант структуры, которая не меняется, я привел выше — отсортированный вектор.
P.S.
Если вы сделаете в Тарантул pull-request, который мы примем и который бы поменял там все структуры таким образом, чтобы они копировались в среднем со скоростью 5Gb/s для баз данных в 256Gb, и которые при этом не занимали бы больше памяти, чем имеющиеся, то я вам тут же заплачу 3 миллиона рублей.
P.P.S.
Даже если допустить, что сделать структуры данных применимые для Тарантула, которые можно копировать со скоростью 5Gb/сек, то минута простоя и удвоенное потребление памяти — это все равно не вариант.
А когда, сверх того, постоянная память будет адресоваться напрямую процессором и при этом каждое изменение (каждый байт) будет моментально и синхронно персистить с латентностью текущей RAM, то и ваши любимые дисковые СУБД полетят в помойку — достаточно будет взять любую библиотеку структур данных, например, плюсовую STL и использовать ее как персистентную базу данных.
Насчет SSD — там такая же проблема как с HDD, но не в тех масштабах. На 2 порядка быстрее HDD, но все еще на 4 порядка медленнее памяти.
Есть сравнительные тесты Tarantool с другими СУБД в памяти: http://highscalability.com/blog/2015/12/30/how-to-choose-an-in-memory-nosql-solution-performance-measur.html, https://medium.com/@rvncerr/tarantool-vs-competitors-racing-in-microsoft-azure-ebde9c5d619#.ispbmmius. С дисковыми СУБД сравнений нет — там и так понятно, что выигрышь на несколько порядков.
К утру сошлись на трех рублях :-)
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
В разогретой базе процент попадания в кэш высокий. Вопрос в том, как быстро работает это кэш версус ин-мемори база. Обычно хорошо, если в 10 раз медленнее, как я написал выше. Плюс его разгорев — это отдельная боль, я уже писал про это.
Ибо, если пользователи не такие адекватные, то проблем не возникает только лишь при соответствующей настройке базы, чтобы она все грязные страница флашила путем последовательнорго обхода всей базы, чтобы не упираться в рандомную запись, а это значит, что пока она обходит должно быть место в памяти для хранения всех грязных страниц, что, в свою очередь, при равномерно распределенной нагрузке по всей базе почти неизбежно означает, что нужно в памяти хранить всю копию базы. Я этот тезив в том или ином виде повторяю уже Nый раз, и в ответ слышу лишь про магические хорошие настройки и тд без конкретнго объяснения физике процесса как узкая труба становится широкой.
in-memory базам хватает памяти. Они просто не работают, когда кончается память. Это не повод для гордости. Но это обратная строна медали, с которой надо мириться заранее при проектировании приложения. Ровно также как обычные базы перестают работать при нагрузке хотя бы 1/10 от in-memory баз, даже если все сидит в кэше. И с этим фактом тоже надо мириться заранее при проектировании приложения.
Вест кусок, да на диск. Описал тут в деталах в одном из коментов. И это можно делать часто, ибо это происходит линейно, диск не нагружая, оставляя много IOPS'ов для REDO.