Pull to refresh
0
0
Send message
На случай если кто решит так сделать — воду лить надо на теплоноситель, а не на само горящее вещество. Иначе вода испаряется на топливе и конденсируется на трубах теплоносителя передавая таким образом ему еще дофига тепла. Тем более что котлы обычно устроены так что стекающая вода в итоге таки попадет на огонь, но к тому времени и температура теплоносителя будет меньше и сами трубы будут в воде, а значит доп тепло пойдет на ее испарение.
Доп эффекты дают ну очень незначительные отклонения.
Потипу такого — если нарисовать треугольник на земле, то сумма его углов должна быть больше чем 180 т.к. на самом деле он же нарисован на поверхности сферы. Но можно ли это заметить обычным транспортиром?
Ну, такие структуры часто заворачиваются в какой нить shared_ptr, так что как такового мемори лика нет — указатель на память не теряется, просто живет всю жизнь процесса. При выходе из main счетчик станет равен 0 и память освободится. Если же там сырой указатель, то да valgrind скажет что течет.
В сторону kairosdb не смотрели? Это как раз time-series сервис хранящий данные в Кассандре. По сути это дб схема + апи.
Оптимизация конфига MySQL это дать побольше под innodb_buffer_pool_size и включить innodb_numa_interleave.
Все, остальной тюнинг на данном этапе (когда нужно править запросы и индексы и переезжать на InnoDB) ничего не даст.
Нет, можно конечно остаться на MyISAM и тюнить уже его, но это будет время потраченное зря.
Ну скажем так — оно то может и можно подпинать оптимизатор в сторону более идеального запроса, но разница обычно небольшая ~1%. Я говорю про случаи когда запрос написан вдумчиво и правильно, а не абы как, тогда и подсказывать ненадо.

является замена join с таблицей на join с подзапросом,

Сколько не видел — всегда появление подзапроса портило план выполнения, вот уж где оптимизатор Mysql тупит вовсю. Из последних случаев — наличие подзапроса вызывало лок всех строк в таблице, как по выводу explain так и по факту. Выкидывание подзапроса и join таблицы на себя — получаем идеальный план выполнения.

У оптимизатора Oracle свои причуды. Например он очень котирует индексы по временным колонкам в партиционированной по времени таблицы и игнорит другой очень селективный индекс.
Была в проекте на прошлой работе одна InnoDB-табличка на несколько сотен записей. Она пополнялась в триггере при изменении записей в другой таблице.

Т.е. по сути это логгер таблица. Вообщем да, это пожалуй единственный полезный кейс MyISAM т.к. нетранзакционная, а в mysql нет autonomous transaction. Если надо заллогировать фейл транзакции то выбора по сути нет.
Но такая лог таблица обычно а) не содержит критикал данных б) нет требований по производительности, так что по сути в вашем случае можно было взять любой другой движок на выбор.
1. Не поможет. Вот к примеру идет поток insert'ов на MyISAM таблицу и каждый делает лок/инсерт/анлок. Т.е. происходит такая себе конвертация в serializable что все равно никак не ускорит процесс.
2. В MySQL оптимизатор конечно не идеальный, но такую оптимизацию даже он сделает.
4. На самом деле в 5.7 (да даже с 5.6) его неплохо так пилят и он уже вполне неплох.
Ну перестаньте уже эту городскую легенду таскать, тем более что у вас уже 5.7. Innodb прекрасно в нем работает, а недостатков у MyISAM столько, что я уже не знаю зачем его можно использовать.

В вашем случае переезд на Innodb как минимум даст
а) неблокирующее чтение вообще, т.к. данные читаются из снапшота
б) локи только на нужные строки

Это гарантированно улучшит общий перфоманс базы.
Я вот не совсем понял. Есть мастер база, данные льются по реплике на стендбай, вроде все ок. Дальше мы берем и стопнув инстанс базы на мастере удаляем дб файлы там же. Но на стендбай же это никак не отразилось! Если б он не «rm -rf», а «drop database» сделал, тогда да, реплики не спасают, но сдесь то как?
Полистал их доки — они юзают append only WAL и SStables, т.е. очень похоже на Cassandra.
SStables видимо immutable, к сожалению тема update/delete не раскрыта, но если так, то модель вообще 1в1 Cassandra.

Так что можно предположить что MyRocks имеет те же недостатки — любой select/update/delete по очень давней (исторической) таблице будет очень болезненным т.к. нужно сканить SStables на предмет tombstones.

Именно этот аспект в тестах не раскрыт, что косвенно подтверждает это предположение.
Пример хороший, только это 2ой босс. А 1ый босс как показывает практика очень неочевиден — тем что при первой встрече от него надо убегать.
Если взять
обычно при превышении отметки в 100 Гб менее, чем за месяц

то это 3 часа каждый день послушать музычку онлайн. Если например больше 3х часов или HD youtube то вылетишь за пределы аж бегом и без всякого тетеринга.
По мнению аналитиков всего несколько процентов абонентов на безлимитных тарифах могут существенно загрузить сеть оператора и понизить качество предоставляемых услуг для других абонентов.

И видимо по мнению аналитиков это вида пользователей, а не провайдера. Прекрасно.
Как только мы скопировали данные в отдельный буфер в оперативной памяти, нужно записать их на диск. Пока идет запись копии, исходные данные в памяти продолжают меняться. Эти изменения как-то нужно отслеживать

Вот этот кусок не понял. Да, данные меняются, но в оригинальной же памяти, зачем за ними следить? При заморозке считали айди последней транзакции из commit log'а и записали рядом. Все, у вас есть полная, консистентная копия, на момент транзакции N.
Паял в доме полностью весь водопровод из пластиковых труб. Ничего сложного — 1 раз посмотрел видео на youtube и 1 раз посмотрел в живую, дальше все сам.
Есть еще кейс когда люди просят знакомых «гуру» (тыжпрограмистов) — «а можно что то сделать что б у меня на пол экрана не выскакивало?»
Честно говоря причины бредовые.

Возьмем к примеру упомянутый gerrit:
Говорится что почтой легче например завернуть патч со словами tl:dr. Но чем это отличается от — Нажал Reply..., написал тот же комент, нажал Post. Все. Какого то яростного преимущества почты я в этом сценарии не вижу.

Т.е. все те недостатки web инструментов пор которые они говорят абсолютно так же есть и в почте. Все преимущества почты есть и в web тулзах.
Единственно момент с отсутствием интернета, это да, у почты в этом фора.

Еще непонятный момент — почему критикуя web тулзы они говорят именно про github? Вон в каментах упоминают Gitlab например или вообще что мешает поднять свой для разработки ядра? Таким подходом можно было б и добавить фичу «скачать все патчи за раз». Я так понимаю именно на этот сценарий они упирают в аргументе про постоянный доступ к интернету?
«Если существуют другие вселенные, то они отделены от нас огромными дистанциями, удаляются на огромных скоростях»

Но по логике текста пространство это часть (свойство) именно вселенной. Т.е. «за пределами» нашей вселенной говорить о пространстве, а значит и о расстоянии, скорости, некорректно. Разве нет?

Information

Rating
Does not participate
Registered
Activity