The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка  RSS
"Представлена тестовая версия MySQL 5.5"
Вариант для распечатки  
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [ Отслеживать ]

"Представлена тестовая версия MySQL 5.5"  +/
Сообщение от opennews on 16-Дек-09, 00:46 
Представлен (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.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=24684

Высказать мнение | Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Представлена тестовая версия MySQL 5.5"  +1 +/
Сообщение от klalafuda on 16-Дек-09, 00:46 

> Foreign keys not supported.   Partitioned tables do not support foreign keys. This means that:

И это в пре-5.5! Все, закапывайте :-/

PS: Да, SIGNAL/RESIGNAL конечно полезно. Хотя что мешало сделать их N лет назад вопросы открытый. Но партиции без внешних ключей - их можно сказать что просто нет. Отсутствуют как класс. Ибо смысл.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

2. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от tty email(??) on 16-Дек-09, 02:40 
сейчас Оракл всё поправит в Мускуле :) и будет MyOracle :)
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

12. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Sw00p aka Jerom email on 16-Дек-09, 10:25 
лучше MOSql
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

15. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от klalafuda on 16-Дек-09, 11:33 

Скорее MyRacle. Хотя сомневаюсь я в этом :-/ Все больше смотрю в сторону pgsql. Тем более что и в среднем позитивный опыт работы с ней имеется. Хотя и там не без камней.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

3. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от gogo on 16-Дек-09, 02:46 
Батенька, а вы вообще читали о каком продукте идет речь? Это mysql, а не mssql. Он должен БЫСТРО сделать ПРОСТУЮ работу. А остальное для него - от лукавого, в угоду извращенцам программистам и конкурентам.
Для, например, банерной сети внешние индексы на фик не нужны. Нужно записал/прочитал.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

5. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от X on 16-Дек-09, 03:56 
> Он должен БЫСТРО сделать ПРОСТУЮ работу.

По-моему эта ниша занята sqlite, а в нише классом повыше PostgreSQL. :) Так что пора признать MySQL свое упустил лет 5-6 назад еще.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

7. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Kaiser (ok) on 16-Дек-09, 04:22 
В PostgreSQL есть партицирование?
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

8. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от X on 16-Дек-09, 04:50 
>  В 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 и партицирования и триггеров для несупервользователей там не было.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

6. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Kaiser (ok) on 16-Дек-09, 04:21 
А вы документацию то почитайте, внешние ключи там уже много лет как есть.
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

11. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от vadiml on 16-Дек-09, 09:45 
Для InnoDB
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

13. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от klalafuda on 16-Дек-09, 10:39 

Но на таблицах разбитых на партиции их *нет*. Причем независимо от того, какой используется движок включая InnoDB. И судя по всему ещё оочень долго не появятся. Я такие надежды питал на 5.1 где они появились а меня так жестоко и по-иезуитски обломали. Что не может не удручать :-/
Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

10. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Антон (??) on 16-Дек-09, 09:42 
>
>> Foreign keys not supported.   Partitioned tables do not support foreign keys. This means that:
>
>И это в пре-5.5! Все, закапывайте :-/

Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам. Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

16. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Edgar Codd on 16-Дек-09, 11:42 
> ... структуру с контролем целостности на уровне приложения.

Если приложений больше 1-го для доступа к данным? Будет к примеру 10 ;) (на Perl, PHP, C, Python и т. д.), во всех будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных языках?

Может быть, контроль целостности это все же удел БД, а не приложений. Как считаете?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

18. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от pro100master (ok) on 16-Дек-09, 14:00 
>> ... структуру с контролем целостности на уровне приложения.
>
>Если приложений больше 1-го для доступа к данным? Будет к примеру 10
>;) (на Perl, PHP, C, Python и т. д.), во всех
>будете писать алгоритмы контроля целостности базы данных изобретая лесапеды на разных
>языках?
>
>Может быть, контроль целостности это все же удел БД, а не приложений.
>Как считаете?

от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?

А по поводу логики в языках, вам на каком языке написать
условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;

задача! афигеть, товарищ, правда :)))

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

19. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от klalafuda on 16-Дек-09, 15:15 
> от партатиций в мускуле вообще сомнительная польза. Что там хранить, что не уместится на много-много терабайтных раидах?

Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов к данной таблице. При этом физически табличка может занимать буквально единицы от силы -десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по бОльшей части живет в кеше базы.

> А по поводу логики в языках, вам на каком языке написать

условие вида:
если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;

Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

20. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от pro100master (ok) on 16-Дек-09, 17:35 
>Чтобы заткнуть базу по производительности нет необходимости в таблицах 'по много-много >терабайт'. Дело не в абсолютном объеме данных. Вполне достаточно хорошего трафика запросов >к данной таблице. При этом физически табличка может занимать буквально единицы от силы >-десятки мегабайт. И никакой мега-рейд в этой ситуации не поможет, т.к. табличка и так по >бОльшей части живет в кеше базы.

вы путаете и это пугает, что у нас такие "спецы". Партиция в этом случае вас абсолютно не спасёт. Спасёт репликация. И там хоть 1М обращений, только и знай "дочек" на чтение выстраивай в ряд.

>Не совсем понял, если честно, вопроса. Вы просите чтобы вам это условие написали или предлагаете его написать сами?

это был вопрос о трудностях реализации "логики". Я не вижу труда реализовать данное условие ни на одном из языков ;)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

21. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Edgar Codd on 17-Дек-09, 04:16 
> Что там хранить, что не уместится на много-много терабайтных раидах?

Про то что не в размере и скорости носителя счастье Вам уже написали.

> А по поводу логики в языках, вам на каком языке написать
> условие вида:
> если данные старше 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.0.250;
> если данные моложе 1000000 микросекунды, то обращаться к серверам 10.0.0.1-10.0.1.250;

Давайте о погоде поговорим еще может быть? Какое отношение соединение приложения к разным узлам имеет к ЦЕЛОСТНОСТИ базы данных? Речь шла о том, что база данных должна сама следить за связями между таблицами, на то она и RDBMS. Не говорю уже о том, что с помошью триггеров  и хранимых процедур, в нормальных RDBMS можно и реализовывать целостностиь данных между разными базами данных. И это будет в разы быстрее и надежнее по коду и затраченному времени разработки, чем реализовать проверку в приложении (клиенте) к базе данных.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

22. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от pro100master (ok) on 17-Дек-09, 09:50 
> Про то что не в размере и скорости носителя счастье Вам уже написали.
> Давайте о погоде поговорим еще может быть?

давайте определимся, мы о вебе или мы о сферическом коне? Если да, то вы один на миллион. Потому что b2b, b2c приложений в вебе примерно в такой пропорции к сайтам вообще. Поэтому делайте скидку на универсальность. Если не о вебе, то, возможно вам это понравится, я считаю, что мускулу не место в "невеб" бизнес приложениях. Как и не место постгри, как бы не мечтали приверженцы последнего.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

23. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от Edgar Codd on 17-Дек-09, 10:35 
> давайте определимся, мы о вебе или мы о сферическом коне?

В принципе, если вы не заметили о чем шла речь, то намекну Вам, что речь шла о внешних ключах для определенного типа таблиц, а не о конях и вебах... :)

Ну а что касается "коней"... Да хоть и вебе. С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД? Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?

А может это происходит, потому что программеру пишущему эти приложения неизвестно что RDBMS, это не просто хранилище данных, а несколько больше. И на самом деле, беда кодящего бедолаги в том, что он дальше PHP ничего не хочет видеть. :)

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

14. "Представлена тестовая версия MySQL 5.5"  +1 +/
Сообщение от klalafuda on 16-Дек-09, 11:31 
> Речь про неработу "foreign keys" только для "Partitioned" таблиц, т.е. когда данные в таблице по определенному критерию разбалансированы по нескольким дискам.

Ну не обязательно именно дискам.

Старая как мир плюшка - ручное разбиение высоконагруженной таблицы ABC на N идентичных по структуре таблиц ABC00..ABCn с выборкой конкретной таблицы по какому то простому признаку скажем от primary key. Иногда это позволяет в разы а иногда и на порядки снизить общую нагрузку на базу, если ABC является бутылочным горлышком. Банально из-за снижения вероятности ожидания на блокировке.

Однако, возникает и естественное неудобство при работе с такой вот вручную разбитой 'таблицей'. Особенно, если требуется сделать какую то выборку из всей таблицы. Именно тут IMHO partitioning на уровне RDBMS был бы как нельзя кстати - и волки сыты и овцы целы. Конечно, вопрос об конечной эффективности встроенного разбиения могут показать лишь тесты и работа на реальной системе, но все предпосылки налицо.

Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.

> Это совсем не критично, при том объеме данных, при котором используют партицирование, никто в здравом уме не будет "foreign keys" использовать, как правило делают самую простую структуру с контролем целостности на уровне приложения.

'Тот объем данных' - понятие сильно растяжимое. Все может радостно встать колом практически независимо от железа даже на каких то 1M записей в несложной табличке, если к ней ведётся разношерстный параллельный доступ на чтение/модификацию.

Отказ же от внешних ключей и перенос контроля за целостностью базы на уровень приложения лишь потому, что 'почему то все тормозит' - это совершенно не аргумент при дизайне системы. Разве что камень в огород конкретной RDBMS.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

17. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от pro100master (ok) on 16-Дек-09, 13:52 
> Да, конечно, для полноты картины можно разнести партиции ещё и по стораджам, но даже когда все происходит в контексте одного позитивный эффект от ручного разбиения более чем заметен.

если вам так пофиг на скорость, то проще распределенную ФС использовать, чем добавлять лишнюю сущность в уравнение вероятности сбоя.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

25. "Представлена тестовая версия MySQL 5.5"  +/
Сообщение от pro100master (ok) on 17-Дек-09, 17:55 
С каких это интересно пор, стало де-факто, что у веб-приложения не может быть сложной структуры БД?
-----
не путайте сложную структуру с логикой. Это бесово. Если вы хотите связать действительно сложную структуру, логику и, при этом, говорить о целостности всего этого, то мускулу еще лет адцать идти к этому. Это задачи оракла. Почему? Потому. Ничто, кроме как приложение работающее на самом сервере БД, не обеспечит вам достаточную целостность. Ключи это просто примитивы, типа для бедных.

Или может я что-то упустил, и на вебе стало модно НЕ использовать внешние ключи, транзакции, хранимые процедуры?
-----
удивлю, 99.9% сайтов не используют и не собираются использовать это. Ссылок не дам. Посмотрите самые тяжелые oss-проекты. Они примитивны, с точки зрения БД и кода на стороне БД.

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Индекс форумов | Темы | Пред. тема | След. тема




Спонсоры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру