Разработчики социальной сети Facebook сообщили (http://www.facebook.com/notes/mysql-at-facebook/online-schem...) об открытии утилиты OSC (Online Schema Change), позволяющей обеспечить возможность изменения на лету схемы представления данных в MySQL. По заявлению разработчиков использование классической операции "ALTER TABLE" для изменения структуры реплицированной на многие серверы базы выполняется слишком долго, поэтому для ускорения в OSC задействованы триггеры MySQL 5.0 для выполнения операций ALTER TABLE в неблокирующем режиме.
Алгоритм OSC сводится к выполнению полного копирования данных во временную таблицу; изменению схемы временной таблицы без блокирования работы основной таблицы; синхронизации из основной таблицы всех данных, изменившихся с момента копирования (используются триггеры); замене базовой таблицы на подготовленную временную таблицу с новой структурой. Интересно, что по словам (http://www.theregister.co.uk/2010/09/21/facebook_online_s...URL: http://www.theregister.co.uk/2010/09/21/facebook_online_sche.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=28046
Интересно, как они борятся с внешними ключами :-? Вот есть рабочие таблица A на которую ключи из таблицы B. Мы решили что-то поменять в структуре таблицы A. Сделали временную таблицу T, в которую скопировали содержимое таблицы A + синхронизируем во времени содержимое T с A посредством тригеров. Через какое-то время T поменяла структуру. Дальше просто RENAME TABLE T в A :-? И при этом ключи из B в A не испортятся?
>Интересно, как они борятся с внешними ключами :-?Никак:
if ($row['count'] != 0) {
$error = 'FK exists to or from table being altered. '.
'FK and triggers may not work well together. '.
'So OSC not allowed unless OSC_FLAGS_ACCEPTFK is set.';
$this->raiseException($error, false);
}
Кстати это и называется
>расширена поддержкой проверки внешних ключей=)
> if ($row['count'] != 0) {
> $error = 'FK exists to or from table being altered. '.
> 'FK and triggers may not work well together. '.
> 'So OSC not allowed unless OSC_FLAGS_ACCEPTFK is set.';
> $this->raiseException($error, false);
> }Это я так понимаю кусок кода из их скриптов? Я их не смотрел пока если честно. Т.е. получается, что OSC явным образом проверяет на наличие FK и отказывается работать с таблицами, в которых они присутствуют? Чудное решение...
Смотреть там не на что. Прямая ссылка на 1000 строк кода на похапэ под BSDL.
По FK запрос к схеме на предмет ключей и если есть, то отказать. Очень нужная подачка.
а чо удалить предварительно ключи никак ?там же написано на коде какой утилиты и какого набора этого строится .. наверняка это плевое дело .
А наши социальные сети odnoklassniki.ru и vkontakte.ru, открывают свои доработки?
а что у них есть _свои_ наработки? :)
Автор предудущего поста весьма точно описал что у них свои не _наработки_ а _доработки_ :)) Хотя я бы ещё приставочку "не" добавил, чтоб уж совсем правда была :))
(Оффтопик, в общем-то)> ... по словам представителя Facebook ... на тысячах серверов проекта ...
На ТЫСЯЧАХ! :)
(В оригинале - "across its sea of MySQL servers", т.е. их просто "море", а не тысячи)
Читайте внимательно, там сказано "X тысяч":"...company runs "X thousands" of MySQL servers."
еще несколько цитат на тему числа серверов в FaceBook:
"the load on our thousands of servers continues to increase at a pretty astounding rate"
"Facebook: 30000 databases, 1800 db servers"
http://venublog.com/2008/04/16/notes-from-scaling-mysql-up-o.../
http://blog.facebook.com/blog.php?post=7899307130
С такими кастомерами MySQL явно далеко до стагнации. Причем что фейсбук далеко не единственные.
а вы уверенны что они кастомеры??? Мне кажется они её поддерживать своими силами вполне могут...
> а вы уверенны что они кастомеры??? Мне кажется они её поддерживать своими силами вполне могут...А смысл? Поле деятельности фейсбука лежит мягко говоря в совсем другой стороне. Зачем им держать отдельный коллектив, который будет заниматься разработкой RDBMS? Если проще и дешевле отдать это на аутсорс == купить поддержку у мускуля. С таким же успехом они и 'Linux смогут поддерживать' :) Но зачем..
поле деятельности google тоже явно не в той стороне. что не мешает им "держать отдельный коллектив", в.т.ч. и для поддержки linux.
> поле деятельности google тоже явно не в той стороне. что не мешает им "держать отдельный коллектив", в.т.ч. и для поддержки linux.Боюсь, масштабы гугла и фейсбука несколько не сопоставимые. А, главное, масштабы их хотелок. Поэтому гугл - это гугла, а фейсбук - это фейсбук. Не думаю, что последний ставит перед собой задачи завоевания Галактики и тд и тп. Ребята просто работают на волне. Без особых претензий.
> Ребята просто работают на волне. Без особых претензий.ага. набрали полмиллиарда пользователей, без особых претензий. в gmail (и соответственно прочих гуглосервисах), к слову, аккаунтов меньше раза этак в два.
> ага. набрали полмиллиарда пользователей, без особых претензий. в gmail (и соответственно прочих гуглосервисах), к слову, аккаунтов меньше раза этак в два.Про полмиллиарда пользователей - это они вам сами сказали? Они соврали. У них как минимум пять миллиардов. А по проверенным слухам существенно больше...
> Про полмиллиарда пользователей - это они вам сами сказали?ну естественно. подобного рода данные публикуют многие компании. не вижу причин, по которым тот же пейсбук мог бы завысить цифры.
> "...company runs "X thousands" of MySQL servers."Я тоже "runs X thousands of MySQL servers" при X = 0.005 :-)
Какой-то странный костыль, а почему не создать новую таблицу и не переносить туда записи. Параллельно используя представления (VIEW) для выборки данных из обоих таблиц???
из-за блокировки?