ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / PostgreSQL vs MySQL
190 сообщений из 190, показаны все 8 страниц
  все  
PostgreSQL vs MySQL
    #34434515
Фотография YuriyB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuriyB
Участник
здравствуйте .

кто знает действительно ли PostgreSQL + PHP
будет работать быстрее чем MySQL + PHP ?

на какие еще отличительные обобенности PostgreSQL
следует обратить внимание для работы в интренет ?

спасибо.
...
Рейтинг: 0 / 0
03.04.2007, 15:20
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34434558
BlackDan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
BlackDan
Гость
Вопрос из серии
"Действительно БМВ быстрее АУДИ".
...
Рейтинг: 0 / 0
03.04.2007, 15:31
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34434991
Ivan Evtuhovich
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan Evtuhovich
Гость
BlackDanВопрос из серии
"Действительно БМВ быстрее АУДИ".

Кто сильнее, слон или кит?

Извините, не удержался. ;-)
...
Рейтинг: 0 / 0
03.04.2007, 17:04
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34435123
st_serg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
st_serg
Участник
разве кит? дельфин вроде ж бы...

2YuriyB
"Как вы яхту назовете, так она и поплывет" (с)

Я к тому, что как напишите приложение, так и будет работать, где-то быстре, где-то медленней, надо лишь знать, то что для mysql хорошо, для pgsql может быть плохо, и наоборот.

ps. насколько я помню, не так давно на opennet.ru пробегала статья по поводу pg в web-приложениях
...
Рейтинг: 0 / 0
03.04.2007, 17:35
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34435337
Фотография YuriyB
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
YuriyB
Участник
st_sergразве кит? дельфин вроде ж бы...

2YuriyB
"Как вы яхту назовете, так она и поплывет" (с)

Я к тому, что как напишите приложение, так и будет работать, где-то быстре, где-то медленней, надо лишь знать, то что для mysql хорошо, для pgsql может быть плохо, и наоборот.

ps. насколько я помню, не так давно на opennet.ru пробегала статья по поводу pg в web-приложениях

приложение уже написано и работает

есть ли смысл поменять базу данных
...
Рейтинг: 0 / 0
03.04.2007, 18:46
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34435354
Andrey Daeron
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Andrey Daeron
Участник
YuriyB
приложение уже написано и работает

есть ли смысл поменять базу данных
А ЗАЧЕМ????
...
Рейтинг: 0 / 0
03.04.2007, 18:50
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34435410
Shweik
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Shweik
Участник
Модератор: флейм переносим в Сравнение СУБД
...
Рейтинг: 0 / 0
03.04.2007, 19:13
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34440699
Фотография Arpanx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arpanx
Участник
под Postgres нет удобных инструментов для разработки. Скорость разработки низкая. Как с этим у MySql не знаю. Сижу сам на Postgres еще ни разу не падало.
Достает то что, PostGres скомпилит процедуру молча, а при запуске процедуры выясняются все ошибки.
...
Рейтинг: 0 / 0
05.04.2007, 14:45
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34441624
strizh
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
strizh
Участник
>Достает то что, PostGres скомпилит процедуру молча, а при запуске процедуры выясняются все >ошибки.
А зачем Вы ошибки делаете ?
Внимательней надо быть, а не на женские ножки отвлекаться :)
А проверить процедуру без исполнения можно:
explain select <процедура()>;
...
Рейтинг: 0 / 0
05.04.2007, 18:32
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #34449226
IgorK
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
IgorK
Участник
Arpanxпод Postgres нет удобных инструментов для разработки. Скорость разработки низкая.Что подразумевается по словом "инструментов для разработки" ?
Вот это видели? http://www.sqlmanager.net/en/products/studio/postgresql
...
Рейтинг: 0 / 0
10.04.2007, 10:50
| Ответить | Цитировать | Написать  
Период между сообщениями больше года.
PostgreSQL vs MySQL
    #36017084
prustr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
prustr
Участник
все ветку надо выбросить в корзину. Ни одного ответа, только общие слова с уроков информатики и рекомендация купить софтину за 700 долларов человеку, который ищет свободный продукт...
А вопрос при этом остается актуальным.
...
Рейтинг: 0 / 0
30.05.2009, 12:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36017140
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
prustrНи одного ответа, только общие слова с уроков информатики
....
А вопрос при этом остается актуальным.
Остаётся. Для тех, кто прогуливал уроки информатики в школе, да ещё и здесь не хочет слышать.
...
Рейтинг: 0 / 0
30.05.2009, 14:12
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36017145
Фотография Di_LIne
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Di_LIne
Участник
softwarerОстаётся. Для тех, кто прогуливал уроки информатики в школе, да ещё и здесь не хочет слышать.
Значит будут бить. (С)
...
Рейтинг: 0 / 0
30.05.2009, 14:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36035078
us0ldr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
us0ldr
Гость
Сегодня нашел в гугле. http://www.samag.ru/art/07.2007/07.2007_02.html Качественная статья где сравниваются MySQL и PostgreSQL на примере блогохостинга.
...
Рейтинг: 0 / 0
10.06.2009, 11:42
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36035244
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
тоже фигня. 20 коннектов, и MySQL издох? Лажа какая-то. Как тогда сотни тысяч серьезных проектов работали на MySQL, пока PostgreSQl не вылез из университетов? До определенного времени PG вообще всерьез не рассматривался, в силу совершенно объективных причин. Сейчас да, не спорю, силен, но чтобы так MySQL загибать, это сомнительно.
...
Рейтинг: 0 / 0
10.06.2009, 12:28
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36036665
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
kdv, не совсем так. PgSQL был ещё когда ещё mSQL'а в проекте не было.
Может быть, тестеры лажанулись с настройками mysql.
Но слон за это время здорово подрос.
...
Рейтинг: 0 / 0
11.06.2009, 01:22
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36036669
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
us0ldrСегодня нашел в гугле. http://www.samag.ru/art/07.2007/07.2007_02.html Качественная статья где сравниваются MySQL и PostgreSQL на примере блогохостинга.

Ох да.. качественная.. Одни запросы для mysql посмотреть - на полчаса смеха..

Это что за бред:
Код: plaintext
1.
2.
3.
4.
CommentId = SELECT MAX(comment_id) FROM commnets; 
INSERT IGNORE INTO \
    comments (user_id, posts_id, comment_id, from_user_id, comment_date, comment_title, comment_body) \
    VALUES (UserId, PostId, CommentId, PosterId, Date, Title, Body);

А это что? :
Код: plaintext
1.
PostID = SELECT MAX(post_id) FROM posts;
INSERT IGNORE INTO posts (user_id, post_id, post_date, post_title, post_body) VALUES (UserID, PostID, Date, Title, Body);

Это у них так "высоконагруженные проекты" работают?

А результаты?

Postgresql - от 10 и выше (до сколько хотите) - одни и теже значения. Типа скорострельность не меняется от количества соединений..

mysql - Отказ от обслуживания при 20??

В общем пожалуйста не ссылайтесь на такие статьи как на "качественные"
...
Рейтинг: 0 / 0
11.06.2009, 01:49
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36036676
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
ОКТОГЕН,

был то он был, да только до версии 7 он был не слишком рабочим. Скажем на той же 6 падение сервера было обычным явлением. Во время copy например.

Еще в первой семерке был противный баг, когда vacuum при стечении определенных обстоятельств зацикливался и и бесконечно создавал временные файлы пока не займут все место на диске (это 2002 год)

Сейчас - да, вполне достойный сервер.
...
Рейтинг: 0 / 0
11.06.2009, 02:01
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36036923
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен wrote:

> В общем пожалуйста не ссылайтесь на такие статьи как на "качественные"

Я прочитал статью и не нашёл там никакой лажы.
Подход очень разумный, человек-автор кажется вполне адекватный.
Запросы вполне себе хорошие и реальные.

А результаты впечатляющие.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.06.2009, 10:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36036937
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОКТОГЕН wrote:

> Может быть, тестеры лажанулись с настройками mysql.
> Но слон за это время здорово подрос.

Самая большая проблема MySQL -- это его дурацкая
плагиновская архитектура. Из-за неё у MySQL все беды.
А реально людям не нужны многочисленные движки, нужен
один, но хороший. PgSQL же наоборот с архитектурной точки
зрения целостный и красивый. Вот жаль я в код его ещё не
смотрел, MySQL-евский код, скажем так, далёк от совершенства.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.06.2009, 10:17
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36038469
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
MasterZiv,
у них на сайте сырцы лежат.
...
Рейтинг: 0 / 0
11.06.2009, 21:34
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36038481
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
MasterZiv, но ведь это
Код: plaintext
1.
2.
PostID = SELECT MAX(post_id) FROM posts;
INSERT IGNORE INTO posts (user_id, post_id, post_date, post_title, post_body) VALUES (UserID, PostID, Date, Title, Body);

действительно бред. Так на боевом сервере никто не делает.
В pgSQL надо использовать последовательности
В mySQL автоинкремент
...
Рейтинг: 0 / 0
11.06.2009, 21:45
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36038501
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
"INSERT IGNORE" смеялсо ...
...
Рейтинг: 0 / 0
11.06.2009, 22:33
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36038510
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОКТОГЕН wrote:

> MasterZiv,
> у них на сайте сырцы лежат.

Они лежат и на моём жёстком диске тоже, да только вот
время знаешь ли надо, чтобы прочитать
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.06.2009, 22:44
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36038524
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОКТОГЕН wrote:

> действительно бред. Так на боевом сервере никто не делает.
> В pgSQL надо использовать последовательности
> В mySQL автоинкремент

Если на двух одинаково, то я считаю ничего страшного.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.06.2009, 23:06
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36038556
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
MasterZiv, в том-то и дело что одинаково. А надо бы оптимизировать под каждый сервер.
Например, Count() в постгре считается медленнее, чем в myISAM-движке мускуля и примерно одинаково в INNODB. А последовательности и автоинкремент заведомо быстрее одного лишнего запроса.
Конструкция также не учитывает полное отсутствие ACID в MyISAM,
и между запросами
CommentId = SELECT MAX(comment_id) FROM commnets;
И INSERT INTO commnets может быть вставлено что-нибудь, и инсерт или не сработает или вставит запись с повтором CommentId.

моё мнение - если тест претендует на звание "хороший", то его запросы должны быть вылизаны
под каждую базу с учётом потрохов и того и другого. Должен использоваться диспетчер соединений(пул). Должны использоваться кеши разобранных запросов, индексы и пр.
...
Рейтинг: 0 / 0
12.06.2009, 00:03
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36039982
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
ОКТОГЕНмежду запросами
CommentId = SELECT MAX(comment_id) FROM commnets;
И INSERT INTO commnets может быть вставлено что-нибудьНе может, если таблица залочена.
ОКТОГЕНи инсерт или не сработает или вставит запись с повтором CommentId.
В первом случае количество вставленых записей будет равно нулю, во втором возникнет ошибка. И то, и другое возможно проконтролировать.

ОКТОГЕНмоё мнение - если тест претендует на звание "хороший", то ...тест не может быть абстрактно "хороший", любой тест рассчитан на то, чтобы показать что-то конкретное.

Тем не менее, всецело соглашусь, что на боевой базе вышеупомянутые запросы вряд ли будут хорошим решением.
...
Рейтинг: 0 / 0
14.06.2009, 00:44
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36041124
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОКТОГЕН wrote:

> MasterZiv, в том-то и дело что одинаково. А надо бы оптимизировать под
> каждый сервер.

Не обязательно. Мы сравниваем не две системы живых журналов, а две СУБД,
лежащие под ними.

> Конструкция также не учитывает полное отсутствие ACID в MyISAM,
> и между запросами

Но даже без ACID он постгресу почему-то проигрывает.
Знаешь, сколько я слышал воплей, что MySQL - быстрый, потому что в нём нет ACID ?

> моё мнение - если тест претендует на звание "хороший", то его запросы
> должны быть вылизаны
> под каждую базу с учётом потрохов и того и другого. Должен
> использоваться диспетчер соединений(пул). Должны использоваться кеши
> разобранных запросов, индексы и пр.

Ещё раз, мы сравниваем не пользовательские системы, а СУБД, работающие
под ними. В таком случае НОРМАЛЬНО поставить две СУБД в однинаковые
условия и посмотреть, что будет. Два лишних запроса, которых могло бы
и не быть, тут не важны. Главное - что они есть в обоих вариантах.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
15.06.2009, 12:18
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36041138
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
MasterZiv
Не обязательно. Мы сравниваем не две системы живых журналов, а две СУБД,
лежащие под ними.


глупо ...
...
Рейтинг: 0 / 0
15.06.2009, 12:22
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36041253
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv

Ещё раз, мы сравниваем не пользовательские системы, а СУБД, работающие
под ними. В таком случае НОРМАЛЬНО поставить две СУБД в однинаковые
условия и посмотреть, что будет. Два лишних запроса, которых могло бы
и не быть, тут не важны. Главное - что они есть в обоих вариантах.



Волшебное слово тут НОРМАЛЬНО.. А в статье как раз "бестолково". И эти запросы - это всего лишь пример. Там много чего "оптимизировано".
...
Рейтинг: 0 / 0
15.06.2009, 13:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36041488
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv
ОКТОГЕН wrote:

> действительно бред. Так на боевом сервере никто не делает.
> В pgSQL надо использовать последовательности
> В mySQL автоинкремент

Если на двух одинаково, то я считаю ничего страшного.


Дак оно не одинаково..

В постгресе у них :
Код: plaintext
1.
2.
3.
4.
    SELECT NEXTVAL('objects_id_seq') INTO iPostId;

    INSERT INTO posts (user_id, post_id, post_date, post_title, post_body)
        VALUES (iUserId, iPostId, iDate, sTitle, sBody);

В mysql:

Код: plaintext
1.
PostID = SELECT MAX(post_id) FROM posts;
INSERT IGNORE INTO posts (user_id, post_id, post_date, post_title, post_body) values (UserID, PostID, Date, Title, Body);

И кстати - Вас не смущает, что постгресу выделено памяти 500000 кусков по 8кило каждый (4гига) а скажем для myisam - всего 1 гиг?
...
Рейтинг: 0 / 0
15.06.2009, 14:29
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36041571
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен wrote:

> Дак оно не одинаково..

Вот это -- другой разговор. Тогда плохо.

Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
15.06.2009, 15:01
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36044709
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
us0ldrСегодня нашел в гугле. http://www.samag.ru/art/07.2007/07.2007_02.html Качественная статья где сравниваются MySQL и PostgreSQL на примере блогохостинга.
Обратите внимание, что статья 2-х летней давности.
Рекомендую посмотреть современные тесты этих двух СУБД
http://dimitrik.free.fr/blog/archives/cat_toolsiobench.html
http://dimitrik.free.fr/blog/archives/2009/05/entry_48.html
Рузультаты разительно отличаются. Автор - профессиональный benchmark engineer, так что результатам верить можно.
Он как раз и отмечает: " A big surprise - if two years ago on the same workload PostgreSQL was two times faster (see: http://dimitrik.free.fr/db_STRESS_BMK_Part2_ZFS.html ), now it's MySQL 5.4 outperforming PostgreSQL! "
...
Рейтинг: 0 / 0
16.06.2009, 21:58
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36044727
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
vasilis
http://dimitrik.free.fr/blog/archives/cat_toolsiobench.html
http://dimitrik.free.fr/blog/archives/2009/05/entry_48.html
Рузультаты разительно отличаются. Автор - профессиональный benchmark engineer, так что результатам верить можно.
Он как раз и отмечает: " A big surprise - if two years ago on the same workload PostgreSQL was two times faster (see: http://dimitrik.free.fr/db_STRESS_BMK_Part2_ZFS.html ), now it's MySQL 5.4 outperforming PostgreSQL! "

И в эту сторону я бы не стал так однозначно считать..
Достаточно посмотреть на e-mail автора тестов - (оно кончается на @sun.com ) И если учесть что пару лет назад sun поддерживал postgres, а теперь владеет mysql, то я бы с осторожностью относился к этим тестом. И к старым и к новым.
...
Рейтинг: 0 / 0
16.06.2009, 22:15
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36050318
vasilis
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vasilis
Участник
Хренvasilis
http://dimitrik.free.fr/blog/archives/cat_toolsiobench.html
http://dimitrik.free.fr/blog/archives/2009/05/entry_48.html
Рузультаты разительно отличаются. Автор - профессиональный benchmark engineer, так что результатам верить можно.
Он как раз и отмечает: " A big surprise - if two years ago on the same workload PostgreSQL was two times faster (see: http://dimitrik.free.fr/db_STRESS_BMK_Part2_ZFS.html ), now it's MySQL 5.4 outperforming PostgreSQL! "
И в эту сторону я бы не стал так однозначно считать..
Достаточно посмотреть на e-mail автора тестов - (оно кончается на @sun.com ) И если учесть что пару лет назад sun поддерживал postgres, а теперь владеет mysql, то я бы с осторожностью относился к этим тестом. И к старым и к новым.
Я лично знаю автора и могу гарантировать его объективность в его тестах, особенно тех, которые публикуются. Не зря он публикует их в своем блоге, а не в официальных пресс-релизах.
Если мое мнение тоже под сомнением (здесь вообще ничье мнение не считается честным и объективным), то есть еще много людей-профи, которые ссылаются на его результаты и доверяют им. InfoWorld, например.
...
Рейтинг: 0 / 0
19.06.2009, 11:56
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36050470
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
в этом db_STRESS 5 табличек, 2 тупых селекта которые нарушая логику читают без блокировок и 3 модифицирующих запроса. никаких транзакций (autocomit) + аффтар все эту нехитрую конструкцию загнал в память.
имхо сделать какие-либо выводы о субд по такому тесту не представляется возможным, зато об умственных способностях аффтора - имхо легко.
...
Рейтинг: 0 / 0
19.06.2009, 12:34
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36129679
Amnesyac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Amnesyac
Гость
Здесь http://madjack.ru/developer/2009/08/mysql-vs-postgresql.html подробно все рассовано по полочкам. Советую почитать. Можно сделать выбор основываясь на прочитанном. Я допустим его уже сделал.
...
Рейтинг: 0 / 0
06.08.2009, 12:36
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36129682
Amnesyac
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Amnesyac
Гость
Выше не получилось ссылку дать. ЗДЕСЬ расположена статья, где субъективно основываясь на фактах рассмотрены все сильные и слабые стороны MySQL и PostgreSQL.
...
Рейтинг: 0 / 0
06.08.2009, 12:37
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36130210
FreemanZAV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FreemanZAV
Участник
AmnesyacВыше не получилось ссылку дать. ЗДЕСЬ расположена статья, где субъективно основываясь на фактах рассмотрены все сильные и слабые стороны MySQL и PostgreSQL.
Фигня какя-то.
...
Рейтинг: 0 / 0
06.08.2009, 14:54
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36130246
FreemanZAV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
FreemanZAV
Участник
Начало просто офигительное
Код: plaintext
Выбор между MySQL и PostgreSQL - это решение, которое должен принять каждый разработчик, который выбирает между различными Open-Source СУБД.
...
Рейтинг: 0 / 0
06.08.2009, 15:05
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36130299
zMakc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zMakc
Участник
Думаю в данном сравнении стоит рассматривать не только сравнение производительности.
Даже 10% в производительности это не принципиально.

Есть и другие критерии.

Распространенность к примеру.

Мы используем MySQL 2 года, есть наработки, покупали компоненты сторонних разработчиков для своих решений. Под MsSQL , MySQL, Oracle есть то что нам нужно. Под PostgreSQL нет.

Специалистов по PostgreSQL много в свободном доступе замечено не было.

От сотрудника не раз слышал, в PostgreSQL "что-то" есть, или что-то работает быстрее.
Но это "что-то" не достаточное основание для перехода или новых проектов.

С учетом текущей ситуации, преимущество(какое-то где-то) PostgreSQL не значительно и значимого экономического эффекта не даст.
...
Рейтинг: 0 / 0
06.08.2009, 15:20
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36130457
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
zMakc, если всё хорошо работает, то зачем переходить?
Если начинать новый проект, то зависит от потребностей.
...
Рейтинг: 0 / 0
06.08.2009, 15:59
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36130498
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
zMakcПод MsSQL , MySQL, Oracle есть то что нам нужно. Под PostgreSQL нет.

А что вам нужно-то? Может, опишете?
...
Рейтинг: 0 / 0
06.08.2009, 16:07
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36131158
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
FreemanZAV пишет:

> Фигня какя-то.

Сначала подумал:
"Статья, как минимум, написана неадекватно пишушим по-русски человеком."

Потом прочитал далее -- действительно, полная лажа.

Но мне приятно, что чел. знает SolidDB, в разработке которого
я принимал участие.

В общем, почитать можно, но с оглядкой на многие технические
ляпы типа

"Транзакционный СУБД, которые построенны по модели MVCC, такие как PostgreSQL и
InnoDB выполняют COUNT(*) очень медленно в сравнении с не транзакционными СХД,
такими как MyISAM."

( дело не в "транзакционности" а в версионности. транзакционные неверсионные
СУБД замечательно делают COUNT(*) )

Есть и ещё, но иногда кажется, что автор, ещё раз, просто по-русски
не умеет писать, и пишет какую-то хрень.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
06.08.2009, 19:34
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36131168
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
zMakc пишет:

> С учетом текущей ситуации, преимущество(какое-то где-то) PostgreSQL не
> значительно и значимого экономического эффекта не даст.

Я могу сказать, в чём огромное преимущество PostgreSQL перед MySQL.
PostgreSQL -- это нормальная СУБД, которая разрабатывалась долго
и вдумчиво нормальными людьми. MySQL же -- это просто куча никчёмного
кода, который, к нещастью, работает.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
06.08.2009, 19:43
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143035
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Я могу рассказать в чем огромное преимущество MySQL перед PgSQL

Postgresql разрабатывается по принципу "вали все в кучу, потом разберемся", толпой у которой даже багтрекера нет - форумом обходятся. Поэтому там до фига фич, и те места, которые интересно писать - прописаны хорошо. А скучные - типа тех же collation - никого не вдохновляют.

MySQL же разрабатывается одной командой, с вменяемой (платной) техподдержкой и возможностью решить вопросы на любом уровне, включая патчи специально под твои нужды. Не так давно к примеру видел такой патч, который позоляет держать 20 - 30 тыщщ соединений.
...
Рейтинг: 0 / 0
13.08.2009, 21:05
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143286
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Хрен
MySQL же разрабатывается одной командой, с вменяемой (платной) техподдержкой и
возможностью решить вопросы на любом уровне, включая патчи специально под твои нужды.
Не так давно к примеру видел такой патч, который позоляет держать 20 - 30 тыщщ соединений.

Это не пул соединений часом?
Про патч полнотекстового поиска для innoDB я краем уха слышал.
Как оно работает - не знаю. Почему эта сплочённая команда не протестировала этот насущно
необходимый код и не включила его в релиз - вопрос отдельный.
А вот не появилось ли там патча, реализующего CHECK'и и табличные функции хотя бы как в MSSQL?
Чтоб не писать для каждого случая свою процедуру, а использовать уже готовые, просто JOIN'я их?
Этот момент меня лично реально напрягал , когда я делал проекты на mysql.
Ещё реально напрягали нюансы с пятёркой. Например, комментарии в триггере на русском
языке приводили к нечитаемости(и дальнейшей порче при попытке изменить) кода триггера с
начала комментария. Поведение нигде не документировано. Моя попытка пообщаться с
разработчиками ни к чему вразумительному ни привела. Ответ , который мне был дан ,
примерно "учитесь настраивать систему".
Не говоря про залипуху с математикой(невдолбенные погрешности при операциях умножения)
в версиях до 5.0.20.
О волшебных преобразованиях нормального запроса в синтаксически неверный в
представлениях тоже говорить не будем, здесь про это тоже кто-то писал.
В PostgreSQL же это всё просто работает, работает давно, и так, как надо.
...
Рейтинг: 0 / 0
14.08.2009, 01:35
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143292
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
MasterZivMySQL же -- это просто куча никчёмного
кода, который, к нещастью, работает.
Почему же к несчастью? Наоборот, к счастью.
Если это есть, значит кому-то нужно.
...
Рейтинг: 0 / 0
14.08.2009, 01:39
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143580
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
ОКТОГЕН
Ещё реально напрягали нюансы с пятёркой. Например, комментарии в триггере на русском
языке приводили к нечитаемости(и дальнейшей порче при попытке изменить) кода триггера с
начала комментария. Поведение нигде не документировано.


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
mysql> show create trigger ctest\G
***************************  1 . row ***************************
               Trigger: ctest
              sql_mode: 
SQL Original Statement: CREATE DEFINER=`root`@`localhost` trigger ctest before insert on tbl1 for each row
BEGIN
   -- Привет проба коммента
   set new.i =  2 ;
END
  character_set_client: utf8
  collation_connection: utf8_general_ci
    Database Collation: utf8_general_ci
 1  row in set ( 0 , 00  sec)

ОКТОГЕН Ответ , который мне был дан , примерно "учитесь настраивать систему".

:-)

ОКТОГЕН
В PostgreSQL же это всё просто работает, работает давно, и так, как надо.


Я бы поверил, если бы не было на работе нагруженного сервера pgsql. Если вы думаете, я никогда не видел sigsegv на нем, то ошибаетесь.
...
Рейтинг: 0 / 0
14.08.2009, 10:03
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143597
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Хрен, славненько.
А теперь попробуйте вытащить код триггера из системы.
...
Рейтинг: 0 / 0
14.08.2009, 10:11
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143625
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
ОКТОГЕН,

А это что по вашему было?
...
Рейтинг: 0 / 0
14.08.2009, 10:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143854
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
упс. Не заметил.
...
Рейтинг: 0 / 0
14.08.2009, 11:36
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36143859
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
А какая это версия?
Просто с такой проблемой сталкивался не я один.
...
Рейтинг: 0 / 0
14.08.2009, 11:37
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36144221
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Ух ты! 5.1.30-community проблемы нет, видимо, действительно, пофиксили.
Лучше поздно, чем никогда...
В версиях 5.0.20 - 5.0.30х я тестировал это под разными осями, под разными кодировками(и клиентов и серверов и осей) и разными либами. Дело было точно не в настройках,
потому, как перед созданием триггера в этом же сеансе создавалась процедура с комментарием, и там было всё в порядке. При этом русский текст отображался правильно.
...
Рейтинг: 0 / 0
14.08.2009, 13:05
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36147556
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен пишет:

> Postgresql разрабатывается по принципу "вали все в кучу, потом
> разберемся", толпой у которой даже багтрекера нет - форумом обходятся.
> Поэтому там до фига фич, и те места, которые интересно писать -
> прописаны хорошо. А скучные - типа тех же collation - никого не
> вдохновляют.
>
> MySQL же разрабатывается одной командой, с вменяемой (платной)
> техподдержкой и возможностью решить вопросы на любом уровне, включая
> патчи специально под твои нужды. Не так давно к примеру видел такой
> патч, который позоляет держать 20 - 30 тыщщ соединений.

Ну, ну. Особенно про "MySQL же разрабатывается одной командой" здорово.

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.
MySQL -- использует многозадачность операционной сисстемы, на каждый
коннект создаёт поток. Это -- ОЧЕНЬ ПЛОХО по большому счёту, но дёшево
(попсово) в реализации.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
17.08.2009, 13:29
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36147565
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
ОКТОГЕН пишет:

> Почему же к несчастью? Наоборот, к счастью.

Потому что если бы он не работал, то люди не парили бы себе
и разработчикам мозг по использованию и поддержке этого Г.


А использовали бы либо нормальные платные СУБД (дешёвых не так мало),
либо нормальные бесплатные СУБД.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
17.08.2009, 13:32
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36147976
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
MasterZiv
Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.

Не совсем. Слон использует процессы.
Под виндами в этом есть минусы, т.к. процессы тут тормозят.
Зато взаимодействие основанное на процессах значительно надёжнее,
чем на потоках.
ХренЕсли вы думаете, я никогда не видел sigsegv на нем, то ошибаетесь.
А я видел то же самое на oracle. Видел, как M$SQL умирает. Баги есть везде.
...
Рейтинг: 0 / 0
17.08.2009, 15:16
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36148923
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv
Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.
MySQL -- использует многозадачность операционной сисстемы, на каждый
коннект создаёт поток. Это -- ОЧЕНЬ ПЛОХО по большому счёту, но дёшево
(попсово) в реализации.


Во первых pgsql не использует "свою многозадачность". Он использует process per connect стратегию для соединений.
Во вторых "ОЧЕНЬ ПЛОХО" - нуждается в обосновании.
...
Рейтинг: 0 / 0
18.08.2009, 00:38
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36148929
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
ОКТОГЕН
Под виндами в этом есть минусы, т.к. процессы тут тормозят.
Зато взаимодействие основанное на процессах значительно надёжнее,
чем на потоках.


Не в случае с pgsql. Сервера, с process per connect считаются надежнее, так как процессы изолированы друг от друга, не имеют общей памяти, и не могут нагадить друг другу. Но pgsql имеет общую память для всех процессов в shared memory, которая синхронизируется семафорами. Поэтому нагадить друг другу - они могут точно также как threads в mysql.

Собственно - так и происходит в случае внезапной кончины одного из процессов в pgsql. В таком случае - семафоры и shared memory остаются в неопределенном состоянии, поэтому postmaster - управляющий процесс - просто убивает все остальные соединения, и ре-инициализирует семафоры и shared memory заново. То есть - pgsql просто не использует те advantages, которые дает архитектура process per connect.

А drawbacks такой архитектуры - более ресурсоемкие соединения - они остаются, их никуда не денешь..
...
Рейтинг: 0 / 0
18.08.2009, 00:47
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36148941
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
2Хрен

меня терзают смутные сомнения. о каких семофорах идет речь, операционной системы ? что за ОСь такая у которой остаются болтаться семофоры ? но больше заинтриговало shared memory - что там такого может оставить юзерский процесс, чего там такого чего нет в оракле ?
...
Рейтинг: 0 / 0
18.08.2009, 01:31
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36148942
Фотография Ёш
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ёш
Участник
ХренНе в случае с pgsql. Сервера, с process per connect считаются надежнее, так как процессы изолированы друг от друга, не имеют общей памяти, и не могут нагадить друг другу. Но pgsql имеет общую память для всех процессов в shared memory, которая синхронизируется семафорами. Поэтому нагадить друг другу - они могут точно также как threads в mysql.

Собственно - так и происходит в случае внезапной кончины одного из процессов в pgsql. В таком случае - семафоры и shared memory остаются в неопределенном состоянии, поэтому postmaster - управляющий процесс - просто убивает все остальные соединения, и ре-инициализирует семафоры и shared memory заново. То есть - pgsql просто не использует те advantages, которые дает архитектура process per connect.Вы как-то сами себе противоречите, возможность отследить разрушение данных в общей памяти, падение процесса и произвести после этого корректный перезапуск как раз и есть то самое использование преимуществ раздельных процессов в pg.
...
Рейтинг: 0 / 0
18.08.2009, 01:35
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149251
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Хрен, эксперимент показывает, что убийства процессов не происходит.
На остальных сеансах это не отражается(8.4)
...
Рейтинг: 0 / 0
18.08.2009, 10:22
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149624
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ОКТОГЕН,
а как именно ты заставил коннект умереть лютой смертью?
...
Рейтинг: 0 / 0
18.08.2009, 12:05
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149676
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
dimitrа как именно ты заставил коннект умереть лютой смертью?
кому-то известно более одного способа "убийства процессов" ?
...
Рейтинг: 0 / 0
18.08.2009, 12:19
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149703
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
ОКТОГЕНХрен, эксперимент показывает, что убийства процессов не происходит.
На остальных сеансах это не отражается(8.4)

Это интересно, надо попробовать. Быстрая проба на 8.3:

В двух окнах открываем 2 соединения psql
потом убиваем один из процессов:
Код: plaintext
1.
root@home:~# kill - 11   20204

Потом в каждом из соединений делаем скажем select 1;

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
$ psql
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

walrus=# 
walrus=# select 1;
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

и во втором
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
$ psql 
Welcome to psql 8.3.7, the PostgreSQL interactive terminal.

Type:  \copyright for distribution terms
       \h for help with SQL commands
       \? for help with psql commands
       \g or terminate with semicolon to execute query
       \q to quit

walrus=# 
walrus=# select 1;
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

В логе:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2009-08-18 16:33:20 EST LOG:  server process (PID 20204) was terminated by signal 11: Segmentation fault
2009-08-18 16:33:20 EST LOG:  terminating any other active server processes
2009-08-18 16:33:20 EST WARNING:  terminating connection because of crash of another server process
2009-08-18 16:33:20 EST DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2009-08-18 16:33:20 EST HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2009-08-18 16:33:20 EST LOG:  all server processes terminated; reinitializing
2009-08-18 16:33:20 EST LOG:  database system was interrupted; last known up at 2009-08-18 16:32:37 EST
2009-08-18 16:33:20 EST LOG:  database system was not properly shut down; automatic recovery in progress
2009-08-18 16:33:20 EST LOG:  record with zero length at 0/3C7F17AC
2009-08-18 16:33:20 EST LOG:  redo is not required
2009-08-18 16:33:20 EST LOG:  autovacuum launcher started
2009-08-18 16:33:20 EST LOG:  database system is ready to accept connections

То есть по крайней мере, в 8-3 происходит именно так, как я описывал.. А в 8-4 надо будет обязательно попробовать, как только руки дойдут
...
Рейтинг: 0 / 0
18.08.2009, 12:28
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149746
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
интересно, а если 8.3 именно убивать, kill -9 ?
...
Рейтинг: 0 / 0
18.08.2009, 12:42
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149794
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Yo.!, под вендой завершались через диспетчер задач-завершение процесса.
И 8.3.7 и 8.4 другие клиентские процессы при этом не завершались.
Особенности системы?
...
Рейтинг: 0 / 0
18.08.2009, 12:56
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149842
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
скорее segfault постгрес решает обрабатывать перегрузкой сервера, нужно под линуксом 8.3 попробовать прибить по -9, тогда можно будет делать выводы ...
...
Рейтинг: 0 / 0
18.08.2009, 13:08
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36149857
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Yo.!кому-то известно более одного способа "убийства процессов" ?
более интересна была бы реакция на AV/SEGV в одном из рабочих процессов
...
Рейтинг: 0 / 0
18.08.2009, 13:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150178
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Yo.!скорее segfault постгрес решает обрабатывать перегрузкой сервера, нужно под линуксом 8.3 попробовать прибить по -9, тогда можно будет делать выводы ...

то же самое при kill -9

Первое соединение:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
walrus=# select 1;
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and repeat your command.
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

Второе соединение:

Код: plaintext
1.
2.
3.
4.
5.
walrus=# select 1;
server closed the connection unexpectedly
	This probably means the server terminated abnormally
	before or while processing the request.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.
walrus=#


в логе
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
2009-08-18 20:33:36 EST LOG:  server process (PID 20215) was terminated by signal 9: Killed
2009-08-18 20:33:36 EST LOG:  terminating any other active server processes
2009-08-18 20:33:36 EST WARNING:  terminating connection because of crash of another server process
2009-08-18 20:33:36 EST DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2009-08-18 20:33:36 EST HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2009-08-18 20:33:36 EST LOG:  all server processes terminated; reinitializing
2009-08-18 20:33:36 EST LOG:  database system was interrupted; last known up at 2009-08-18 16:33:20 EST
2009-08-18 20:33:36 EST LOG:  database system was not properly shut down; automatic recovery in progress
2009-08-18 20:33:36 EST LOG:  record with zero length at 0/3C7F17EC
2009-08-18 20:33:36 EST LOG:  redo is not required
2009-08-18 20:33:36 EST LOG:  autovacuum launcher started
2009-08-18 20:33:36 EST LOG:  database system is ready to accept connections
...
Рейтинг: 0 / 0
18.08.2009, 14:40
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150425
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен пишет:

> Во первых pgsql *не* использует "свою многозадачность". Он использует
> process per connect стратегию для соединений.

Ну не знаю. Надо посмотреть как у них серверный процесс выглядит.

> Во вторых "ОЧЕНЬ ПЛОХО" - нуждается в обосновании.

Для всего-то вам обоснования нужны ...
В любой операционной системе создавать бесконечное число потоков
невозможно, и бессмысленно с точки зрения СУБД -- у неё все равно
5-20 процессоров только есть, больше потоков создавать бессмысленно --
это одна накладуха (в ОС). Лучше иметь 5-20 потоков и брать их
из пула и выполнять в них запросы, передавая им структуру контекста
выполнения серверного процесса. Последнюю структуру надо иметь
в любом случае, так зачем тогда 2000 потоков ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.08.2009, 15:53
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150439
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен пишет:

> Не в случае с pgsql. Сервера, с process per connect считаются надежнее,
> так как процессы изолированы друг от друга, не имеют общей памяти, и не
> могут нагадить друг другу.

Как процессы сервера БД могут не иметь общей памяти, скажи пожалуйста ?
Это что же, каждому коннекту свой кэш данных ?
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.08.2009, 15:55
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150446
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Yo.! пишет:

> меня терзают смутные сомнения. о каких семофорах идет речь, операционной
> системы ? что за ОСь такая у которой остаются болтаться семофоры ? но
> больше заинтриговало shared memory - что там такого может оставить
> юзерский процесс, чего там такого чего нет в оракле ?

Да гонит он. Чепуху какую-то сморозил.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.08.2009, 15:56
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150789
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv
Хрен пишет:

> Во первых pgsql *не* использует "свою многозадачность". Он использует
> process per connect стратегию для соединений.

Ну не знаю. Надо посмотреть как у них серверный процесс выглядит.


Посмотрите, посмотрите.. прежде чем спорить.

MasterZiv
В любой операционной системе создавать бесконечное число потоков
невозможно, и бессмысленно с точки зрения СУБД -- у неё все равно
5-20 процессоров только есть, больше потоков создавать бессмысленно --
это одна накладуха (в ОС). Лучше иметь 5-20 потоков и брать их
из пула и выполнять в них запросы, передавая им структуру контекста
выполнения серверного процесса. Последнюю структуру надо иметь
в любом случае, так зачем тогда 2000 потоков ?


Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.
...
Рейтинг: 0 / 0
18.08.2009, 17:50
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150800
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv
Как процессы сервера БД могут не иметь общей памяти, скажи пожалуйста ?
Это что же, каждому коннекту свой кэш данных ?


Может быть и такое. interbase classic к примеру
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_ss_vs_classic Classic architecture, the design in InterBase 4.0 and earlier, was process-based. For every client connection, a separate server process was started to execute the database engine, and each server process had a dedicated database cache.

А теперь сделайте еще один шаг и скажите, если shared data все равно нужна - в чем преимущество модели process per connection, которую использует postgres относительно mysql thread per connection?
...
Рейтинг: 0 / 0
18.08.2009, 17:54
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150801
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv
Да гонит он. Чепуху какую-то сморозил.


Вы сами то понимаете, что выглядите клоуном, когда спорите против фактов? Легко же посмотреть/почитать документацию/проверить.
...
Рейтинг: 0 / 0
18.08.2009, 17:56
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150842
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
ОКТОГЕНYo.!, под вендой завершались через диспетчер задач-завершение процесса.
И 8.3.7 и 8.4 другие клиентские процессы при этом не завершались.
Особенности системы?

Есть предположение, что диспетчер задач посылает то, что в юниксах называется SIGTERM. А он не рассматривается postgres-ом как ненормальное завершение, потому что не может быть в результате бага и используется к примеру при shutdown операционной системы. В постгресе по sigterm закрывается одно текущее соединение - с flush файлов и нормальным освобождением ресурсов..
...
Рейтинг: 0 / 0
18.08.2009, 18:16
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150863
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Хрен, и всё-таки взаимодействие процессов поломать значительно сложнее, чем взаимодействие потоков. А отдельные буфера и у процессов постгреса есть(workmem, по моему).
...
Рейтинг: 0 / 0
18.08.2009, 18:26
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36150915
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Хрен
Есть предположение, что диспетчер задач посылает то, что в юниксах
называется SIGTERM. А он не рассматривается postgres-ом как ненормальное
завершение,

Скорее используется TerminateProcess и рассматривать его как нормальное
завершение чисто технически невозможно - убиваемый процесс никак не
оповещается и не имеет возможности отреагировать.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.08.2009, 18:56
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36151200
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен пишет:

> Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.

MySQL создаёт на каждое соединение с клиентом поток (thread).
Это не то, что я приводил.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.08.2009, 23:30
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36151201
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен пишет:

> А теперь сделайте еще один шаг и скажите, если shared data все равно
> нужна - в чем преимущество модели process per connection, которую
> использует postgres относительно mysql thread per connection?

В отсутствии накладных расходов в ОС на создание множества безполезных
потоков. И в применении собственной диспечтеризации СУБД, а не
диспетчеризации операционной системы, которая понятия не имеет о состоянии
задач, выполняемых СУБД.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
18.08.2009, 23:32
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36151272
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
MasterZiv
Хрен пишет:

> Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.

MySQL создаёт на каждое соединение с клиентом поток (thread).
Это не то, что я приводил.


mysqlManualAs of MySQL 6.0.4, an alternative thread model is available for dealing with the preceding issues that occur when scaling to large numbers of simultaneous connections. This model uses thread pooling:

*Connection manager threads do not dedicate a thread to each client connection. Instead, the connection is added to the set of existing connection sockets. The server collects input from these sockets and when a complete request has been received from a given client, it is queued for service.

*The server maintains a pool of service threads to process client requests. When a queued request is waiting and there is an available (not busy) service thread in the pool, the request is given to the thread to be handled. After processing the request, the service thread becomes available to process other requests.

*Service threads are created at server startup and exist until the server terminates. A given service thread is not tied to a specific client connection and the requests that it processes over time may originate from different client connections.

*The pool of service threads has a fixed size, so the amount of memory required for it does not increase as the number of client connections increases.


http://dev.mysql.com/doc/refman/6.0/en/connection-threads.html
...
Рейтинг: 0 / 0
19.08.2009, 03:18
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36151826
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Хрен пишет:

> As of MySQL 6.0.4, an alternative thread model is available for dealing
> with the preceding issues that occur when scaling to large numbers of
> simultaneous connections. This model uses thread pooling:
>
> *Connection manager threads do not dedicate a thread to each client
> connection. Instead, the connection is added to the set of existing
> connection sockets. The server collects input from these sockets and

Ну, а я про что ?

Но это 6-ка, она ещё не вышла. И, может быть, не выйдет никогда.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
19.08.2009, 11:51
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36183469
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
Хрен
MasterZiv
В любой операционной системе создавать бесконечное число потоков
невозможно, и бессмысленно с точки зрения СУБД -- у неё все равно
5-20 процессоров только есть, больше потоков создавать бессмысленно --
это одна накладуха (в ОС). Лучше иметь 5-20 потоков и брать их
из пула и выполнять в них запросы, передавая им структуру контекста
выполнения серверного процесса. Последнюю структуру надо иметь
в любом случае, так зачем тогда 2000 потоков ?


Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.

Пока глупые пользователь pgsql вовсю используют пул соединений PgBouncer , написанный какими-то хренами с бугра из ....
Модератор: лексика кульных хацкеров здесь не приветствуется, вплоть до их забанивания
...
Рейтинг: 0 / 0
08.09.2009, 11:03
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36283662
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
Полемика затихла. А я вот как раз оказался перед выбором, что лучше предпочесть, MySQL или PostgreSQL?

Требуется в основном под Web достаточно сложная база. Несколько десятков таблиц, Foreign keys, триггеры. В вебе большое количество читателей, делающих разнообразные достаточно сложные поиски. И небольшое количество писателей. Писатели по большей части пополняют базу.

Есть команда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему. Других доводов нет. И собственно для них мне и нужно спроектировать БД, обеспечить импорт данных и т.п.
Вот у меня и возникли сомнения. С PostgreSQL у меня только очень поверхностное знакомство: ставил, пробовал, "игрался". С MySQL вообще знакомство только понаслышке.
Но чтобы убедить ту команду web-разработчков сменить БД, нужны серьезные основания. А надо ли вообще переубеждать и менять?
...
Рейтинг: 0 / 0
31.10.2009, 12:12
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36283677
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Александр Гoлдун пишет:

> Полемика затихла. А я вот как раз оказался перед выбором, что лучше
> предпочесть, MySQL или PostgreSQL?

PostgreSQL. Если только тебе не нужен режим работы без транзакций.

MySQL --евцы все пруца с этого, типа -- быстро очень на MyIsam.
Я не знаю, сам не проверял. Для меня без транзакций работать --
дикость вообще.

Переубеждать кого-нибудь -- задача неблагодарная.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
31.10.2009, 12:27
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284163
zMakc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zMakc
Участник
Александр Гoлдункоманда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему.

По моему мнению MySQL и PostgreSQL имеют много особенностей и приложение нужно проектировать с учетом этих особенностей, тоесть под СУБД. Лучшая в данном случае та которую лучше знают.

Мой сотрудник раньше часто поднимал вопрос о переходе на PostgreSQL. Мотивируя тем что она "серьезная и крутая"...

Помимо технических аспектов в сравнении нужно рассмотреть и многие другие.

В ходе сравнения выяснилось:

-В PostgreSQL больше видов индексов (GIST) и на некоторых запросах оптимизатор умнее.

-В PostgreSQL мощнее триггеры и хранимые.
ИМХО реализовывать более менее серьезную логику на триггерах это извращение (хороший объектный код на C# или PHP гораздо проще поддерживать).

-Возможность использования разных типов таблиц в MySQL в некоторых случаях дает значительное превосходство

-Как мне показалось с репликацией в MySQL дела обстоят лучше.

-На одних запросах быстрее PostgreSQL на других MySQL, если грамотно использовать (обходить слабые места и использовать сильные) то итоговая разница в производительности на типовых задачах не настолько большая(кто и где быстрее вопрос спорный) чтобы быть определяющим фактором в выборе.Еще версия 5.4 заметно лучше.

Распространенность, количество специалистов, c MySQL ситуация лучше.


Как альтернативу MySQL в первую очередь рассматриваю MsSQL, там есть много вкусностей :)
...
Рейтинг: 0 / 0
01.11.2009, 00:34
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284193
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
zMakc
По моему мнению MySQL и PostgreSQL имеют много особенностей и приложение нужно проектировать с учетом этих особенностей, тоесть под СУБД. Лучшая в данном случае та которую лучше знают.

Слово "знают" в отношении многих (но не всех) Web-разработчиков имеет особый смысл...

zMakc
-В PostgreSQL мощнее триггеры и хранимые.
ИМХО реализовывать более менее серьезную логику на триггерах это извращение (хороший объектный код на C# или PHP гораздо проще поддерживать).

Хорошо еще что хоть внешние ключи и транзакции не посоветовали на PHP реализовывать.
zMakc
Распространенность, количество специалистов, c MySQL ситуация лучше.

Ага, я заметил. Эти специалисты мне как раз написали, что лучше бы MyIsam таблицы использовать, если у меня нет серьезных доводов для InnoDB
А я вот смотрю на простыню, распечатанную из PD, на которой почти полсотни таблиц и все испещрено связями и думаю, достаточно ли это серьезный довод хотя бы для использования InnoDB, не говоря уж про выбор нормального сервера, или я чего-то перестал понимать в вопросах баз данных?
zMakc
Как альтернативу MySQL в первую очередь рассматриваю MsSQL, там есть много вкусностей :)
Я был бы рад и MS SQL, хотя если б это зависело только от меня, то вообще выбрал бы SQL Anywhere Web edition. Но ирония в том, что практически делается перевод базы с MS SQL на MySQL, ибо с MSSQL команда специалистов незнакома, MySQL им привычнее.
...
Рейтинг: 0 / 0
01.11.2009, 01:28
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284197
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
zMakc
-Как мне показалось с репликацией в MySQL дела обстоят лучше.

Это вам показалось.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
01.11.2009, 01:43
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284318
zMakc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zMakc
Участник
Александр Гoлдун,

авторвнешние ключи и транзакции не посоветовали на PHP
При чем тут ключи?


авторMyIsam таблицы использовать, если у меня нет серьезных доводов для InnoDB
Для большинства таблиц InnoDB однозначно. Где вы таких "специалистов" нашли? :)
...
Рейтинг: 0 / 0
01.11.2009, 12:20
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284438
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
zMakc
-В PostgreSQL мощнее триггеры и хранимые.
ИМХО реализовывать более менее серьезную логику на триггерах это извращение (хороший объектный код на C# или PHP гораздо проще поддерживать).

Когда в MySQL не было транзакций, их предлагалось реализовывать в приложении.
Когда в MySQL не было внешних ключей, в документации была глава, что "внешние ключи --- плохо".
Что-то мне подсказывает, что когда в MySQL наконец реализуют нормальную поддержку хранимых процедур и триггеров, то и хранение логики в базе ВНЕЗАПНО перестанет быть извращением.

И, кстати, в PostgreSQL можно писать триггеры и процедуры хоть на PHP .

zMakc
-Возможность использования разных типов таблиц в MySQL в некоторых случаях дает значительное превосходство

Превосходство, видимо, заключается в том, что при помощи зоопарка типов таблиц получается приблизится к функциональности единственного типа таблиц в PostgreSQL.

Как там, в MySQL уже можно использовать полнотекстовые индексы одновременно с транзакциями?

zMakc
-Как мне показалось с репликацией в MySQL дела обстоят лучше.

В том плане, что она там встроенная, one size fits all? А сколько решений для репликации в PostgreSQL рассматривалось, и какие именно?

::в сторону::
Что интересно, обычно одни и те же люди в одном и том же посте умудряются хвалить MySQL за множество табличных движков и утверждать, что множество различных решений для репликации в PostgreSQL --- плохо.

zMakc
Распространенность, количество специалистов, c MySQL ситуация лучше.

Распространённость, количество "специалистов", с Windows ситуация лучше. Почему-то на это очевидное сравнение пользователи MySQL очень обижаются.

Ну и забыли про главное достоинство PostgreSQL щас --- его не купил Оракл, и поэтому больше шансов на дальнейшее развитие, бгыгыгы.
...
Рейтинг: 0 / 0
01.11.2009, 15:07
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284521
zMakc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
zMakc
Участник
Sad Spirit,

авторВНЕЗАПНО перестанет Не перестанет. Одно дело базовые вещи, другое логика.

авторпроцедуры хоть на PHP. Опять громкие заявления... На сайте указано что последний релиз 10/15/ 2007 (наверное поддержку версии 5.3 вот-вот сделают :) ) и судя по всему проект бете, это не для серьезного применения.

авторЧто интересно, обычно одни и те же люди в одном и том же посте умудряются хвалить MySQL за множество табличных движков... Потому что эти табличные движки идут в составе изначально. Это разные вещи.

авторMySQL очень обижаются

Ничего обидного в этом нет (тем более Windows хороший продукт). Адекватных специалистов как ни крути в разы больше. Если популярность PostgreSQL будет расти то "специалисты" тоже появятся и будут своим творчеством веселить.

авторего не купил Оракл Ларри Элисон заявил что денег на разработку MySQL будут тратить больше чем Sun, не думаю что он бросает слова на ветер. Гробить MySQL им не выгодно, наоборот.
...
Рейтинг: 0 / 0
01.11.2009, 16:36
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284558
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
zMakcSad Spirit,
авторВНЕЗАПНО перестанет Не перестанет. Одно дело базовые вещи, другое логика.

А где конкретно граница между базовыми вещами и логикой? Реализация ограничений на данные при помощи внешних ключей ещё хорошо, а при помощи триггеров --- уже плохо? Историю изменений записи тоже будем на похапэ реализовывать, чтобы потом концов не найти, когда кто-нибудь через консоль влезет?

Или напишем дерево по методу Nested Sets, а потом оно ВНЕЗАПНО развалится, ибо руками поправили .

А кстати об ограничениях, а MySQL уже CHECK понимать начал?

zMakc
авторпроцедуры хоть на PHP. Опять громкие заявления... На сайте указано что последний релиз 10/15/ 2007 (наверное поддержку версии 5.3 вот-вот сделают :) ) и судя по всему проект бете, это не для серьезного применения.

Ну да, не особо задался pl/php, ибо абсолютное большинство похапистов "знают" MySQL и неспособны выучить что-либо ещё, а без пользователей и смысла развивать нету. Но зато есть вполне стабильные pl/perl , pl/python , pl/tcl .

Есть и куча менее стабильных вещей , включая pl/java.

А на скольких языках можно писать процедуры для MySQL?..

zMakc
авторЧто интересно, обычно одни и те же люди в одном и том же посте умудряются хвалить MySQL за множество табличных движков... Потому что эти табличные движки идут в составе изначально. Это разные вещи.

То есть наличие табличных движков, которые не идут в составе изначально --- это плохо? Так и запишем.


zMakc
авторMySQL очень обижаются
Ничего обидного в этом нет (тем более Windows хороший продукт). Адекватных специалистов как ни крути в разы больше.

Адекватным можно быть только по отношению к чему либо. Поэтому тут не поспоришь: специалистов по MySQL, адекватных используемому продукту , действительно в разы больше.

zMakc
авторего не купил Оракл Ларри Элисон заявил что денег на разработку MySQL будут тратить больше чем Sun, не думаю что он бросает слова на ветер. Гробить MySQL им не выгодно, наоборот.
Ну да, только разработчики-то уже разбежались как тараканы. Какую из 50 новых несовместимых веток MySQL его пользователи планируют ставить через год-два? Ну и пока Ларри "заявляет", PostgreSQL развивается.
...
Рейтинг: 0 / 0
01.11.2009, 17:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284896
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
zMakc
авторвнешние ключи и транзакции не посоветовали на PHP
При чем тут ключи?

При том, что вы уже предложили вместо триггеров PHP использовать. Вот я и попытался экстраполировать направление полета вашей мысли до реализации ссылочной целостности и транзакций также средствами PHP.
...
Рейтинг: 0 / 0
01.11.2009, 23:49
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284941
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Sad Spirit
zMakc
-Как мне показалось с репликацией в MySQL дела обстоят лучше.

В том плане, что она там встроенная, one size fits all? А сколько решений для репликации в PostgreSQL рассматривалось, и какие именно?


А какие рабочие решения по репликации для pg предложили бы Вы?
...
Рейтинг: 0 / 0
02.11.2009, 01:09
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284942
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Александр Гoлдун
Есть команда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему. Других доводов нет.

А Ваша роль какая?
...
Рейтинг: 0 / 0
02.11.2009, 01:12
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36284945
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Sad Spirit
Пока глупые пользователь pgsql вовсю используют пул соединений PgBouncer , написанный какими-то хренами с бугра из ....


Ну этого добра и у нас есть.

http://forge.mysql.com/wiki/MySQL_Proxy

Тут тебе и пул коннекций, и переписывание запросов, и failover и load balancing. И разрабатывается в Сане.
...
Рейтинг: 0 / 0
02.11.2009, 01:20
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36285125
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
ХренАлександр Гoлдун
Есть команда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему. Других доводов нет.
А Ваша роль какая?
Моя роль - спроектировать им базу. Кроме того, есть некая исходная база в MSSQL, откуда понадобятся данные, разово либо на регулярной основе.
...
Рейтинг: 0 / 0
02.11.2009, 09:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36285448
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
ХренSad Spirit
zMakc
-Как мне показалось с репликацией в MySQL дела обстоят лучше.

В том плане, что она там встроенная, one size fits all? А сколько решений для репликации в PostgreSQL рассматривалось, и какие именно?


А какие рабочие решения по репликации для pg предложили бы Вы?
А почемы Вы отвечаете вопросом на вопрос?

Я, пожалуй, подожду давать советы космического масштаба, etc. Пусть сначала автор расскажет, для какой задачи ему потребовалась репликация, какие решения он рассматривал, и по каким критериям ему "показалось".

Хрен
Ну этого добра и у нас есть.

http://forge.mysql.com/wiki/MySQL_Proxy

Тут тебе и пул коннекций, и переписывание запросов, и failover и load balancing. И разрабатывается в Сане.

???
Это скорее аналог pl/proxy , чем обычный пул соединений.
...
Рейтинг: 0 / 0
02.11.2009, 11:41
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36290099
Фотография Хрен
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хрен
Участник
Sad Spirit
А почемы Вы отвечаете вопросом на вопрос?

Я, пожалуй, подожду давать советы космического масштаба, etc. Пусть сначала автор расскажет, для какой задачи ему потребовалась репликация, какие решения он рассматривал, и по каким критериям ему "показалось".


Ну то есть, вы же критикуете автора, наверное знаете что-то такое, что осталоьтным надо бы знать, а они не знают. Ну не slony I же вы имеете в виду!


Хрен
Ну этого добра и у нас есть.

http://forge.mysql.com/wiki/MySQL_Proxy

Тут тебе и пул коннекций, и переписывание запросов, и failover и load balancing. И разрабатывается в Сане.

???
Это скорее аналог pl/proxy , чем обычный пул соединений.[/quot]

Нет, не аналог. pl/proxy выполняется в процессе постгреса. Это всего лишь прокси. Что-то типа расширенного RPC между postgres серверами. Так что pl/proxy скажем от 10000 соединений не поможет ничем.

mysql proxy - отдельный процесс, который держит пул соединений с одной или несколькими базами, и которому может цепляться туча клиентов. Он анализирует, переписывает запросы, обеспечивает failover и тд. Вот он как раз может выполнять работу и pgbouncer-а в том числе.
...
Рейтинг: 0 / 0
04.11.2009, 12:42
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36290709
Sad Spirit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Sad Spirit
Участник
ХренSad Spirit
А почемы Вы отвечаете вопросом на вопрос?

Я, пожалуй, подожду давать советы космического масштаба, etc. Пусть сначала автор расскажет, для какой задачи ему потребовалась репликация, какие решения он рассматривал, и по каким критериям ему "показалось".


Ну то есть, вы же критикуете автора, наверное знаете что-то такое, что осталоьтным надо бы знать, а они не знают. Ну не slony I же вы имеете в виду!

Б-же упаси, я никого не критикую! Я доброжелательно интересуюсь, в целях расширения собственного кругозора и кругозора окружающих. Но автор почему-то кругозор расширять не торопится. :(

Опять же, и прочим холиварщикам польза, вот сделают в PostgreSQL 8.5 встроенную репликацию, придётся переписывать сравнения в стиле

Репликация:
[x] MySQL [ ] PostgreSQL (ну есть какие-то там левые slony, но мы их рассматривать не будем)

так хоть можно в этой теме набрать материала будет.
...
Рейтинг: 0 / 0
04.11.2009, 18:46
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36303844
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
В MySQL оптимизатор использует гистограммы распределения значений? А в PostgreSQL?
...
Рейтинг: 0 / 0
11.11.2009, 13:55
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36303953
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Александр Гoлдун wrote:
> В MySQL оптимизатор использует гистограммы распределения значений?

Это на самом деле не так.
В MySQL это реализовано в engine-е, и есть API, на основе
которого ядро узнаёт оценку кол-ва записей для каких=то
критериев. А то, как это сделано -- зависит от конкретного
engine.

А в
> PostgreSQL?

Вроде, использует.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
11.11.2009, 14:25
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36304229
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Александр Гoлдун... оптимизатор использует гистограммы распределения значений ... в PostgreSQL?
да

14.2. Statistics Used by the Planner
...
Рейтинг: 0 / 0
11.11.2009, 15:28
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36343193
LeXa NalBat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LeXa NalBat
Участник
Александр Гoлдун... оптимизатор использует гистограммы распределения значений ... в PostgreSQL?
наткнулся на более подробное описание, последняя глава в документации :)

55.1. Row Estimation Examples
...
Рейтинг: 0 / 0
02.12.2009, 13:13
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36385174
Васек Pg
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Васек Pg
Гость
Arpanxпод Postgres нет удобных инструментов для разработки

это ты откуда взял?

стандартный PgAdmin III
EMS PostgreSQL (Free или полная платная студия)
...
Рейтинг: 0 / 0
24.12.2009, 17:48
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36388492
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
А кто-нибудь может подсказать, как обстоят дела с анализом производительности живых баз в работе для MySQL и PostgreSQL? Нужно что-нибудь типа индекс консультанта в Sybase ASA: он позволяет собрать за какое-то время статистику посылаемых к серверу запросов, проанализировать их эффективность и даже выдает рекомендации по индексам, с указанием эффекта от их создания.
...
Рейтинг: 0 / 0
27.12.2009, 14:01
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36388576
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Александр Гoлдун, oracle, насколько можно верить моему склерозу, такую штуку имеет.
А pgSQL и MySQL - нет. Можно использовать стороннюю приблуду, но я таких не знаю.
В pgSQL с помощью статистики можно определить - используются ли индексы, или они
зря созданы, насчёт MySQL - не знаю.
Ну, и explain analyze рулит, конечно.
...
Рейтинг: 0 / 0
27.12.2009, 15:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36388965
Фотография Александр Гoлдун
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Александр Гoлдун
Участник
То что в оракле есть подобное - я и не сомневаюсь.
Получение плана единичного запроса - это не то, это уже инструмент для детального разбора конкретного запроса. Интересует общий анализ эффективности. Задал вопросы в соотв. форумах - может кто-то что-то подскажет.
...
Рейтинг: 0 / 0
27.12.2009, 22:38
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36389154
klip
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
klip
Гость
Александр Гoлдун, для mysql есть query analyzer и maatkit
...
Рейтинг: 0 / 0
28.12.2009, 07:22
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36560194
JhonyBeGood
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JhonyBeGood
Гость
Интересует мнение какой выбор будет целесообразным при запуске интернет проекта социальной сети на Drupal
MySQL или PostgreSQL ?
и какие особенности (принципиальные различия) характерны для последующего поддержания такой базы данных (в первую очередь финансовые)?

если не затруднит то может кто то сможет привести конкретные примеры уже реализованных проектов
...
Рейтинг: 0 / 0
04.04.2010, 22:13
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36560201
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
JhonyBeGoodИнтересует мнение какой выбор будет целесообразным при запуске интернет проекта социальной сети на Drupal
MySQL или PostgreSQL ?
и какие особенности (принципиальные различия) характерны для последующего поддержания такой базы данных (в первую очередь финансовые)?

если не затруднит то может кто то сможет привести конкретные примеры уже реализованных проектов

Оба будут тормозить при серьезных нагрузках. И плохо масштабироваться:) Целесообразным будет выбор couchdb или чего-то аналогичного.
...
Рейтинг: 0 / 0
04.04.2010, 22:21
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36560266
JhonyBeGood
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JhonyBeGood
Гость
БредJhonyBeGoodИнтересует мнение какой выбор будет целесообразным при запуске интернет проекта социальной сети на Drupal
MySQL или PostgreSQL ?
и какие особенности (принципиальные различия) характерны для последующего поддержания такой базы данных (в первую очередь финансовые)?

если не затруднит то может кто то сможет привести конкретные примеры уже реализованных проектов

Оба будут тормозить при серьезных нагрузках. И плохо масштабироваться:) Целесообразным будет выбор couchdb или чего-то аналогичного.

Ребята, нужен дельный совет ... у меня такое чувство, что от этого сейчас может зависит моя жизнь :)

P.S. "Налево пойдешь - коня потеряешь ... "
...
Рейтинг: 0 / 0
04.04.2010, 23:47
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36560268
Бред
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Бред
Участник
JhonyBeGood
Ребята, нужен дельный совет ...


А-а-а, дельный... Извините, не сообразил:) Забудьте то, что я сообщил:)
...
Рейтинг: 0 / 0
04.04.2010, 23:50
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36560305
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
авторот этого сейчас может зависит моя жизнь
еще одна социальная сеть? подымаем бабло? По-моему, еще даже год назад было понятно, что социальные сети в тупике. Впрочем, не обращайте внимания, я риторически.
...
Рейтинг: 0 / 0
05.04.2010, 00:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36560349
JhonyBeGood
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JhonyBeGood
Гость
kdvавторот этого сейчас может зависит моя жизнь
еще одна социальная сеть? подымаем бабло? По-моему, еще даже год назад было понятно, что социальные сети в тупике. Впрочем, не обращайте внимания, я риторически.
Нет )) здесь исключительно гуманные цели, порабощать мир идиотизмом в них не входит ...
Просто организация площадки для определенного сообщества, его обширность мне сложно оценивать.
А про финансовую сторону спрашиваю из-за ограниченности первоначальных средств, не хочется что бы общая идея загнулась на пол пути из-за неправильного подхода и опрометчивых решений.

P.S. Ведь существуют же и полезные сообщества, к примеру Хабр ...
...
Рейтинг: 0 / 0
05.04.2010, 01:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36563020
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
JhonyBeGood,

Тут
...
Рейтинг: 0 / 0
06.04.2010, 12:27
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36566595
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
ХренОКТОГЕН,

был то он был, да только до версии 7 он был не слишком рабочим. Скажем на той же 6 падение сервера было обычным явлением. Во время copy например.

Еще в первой семерке был противный баг, когда vacuum при стечении определенных обстоятельств зацикливался и и бесконечно создавал временные файлы пока не займут все место на диске (это 2002 год)

Сейчас - да, вполне достойный сервер.
Я бы сказал на данный момент на небольших объемах the first ...
...
Рейтинг: 0 / 0
07.04.2010, 17:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36566648
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
JhonyBeGood

Ребята, нужен дельный совет ... у меня такое чувство, что от этого сейчас может зависит моя жизнь :)

P.S. "Налево пойдешь - коня потеряешь ... "
А направо пойдешь - без парток останешься ;)
Вот и делай выбор.
Тем более с такими вводными данными ИМХО действительно все равно.

PS Прямых рук тебе :) ...

Бред
Оба будут тормозить при серьезных нагрузках. И плохо масштабироваться:) Целесообразным будет выбор couchdb или чего-то аналогичного.
Серьезные нагрузки - это приблизительно сколько?
И масштабирование ... не скажу за Мускул, а вот о Слоне откуда такая информация?
...
Рейтинг: 0 / 0
07.04.2010, 17:26
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36566767
ОКТОГЕН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ОКТОГЕН
Участник
Pure.....,
Ну, наверное, десяток терабайт данных, какой-нибудь портал с 10-20 тысячами пользователей одновременно, которые конкурентно читают и пишут.
...
Рейтинг: 0 / 0
07.04.2010, 18:00
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36566920
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
ОКТОГЕН,

Э-эээ.... Космос нашептывает Postgre :)
...
Рейтинг: 0 / 0
07.04.2010, 19:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36567031
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
ОКТОГЕНPure.....,
Ну, наверное, десяток терабайт данных, какой-нибудь портал с 10-20 тысячами пользователей одновременно, которые конкурентно читают и пишут.

Хех. Если на указанной задаче у топикстартера затык будет исключительно в БД, это не страшно :-)
...
Рейтинг: 0 / 0
07.04.2010, 20:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36567775
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
MBGОКТОГЕНPure.....,
Ну, наверное, десяток терабайт данных, какой-нибудь портал с 10-20 тысячами пользователей одновременно, которые конкурентно читают и пишут.

Хех. Если на указанной задаче у топикстартера затык будет исключительно в БД, это не страшно :-)
Ну он-то по-любому будет считать. что БД виновата...
...
Рейтинг: 0 / 0
08.04.2010, 10:55
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36568113
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Pure.....
Ну он-то по-любому будет считать. что БД виновата...

Скорее, виноватым будет считать того, кто эту СУБД посоветовал

Если серьезно, то любая современная СУБД - от постгреса до эскулайта - успешно работает с БД в десятки гигабайт в многопользовательском сценарии. Притом проблемы-то везде похожие, и только пути решения этих проблем совсем разные для каждой СУБД. И притом в инете множество примеров различных проектов приведено для самых разных СУБД... но чтобы создать свой большой проект, придется много поработать, а не просто почитать презентации.
...
Рейтинг: 0 / 0
08.04.2010, 12:31
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36573451
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
Если серьезно, то любая современная СУБД - от постгреса до эскулайта - успешно работает с БД в десятки гигабайт в многопользовательском сценарии.[/quot]
Вот слово "успешно" я бы убрал ...
...
Рейтинг: 0 / 0
12.04.2010, 10:29
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36573653
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Pure.....Вот слово "успешно" я бы убрал ...

Есть опыт переноса систем с оракла и постгреса на эскулайт, архитектура при этом меняется, но функциональность остается идентичной. Так что с точки зрения конечного пользователя разницы нет. С точки зрения разработчика - чем проще СУБД, тем сложнее разработка, зато и проще администрирование (эскулайт администрирования вообще не требует, хотя временами нужно дописать требуемые в проекте модули, но при установке на нескольких хостах лучше уж один раз дописать, чем годами администрировать). Так что вполне себе успешно.
...
Рейтинг: 0 / 0
12.04.2010, 11:48
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575011
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
MBG С точки зрения разработчика - чем проще СУБД, тем сложнее разработкаСогласен. Просто изобретаем велосипед
MBG зато и проще администрированиеС какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?
MBG скулайт администрирования вообще не требуетЭто просто значит, что для данной задачи дефолтные настройки являются оптимальными.
MBG хотя временами нужно дописать требуемые в проекте модули, но при установке на нескольких хостах лучше уж один раз дописать, чем годами администрироватьСогласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней
...
Рейтинг: 0 / 0
12.04.2010, 19:57
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575305
Фотография Saller
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Saller
Участник
SERG1257MBG зато и проще администрированиеС какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?
Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?
...
Рейтинг: 0 / 0
13.04.2010, 00:45
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575307
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
SERG1257
С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?

Как пример - файловые СУБД работают с правами ФС, и правильно, ибо незачем права и роли дублировать на уровне самой СУБД. При желании можно и ACL для ФС включить, если что-то хитрое нужно. С памятью и диском тоже все легче, т.к. нет гигантских пулов shared memory - пережитков мэйнфреймов.

SERG1257Это просто значит, что для данной задачи дефолтные настройки являются оптимальными.

Что есть в вашем понимании "дефолтовые настройки"? Апстримовская сборка, сборка из моего репозитория, выставляемые приложением параметры? :-) Я говорил про то, что не требуется постоянно настраивать при изменении нагрузки/соотношения типов запросов/объема данных в БД/etc. Пример - при изменении названных величин в постгресе съезжают все планы запросов, что требует периодической перенастройки. Да еще чертов гистерезис при изменении значений параметров.

SERG1257Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней

Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
...
Рейтинг: 0 / 0
13.04.2010, 00:50
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575310
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
SallerSERG1257...
Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?

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

Типичная задача - создать тестовое распределение, обучить планировщик БД на нужном наборе запросов, получить статистику, по которой строятся нужные планы запросов. Как теперь результат обучения тестовой БД перенести на рабочую? В эскулайте просто - сохранить статистику из тестовой и залить в рабочую. А в постгресе, мускуле, и многих других ответ один - никак, им нужен админ, постоянно занимающийся отслеживанием поведения БД и подстройкой. Вот это и входит в стоимость администрирования. Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД. И уж вовсе ни к чему дублировать названные функции в СУБД.
...
Рейтинг: 0 / 0
13.04.2010, 00:59
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575311
Vinny the POOH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vinny the POOH
Участник
MBG,


Как пример - файловые СУБД работают с правами ФС, и правильно, ибо незачем права и роли дублировать на уровне самой СУБД.


А row-level security, например, как делать? Для трёхзвенной архитектуры, конечно, не столь важно, но всё же?

автор
С памятью и диском тоже все легче, т.к. нет гигантских пулов shared memory - пережитков мэйнфреймов.

А куда прикажете кешировать планы запросов, статистику и частоиспользуемые блоки данных? Всецело полагаться на кеш ОС? Он не оптимизирован для этого, нет...

Конечно, для запросов вида SELECT * FROM моя_телефонная_книжка SQLite, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...
...
Рейтинг: 0 / 0
13.04.2010, 01:00
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575333
SERG1257
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SERG1257
Участник
SallerСудя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?Это был ответ на скулайт администрирования вообще не требует
MBG Я говорил про то, что не требуется постоянно настраивать при изменении нагрузки/соотношения типов запросов/объема данных в БД/etcТо есть у вас one size fits all. Один размер на всех. При этом с необходимостью настройки вы согласны.
MBG Пример - при изменении названных величин в постгресе съезжают все планы запросов, что требует периодической перенастройкиЕсли постгресс попытался подстроиться под изменившиеся условия и ошибся то это баг. По-вашему лучше было тупо закрутить все гайки?
MBG Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)?Да я верю, что в вашем велосипеде нечему ломаться.
MBG Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД.А мужики-то не знают.
Я допускаю, что в вашем случае действительно велосипед лучше, чем автомобиль или грузовик.
Я не согласен что велосипед всегда может их заменить но функциональность остается идентичной
...
Рейтинг: 0 / 0
13.04.2010, 02:06
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575359
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
какой полет мысли, а никто не оценил

MBGВ эскулайте просто - сохранить статистику из тестовой и залить в рабочую.
интересно в чем смысл в переносе учитываю нишу и объемы типичной бд sqllite ?
если речь о системной статистики то сгенерить ее от балды позволит оптимизатору генерить более прямые планы. полезность системной статистики собранной с тестового PIII 500Mhz с IDE дисками на 3GHZ xeon с SCSI даже не нулевая, а отрицательная. с исходными от PIII у оптимизатора точно не будет шансов сгенерить хотя бы близкий к оптимальному план.
если речь о статистики таблиц, индексов - то в любой взрослой субд эта статистика собирается автоматом и без вмешательство дба. кстате, в отличие от sqllite взрослая субд имеет сотню механизмов по отслеживанию устаревшей статистики, не говоря уже о отслеживании не оптимальных планов и огромный пласт наворотов вокруг.
тайный смысл в переносе 3 байтов "статистики" для типичной sqllite базы в 3Мб думаю для меня останется загадкой.

MBGДобавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД. И уж вовсе ни к чему дублировать названные функции в СУБД.
глубокая мысль, но к сожалению поражает не глубиной. если оптимизатор лишен знания того, что у него в кеше он тупо не может принять решение какой метод доступа применить к таблице/индексу. план запроса будет отличаться если оптимизатору известно, что в кеше менее 1% нужного индекса от того который будет при знании о том что 99% индекса уже в кеше. я не говорю уже о том, что взрослая субд управляет и дает пользователю управлять объектами в кеше. оракл, например, мелкие таблицы кеширует целиком и не позволяет им выпасть из кеша.
к стате, огромная проблема куцых субд с небогатым набором методов доступа - вымывание кеша. запрос в sqllite читающий большую таблицу тупо забьет кеш оси одной таблицей со всеми вытекающими...

MBGКак пример - файловые СУБД работают с правами ФС, и правильно, ибо незачем права и роли дублировать на уровне самой СУБД.
в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf
...
Рейтинг: 0 / 0
13.04.2010, 03:11
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575375
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Yo.!какой полет мысли, а никто не оценил
Чтобы в полной мере оценить полёт мысли, нужно еще прочитать высказывания этого автора в соседнем топике
Полёт просто ужасающий.

Там у него какие-то катастрофические проблемы для всех СУБД, стоит лишь объёму данных превысить объём ОЗУ. Причём проблемы жуть как неразрешимы.
Здесь у него, видишь ли, любая современная СУБД успешно работает с десятками гигабайт. Причём даже СУБД не нужна.
Там у него с кешированием данных, индексов, распределением памяти, управлением IO и прочей лабудой такие огроменные сложности, что никакие (даже специально для этого созданные) средства БД при поддержке квадратнолобых теоретиков с этим справиться не в состоянии.
Здесь у него те же самые задачи - фи, раз плюнуть, оказывается с этим справляется даже операционная система, не знающая ровным счётом ничего про то, с чем же именно она работает.

Просто диву даёшься, как можно за столь короткое время высказать два диаметрально противоположных суждения, и - апплодисменты - оба раза сказать несусветнейшую чушь

Я не доктор, но товарисчу MGB пора лечиться.
Если это вообще лечится.
...
Рейтинг: 0 / 0
13.04.2010, 04:33
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575713
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
ЛП
Там у него какие-то катастрофические проблемы для всех СУБД, стоит лишь объёму данных превысить объём ОЗУ. Причём проблемы жуть как неразрешимы.
Здесь у него, видишь ли, любая современная СУБД успешно работает с десятками гигабайт. Причём даже СУБД не нужна.
Там у него с кешированием данных, индексов, распределением памяти, управлением IO и прочей лабудой такие огроменные сложности, что никакие (даже специально для этого созданные) средства БД при поддержке квадратнолобых теоретиков с этим справиться не в состоянии.
Здесь у него те же самые задачи - фи, раз плюнуть, оказывается с этим справляется даже операционная система, не знающая ровным счётом ничего про то, с чем же именно она работает.


Если своей головой подумать не хотите, то посмотрите хотя бы, к примеру, зачем оракл использует вспомогательную СУБД (timesten). Будете утверждать, что это решение несуществующих проблем? Или решение проблем, которые запросто можно решить средствами оракл, только его разработчики о том не знают? Хинт: то, что проблема неразрешима средствами самой СУБД, отнюдь не означает неразрешимость в целом.
...
Рейтинг: 0 / 0
13.04.2010, 10:45
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575782
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Vinny the POOH
А row-level security, например, как делать? Для трёхзвенной архитектуры, конечно, не столь важно, но всё же?

Пожалуйста:

The "authorizer" methodThe "authorizer" method provides access to the sqlite3_set_authorizer C/C++ interface. The argument to authorizer is the name of a procedure that is called when SQL statements are being compiled in order to authorize certain operations. The callback procedure takes 5 arguments which describe the operation being coded. If the callback returns the text string "SQLITE_OK", then the operation is allowed. If it returns "SQLITE_IGNORE", then the operation is silently disabled. If the return is "SQLITE_DENY" then the compilation fails with an error.

If the argument is an empty string then the authorizer is disabled. If the argument is omitted, then the current authorizer is returned.

Хоть на уровне ячейки делается проверка доступа.

Vinny the POOH
А куда прикажете кешировать планы запросов, статистику и частоиспользуемые блоки данных? Всецело полагаться на кеш ОС? Он не оптимизирован для этого, нет...

Статистика хранится в системных таблицах, посмотрите тот же постгрес. Планы запросов прекрасно кэшируются на уровне клиентского подключения, глобальный кэш для них не особо полезен. Что касается часто используемых блоков данных то и вовсе - одна из проблем постгреса, в частности, это двойная буфферизация, т.к. постгрес кэширует уже закэшированнные ОС данные. И это проблема почти всех СУБД, исключая разве что оракл на raw device (нет ФС - нет кэша ОС). Так что кэш ОС есть всегда, только СУБД в своем большинстве не умеют им пользоваться. И этот кэш ничуть не хуже кэша СУБД, алгоритмы аналогичные используются (см. lru). Более того, в рэйд-контроллерах есть еще и кэш записи, притом более эффективный, нежели в СУБД и часто используемый совместно с СУБД :-) Это и без рэйд-массива легко проверить - с десктопными дисками 7200 rpm СУБД работает хуже, нежели с чем-то вроде 10 000 rpm raptor, хотя скорость линейного чтения фактически идентична и при идеальном кэшировании и планировании IO в СУБД разницы от более "умного" контроллера диска с большей глубиной очереди быть не должно.

Vinny the POOH
Конечно, для запросов вида SELECT * FROM моя_телефонная_книжка SQLite, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...

Вы пытаетесь доказать логичность и необходимость чего-то самим фактом его существования? Забавно, т.к. это догмат веры, а к логике отношения иметь не может, и обычно выражается как "что боженька пошлет". Задумайтесь хотя бы, сколько различных "навороченных" систем сгинуло за короткий век существования электронной вычислительной техники...
...
Рейтинг: 0 / 0
13.04.2010, 11:06
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36575902
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Yo.!
интересно в чем смысл в переносе учитываю нишу и объемы типичной бд sqllite ?

Припоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ. Для вашего сведения, московский биллинг сотового оператора большой тройки на оракле хранит около 16 терабайт данных и работает на очень мощном "железе". Так что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.

Yo.!
полезность системной статистики собранной с тестового PIII 500Mhz с IDE дисками на 3GHZ xeon с SCSI...

А кто вас заставляет собирать статистику черт знает откуда? Поставьте идентичную машину или даже на рабочей машинке сгенерируйте.

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

Вот огромный пласт наворотов и есть их проблема, т.к. по собранной статистике план запроса однозначно не определяется. Во многих случаях разумнее показать оптимизатору собственные гистограммы, созданные на тестовых данных, нежели крутить настройки, но это-то и не реализовано.

Yo.!
тайный смысл в переносе 3 байтов "статистики" для типичной sqllite базы в 3Мб думаю для меня останется загадкой.

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

Yo.!огромная проблема куцых субд с небогатым набором методов доступа - вымывание кеша. запрос в sqllite читающий большую таблицу тупо забьет кеш оси одной таблицей со всеми вытекающими...

Про двойную буфферизацию в постгресе не знаете? Любой процесс, читающий данные из ФС, для ОС эквивалентен, независимо от функций, в нем реализованных. А вот "тупо забьет кеш оси" это не так, см. реализацию кэша ФС (по крайней мере, в линуксе, других ОС уже лет пять не видел, ничего о них сказать не могу).

Yo.!
в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf

Интересно, а что помешает вирусу "дописать свое тело без разбора во все сетевые файлы, в том числе" файлы данных СУБД? Вы открыли закон природы, по которому испортить файлы таблиц постгреса вирусам запрещено? :-) Если нет, то не давайте прямого доступа к файлам, и не будет их модификации, независимо от того, что это за файлы.
...
Рейтинг: 0 / 0
13.04.2010, 11:37
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576332
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
MBG
Припоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ. Для вашего сведения, московский биллинг сотового оператора большой тройки на оракле хранит около 16 терабайт данных и работает на очень мощном "железе". Так что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.

Интересно, а как обстоят дела с резервированием?

MBG
Про двойную буфферизацию в постгресе не знаете? Любой процесс, читающий данные из ФС, для ОС эквивалентен, независимо от функций, в нем реализованных. А вот "тупо забьет кеш оси" это не так, см. реализацию кэша ФС (по крайней мере, в линуксе, других ОС уже лет пять не видел, ничего о них сказать не могу).

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

Насчет кэша см. например msdn createfile и флаг FILE_FLAG_NO_BUFFERING.

Кстати sqlite без кэша работать просто не умеет. В этом тесте, если откинуть BEGIN TRANSACTION - sqlite работал два часа (а mssql - 10минут).

MBG
Yo.!
в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf

Интересно, а что помешает вирусу "дописать свое тело без разбора во все сетевые файлы, в том числе" файлы данных СУБД? Вы открыли закон природы, по которому испортить файлы таблиц постгреса вирусам запрещено? :-) Если нет, то не давайте прямого доступа к файлам, и не будет их модификации, независимо от того, что это за файлы.[/quot]

В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.
...
Рейтинг: 0 / 0
13.04.2010, 13:29
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576594
Vinny the POOH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vinny the POOH
Участник
Там где-то в соседней ветке чел рассказывал, что у него база в пару терабайт и в пару сотен юзеров болтается на фокспро. Мне его даже как-то жалко стало... А скулайт от фоксбейса идеологически мало чем отличается, разве что к выньтузу гвоздями не прибит.
...
Рейтинг: 0 / 0
13.04.2010, 15:03
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576618
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
MBG
Хоть на уровне ячейки делается проверка доступа.

смешно, какая проверка может быть когда файлы бд торчат наружу (из ФС-сервера) и любой дурачек мимо этого интерфейса поверх файлов бд свой порноархив записать может и это в лучшем случае. в худшем кто-то сообразительней hex-редактором изменит пару строк не оставив никаких следов со всеми вытекающими.

MBG
Так что кэш ОС есть всегда, только СУБД в своем большинстве не умеют им пользоваться. И этот кэш ничуть не хуже кэша СУБД, алгоритмы аналогичные используются (см. lru).
о! а мусье случайно располагает данными сколько времени нужно средней субд, чтоб научится пользовать кеш ?
тут недавно Кайт приезжал, нужно было ему рассказать какие глупые в оракле, нет бы примитивный lru пользовать, нет блин напридумывали патентованых алгоритмов и стратегий удержания блоков. а вон sqllite гигабайтами ворочает, а мы не знали

MBGПрипоминается мне одна система на эскулайт, состоящая из кластера 10-ти ксеонов с 32 ГБ ОЗУ каждый, на которых крутятся in-memory эскулайт БД как раз размером в эту ОЗУ.
точно, помню тоже администрил такой кластер на фокспро, помню первый dbf был у тети клавы, второй у петровича, а вот третий не помню, но в принципе архитектура кластера примерна та же.
вот так задумаешся - сколько лет прошло, а кто-то это еще хавает

MBGТак что вот не надо заявлять, что мол БД на треть терабайта это такая мелочь, что не заслуживает внимания. У меня пока не возникало потребностей работать с БД более нескольких десятков Гб размером, хотя тестирую проекты обычно на БД в 10 раз больших, нежели их планируемый рабочий размер. т.е. до сотен Гб.
ясно, как докуришь, идешь заменять блинг большой тройки на sqllite

MBGА кто вас заставляет собирать статистику черт знает откуда? Поставьте идентичную машину или даже на рабочей машинке сгенерируйте.
да блин заказчики чертовы - наркотой не балуются, а без наркоты пока не удается развести на идентичную боевой. все суют под девелоперские задачи пятигодовалый хлам :(

MBGЕсли нужно, чтобы ехало, а не шашечки, то для БД от гигабайта до десятков гигабайт вполне хватает эскулайта (уточняю - для нескольких тысяч одновременных пользователей).
так и встало перед глазами - тысяча пользователей одновременно третью неделю пытаются вытянуть с файл-сервер гигобайтовый индекс, чтоб достать три строки из 10 гб, звонят админу и тот предлагает заменить гигобайтовый свич на интеконект тогда вся тысяча сможет получить три строки всего за неделю

устал
но настроение на весь день, спасибо !
...
Рейтинг: 0 / 0
13.04.2010, 15:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576684
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Siemargl
Интересно, а как обстоят дела с резервированием?
У кого как. У меня лично - утилита sqlite3-rdiff Для синхронной репликации тоже можно сделать, просто руки не дошли пока, не было надобности.

Siemargl
Кстати sqlite без кэша работать просто не умеет. В этом тесте, если откинуть BEGIN TRANSACTION - sqlite работал два часа (а mssql - 10минут).

Вы разеные режимы смотрите - в эскулайте у вас автокоммит с fsync. Отключите fsync и получите желаемую шустрость.

Siemargl
В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.

Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.
...
Рейтинг: 0 / 0
13.04.2010, 15:43
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576688
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Vinny the POOHА скулайт от фоксбейса идеологически мало чем отличается, разве что к выньтузу гвоздями не прибит.
Блин, а я то думаю, чего меня так и тянет этого аффтара назвать фокспрошником. Аж боялся обидеть человека.
А оно вона как.
...
Рейтинг: 0 / 0
13.04.2010, 15:43
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576700
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Yo.!
смешно, какая проверка может быть когда файлы бд торчат наружу (из ФС-сервера) и любой дурачек мимо этого интерфейса поверх файлов бд свой порноархив записать может и это в лучшем случае. в худшем кто-то сообразительней hex-редактором изменит пару строк не оставив никаких следов со всеми вытекающими.
...


У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
...
Рейтинг: 0 / 0
13.04.2010, 15:49
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576749
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
MBG
У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
нет, лично у меня применение фс-субд в 21 веке тождественно умственной неполноценности применяющего, не зависимо какими интерфейсами пытаются прикрыть убогость этой фс-субд. упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...
...
Рейтинг: 0 / 0
13.04.2010, 16:01
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36576835
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Yo.!упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...
Дык тут даже простоты не наблюдается - лишний слой городить на ровном месте.
Несмотря на то, что трёхзвенки это хорошо и правильно - нужны они вовсе не для того, чтобы родовые травмы прикрывать

А так да, бегал тут помнится Sergey Ch, с криками "фокспро плюс веб-сервисы - ничуть не хуже, а может быть даже и лучше, чем всё остальное вместе взятое"
...
Рейтинг: 0 / 0
13.04.2010, 16:37
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577145
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
MBG

SERG1257Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней

Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)
...
Рейтинг: 0 / 0
13.04.2010, 18:08
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577323
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Pure.....MBG
...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)

Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.
...
Рейтинг: 0 / 0
13.04.2010, 19:21
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577331
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Yo.!MBG
У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
нет, лично у меня применение фс-субд в 21 веке тождественно умственной неполноценности применяющего, не зависимо какими интерфейсами пытаются прикрыть убогость этой фс-субд. упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...

Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.
...
Рейтинг: 0 / 0
13.04.2010, 19:24
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577343
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
MBGPure.....MBG
...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)

Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.
Добро пожаловать на tpc.org
...
Рейтинг: 0 / 0
13.04.2010, 19:33
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577347
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
MBGYo.!MBG
У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
нет, лично у меня применение фс-субд в 21 веке тождественно умственной неполноценности применяющего, не зависимо какими интерфейсами пытаются прикрыть убогость этой фс-субд. упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...

Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.
ваще дурак
BerkeleyDB назвать ФС.
in-memory database приплести.
срочно санитаров

чего еще там в списке "файловых субд"?
ржунимагу
...
Рейтинг: 0 / 0
13.04.2010, 19:38
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577364
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
MBG
Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.

http://www.sqlite.org/whentouse.htmlSQLite uses reader/writer locks on the entire database file. That means if any process is reading from any part of the database, all other processes are prevented from writing any other part of the database. Similarly, if any one process is writing to the database, all other processes are prevented from reading any other part of the database.
слабо представляю кому понадобится тестировать вот это для задач решаемых взрослыми субд.

MBGБедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.
хи-хи, по вашему это покупалось на замену ораклу ?
боже, до меня только, что дошло - последним покался innodb, значит именно он заменит все субды оракла разом
...
Рейтинг: 0 / 0
13.04.2010, 19:55
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577602
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
MBGSiemargl
Интересно, а как обстоят дела с резервированием?
У кого как. У меня лично - утилита sqlite3-rdiff Для синхронной репликации тоже можно сделать, просто руки не дошли пока, не было надобности.

Если на ходу сдохнет сервер биллинга с 32Гб незаконченных транзакций, сколько ж это будет в невзятых деньгах с клиентов?? :-)

MBG
Siemargl
В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.
Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.
Это на линухе. На винде, где я живу, такой фокус без прибития процессов не пройдет=)

2ЛП. А что же такое БерклиДБ, по Вашему ? )

Йо! К сожалению, Оракл в каждую дырку не засунешь - не пролезет, как тот Винни-Пух =) Файловые БД имеют свою нишу в эмбеддед ~
...
Рейтинг: 0 / 0
13.04.2010, 23:36
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577640
Vinny the POOH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vinny the POOH
Участник
Siemargl
Это на линухе. На винде, где я живу, такой фокус без прибития процессов не пройдет=)


Имея рутовый пароль к чему угодно, прибить процессы особо то никто и не мешает. Да и жизненно важные сервисы на венде никто не держит, разве что полные извращенцы. Идеология всей системы ущербна, сколько костылей на неё ни вешай.
...
Рейтинг: 0 / 0
14.04.2010, 00:38
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577645
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Vinny the POOH,

Может и ущербна. Но не так много людей точно знают места ущербности =) Особенно с серверной стороны. А скорость подтянули за 10 лет.
...
Рейтинг: 0 / 0
14.04.2010, 00:48
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577658
Vinny the POOH
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vinny the POOH
Участник
SiemarglVinny the POOH,

Может и ущербна. Но не так много людей точно знают места ущербности =) Особенно с серверной стороны.

Не многие знают, но кто знает - использует на всю мощь, ворочая многомиллионными ботнетами. "Серверная" от "клиентской" отличаются лишь ценой, комплектом "ПО" и дефолтными настройками. Ядро - одно и то же. Ядро и всякие КОМы, Tridentы и прочий дырявый шлак, запиленный в него намертво - везде одни и те же. Недаром ведь по моей статистике 90% спама прёт либо с вендовых затрояненных вендовых машин либо с затрояненных же вендовых серваков. Недаром же все знакомые сотрудники датацентров лютой ненавистью ненавидят вендовые колокейшн-сервера из-за того, что с ними больше всего гымора в плане перезагрузок и блокировок в связи с нивротъибенным спам-трафиком.

А скорость подтянули за 10 лет.
Не скорость подтянули, а аппаратные мощности. Скорость упала на несколько порядков: попробуйте-ка поставить какой-нить 2008R2 на железо 2004 года выпуска? Оно там хоть заведётся? А Линукс 2009 года - не просто заводится, а держит достаточно неплохую нагрузку, и не требует внимания ровно до первого отказа железа. Какая венда способна таким похвастаться? А какая венда может похвастаться тем, что она управляет котлами, разводными мостами, авиационными диспетчерскими станциями, ядерными реакторами?... Да блин, задолбали эти споры. Непригодна венда к серьёзным ТЕХНОЛОГИЧЕСКИМ задачам, и всё тут. Да, как игровая приставка - самая идеальная система, для этого она и делалась. Сидели бы M$ в своей нише игр и мультимедиа - всем бы щастье было, это у них хорошо выходит. Но нет же - полезли в корп.сектор, и наделали мегатонны геммороя, за что им - лучи ненависти.

Эх простите, если кого обидел, но просто не могу я, блин, читать весь этот гнусный пеар венды и вендорешений как "надёжных" и "недорогих" средств организации корпоративной инфраструктуры. Ложь и ересь, причем от начала и до конца. А я, блин, правду люблю.
...
Рейтинг: 0 / 0
14.04.2010, 01:21
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577665
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Vinny the POOHА какая венда может похвастаться тем, что она управляет котлами, разводными мостами, авиационными диспетчерскими станциями, ядерными реакторами?
Можете смеяться, именно этим я и занимаюсь.
И кроме того, нет для этого систем, кроме винды. Для OS/2 последняя SCADA померла 3 года назад, для QNX домирает. Для остального и не было.
Не знаете, так не {звез}$%ъдите.
...
Рейтинг: 0 / 0
14.04.2010, 01:41
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577666
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
А насчет недорогих соглашусь. Дорого тут все. Аппаратное резервирование только чего стоит. И перспективы удешевления пока нетути :)~
...
Рейтинг: 0 / 0
14.04.2010, 01:44
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36577690
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 Siemargl
2ЛП. А что же такое БерклиДБ, по Вашему ? )
Обычная нереляционная embedded субд
Отнести её к файл-серверным, при том что там вроде как даже сетевого кода нет ни грамма - это надо очень извращенной фантазией обладать.

К сожалению, Оракл в каждую дырку не засунешь - не пролезет, как тот Винни-Пух =) Файловые БД имеют свою нишу в эмбеддед ~
Это не файл-серверные СУБД имеют свою нишу в embedded.
Это embedded имеют свою нишу. Локальные однопользовательские базы данных сложностью чуть выше телефонной книжки. А уж ФС в эту нишу как могут влезают. Потому как нигде больше все эти аксесы, фокспры, и т.п. - просто нафиг не нужны.

И никто не хочет пихать в эту дырку оракл. Пусть бы в этой дырке сидели специально созданные для этой дырки embedded и нашедшие там свой последний приют ФС. Однако ж нет, выползают выползни со своими адептами-мозговыми слизнями, хотят захватить весь мир. Можно ли остановить выползание выползней из дыры - тот еще вопрос. Взять в руки окуенную хиянку, и хотя бы даже и ораклом дыру наглухо заколотить. Жалко конечно оракл, но ведь для дела.

----------------------

2 Vinny the POOH
Не скорость подтянули, а аппаратные мощности. Скорость упала на несколько порядков: попробуйте-ка поставить какой-нить 2008R2 на железо 2004 года выпуска? Оно там хоть заведётся? А Линукс 2009 года - не просто заводится, а держит достаточно неплохую нагрузку, и не требует внимания ровно до первого отказа железа. Какая венда способна таким похвастаться?
Линуксы со своими гламурными кедами и прочей эпидерсией по прожорливости обогнал уже даже висту. Чего, как мне казалось раньше, сделать невозможно в принципе.
А 2008R2 таки запускается и шустренько шуршит на весьма говённеньком железе.
Так что, как уже сказали - не знаете, так не {звез}$%ъдите.

Да блин, задолбали эти споры. Непригодна венда к серьёзным ТЕХНОЛОГИЧЕСКИМ задачам, и всё тут.
Вы абсолютно правы. Непригодна. И именно по этому на рынке серверов - решения на вындоузе в прошлом году схавали кажется этак процентов 75 продаж, если считать в штуках проданных серверов (в деньгах поменьше, ибо бесплатные линуксы дороже продаются, как ни странно).

Сидели бы M$ в своей нише игр и мультимедиа - всем бы щастье было, это у них хорошо выходит.
Сидели бы юнихи, линухи, и прочая занимательная педерастия в своей нише высокопроизводительных серверов - и всем щастье было бы. У них это хорошо получается. Нет же, лезут куда-то на десктопы, с криками "теперь и под линухом можно читать книжки, смотреть киношки, лазить по интернетам, читать почту, вах как круто, всё что нужно для домашнего пользования".
Тьфу на эту занимательную педерастию с пингвиньим лицом. Тьфу на неё еще раз.
...
Рейтинг: 0 / 0
14.04.2010, 04:03
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578428
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
ЛП2 Siemargl
2ЛП. А что же такое БерклиДБ, по Вашему ? )
Обычная нереляционная embedded субд
Отнести её к файл-серверным, при том что там вроде как даже сетевого кода нет ни грамма - это надо очень извращенной фантазией обладать.

С какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.

P.S. А эмбеддед клиент-серверных не бывает, как упыря.
...
Рейтинг: 0 / 0
14.04.2010, 13:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578456
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
MBGС какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.
Ждал этого вопроса
И что же такое "файловые СУБД"?
БД, которые хранят данные в файлах?
Дык они все там данные хранят. За редкими исключениями (кои умеют хранить данные прямиком на сырых партишенах, безо всяких там файлов).
Даже не к ночи упомянутые in-memory таки файлы используют, да.
Эксель - файловая БД?

В принципе конечно под "файловыми СУБД" можно понимать СУБД-нашлёпки поверх файловых систем (здрасть, товарисч Siemargl со своей Кэтрин). Здравые мысли в таком подходе есть. Но к упомянутой BerkeleyDB оно опять таки никакого отношения не имеет.
...
Рейтинг: 0 / 0
14.04.2010, 13:28
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578508
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Siemargl
Если на ходу сдохнет сервер биллинга с 32Гб незаконченных транзакций, сколько ж это будет в невзятых деньгах с клиентов?? :-)


Что-то много у вас незавершенных транзакций, коммитьте пакетно, раз система не справляется. А по теме - у меня система сбора данных распределенная, если один хост упадет, это не беда; даже если все упадут, есть парсер логов, зальем асинхронно, т.к. основа распределенная, дубликаты игнорируются автоматически. Собственно, кое-что у меня в блоге описано, например, здесь:
Утилиты телефонного биллинга

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

Siemargl
Это на линухе. На винде, где я живу, такой фокус без прибития процессов не пройдет=)


И процессы прибьем. Любой мало-мальски современный вирус еще не то умеет - справляется с десятками антивирусов и файрволов, маскируется, прописывается в реестр и т.п. - и файлы ваших БД повредить сможет, не рассчитывайте его "напугать" блокировками.
...
Рейтинг: 0 / 0
14.04.2010, 13:42
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578550
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
ЛП
Линуксы со своими гламурными кедами...

КДЕ и под винды давно работает (с версии 4.0), причем тут линукс? :-)
...
Рейтинг: 0 / 0
14.04.2010, 13:59
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578572
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
MBG,

Я не придираюсь. Вспомнились времена, когда у сотовых операторов на Новый Год биллинг дох. И до выхода на работу их Айтишников все было бесплатно )

В любом случае, чем меньше писать руками, тем лучше.

Деньги заказчиков считать не будем. Если сами решат, что тиражное изделие в эксплуатации даст больший эффект, чем самописный кластер, то так тому и быть. Уж больно дорогое время простоя может оказаться. См.пример про Н.Г.

MBGP.S. А эмбеддед клиент-серверных не бывает, как упыря.
А FB Embedded ? )))

Про проблемы в безопасности Windows можно начать забывать, особенно в серверах. Начиная с Висты/2008. Оставшаяся дыра в OLE эволюционно вытесняется вполне безопасным дотнетом.
...
Рейтинг: 0 / 0
14.04.2010, 14:07
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578634
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
ЛПMBGС какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.
Ждал этого вопроса
И что же такое "файловые СУБД"?


Представляют собой библиотеки доступа к файлам, простейший вариант - к flat-файлам. Эмбедед - когда вдобавок исполняются в адресном пространстве приложения, т.е. обычные динамические библиотеки или вкомпилированы непосредственно в приложение. Берклидб или эскулайт - это библиотеки, а не сервера или приложения. Под виндой есть существенная разница между доступом к локальным и удаленным файлам, потому и появился подкласс "файл-серверных" (когда файлы БД физически размещаются на удаленной машине), и подкласс эмбеддед (файлы БД доступны локально). В других ОС работа с удаленными и локальными файлами полностью идентична и понятие "файл-серверный" лишено смысла, так что файловые и эмбеддед принципиально не отличаются.

http://ru.wikipedia.org/wiki/Система_управления_базами_данныхФайл-серверные
В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть.

Встраиваемые
Встраиваемая СУБД — библиотека, которая позволяет унифицированным образом хранить большие объёмы данных на локальной машине.

В линуксе, план9 и многих других ОС эти определения бесполезны. Как пример, у меня на ноутбуке сейчас примонтированы файловые системы пары серверов и я работаю с их файлами как с локальными, хотя один из указанных серверов находится от меня за полстраны. И эмбеддед СУБД эскулайт, запущенная в процессе на моей машине, может оперировать данными, физически расположенными в Москве или Нью-Йорке или с теми и другими одновременно.

Добавив к файловым СУБД сетевой интерфейс, получим клиент-серверные. Например, sqlite + sqlrelay - это уже клиент-серверная СУБД. Соответственно, используя свой сервер приложений плюс эмбеддед СУБД, мы получаем решение, полностью заменяющее клиент-серверные СУБД, а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.
...
Рейтинг: 0 / 0
14.04.2010, 14:30
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578683
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 MBG
Под виндой есть существенная разница между доступом к локальным и удаленным файлам, потому и появился подкласс "файл-серверных" (когда файлы БД физически размещаются на удаленной машине), и подкласс эмбеддед (файлы БД доступны локально).
Чушь.
Файл-серверные СУБД появились задолго до винды.
Равно как и клиент-серверные.
Равно как и встраиваемые.
Идите хоть историю поучите, раз уж с информатикой не сложилось.

В других ОС работа с удаленными и локальными файлами полностью идентична и понятие "файл-серверный" лишено смысла, так что файловые и эмбеддед принципиально не отличаются.
Чушь.
Какой-нибудь Filemaker бррр под MacOS при всём желании не назвать embedded. Самое что-ни на есть файл-серверное уродство.

Добавив к файловым СУБД сетевой интерфейс, получим клиент-серверные.
Три раза чушь. Даже комментировать нечего.
...
Рейтинг: 0 / 0
14.04.2010, 14:47
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578696
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
MBG,

почитал блог, я правильно понял архитектуру ? я понял, что АТС пишет данные звонков в файлик на фс-сервере, параллельно по некому протоколу (tcp?) передает эти же данные в программу-коллектор. программа коллектор блокирует всю бд sqllite на любой доступ (в том числе и на чтение) и заливает пачку данных, после этого отпускает блокировку бд и бд "захватывает" следующий коллектор. так продолжается весь месяц, а с первого числа коллекторы начинают писать уже в новую бд, позволяя теперь "билинговать" старую бд, в которую уже ничего не пишется.
как-то не понятно как при таком раскладе хотя бы лимиты на звонки учитывать.
...
Рейтинг: 0 / 0
14.04.2010, 14:55
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578913
Фотография roden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
roden
Участник
MBGа за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.
Типа SQlite на локальных машинах круче всех?
...
Рейтинг: 0 / 0
14.04.2010, 16:25
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36578941
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Yo.!MBG,

почитал блог, я правильно понял архитектуру ? я понял, что АТС пишет данные звонков в файлик на фс-сервере, параллельно по некому протоколу (tcp?) передает эти же данные в программу-коллектор. программа коллектор блокирует всю бд sqllite на любой доступ (в том числе и на чтение) и заливает пачку данных, после этого отпускает блокировку бд и бд "захватывает" следующий коллектор. так продолжается весь месяц, а с первого числа коллекторы начинают писать уже в новую бд, позволяя теперь "билинговать" старую бд, в которую уже ничего не пишется.
как-то не понятно как при таком раскладе хотя бы лимиты на звонки учитывать.

Программа-коллектор опрашивает набор АТС одного типа, преобразует данные и пишет в едином формате в in-memory SQLite базу (кроме того, с АТС можно "сырые" данные в текстовые логи писать, если это так, то коллектор может эти данные отпарсить, если их "скормить" ему на stdin). Раз в N секунд каждый коллектор (число коллекторов равно числу типов АТС) пакетно заливает данные в дисковую SQLite базу, блокируя ее на время порядка десятков миллисекунд. Биллингатор работает с этой же базой одновременно с коллекторами. В итоге при десятке подключенных АТС и онлайн биллинговании база блокируется менее чем на 100 миллисекунд каждую секунду, так что блокировки никому не мешают. По истечению месяца база перестает изменяться и ее можно скинуть в архив на рид-онли носитель, удалить и т.п. (если основной биллинг и просмотр отчетов на разных хостах, то старые БД биллингу не нужны; притом, всегда можно восстановить старые периоды, скопировав БД с архивных носителей).

В общем-то, такая технология шардинга аналогична использованию табличных пространств, но намного удобнее в администрировании. Администратор СУБД для описанной системы вовсе не нужен, все автоматизировано. Плюс скорость работы системы сохраняется, независимо от объема данных (т.к. данные разделены по месяцам, нет разницы, хранятся данные за 1 месяц или за 100).
...
Рейтинг: 0 / 0
14.04.2010, 16:33
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579000
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
rodenMBGа за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.
Типа SQlite на локальных машинах круче всех?

Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов. Например, простой селект в эскулайте выполняется за десятки или сотни микросекунд, что и не снилось клиент-серверам (которым надо обеспечить конкурентный доступ, общий кэш, набор препаред запросов, передать данные по сети, а клиент должен эти переданные данные еще и разобрать...). Открытие соединения за время около 100 микросекунд тоже недостижимо для клиент-серверной технологии (частично решается пулами соединений, но это ухудшает возможности многопоточного чтения).

В тех случаях, когда нужно предоставить клиентам веб-интерфейс, зачастую нет смысла лишний уровень городить, да еще через tcp/ip, когда можно прямо из application server получить доступ к данным с помощью встраиваемых СУБД. Разумеется, есть и свои проблемы у последних - скажем, сложно обеспечить поддержку длительных транзакций, но для веб-приложений, тем более, использующих ajax, это просто не требуется. Клиент-серверы хороши именно для тех задач, где пользователи подключаются к терминалам и вручную выполняют запросы, зачастую продолжительные, - но со времен мэйнфреймов такой сценарий работы стал весьма экзотическим (да и для клиент-серверов сейчас почти всегда для запросов, занимающих минуты/дни/часы, создают отдельное хранилище данных, доступное лишь в режиме рид-онли).
...
Рейтинг: 0 / 0
14.04.2010, 16:47
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579246
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
MBGЭскулайт, берклидб и подобные на порядки быстрее клиент-серверов
что то это сильно мне напоминает это, только наоборот )))))))

Как дошло до тестов, проявляющих поведение в рабочих условиях, так сразу отступные речи...
...
Рейтинг: 0 / 0
14.04.2010, 18:34
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579316
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
SiemarglMBGЭскулайт, берклидб и подобные на порядки быстрее клиент-серверов
что то это сильно мне напоминает это, только наоборот )))))))

Как дошло до тестов, проявляющих поведение в рабочих условиях, так сразу отступные речи...

Там тесты однозначно показали, что ваш хэш массив в ОЗУ работает медленнее дисковой базы эскулайт. Что касается рабочей архитектуры, я несколько раз указывал, что основным ограничением является необходимость пакетной вставки данных для дисковой БД, из-за ограничений оборудования при использовании fsync. Можно отключить fsync и тогда нет нужды именно в пакетной вставке, но целостность БД нужно обеспечить внешними средствами (например, с помощью логирующей ФС или репликации). В обсуждаемом биллинге реализована именно вышеназванная техника пакетной вставки и многопоточного чтения, коды коллекторов можно в моем открытом деб-репозитории посмотреть.

Также периодически напоминаю об ограничениях на размер индексов и т.п. И тесты публикую - как можно нарваться на проблемы на миллионе записей и как можно получить высокое быстродействие на миллиарде записей. Иначе и молотком можно лоб расшибить, если пользоваться не умеете.
...
Рейтинг: 0 / 0
14.04.2010, 19:15
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579472
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
долго пытался воткнутся как с таким убожеством можно что-то онлайн провернуть, решил копнуть и наткнулся на чудесный документ с гордым названием "Техническое описание программы MBG Биллинг". данное ТЗ поражает не сколько проработанностью, сколько техническими решениями авторов.

онлайн биддинг:
интернет услуги2.1.2 Приостановление использования клиентом услуг Компании при отрицательном балансе (проверка баланса 1 раз в месяц).
2.2.3 Приостановление использования клиентом услуг Компании при отрицательном балансе (проверка баланса 1 раз в день).

телефонная связь 3.1.3 Пересчет денежного баланса клиента в зависимости от стоимости полученных им услуг Компании, рассчитанной в соответствии с установленными тарифами и зоны разговора (выполняется 1 раз в день или 1 раз в час).
3.1.4 Приостановление использования клиентом услуг Компании при отрицательном балансе (проверка баланса 1 раз в день или 1 раз в час).


Примечания по реализации:
примечания
4. Интернет-трафик агрегировать
4.1 по часам трафик по клиенту (база stat_yy_mm.db)
4.2 по дням по клиенту (база stat.db)
4.3 по дням по хосту и клиенту (база stat_yy_mm.db)
4.4 по месяцам по клиенту (база stat.db)


занавес.
...
Рейтинг: 0 / 0
14.04.2010, 22:12
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579516
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Yo.!,

Это что, у Оракла есть шанс отбить клиента, да?

ЗЫ. У нас биллинг с "мгновенным" перерасчетом дэдлочится (на Ора) периодически.
...
Рейтинг: 0 / 0
14.04.2010, 23:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579524
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
навеяло
http://www.youtube.com/v/wMV6XIHjt2E
...
Рейтинг: 0 / 0
14.04.2010, 23:27
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579530
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
Siemargl
Это что, у Оракла есть шанс отбить клиента, да?

в смысле шанс ? промышленные билинги бывают на чем то кроме оракла ?
...
Рейтинг: 0 / 0
14.04.2010, 23:31
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579537
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 MBG
В тех случаях, когда нужно предоставить клиентам веб-интерфейс, зачастую нет смысла лишний уровень городить, да еще через tcp/ip, когда можно прямо из application server получить доступ к данным с помощью встраиваемых СУБД.
Хосспадя, зачем вам какой-то там аппликейшн сервер, если вы элементарных вещей не понимаете?
Смешались в кучу кони, люди...
Вам противопоказано выходить куда-либо за уровень однозвенных однослойных приложений "всё в одном".
ТелефоннаяКнижка.mdb - уровень встраиваемых субд. Ваш тоже.

Разумеется, есть и свои проблемы у последних - скажем, сложно обеспечить поддержку длительных транзакций, но для веб-приложений, тем более, использующих ajax, это просто не требуется.
Это ж какая каша должна быть в голове, чтоб такое написать.
Как может необходимость (или отсутствие необходимости) в длительных транзакциях зависеть от какой-то там технологии частичного обновления клиентской хтмл-странички?
Хорошо хоть не от цветовой гаммы пользовательского интерфейса длительность транзакций зависит.

Клиент-серверы хороши именно для тех задач, где пользователи подключаются к терминалам и вручную выполняют запросы, зачастую продолжительные
Ага. Штекер мозг, лопату в руки, и вперёд, вручную запросы исполнять

для клиент-серверов сейчас почти всегда для запросов, занимающих минуты/дни/часы, создают отдельное хранилище данных, доступное лишь в режиме рид-онли
Правда что-ли?
А мужики то и не знают.
...
Рейтинг: 0 / 0
14.04.2010, 23:39
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579545
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
ЛП, извини, но такие посты я буду тереть - ни конкретики, ни юмора, одни обращения к личности

теряешь квалификацию :)
...
Рейтинг: 0 / 0
14.04.2010, 23:49
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579559
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
SergSuper, ну как можно бред комментировать...
Какую конкретику тут можно ожидать, сам подумай.
На что конкретику? На вот это вот "для клиент-серверов сейчас почти всегда для запросов, занимающих минуты/дни/часы, создают отдельное хранилище данных, доступное лишь в режиме рид-онли" что-ли?
Хочешь тереть - твоё право.
Но лучше форум от этого бредогенератора очисти.
...
Рейтинг: 0 / 0
15.04.2010, 00:05
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579567
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Ладно старые черепахи, прочитают, ужаснутся, посмеются.
А неопытные бойцы всю эту чухню прочитают и быть может даже поверят.
...
Рейтинг: 0 / 0
15.04.2010, 00:14
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579598
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Yo.!долго пытался воткнутся как с таким убожеством можно что-то онлайн провернуть, решил копнуть и наткнулся на чудесный документ с гордым названием "Техническое описание программы MBG Биллинг". данное ТЗ поражает не сколько проработанностью, сколько техническими решениями авторов.

Что-то у вас со зрением - там написано Техническое задание. И это далеко не худшее ТЗ, с которым нам доводилось работать.

P.S. А вы когда-нибудь живого заказчика видели? Если вас это ТЗ так пугает...
...
Рейтинг: 0 / 0
15.04.2010, 01:11
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579621
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
MBG
Что-то у вас со зрением - там написано Техническое задание.
а если присмотреться ? ;)
http://mobigroup.ru/billing.html
MBG
И это далеко не худшее ТЗ, с которым нам доводилось работать.

как говориться кому и кобыла невеста ...
...
Рейтинг: 0 / 0
15.04.2010, 02:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579635
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
Блин, я понял.

Невнятные библиотеки доступа.
Самые быстрые, а все ваши ораклы это медлено и плохо.
Перелопачивание тонн фигни в оперативке.
А что не влезет в оперативку, то столкнётся с неразрешимыми проблемами.
Которые только средствами оси можно решить.
Кластеры из плюшевых софтин.
В конце концов, предметная область - многострадальный биллинг.

Это очередной виток TJ7.
...
Рейтинг: 0 / 0
15.04.2010, 02:51
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36579767
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
Yo.!Siemargl
Это что, у Оракла есть шанс отбить клиента, да?

в смысле шанс ? промышленные билинги бывают на чем то кроме оракла ?
Биллинг на СУБД Caché.
...
Рейтинг: 0 / 0
15.04.2010, 09:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36580579
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Yo.!
а если присмотреться ? ;)
http://mobigroup.ru/billing.html

Файлик-то откройте :-) Если хотите увидеть результат работы - sudo aptitude install ... из нашего репозитория коллекторы и еще кое-что. Хотите поговорить предметно - делаете тесты, присылаете и мы их обсуждаем.
...
Рейтинг: 0 / 0
15.04.2010, 14:08
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36607613
Фотография roden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
roden
Участник
MBGrodenMBGа за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.
Типа SQlite на локальных машинах круче всех?

Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов. Например, простой селект в эскулайте выполняется за десятки или сотни микросекунд, что и не снилось клиент-серверам (которым надо обеспечить конкурентный доступ, общий кэш, набор препаред запросов, передать данные по сети, а клиент должен эти переданные данные еще и разобрать...). Открытие соединения за время около 100 микросекунд тоже недостижимо для клиент-серверной технологии (частично решается пулами соединений, но это ухудшает возможности многопоточного чтения).
И прямо таки есть соответствующие тесты? Реально sqlite работает быстрее любой СУБД с клиент-серверной архитектурой?
...
Рейтинг: 0 / 0
30.04.2010, 14:47
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36607644
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
roden
И прямо таки есть соответствующие тесты? Реально sqlite работает быстрее любой СУБД с клиент-серверной архитектурой?

Ну канешна :)
Особенно на конкурентных update-ах
...
Рейтинг: 0 / 0
30.04.2010, 14:57
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36607800
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
rodenMBGroden
Типа SQlite на локальных машинах круче всех?

Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов. Например, простой селект в эскулайте выполняется за десятки или сотни микросекунд, что и не снилось клиент-серверам (которым надо обеспечить конкурентный доступ, общий кэш, набор препаред запросов, передать данные по сети, а клиент должен эти переданные данные еще и разобрать...). Открытие соединения за время около 100 микросекунд тоже недостижимо для клиент-серверной технологии (частично решается пулами соединений, но это ухудшает возможности многопоточного чтения).
И прямо таки есть соответствующие тесты? Реально sqlite работает быстрее любой СУБД с клиент-серверной архитектурой?
Реально эскулайт может работать быстрее ... :)
А вот насчет сравнения с клиент-серверами .... ну скажем сомневаюсь я насчет всех (и то если мягко сказать)
...
Рейтинг: 0 / 0
30.04.2010, 16:10
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36608070
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
roden
И прямо таки есть соответствующие тесты?

Конечно. Как пример:
http://geomapx.blogspot.com/2009/09/sqlite-3617-mobigroup2.html
http://geomapx.blogspot.com/2010/01/sqlite-fts3.html
http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-3620-in-real.html

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

rodenРеально sqlite работает быстрее любой СУБД с клиент-серверной архитектурой?

Я вам не скажу за всю галактику - не в курсе насчет возможностей СУБД на Альдебаране :-)
...
Рейтинг: 0 / 0
30.04.2010, 18:58
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36608079
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Gluk (Kazan)roden
И прямо таки есть соответствующие тесты? Реально sqlite работает быстрее любой СУБД с клиент-серверной архитектурой?

Ну канешна :)
Особенно на конкурентных update-ах

Ну-ну, громкие слова не аргумент.

Давайте немного посчитаем: на винте 10 000 RPM мы запросто можем выполнять 100 модифицирующих транзакций в секунду, полагая каждую транзакцию добавляющей всего лишь 100 байт (включая служебные данные, т.е. рассматриваем занятое дисковое пространство), получаем скорость роста БД 10 килобайт в секунду или, при 8-ми часовом рабочем дне (берем по минимуму) с пиковой нагрузкой, в корень из двух раз превышающей среднюю, 100 МБ в сутки или 30 ГБ в год. Срок хранения данных обычно не менее 3-х лет, за это время БД вырастет до 100 ГБ. Это оценка для обычного жесткого диска, причем без потребности в конкурентных апдейтах. Разделяя БД, например, по регионам (коих в России почти сотня), можно работать и с терабайтными датасетами. Но разумеется, у вас все базы как минимум петабайтные, а серверов в вашем кластере больше, чем людей на планете, и эти цифры для вас слишком мелки.
...
Рейтинг: 0 / 0
30.04.2010, 19:09
| Ответить | Цитировать | Написать  
PostgreSQL vs MySQL
    #36625207
Pure.....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pure.....
Участник
MBG
Конечно. Как пример:
http://geomapx.blogspot.com/2009/09/sqlite-3617-mobigroup2.html
http://geomapx.blogspot.com/2010/01/sqlite-fts3.html
http://geomapx.blogspot.com/2009/11/postgresql-81-vs-sqlite-3620-in-real.html

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

Видимо мои тестеры с кривыми руками, но по их тестам постгрес как-то лучше выглядит :)
(точнее по стандартным тестам)
Задумался... может быть действительно будущее за скулайтом?!... Главное не всеми не задумываться ...
...
Рейтинг: 0 / 0
13.05.2010, 11:52
| Ответить | Цитировать | Написать  
190 сообщений из 190, показаны все 8 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / PostgreSQL vs MySQL
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1552804]:
 0ms
get settings:
 12ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 35ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 302ms
get tp. blocked users:
 1ms
others: 13ms
total:  398ms
созд. / загр.: 398ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]