forum.opennet.ru - "OpenNews: Вышла production-версия MySQL 4.1.7" (17)

форумы

помощь

поиск

регистрация

майллист

ВХОД

слежка

"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.dev/opennews/art.shtml?num=4563
Cообщить модератору \| Наверх \| ^

Оглавление

Вышла production-версия MySQL 4.1.7, zlo, 11:02 , 28-Окт-04, (1)

Вышла production-версия MySQL 4.1.7, Nickolay, 11:38 , 28-Окт-04, (2)

Вышла production-версия MySQL 4.1.7, Zen, 17:43 , 28-Окт-04, (3)

Вышла production-версия MySQL 4.1.7, Nickolay, 18:07 , 28-Окт-04, (4)
Вышла production-версия MySQL 4.1.7, GliNT, 16:48 , 29-Окт-04, (5)

Вышла production-версия MySQL 4.1.7, Hety, 17:39 , 29-Окт-04, (6)

Вышла production-версия MySQL 4.1.7, GliNT, 17:57 , 29-Окт-04, (7)

Вышла production-версия MySQL 4.1.7, Hety, 12:18 , 30-Окт-04, (8)

> А еще вкуснее снести все это нафиг и поставить PostgreSQL, poige, 14:09 , 31-Окт-04, (11)

> А еще вкуснее снести все это нафиг и поставить PostgreSQL, misha, 14:34 , 31-Окт-04, (12)

> Да диска жрет больше, но я ему это прощаю :), poige, 15:19 , 31-Окт-04, (13)

> Да диска жрет больше, но я ему это прощаю :), misha, 15:33 , 31-Окт-04, (14)

>А как же триггеры, процедури, views? , poige, 16:03 , 31-Окт-04, (15)

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

> Да диска жрет больше, но я ему это прощаю :), poige, 08:06 , 01-Ноя-04, (17)

Вышла production-версия MySQL 4.1.7, vgray, 20:22 , 30-Окт-04, (9)

Вышла production-версия MySQL 4.1.7, Hety, 13:25 , 31-Окт-04, (10)

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

1. "Вышла production-версия MySQL 4.1.7"

Сообщение от zlo (??) on 28-Окт-04, 11:02

атлична!! так держать. особенно порадовало копирование структуры таблицы - можно применять иногда

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

2. "Вышла production-версия MySQL 4.1.7"

Сообщение от Nickolay (??) 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 (??) on 28-Окт-04, 18:07

извечное противостояние слона и дельфина :-)
а если по офтопу: кто бы спорил.

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

5. "Вышла production-версия MySQL 4.1.7"

Сообщение от GliNT (??) 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 (??) 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 (??) 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 (??) on 31-Окт-04, 14:34

Вы извените, но я недавно начал осваивать постгрис, и сказать поправде не могу нарадоваться. Возможностей куча. Сейчас
дописываю на нем биллинг. Такого я б на мускуле не сделал, все внутри бази,
тоесть в базу приходит только ip accounting а дальше "база" сама считает. И производительность приятно удивляет :)
Реализован выбор сетевой зони для трафика, я и не думал что это будет так бистро на постгрис :) в базе около полтори тисячи сетей /19 - /24.
Да диска жрет больше, но я ему это прощаю :) ибо компенсирует он это другими
вкусностями :). Место мне не расходится (масив 240 Гб)
я выбираю постгрис.

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

13. "> Да диска жрет больше, но я ему это прощаю :)"

Сообщение от poige (??) 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 (??) 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 (??) 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 (??) on 30-Окт-04, 20:22

а года через 3 sqllite дорастет до уровня сегодняшнего mysql и тогда появиться sqlsuperlite, а если серьезно то я считаю такое разрастание mysql нехорошим делом, ибо он начинает толстеть и сувать нос туда где постгрес правит а из своей ниши уходить.

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

10. "Вышла production-версия MySQL 4.1.7"

Сообщение от Hety (??) on 31-Окт-04, 13:25

Да и шут с ним. На самом деле было бы сдорово собирать мускуль только с теми фичами, которые конкретно нужны. Мне, к примеру, нужна совместимая записаня книжка. Все новомодные приболуды мускуля я просто не юзаю.

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

Удалить

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


	5. "Вышла production-версия MySQL 4.1.7"
	Сообщение от GliNT (??) 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 (??) 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 (??) 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 (??) on 31-Окт-04, 14:34
	Вы извените, но я недавно начал осваивать постгрис, и сказать поправде не могу нарадоваться. Возможностей куча. Сейчас дописываю на нем биллинг. Такого я б на мускуле не сделал, все внутри бази, тоесть в базу приходит только ip accounting а дальше "база" сама считает. И производительность приятно удивляет :) Реализован выбор сетевой зони для трафика, я и не думал что это будет так бистро на постгрис :) в базе около полтори тисячи сетей /19 - /24. Да диска жрет больше, но я ему это прощаю :) ибо компенсирует он это другими вкусностями :). Место мне не расходится (масив 240 Гб) я выбираю постгрис.
	Cообщить модератору \| Наверх \| ^


	13. "> Да диска жрет больше, но я ему это прощаю :)"
	Сообщение от poige (??) 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 (??) 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 (??) 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 (??) on 30-Окт-04, 20:22
а года через 3 sqllite дорастет до уровня сегодняшнего mysql и тогда появиться sqlsuperlite, а если серьезно то я считаю такое разрастание mysql нехорошим делом, ибо он начинает толстеть и сувать нос туда где постгрес правит а из своей ниши уходить.
Cообщить модератору \| Наверх \| ^


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