The OpenNET Project / Index page

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

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"OpenNews: Вышла production-версия MySQL 4.1.7"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение [Проследить за развитием треда]

"OpenNews: Вышла production-версия MySQL 4.1.7"
Сообщение от opennews (??) on 28-Окт-04, 11:02 
Разработчики MySQL AB выпустили первую production-версию MySQL 4.1.7 (http://dev.mysql.com/doc/mysql/en/News-4.1.7.html).


Список значительных отличий от 4.0:

<ol>
-  Поддержка подзапросов (subqueries).
-  Быстрый бинарный клиент-серверный протокол с поддержкой подготовленных (prepared) запросов и привязкой (binding) параметров.
-  Быстрое дублирование структуры таблицы:
CREATE TABLE tbl_name2 LIKE tbl_name1
-  MyISAM теперь поддерживает пространственные типы данных OpenGIS для хранения географических данных.
-  Кодировка теперь может быть указана конкретно для колонки, таблицы и базы данных.
-  Клиент в любой момент может установить любую временную зону (timezone).
-  У сервера теперь появилась команда HELP, с помощью которой клиент может получить справку по той версии SQL, которая поддерживается этим сервером.
</ol>

Процесс обновления версии 4.0 до 4.1 описан в документе "Upgrading from Version 4.0 to 4.1 (http://dev.mysql.com/doc/mysql/en/Upgrading-from-4.0.html)", частичный перевод на русский язык доступен здесь (http://dev.mysql.com/doc/mysql/ru/Upgrading-from-4.0.html).

URL: http://dev.mysql.com/downloads/mysql/4.1.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=4563

Cообщить модератору | Наверх | ^

 Оглавление

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


1. "Вышла production-версия MySQL 4.1.7"
Сообщение от zlo email(??) on 28-Окт-04, 11:02 
атлична!! так держать. особенно порадовало копирование структуры таблицы - можно применять иногда
Cообщить модератору | Наверх | ^

2. "Вышла production-версия MySQL 4.1.7"
Сообщение от Nickolay email(??) on 28-Окт-04, 11:38 
а еще очень "вкусные" функции для работы с датами.
Cообщить модератору | Наверх | ^

3. "Вышла production-версия MySQL 4.1.7"
Сообщение от Zen (??) on 28-Окт-04, 17:43 
А еще вкуснее снести все это нафиг и поставить PostgreSQL, который при прямых руках и правильной настройке будет даже на простых и частых запросах работать сравнимо с MySQL по скорости, а вот возможностями он MySQL превосходит настолько, что MySQL доползет до них года через два-три, если вообще доползет. :-)

Сорри за оффтоп. :-)

Cообщить модератору | Наверх | ^

4. "Вышла production-версия MySQL 4.1.7"
Сообщение от Nickolay email(??) on 28-Окт-04, 18:07 
извечное противостояние слона и дельфина :-)
а если по офтопу: кто бы спорил.
Cообщить модератору | Наверх | ^

5. "Вышла production-версия MySQL 4.1.7"
Сообщение от GliNT email(??) on 29-Окт-04, 16:48 
Модификация:
А еще вкуснее снести все это нафиг и поставить Oracle 10g, который при прямых руках и правильной настройке будет даже на простых и частых запросах работать сравнимо с Postgres по скорости, а вот возможностями он Postgres превосходит настолько, что Postgres доползет до них года через два-три, если вообще доползет. :-)

"Oracle 10g" можно заменить на IBM DB2, Sybase ASE или Informix Dynamic Server, кому что по вкусу.

Cообщить модератору | Наверх | ^

6. "Вышла production-версия MySQL 4.1.7"
Сообщение от Hety (??) on 29-Окт-04, 17:39 
Гы :) И крутить на этом самом оракле табличку 10х200 для локального почтовика :)

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

Cообщить модератору | Наверх | ^

7. "Вышла production-версия MySQL 4.1.7"
Сообщение от GliNT email(??) on 29-Окт-04, 17:57 
>Гы :) И крутить на этом самом оракле табличку 10х200 для локального
>почтовика :)
>
>Все хорошо в меру :) Там где нужен мускуль, ни постгрес, ни
>оракла тем более не нужны. Это еще не считая того, что
>за ораклу прийдется заплатить.

Вообще-то за все нужно платить.
Либо за софт, либо за настройку этого софта, либо программисту за написание дополнительных программ для работы с этим софтом.
MySQL разрастается возможностями - это хорошо, поле его применений расширяется. Так, где раньше нужен был Postgres или что-то посерьезней скоро будет хватать и MySQL. Меньше разных СУБД в системе - уже хорошо. Для администратора :)

Cообщить модератору | Наверх | ^

8. "Вышла production-версия MySQL 4.1.7"
Сообщение от Hety (??) on 30-Окт-04, 12:18 
Я имел ввиду платить за сам софт :) К любой базе в юбо случае нужен администратор :)
Больше баз - больше выбора. Там, где раньше был мускуль, наверняка скоро окажется sqlite.
Cообщить модератору | Наверх | ^

11. ">  А еще вкуснее снести все это нафиг и поставить PostgreSQL"
Сообщение от poige email(??) on 31-Окт-04, 14:09 
А позвольте не согласиться? ;-)

В PostgreSQL, мне, например, очень не хватает того набора типов данных, который поддерживается MySQL. В MySQL-таблице можно сделать колонку, которая будет занимать, во внутреннем представлении, 1 (да, всего один) байт. Те таблицы, которые у меня занимают по 6 GB, в варианте для PostgreSQL -- 18 GB, и более... Что уж говорить, про размеры MySQL-баз в 30 GB? Так что, вы уж извините, но снести нафиг, зачастую приходилось PostgreSQL. ;-) А вообще, я как считал, так и считаю по-прежнему, что нужно знать разные инструменты, чтобы выбирать наиболее подходящие в каждом конкретном случае. ;-)

  http://dev.mysql.com/tech-resources/crash-me.php

/poige
--
http://www.i.morning.ru/~poige/

Cообщить модератору | Наверх | ^

12. ">  А еще вкуснее снести все это нафиг и поставить PostgreSQL"
Сообщение от misha email(??) on 31-Окт-04, 14:34 
Вы извените, но я недавно начал осваивать постгрис, и сказать поправде не могу нарадоваться. Возможностей куча. Сейчас
дописываю на нем биллинг. Такого я б на мускуле не сделал, все внутри бази,
тоесть в базу приходит только ip accounting а дальше "база" сама считает. И производительность приятно удивляет :)

Реализован выбор сетевой зони для трафика, я и не думал что это будет так бистро на постгрис :) в базе около полтори тисячи сетей /19 - /24.

Да диска жрет больше, но я ему это прощаю :) ибо компенсирует он это другими
вкусностями :). Место мне не расходится (масив 240 Гб)

я выбираю постгрис.

Cообщить модератору | Наверх | ^

13. "> Да диска жрет больше, но я ему это прощаю :)"
Сообщение от poige email(??) on 31-Окт-04, 15:19 
Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ к более быстрым выборкам. ;-)

При sequential reading, и прочих равных условиях, выборка будет в 3-и раза быстрее, поскольку читалось в 3-и раза меньше GB. :-)

Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно лучше первый, я занимался этим немало времени и могу говорить уверенно. Приведу, пожалуй, чтобы дать вам представление о масштабах, кол-во записей в одной из таблиц:

  count(*): 778693837

P. S. Выдержка из доки по MySQL:

"...
One of the most basic optimizations is to design your tables to take as little space on the disk as possible. This can give huge improvements because disk reads are faster, and smaller tables normally require less main memory while their contents are being actively processed during query execution. Indexing also is a lesser resource burden if done on smaller columns.
..."

/poige

Cообщить модератору | Наверх | ^

14. "> Да диска жрет больше, но я ему это прощаю :)"
Сообщение от misha email(??) on 31-Окт-04, 15:33 
А как же триггеры, процедури, views?
Разве можно без этого? Разве удобно?
Да и зачем засовывать в БД такое количество информации,
у меня для каждого клиента в день по ~8 записей.
Да и вообшче, что это за СУБД которая умеет 4 операции?(SELECT,INSERT etc.)

привожу реальний пример, таже база перенесена без конструктивных изменений
с мускула в постгрис, так постгрис на 20% бистрее обрабативает те же запросы, а данных только прибавилось .

>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>к более быстрым выборкам. ;-)
>
>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>быстрее, поскольку читалось в 3-и раза меньше GB. :-)
>
>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>лучше первый, я занимался этим немало времени и могу говорить уверенно.
>Приведу, пожалуй, чтобы дать вам представление о масштабах, кол-во записей в
>одной из таблиц:
>
>  count(*): 778693837
>
>P. S. Выдержка из доки по MySQL:
>
>"...
>One of the most basic optimizations is to design your tables to
>take as little space on the disk as possible. This can
>give huge improvements because disk reads are faster, and smaller tables
>normally require less main memory while their contents are being actively
>processed during query execution. Indexing also is a lesser resource burden
>if done on smaller columns.
>..."
>
>/poige


Cообщить модератору | Наверх | ^

15. ">А как же триггеры, процедури, views? "
Сообщение от poige email(??) on 31-Окт-04, 16:03 
>А как же триггеры, процедури, views?
>Разве можно без этого? Разве удобно?

Для данной задачи -- вполне. Вот в качестве БД для RADIUS'а,
PgSQL неплохой выбор. Хотя, опять же, зависит от того, кто, и что желает получить в итоге.

>Да и зачем засовывать в БД такое количество информации,

Людям приятно знать больше. ;-)

/poige

Cообщить модератору | Наверх | ^

16. "> Да диска жрет больше, но я ему это прощаю :)"
Сообщение от uldus (ok) on 31-Окт-04, 20:24 
>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>к более быстрым выборкам. ;-)

А теперь сравни MySQL/InnoDB с PostgreSQL :-) Никакими быстрыми выборками там и не пахнет, когда дело касается транзакций и средств для контроля целостности.

>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>быстрее, поскольку читалось в 3-и раза меньше GB. :-)

Вообще-то частые "sequential reading" на больших таблицах больше проблема проектирования базы :-)

>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>лучше первый,

Только вот под FreeBSD под очень большой нагрузкой не хочет MySQL нормально работать, до сих пор. Но треды сами по себе ресурсов жрут конечно меньше, чем форки PostgreSQL. Для кучи мелких операций, таких как учет трафика, MySQL отличное решение, хотя я все больше в сторону SQLite смотрю.

>  count(*): 778693837

И часто "sequential reading" случается делать ? ;-)
Кстати, проведи эксперимент с базой такого объема в InnoDB.

Cообщить модератору | Наверх | ^

17. "> Да диска жрет больше, но я ему это прощаю :)"
Сообщение от poige (??) on 01-Ноя-04, 08:06 
>>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>>к более быстрым выборкам. ;-)
>
>А теперь сравни MySQL/InnoDB с PostgreSQL :-) Никакими быстрыми выборками там и
>не пахнет, когда дело касается транзакций и средств для контроля целостности.

хватает MyISAM! :-)
>
>
>>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>>быстрее, поскольку читалось в 3-и раза меньше GB. :-)
>
>Вообще-то частые "sequential reading" на больших таблицах больше проблема проектирования базы :-)

про __частые__ где говорилось? :-)
>
>
>>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>>лучше первый,
>
>Только вот под FreeBSD под очень большой нагрузкой не хочет MySQL нормально
>работать, до сих пор. Но треды сами по себе ресурсов жрут

мне есть из чего выбирать OS -- *BSD, Linux, Solaris.

Вообще, то, что тут описано

  http://dev.mysql.com/doc/mysql/en/FreeBSD.html

пробовал?

>конечно меньше, чем форки PostgreSQL. Для кучи мелких операций, таких как
>учет трафика, MySQL отличное решение, хотя я все больше в сторону
>SQLite смотрю.
>
>>  count(*): 778693837
>
>И часто "sequential reading" случается делать ? ;-)

не. sequential чаще (когда любопытно) делается на

count(*): 351983119

Упирается, кстати, не в диск, а CPU. :-)

>Кстати, проведи эксперимент с базой такого объема в InnoDB.

Не нужен мне InnoDB, в этой задаче. Не нужен. ;-)

/poige

Cообщить модератору | Наверх | ^

9. "Вышла production-версия MySQL 4.1.7"
Сообщение от vgray email(??) on 30-Окт-04, 20:22 
а года через 3 sqllite дорастет до уровня сегодняшнего mysql и тогда появиться sqlsuperlite, а если серьезно то я считаю такое разрастание mysql нехорошим делом, ибо он начинает толстеть и сувать нос туда где постгрес правит а из своей ниши уходить.
Cообщить модератору | Наверх | ^

10. "Вышла production-версия MySQL 4.1.7"
Сообщение от Hety (??) on 31-Окт-04, 13:25 
Да и шут с ним. На самом деле было бы сдорово собирать мускуль только с теми фичами, которые конкретно нужны. Мне, к примеру, нужна совместимая записаня книжка. Все новомодные приболуды мускуля я просто не юзаю.
Cообщить модератору | Наверх | ^

Удалить

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




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

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