И о конкурентах
Jan. 26th, 2016 08:21 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
natarajВчера в беседе с ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
alexkuklin с удивлением для себя узнал, что mysql при апгрейде с версии на версию не требует апдейта базы. Новая версия просто кушает бинарное хранилище от старой.
Казалось бы, это ровно то чего хочет пользователь. Просто обновляешься и оно просто работает. Всеобщее счастье и благорастворение воздухов. Но...
Какой ценой это достигается? Достигается это ценой того, что база в себе тащит код для обратной совместимости.
Во-первых это не паханное поле граблей. Это комбинация N версий хранилища на M версий движка. В каком месте что там стрельнет -- даже Рогозину не снилось.
Во-вторых этот весь код N*M надо поддерживать от релиза к релизу, это стоит ресурсов достойных другого примирения.
В-третьих, сюрприз(!) если не обновлять бинарное хранилище, то не начнут работать оптимизации новых версий, связанные с хранением. То есть ты базу обновляешь, а она быстрее работать не начинает!
В-четвертых, если таки захотелось пользоваться новым движком, то, по словамalexkuklin базу данных надо пересоздавать. Как при царском режиме. То есть не натравить на нее программу апгрейда, а именно dump/restore.
Я конечно полагаю что разработчики mysql знают что они делают, тем или иным способом они каждую из этих проблем решают,или минимизируют ущерб. И наверное для базы данных маленьких личных хостингов это решение вполне уместно. Но все что за пределами -- это не уместно совершенно.
Так что покупайте наших слонов! На дельфинах далеко не уедешь!! ;-)
alexkuklin с удивлением для себя узнал, что mysql при апгрейде с версии на версию не требует апдейта базы. Новая версия просто кушает бинарное хранилище от старой.Казалось бы, это ровно то чего хочет пользователь. Просто обновляешься и оно просто работает. Всеобщее счастье и благорастворение воздухов. Но...
Какой ценой это достигается? Достигается это ценой того, что база в себе тащит код для обратной совместимости.
Во-первых это не паханное поле граблей. Это комбинация N версий хранилища на M версий движка. В каком месте что там стрельнет -- даже Рогозину не снилось.
Во-вторых этот весь код N*M надо поддерживать от релиза к релизу, это стоит ресурсов достойных другого примирения.
В-третьих, сюрприз(!) если не обновлять бинарное хранилище, то не начнут работать оптимизации новых версий, связанные с хранением. То есть ты базу обновляешь, а она быстрее работать не начинает!
В-четвертых, если таки захотелось пользоваться новым движком, то, по словам
alexkuklin базу данных надо пересоздавать. Как при царском режиме. То есть не натравить на нее программу апгрейда, а именно dump/restore.Я конечно полагаю что разработчики mysql знают что они делают, тем или иным способом они каждую из этих проблем решают,или минимизируют ущерб. И наверное для базы данных маленьких личных хостингов это решение вполне уместно. Но все что за пределами -- это не уместно совершенно.
Так что покупайте наших слонов! На дельфинах далеко не уедешь!! ;-)
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2016-01-27 12:20 am (UTC)риалли?
без волчьего билета "вон из профессии"?
no subject
Date: 2016-01-27 05:38 am (UTC)no subject
Date: 2016-01-27 06:09 am (UTC)За Сбербанк не скажу, а коллеги из-за стенки свою СУБД апгрейдят минут за 20-30.
no subject
Date: 2016-01-27 05:39 pm (UTC)HCFB - да, 15-30 минут даунтайма раз в квартал планово. но БД при это не трогалась. технологические обновления - да, ставились.