| 1.1, zlo (??), 11:02, 28/10/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
атлична!! так держать. особенно порадовало копирование структуры таблицы - можно применять иногда | | |
| |
| |
| 3.3, Zen (??), 17:43, 28/10/2004 [^] [^^] [^^^] [ответить]
| +/– | |
А еще вкуснее снести все это нафиг и поставить PostgreSQL, который при прямых руках и правильной настройке будет даже на простых и частых запросах работать сравнимо с MySQL по скорости, а вот возможностями он MySQL превосходит настолько, что MySQL доползет до них года через два-три, если вообще доползет. :-)
Сорри за оффтоп. :-) | | |
| |
| 4.4, Nickolay (??), 18:07, 28/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
извечное противостояние слона и дельфина :-)
а если по офтопу: кто бы спорил. | | |
| 4.5, GliNT (??), 16:48, 29/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
 Модификация:
А еще вкуснее снести все это нафиг и поставить Oracle 10g, который при прямых руках и правильной настройке будет даже на простых и частых запросах работать сравнимо с Postgres по скорости, а вот возможностями он Postgres превосходит настолько, что Postgres доползет до них года через два-три, если вообще доползет. :-)
"Oracle 10g" можно заменить на IBM DB2, Sybase ASE или Informix Dynamic Server, кому что по вкусу.
| | |
| |
| 5.6, Hety (??), 17:39, 29/10/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Гы :) И крутить на этом самом оракле табличку 10х200 для локального почтовика :)
Все хорошо в меру :) Там где нужен мускуль, ни постгрес, ни оракла тем более не нужны. Это еще не считая того, что за ораклу прийдется заплатить. | | |
| |
| 6.7, GliNT (??), 17:57, 29/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Гы :) И крутить на этом самом оракле табличку 10х200 для локального
>почтовика :)
>
>Все хорошо в меру :) Там где нужен мускуль, ни постгрес, ни
>оракла тем более не нужны. Это еще не считая того, что
>за ораклу прийдется заплатить.
Вообще-то за все нужно платить.
Либо за софт, либо за настройку этого софта, либо программисту за написание дополнительных программ для работы с этим софтом.
MySQL разрастается возможностями - это хорошо, поле его применений расширяется. Так, где раньше нужен был Postgres или что-то посерьезней скоро будет хватать и MySQL. Меньше разных СУБД в системе - уже хорошо. Для администратора :) | | |
| |
| 7.8, Hety (??), 12:18, 30/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
Я имел ввиду платить за сам софт :) К любой базе в юбо случае нужен администратор :)
Больше баз - больше выбора. Там, где раньше был мускуль, наверняка скоро окажется sqlite. | | |
|
|
|
| 4.11, poige (??), 14:09, 31/10/2004 [^] [^^] [^^^] [ответить]
| +/– | |
А позвольте не согласиться? ;-)
В 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/
| | |
| |
| 5.12, misha (??), 14:34, 31/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
 Вы извените, но я недавно начал осваивать постгрис, и сказать поправде не могу нарадоваться. Возможностей куча. Сейчас
дописываю на нем биллинг. Такого я б на мускуле не сделал, все внутри бази,
тоесть в базу приходит только ip accounting а дальше "база" сама считает. И производительность приятно удивляет :)
Реализован выбор сетевой зони для трафика, я и не думал что это будет так бистро на постгрис :) в базе около полтори тисячи сетей /19 - /24.
Да диска жрет больше, но я ему это прощаю :) ибо компенсирует он это другими
вкусностями :). Место мне не расходится (масив 240 Гб)
я выбираю постгрис.
| | |
| |
| 6.13, poige (??), 15:19, 31/10/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ к более быстрым выборкам. ;-)
При 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
| | |
| |
| 7.14, misha (??), 15:33, 31/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
А как же триггеры, процедури, 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
| | |
| |
| 8.15, poige (??), 16:03, 31/10/2004 [^] [^^] [^^^] [ответить] | +/– | Для данной задачи -- вполне Вот в качестве БД для RADIUS а, PgSQL неплохой выбо... текст свёрнут, показать | | |
|
| 7.16, uldus (ok), 20:24, 31/10/2004 [^] [^^] [^^^] [ответить]
| +/– |
>Дело не только в самом дисковом прос-ве, более оптимальное наполнение -- ключ
>к более быстрым выборкам. ;-)
А теперь сравни MySQL/InnoDB с PostgreSQL :-) Никакими быстрыми выборками там и не пахнет, когда дело касается транзакций и средств для контроля целостности.
>При sequential reading, и прочих равных условиях, выборка будет в 3-и раза
>быстрее, поскольку читалось в 3-и раза меньше GB. :-)
Вообще-то частые "sequential reading" на больших таблицах больше проблема проектирования базы :-)
>Что касается выбора "MySQL or PgSQL?" применительно к задачам статистики трафика, явно
>лучше первый,
Только вот под FreeBSD под очень большой нагрузкой не хочет MySQL нормально работать, до сих пор. Но треды сами по себе ресурсов жрут конечно меньше, чем форки PostgreSQL. Для кучи мелких операций, таких как учет трафика, MySQL отличное решение, хотя я все больше в сторону SQLite смотрю.
> count(*): 778693837
И часто "sequential reading" случается делать ? ;-)
Кстати, проведи эксперимент с базой такого объема в InnoDB.
| | |
| |
| 8.17, poige (??), 08:06, 01/11/2004 [^] [^^] [^^^] [ответить] | +/– | хватает MyISAM - про __частые__ где говорилось - мне есть из чего выбирать... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 1.9, vgray (??), 20:22, 30/10/2004 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 а года через 3 sqllite дорастет до уровня сегодняшнего mysql и тогда появиться sqlsuperlite, а если серьезно то я считаю такое разрастание mysql нехорошим делом, ибо он начинает толстеть и сувать нос туда где постгрес правит а из своей ниши уходить. | | |
| |
| 2.10, Hety (??), 13:25, 31/10/2004 [^] [^^] [^^^] [ответить]
| +/– | |
Да и шут с ним. На самом деле было бы сдорово собирать мускуль только с теми фичами, которые конкретно нужны. Мне, к примеру, нужна совместимая записаня книжка. Все новомодные приболуды мускуля я просто не юзаю. | | |
|
|
