Сегодня я разговаривал с программистом и он спросил меня, а вот какую версию ты посоветуешь для моего сервера mysql?
Сегодня я попытаюсь рассказать вам о преимуществах всех версии 5.х
И так.
Какие у нас бывают ветки Mysql.
1)5.0
2)5.1
3)5.5
Сейчас мы подробно рассмотрим каждую из них.
1) Плюсы первой ветки заключаются в её стабильности, оттестированности на многом железе.
Минусов же много - малый функционал , низкая скорость работы, лаги, глюки, баги , множество неприятных моментов.
2) Это по сути обновлённая чуть чуть версия мускуль, единственное что она стала чуть более медленной и более привередливой к ресурсам.
Из плюсов могу подчеркнуть только расширенный функционал и усиленную защиту.
3)В чём суть этой версии?
Mysql всегда системой управления БД малых или средних масштабов ( не более 1 тысячи коннектов одновременно) , но вот незадача , время идёт и некоторым людям требуется обрабатывать задачи гигантских размеров.
К примеру база данных, весом 5 террабайт, к который обращаются на чтение и запись несколько тысяч клиентов и приложений.
И представьте что всё идёт в одну базу.
Да, не спорю , нужно очень мощное железо , может быть даже кластерные вычисления, для таких задач. Но вот ведь незадача, база всё равно отвечает с заметными глюками, а опеределённых клиентов не успевает обработать , хотя на помощь брошенно самое мощное железо и очень нелохая комманда спецов.
Предложение номер 1 - Давайте переведём наш серверный кластер на другую субд.
Вроде бы никаких нареканий нет , поставить Oracle , хоть он и дорогой и обслуживать клиентов дальше.
Но вот осечка, у оракла совершенно другие подходы к построению сервера БД , то есть клиенты использующие функции Mysql не смогут работать , вывод - потеря 95% клиентов в лучшем случае.
Это не вариант.
Вариант номер 2 - создавать фронт-энл на базе запросов и распределять нагрузку между серверами.
Но вот 2 незадчи
1 - Mysql не знает что такое Front End , технологии кластерного вычисления применяются и так.
2 - Для этого прийдётся обновлять весь серверный парк , а это как минимум 200 серверов к каждому надо подвести розетку , интернет, на такой парк нужно много системных администраторов, много места, бизнес становится не окупаемым.
Вариант номер 3 - Установить SSD и SAS жёсткие диски
Начнём с SAS жёстких - они уже стояли, администрация этого проекта не такие дураки.
Что касается SSD - вы себе представляете 10 террабайт с запасом перевести на SSD? Это вырвать 2-ух месячный оборот и потратить на SSD , если брать его из прибыли , это год в лучшем случае.
Вариант номер 4 - Закешировать всю бд.
Предположим чисто в теории закешировать всю бд можно, но 10 терабайт оперативной памяти выделить не представляется возможным.
Вариант номер 5 - Перевести всё на Linux без Gui с собственной компиляцией.
Стоит минимальный FreeBSD с самоскомпилированным всем без дополнительных модулей под O3, так что от линукса выйгрыша не будет.
Вариант номер 6 - написать свои драйвера для некоторых устройств с оптимизацией под базы данных.
Чтож .. хороший вариант , но опять но но и ещё раз но, это дорого и не рентабельно , плюс нету полигона который это протестирует, или вы постаите нестабильный драйвер на готовое железо?
Вариантов можно придумать массу, но все они имеют критические изьяны, к сожалению которые не позволяют использовать эту СУБД для больших проектов.
Но вот, вышел 5.5, он собирается доказать всем что они ввели множество ускоренных систем, поэтому у них очень высокая скорость обращения ко всему что имеется.
Поэтому на маленьких серверах со слабым железом, выйгрыш составит 1-2% , но вот на серьёзных проектах с большими нагрузками можно весьма потягаться.
Сегодня я попытаюсь рассказать вам о преимуществах всех версии 5.х
И так.
Какие у нас бывают ветки Mysql.
1)5.0
2)5.1
3)5.5
Сейчас мы подробно рассмотрим каждую из них.
1) Плюсы первой ветки заключаются в её стабильности, оттестированности на многом железе.
Минусов же много - малый функционал , низкая скорость работы, лаги, глюки, баги , множество неприятных моментов.
2) Это по сути обновлённая чуть чуть версия мускуль, единственное что она стала чуть более медленной и более привередливой к ресурсам.
Из плюсов могу подчеркнуть только расширенный функционал и усиленную защиту.
3)В чём суть этой версии?
Mysql всегда системой управления БД малых или средних масштабов ( не более 1 тысячи коннектов одновременно) , но вот незадача , время идёт и некоторым людям требуется обрабатывать задачи гигантских размеров.
К примеру база данных, весом 5 террабайт, к который обращаются на чтение и запись несколько тысяч клиентов и приложений.
И представьте что всё идёт в одну базу.
Да, не спорю , нужно очень мощное железо , может быть даже кластерные вычисления, для таких задач. Но вот ведь незадача, база всё равно отвечает с заметными глюками, а опеределённых клиентов не успевает обработать , хотя на помощь брошенно самое мощное железо и очень нелохая комманда спецов.
Предложение номер 1 - Давайте переведём наш серверный кластер на другую субд.
Вроде бы никаких нареканий нет , поставить Oracle , хоть он и дорогой и обслуживать клиентов дальше.
Но вот осечка, у оракла совершенно другие подходы к построению сервера БД , то есть клиенты использующие функции Mysql не смогут работать , вывод - потеря 95% клиентов в лучшем случае.
Это не вариант.
Вариант номер 2 - создавать фронт-энл на базе запросов и распределять нагрузку между серверами.
Но вот 2 незадчи
1 - Mysql не знает что такое Front End , технологии кластерного вычисления применяются и так.
2 - Для этого прийдётся обновлять весь серверный парк , а это как минимум 200 серверов к каждому надо подвести розетку , интернет, на такой парк нужно много системных администраторов, много места, бизнес становится не окупаемым.
Вариант номер 3 - Установить SSD и SAS жёсткие диски
Начнём с SAS жёстких - они уже стояли, администрация этого проекта не такие дураки.
Что касается SSD - вы себе представляете 10 террабайт с запасом перевести на SSD? Это вырвать 2-ух месячный оборот и потратить на SSD , если брать его из прибыли , это год в лучшем случае.
Вариант номер 4 - Закешировать всю бд.
Предположим чисто в теории закешировать всю бд можно, но 10 терабайт оперативной памяти выделить не представляется возможным.
Вариант номер 5 - Перевести всё на Linux без Gui с собственной компиляцией.
Стоит минимальный FreeBSD с самоскомпилированным всем без дополнительных модулей под O3, так что от линукса выйгрыша не будет.
Вариант номер 6 - написать свои драйвера для некоторых устройств с оптимизацией под базы данных.
Чтож .. хороший вариант , но опять но но и ещё раз но, это дорого и не рентабельно , плюс нету полигона который это протестирует, или вы постаите нестабильный драйвер на готовое железо?
Вариантов можно придумать массу, но все они имеют критические изьяны, к сожалению которые не позволяют использовать эту СУБД для больших проектов.
Но вот, вышел 5.5, он собирается доказать всем что они ввели множество ускоренных систем, поэтому у них очень высокая скорость обращения ко всему что имеется.
Поэтому на маленьких серверах со слабым железом, выйгрыш составит 1-2% , но вот на серьёзных проектах с большими нагрузками можно весьма потягаться.
Комментариев нет:
Отправить комментарий