Pull to refresh
98
0
Денис Аникин @danikin

User

Send message
Все верно. Плюс, мы еще в Mail.Ru принимаем решения не на основе «извращние»/«православие», а на основе каких-то более понятных бизнес-терминов — быстрее/медленнее, дешевле/дороже и тд.
По моему опыту (да-да, мы криволапые админы, работающие на самом высоконагруженном сервисе в России и все такое) все наоборот.

Старт БД в RAM

1. Переключаем IP с мастера на реплику
2. Делаем мастер репликой
3. Новый мастер моментально обслуживает запросы
4. Предыдущий мастер в течении часа спокойно стартует

Старт БД НЕ В RAM

1. Прогреваем скриптиками кэш, плящем с бубном, молимся, что он хотя бы за сутки прогреется и начнет с нормальной скоростью сервить запросы
2. На реплику переключать бестолку. Почему? Потому что туда не идут запросы на чтение, поэтому кв кэше там нет тех данных, которые запрашиваются часто с клиентов, и поэтому реплика будет такой же холодной как и мастер.
Учитывая все коментарии выше, где безграмотность? Цитату в студию.

Далее, в какую сумму вы, уважаемый, квалифицированный знаток MySQL, оцениваете свои услуги по грамнотной настройке индексов MySQL, чтобы он работал быстрее Тарантула или хотя бы также? Назовите свою цену, я вас найму, срубите легкие деньги.

Скажу более, Percona вас оторвет с руками за любые деньги. Они с вашей помощью ускорят миллионы инстансов MySQL по всему миру до скорости in-memory баз данных и заработают на это миллиарды долларов.

И, наконец, Фейсбук тут же возьмем вас на работу — они выкинут все их кэши и прочие самописные штуки типа Tao или Dragon поверх MySQL и останутся с голым оптимизированным MySQL, работающим быстрее чем in-memory базы данных. Их специалисты, работающие в крупнейших технологических компаниях мира ждут вас с распростертыми объятиями. Странно6 что вы еще там не работаете.
Ускоряет, но лишь частично. После обращения по индексу, нужно вытащить с диска с данные. А это обычно рандомное обращение к диску.
Эта операция в большинстве моих кейсов — дешевая. Будет отдельная статья с деталями.
Ускорять чтение данных — имеется в виду делать быстрее селекты. В это словосочетание входят и поиск по индексу и чтение данных. Простите, что я термин считывание понимаю не так как вы его понимаете. Хотя, это в практике вещей тут — взять слово, выдрать из контекста, понять его по другому и дальше научить аффтора прописным истинам, сделав вывод из своей фантазии, приписав автору того, чего нет на самом деле. Смысл? Поднять свою значимость?

«Это не недостаток дерева, а любого индекса» — ну а вы контекст расширьте. Фраза написана в контексте, что это дерево на диске. Каждое изменение (да и чтение тоже, кстати) — произвольный доступ к диску. В IMDB такого нет — там все в памяти. Недостаток это или нет? Вопрос филосовский. Кому-то нравится, когда помедленнее.

1,2. Я понял уже, что это тема для отельной статьи, даже двух. Так вот быстро и подробно не ответишь. Скоро опубликую. Вызову, наверное, опять шквал гнева у любителей старины, но что поделаешь :-)
IMDB в этом случае вообще не сможет стартануть.
Я так понимаю, что коллега имеет в виду кэш для table space (write back buffer). Т.е. в журнал транзакций пишем сразу, а в table space применяем отложено. Откладывать можно с точки зрения надежности насколько угодно долго — все равно все изменнеия сохраняются в логе и при рестарте считываются и накатываются в table space.
Буду иметь в виду. Автор тут я, Денис Аникин, можете погуглить другие мои статьи (Dennis Anikin — если по английски решите почитать) :)
Согласен!

Самое любопытное, что извинений за оскорбления не следует.
Да. В контексте этого конкретного обсуждения, если вы читали его, «не in-memory» == «традиционная дисковая СУБД, основанная на B/B+ дереве»

LSM — это отличная структура данных! И я про это в статье упомянул и даже таблицу нарисовал, поищите выше по слову LSM.
Спасибо за ваше интересное мнение. Есть и другие мнения, когда просят сравнить дисковые СУБД и ин-мемори СУБД. Сравнение зачастую кому-то кажется поиском минусов.
Вам никто и не предлагает писать собственную СУБД. Если вы ее напишите, то единственным ее пользователем будете вы сами, поэтому вам лично дешевле остаться на SSD.
Согласен с вами! К сожалению, таких пап много. Когда достижений показать нельзя, то остается только сидеть на хабре папствовать :-)
1. Да, это флаг. А fsync — это системный вызов такой, который под капотом делает dd, когда вы ему флаг dsync задаете. Просил я вас трижды написать конкретную команду, так и не допросился. Можно мой cat заменить вот на такое: dd if=/dev/zero of=/root/testfile bs=1G count=1 oflag=dsync

2. Разница еще в том, что в in-memory записывается в слепок последовательно (раз в какое-то время во время снэпшоттинга), а в не in-memory записывается в слепок рандомно. У вас в не in-memory базе данных одно изменение стоит в среднем больше иопсов чем в in-memory, хотя и там и сям персистится.

3. Если не влезло в кэш, то, надо полагать, дисковая база данных при выполнении SELECT получает данные не рандомными обращениями в B+ деревья, а по воздуху из центрального зикурата на голубях.

Но, кажется, я начинаю понимать. Ваш вопрос такой — зачем ваще эти новомодные ин-мемори базы данных, когда есть дисковые базы данных, у которых можно задрать кэши и получить ту же инмемори. Да? Это тема отдельной статьи. У меня был доклад на хайлоуде про это. Я скоро опубликую. Если кратко, то in-memory в этом случае гораздо быстрее. Казалось бы и там все ин-мемори и здесь. Но когда база сразу заточена под in-memory, то она просто более эффективна, потому что какие-то вещи сразу по другому сделаны, без оглядки на то, что данные могут не влезть в память. В общем, расскажу.

Вторая половина вашего вопроса. База на базу не приходится. Кто-то хранит предыдущие версии (в памяти, разумеется). Кто-то блокирует все жестко. Про это тоже будут статьи обязательно.

4. Да, все веро.

5. Я придерживаюсь принципа — работает — не трож. Если Oracle работает хорошо, то не надо его менять на in-memory. Я не фанат священных войн между дисковыми и ин-мемори СУБД.

6. Да. Но, к сожалению, это не убирает рандомные обращения к диску, которые рано или поздно надо сделать, чтобы сохранить, скажем миллион изменений, которые прямо сейчас сидят в памяти и которым предстоит записаться в различные части диска.

7. 1) А, т.е. я этого факта не знал, пока вы не сказали? :) Цитирую сам себя тогда:

Во-первых, в отличие от СУБД в оперативной памяти, в традиционных СУБД необходимо считывать данные с диска при каждом запросе (давайте ненадолго забудем про кеширование, это тема для отдельной статьи).

7. 2) Не новость для меня

7. 3) Самое прямое. Это структура данных на диске для хранения индексов, которую используют традиционные дисковые СУБД. И эту структуру надо апдейтить. Пусть не на каждое изменение, но рано или поздно надо апдейтить, а значит рандомно читать от корня вниз, рандомно писать в листья, рандомно писать, чтобы сливать-разливать листья.

8. Вы задали вопрос (по существу). Я ответил. Если вам что-то не понятно, то уточните. Я не понимаю к чему этот пассаж.

9. Если маленькая highload БД помещается в память, то ей SSD не нужен. Перечитайте — статью — там популярно объяснено, почему не нужен :) Если она не помешается в память, то, возможно, она уже не такая маленькая.
Наc и так все бюьт за Lua, а вы говорите проприетарный :-)

Насчет операционки — на нас иногда находят мысли, что если унести какие-то вещи в kernel space для уменьшения переключения контекстов, но мы их гоним от себя и думаем как по другому еще можно уменьшить :-)
Комментирую ваше сверху вниз

1. Существенное отличие dd от cat в данном контексте я вижу лишь в том, что в dd можно настроить fsync. Наверное, вы это имели в виду про правильные опции. Сразу возникает вопрос, какой размер записи выбирать перед каждым fsync? Производительность будет отличаться в зависимость от оного размера. Цель была замерить производительность диска в самом-самом лучшем кейсе.

Жду ваш пример команды, которую можно выполнить из консоли *nix системы, и которая более точно покажет максимальную производительность диска на запись чем моя команда. Пока лишь слова.

2. К сожалению, не могу залезть вам в голову и понять, что вы додумали и какие выводы сделали из того, что додумали. У меня мысль была простая — все, что изменено в дисковой СУБД (в любой), должно меняться не только в redo логе, но и в самом табличном пространстве. Да, пусть не сразу, да можно эти изменения кэшировать в памяти (в случае краша они все равно из redo лога восстановятся), но рано или поздно их надо применить в табличное пространство, просто потому что операции SELECT не парсят redo лог (это было бы слишком дорого и долго), они лезут в табличное пространство + смотрят в то, что в кэше. У in-memory баз данных изменения не надо применять в табличное пространство — только запись в redo лог (он же лог транзакций, как я называю его в статье).

3. Где у вас все в памяти? В дисковой СУБД? Вы статью читали вообще или по верхам? :) Я процитирую специально для тех кто в танке:

«поэтому для быстрого считывания дисковым СУБД нужны особые структуры данных, чтобы избежать полного сканирования журнала транзакций.

Одна из таких структур — B/B+-дерево, ускоряющее считывание данных»


4. Мы, наверное, по разному понимаем слово компактификация. То, что я понимаю под этим словом в своей статье я написал в P.S. Не поленитесь почитать.

5. Напишите, пожалуйста, скриптик, который закинет в кэш таблицы индексы, которые не влезают в память. Если они у вас всегда влезают, то это не означает, что у всех также. И если они у вас всегда влезают, то, возможно, вам надо рассмотреть in-memory СУБД. По крайней мере, скриптик писать не придется.

6. В вашем кейсе с миллионами и миллардами изменений одного блока — все так. Запись будет ускоряться. Не видел, правда, в продакшн нагрузке такое. Обычно у меня миллионы и десятки миллионов пользователей и они все пользуются сервисом, и их данные размазаны так или иначе по диску. Хотя, конечно, для системы, где один пользователель постоянно изменяет свои данные миллионы раз, согласен с вами, кэш на запись работает хорошо.

7. Обязательно изменю заголовок, если услышу от вас знание о работе RDBMS, которое бы противоречило тому, что написано в статье.

8. О, наконец-то по существу! :) Зависит от СУБД. В случае Tarantool мы постарались, чтобы таких ограничений было минимально. ACID-транзакции, хранимые процедуры, репликация — все в Tarantool есть. Нет, правда, SQL пока. Он на подходе. Планируем к концу этого года альфа-версия. Главная жертва — это то, что все в памяти. Остальные жертвы, если они есть, они не являются следствием того, что база в памяти, а скорее следствием сфокусированности той или иногй команды in-memory СУБД на тех или иных фичах.

9. Про HDD. В том то весь и фокус, что для in-memory базы вам не нужны SSD. У вас вся запись/чтение последовательное. Почитайте все-таки внимательно статью прежде чем осуждать. Ну или так сразу и напишите, не читал, но осуждаю :-)
Утверждается, что команда выше, если ее оставить на достаточно долгое время, будет демонстрировать максимальную скорость работы диска.

Конечно, если вам не важна сохранность изменений после перезагрузки компьютера, т.е. ваша операционная система настроена так, что вся доступная оперативная память используется для write back буферов, то придется подождать какое-то время, пока все эти буфера не наполнятся.

Хотя, в большинстве случаев, даже при таком аггресивном кэшировании записи, ждать придется недолго. Слава богу, память конечная и слава богу наполнится она быстро, потому что работает быстро (перегонка из буфера в памяти приложения в буфера Linux'а большими кусками через системный вызов происходит на моем опыте со скоростью полгига в секунду и выше). После чего пойдет уже реальная запись на диск, которая будет упираться в диск. И диск при такой нагрузке будет работать на максимальной скорости, ибо писать будет строго последовательно и большими кусками. Собственно, эту максимальную скорость вы и увидите по скорости роста файла.

Но хорошо, что есть такие профессионалы как вы, которые грустят, смеются, обличают других, ничего не знающих про файловый кэш, удивляются их знаниям по работе реальных БД и знают как минимум чуть больше чем ничего про файловый кэш. Они-то нам всем сейчас расскажут как все происходит на самом деле.
Не за что! Вам спасибо за высокую оценку! :-)

Эта статья и есть перевод. А как надо было оформить?

Information

Rating
Does not participate
Location
Москва и Московская обл., Россия
Works in
Date of birth
Registered
Activity