Представлен (http://blogs.mysql.com/kaj/2009/12/15/mysql-550-m2-a-milesto.../) тестовый выпуск MySQL 5.5.0-M2 (http://dev.mysql.com/doc/refman/5.5/en/news-5-5-0.html), созданный на основе новой экспериментальной ветки MySQL. Первый доступный для промышленной эксплуатации релиз MySQL 5.5 планируется выпустить в середине 2010 года.
Версия MySQL 5.5 является первой, развиваемой в рамках новой модели (http://forge.mysql.com/wiki/Development_Cycle) подготовки релизов. Вместо нескольких экспериментальных веток (5.4, 6.0, 6.1), новые возможности теперь будут разрабатываться в единой экспериментальной ветке, без разделения на альфа и бета версии. В соответствии с новой схемой, на базе единой тестовой ветки раз в 3-6 месяцев будут выпускаться промежуточные версии с качеством кандидата в релизы (RC), в промежутке между которыми будут доступны milestone-сборки. Новые возможности будут интегрироваться в дерево исходных текстов в течение двух недель после выхода RC-сборки, ветк...URL: http://blogs.mysql.com/kaj/2009/12/15/mysql-550-m2-a-milesto.../
Новость: http://www.opennet.me/opennews/art.shtml?num=24684
> Foreign keys not supported. Partitioned tables do not support foreign keys. This means that:И это в пре-5.5! Все, закапывайте :-/
PS: Да, SIGNAL/RESIGNAL конечно полезно. Хотя что мешало сделать их N лет назад вопросы открытый. Но партиции без внешних ключей - их можно сказать что просто нет. Отсутствуют как класс. Ибо смысл.
сейчас Оракл всё поправит в Мускуле :) и будет MyOracle :)
лучше MOSql
Скорее MyRacle. Хотя сомневаюсь я в этом :-/ Все больше смотрю в сторону pgsql. Тем более что и в среднем позитивный опыт работы с ней имеется. Хотя и там не без камней.
Батенька, а вы вообще читали о каком продукте идет речь? Это mysql, а не mssql. Он должен БЫСТРО сделать ПРОСТУЮ работу. А остальное для него - от лукавого, в угоду извращенцам программистам и конкурентам.
Для, например, банерной сети внешние индексы на фик не нужны. Нужно записал/прочитал.
> Он должен БЫСТРО сделать ПРОСТУЮ работу.По-моему эта ниша занята sqlite, а в нише классом повыше PostgreSQL. :) Так что пора признать MySQL свое упустил лет 5-6 назад еще.
В PostgreSQL есть партицирование?
> В PostgreSQL есть партицирование?Из каробки с версии 8.1 еще http://www.postgresql.org/docs/8.1/interactive/ddl-partition...
http://www.postgresql.org/docs/8.4/interactive/ddl-partition...А в MySQL уже есть стабильная версия релиза где не надо быть суперпользователем чтобы создать триггер? Или может быть в MySQL есть партицирование в стабильных релизах? На сколько помню стабильным считалась ветка 5.0.x и партицирования и триггеров для несупервользователей там не было.
А вы документацию то почитайте, внешние ключи там уже много лет как есть.
Для InnoDB
Но на таблицах разбитых на партиции их *нет*. Причем независимо от того, какой используется движок включая InnoDB. И судя по всему ещё оочень долго не появятся. Я такие надежды питал на 5.1 где они появились а меня так жестоко и по-иезуитски обломали. Что не может не удручать :-/
>
>> Foreign keys not supported. Partitioned tables do not support foreign keys. This means that:
>
>И это в пре-5.5! Все, закапывайте :-/Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам. Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
> ... структуру с контролем целостности на уровне приложения.Если приложений больше 1-го для доступа к данным? Будет к примеру 10 ;) (на Perl, PHP, C, Python и т. д.), во всех будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных языках?
Может быть, контроль целостности это все же удел БД, а не приложений. Как считаете?
>> ... структуру с контролем целостности на уровне приложения.
>
>Если приложений больше 1-го для доступа к данным? Будет к примеру 10
>;) (на Perl, PHP, C, Python и т. д.), во всех
>будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных
>языках?
>
>Может быть, контроль целостности это все же удел БД, а не приложений.
>Как считаете?от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?
А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;задача! афигеть, товарищ, правда :)))
> от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов к данной таблице. При этом физически табличка может занимать буквально единицы от силы -десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по бОльшей части живет в кеше базы.
> А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?
>Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много >терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов >к данной таблице. При этом физически табличка может занимать буквально единицы от силы >-десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по >бОльшей части живет в кеше базы.вы путаете и это пугает, что у нас такие "спецы". Партиция в этом случае вас абсолютно не спасёт. Спасёт репликация. И там хоть 1М обращений, только и знай "дочек" на чтение выстраивай в ряд.
>Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?
это был вопрос о трудностях реализации "логики". Я не вижу труда реализовать данное условие ни на одном из языков ;)
> Что там хранить, что не уместится на много-много терабайтных раидах?Про то что не в размере и скорости носителя счастье Вам уже написали.
> А по поводу логики в языках, вам на каком языке написать
> условие вида:
> если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
> если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;Давайте о погоде поговорим еще может быть? Какое отношение соединение приложения к разным узлам имеет к ЦЕЛОСТНОСТИ базы данных? Речь шла о том, что база данных должна сама следить за связями между таблицами, на то она и RDBMS. Не говорю уже о том, что с помошью триггеров и хранимых процедур, в нормальных RDBMS можно и реализовывать целостностиь данных между разными базами данных. И это будет в разы быстрее и надежнее по коду и затраченному времени разработки, чем реализовать проверку в приложении (клиенте) к базе данных.
> Про то что не в размере и скорости носителя счастье Вам уже написали.
> Давайте о погоде поговорим еще может быть?давайте определимся, мы о вебе или мы о сферическом коне? Если да, то вы один на миллион. Потому что b2b, b2c приложений в вебе примерно в такой пропорции к сайтам вообще. Поэтому делайте скидку на универсальность. Если не о вебе, то, возможно вам это понравится, я считаю, что мускулу не место в "невеб" бизнес приложениях. Как и не место постгри, как бы не мечтали приверженцы последнего.
> давайте определимся, мы о вебе или мы о сферическом коне?В принципе, если вы не заметили о чем шла речь, то намекну Вам, что речь шла о внешних ключах для определенного типа таблиц, а не о конях и вебах... :)
Ну а что касается "коней"... Да хоть и вебе. С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД? Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
А может это происходит, потому что программеру пишущему эти приложения неизвестно что RDBMS, это не просто хранилище данных, а несколько больше. И на самом деле, беда кодящего бедолаги в том, что он дальше PHP ничего не хочет видеть. :)
> Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам.Ну не обязательно именно дискам.
Старая как мир плюшка - ручное разбиение высоконагруженной таблицы ABC на N идентичных по структуре таблиц ABC00..ABCn с выборкой конкретной таблицы по какому то простому признаку скажем от primary key. Иногда это позволяет в разы а иногда и на порядки снизить общую нагрузку на базу, если ABC является бутылочным горлышком. Банально из-за снижения вероятности ожидания на блокировке.
Однако, возникает и естественное неудобство при работе с такой вот вручную разбитой 'таблицей'. Особенно, если требуется сделать какую то выборку из всей таблицы. Именно тут IMHO partitioning на уровне RDBMS был бы как нельзя кстати - и волки сыты и овцы целы. Конечно, вопрос об конечной эффективности встроенного разбиения могут показать лишь тесты и работа на реальной системе, но все предпосылки налицо.
Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.
> Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.
'Тот объем данных' - понятие сильно растяжимое. Все может радостно встать колом практически независимо от железа даже на каких то 1M записей в несложной табличке, если к ней ведётся разношерстный параллельный доступ на чтение/модификацию.
Отказ же от внешних ключей и перенос контроля за целостностью базы на уровень приложения лишь потому, что 'почему то все тормозит' - это совершенно не аргумент при дизайне системы. Разве что камень в огород конкретной RDBMS.
> Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.если вам так пофиг на скорость, то проще распределенную ФС использовать, чем добавлять лишнюю сущность в уравнение вероятности сбоя.
С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД?
-----
не путайте сложную структуру с логикой. Это бесово. Если вы хотите связать действительно сложную структуру, логику и, при этом, говорить о целостности всего этого, то мускулу еще лет адцать идти к этому. Это задачи оракла. Почему? Потому. Ничто, кроме как приложение работающее на самом сервере БД, не обеспечит вам достаточную целостность. Ключи это просто примитивы, типа для бедных.Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
-----
удивлю, 99.9% сайтов не используют и не собираются использовать это. Ссылок не дам. Посмотрите самые тяжелые oss-проекты. Они примитивны, с точки зрения БД и кода на стороне БД.