Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8      [все]
 PostgreSQL vs MySQL  [new]
YuriyB
Member

Откуда:
Сообщений: 1137
здравствуйте .

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

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

спасибо.
3 апр 07, 15:20    [3973951]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
BlackDan
Guest
Вопрос из серии
"Действительно БМВ быстрее АУДИ".
3 апр 07, 15:31    [3974028]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Ivan Evtuhovich
Member

Откуда: Москва
Сообщений: 113
BlackDan
Вопрос из серии
"Действительно БМВ быстрее АУДИ".


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

Извините, не удержался. ;-)
3 апр 07, 17:04    [3974815]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
st_serg
Member

Откуда: Москва
Сообщений: 591
разве кит? дельфин вроде ж бы...

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

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

ps. насколько я помню, не так давно на opennet.ru пробегала статья по поводу pg в web-приложениях
3 апр 07, 17:35    [3975094]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
YuriyB
Member

Откуда:
Сообщений: 1137
st_serg
разве кит? дельфин вроде ж бы...

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

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

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


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

есть ли смысл поменять базу данных
3 апр 07, 18:46    [3975509]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Andrey Daeron
Member

Откуда: Киев
Сообщений: 1027
YuriyB

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

есть ли смысл поменять базу данных

А ЗАЧЕМ????
3 апр 07, 18:50    [3975539]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Shweik
Member

Откуда:
Сообщений: 1744
Модератор: флейм переносим в Сравнение СУБД
3 апр 07, 19:13    [3975680]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Arpanx
Member

Откуда: Донецк
Сообщений: 1288
под Postgres нет удобных инструментов для разработки. Скорость разработки низкая. Как с этим у MySql не знаю. Сижу сам на Postgres еще ни разу не падало.
Достает то что, PostGres скомпилит процедуру молча, а при запуске процедуры выясняются все ошибки.
5 апр 07, 14:45    [3985024]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
strizh
Member

Откуда: Киев
Сообщений: 937
>Достает то что, PostGres скомпилит процедуру молча, а при запуске процедуры выясняются все >ошибки.
А зачем Вы ошибки делаете ?
Внимательней надо быть, а не на женские ножки отвлекаться :)
А проверить процедуру без исполнения можно:
explain select <процедура()>;
5 апр 07, 18:32    [3986863]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
IgorK
Member

Откуда: Краснодар
Сообщений: 452
Arpanx
под Postgres нет удобных инструментов для разработки. Скорость разработки низкая.
Что подразумевается по словом "инструментов для разработки" ?
Вот это видели? http://www.sqlmanager.net/en/products/studio/postgresql
10 апр 07, 10:50    [4000248]     Ответить | Цитировать Сообщить модератору
Между сообщениями интервал более 1 года.
 Re: PostgreSQL vs MySQL  [new]
prustr
Member

Откуда: C-Петербург
Сообщений: 960
все ветку надо выбросить в корзину. Ни одного ответа, только общие слова с уроков информатики и рекомендация купить софтину за 700 долларов человеку, который ищет свободный продукт...
А вопрос при этом остается актуальным.
30 май 09, 12:14    [7247425]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67998
Блог
prustr
Ни одного ответа, только общие слова с уроков информатики
....
А вопрос при этом остается актуальным.

Остаётся. Для тех, кто прогуливал уроки информатики в школе, да ещё и здесь не хочет слышать.
30 май 09, 14:12    [7247579]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
softwarer
Остаётся. Для тех, кто прогуливал уроки информатики в школе, да ещё и здесь не хочет слышать.

Значит будут бить. (С)
30 май 09, 14:24    [7247594]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
us0ldr
Guest
Сегодня нашел в гугле. http://www.samag.ru/art/07.2007/07.2007_02.html Качественная статья где сравниваются MySQL и PostgreSQL на примере блогохостинга.
10 июн 09, 11:42    [7284770]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30358
тоже фигня. 20 коннектов, и MySQL издох? Лажа какая-то. Как тогда сотни тысяч серьезных проектов работали на MySQL, пока PostgreSQl не вылез из университетов? До определенного времени PG вообще всерьез не рассматривался, в силу совершенно объективных причин. Сейчас да, не спорю, силен, но чтобы так MySQL загибать, это сомнительно.
10 июн 09, 12:28    [7285108]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
kdv, не совсем так. PgSQL был ещё когда ещё mSQL'а в проекте не было.
Может быть, тестеры лажанулись с настройками mysql.
Но слон за это время здорово подрос.
11 июн 09, 01:22    [7288151]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
us0ldr
Сегодня нашел в гугле. http://www.samag.ru/art/07.2007/07.2007_02.html Качественная статья где сравниваются MySQL и PostgreSQL на примере блогохостинга.


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

Это что за бред:
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);

А это что? :
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??

В общем пожалуйста не ссылайтесь на такие статьи как на "качественные"
11 июн 09, 01:49    [7288161]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН,

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

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

Сейчас - да, вполне достойный сервер.
11 июн 09, 02:01    [7288170]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен wrote:

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

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

А результаты впечатляющие.

Posted via ActualForum NNTP Server 1.4

11 июн 09, 10:14    [7288646]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

ОКТОГЕН wrote:

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

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

Posted via ActualForum NNTP Server 1.4

11 июн 09, 10:17    [7288670]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
MasterZiv,
у них на сайте сырцы лежат.
11 июн 09, 21:34    [7292460]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
MasterZiv, но ведь это
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 автоинкремент
11 июн 09, 21:45    [7292497]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
"INSERT IGNORE" смеялсо ...
11 июн 09, 22:33    [7292621]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

ОКТОГЕН wrote:

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

Они лежат и на моём жёстком диске тоже, да только вот
время знаешь ли надо, чтобы прочитать

Posted via ActualForum NNTP Server 1.4

11 июн 09, 22:44    [7292638]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

ОКТОГЕН wrote:

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

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

Posted via ActualForum NNTP Server 1.4

11 июн 09, 23:06    [7292684]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
MasterZiv, в том-то и дело что одинаково. А надо бы оптимизировать под каждый сервер.
Например, Count() в постгре считается медленнее, чем в myISAM-движке мускуля и примерно одинаково в INNODB. А последовательности и автоинкремент заведомо быстрее одного лишнего запроса.
Конструкция также не учитывает полное отсутствие ACID в MyISAM,
и между запросами
CommentId = SELECT MAX(comment_id) FROM commnets;
И INSERT INTO commnets может быть вставлено что-нибудь, и инсерт или не сработает или вставит запись с повтором CommentId.

моё мнение - если тест претендует на звание "хороший", то его запросы должны быть вылизаны
под каждую базу с учётом потрохов и того и другого. Должен использоваться диспетчер соединений(пул). Должны использоваться кеши разобранных запросов, индексы и пр.
12 июн 09, 00:03    [7292868]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
miksoft
Member

Откуда:
Сообщений: 38942
ОКТОГЕН
между запросами
CommentId = SELECT MAX(comment_id) FROM commnets;
И INSERT INTO commnets может быть вставлено что-нибудь
Не может, если таблица залочена.
ОКТОГЕН
и инсерт или не сработает или вставит запись с повтором CommentId.

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

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

Тем не менее, всецело соглашусь, что на боевой базе вышеупомянутые запросы вряд ли будут хорошим решением.
14 июн 09, 00:44    [7296712]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

ОКТОГЕН wrote:

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

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

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

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

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

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

Posted via ActualForum NNTP Server 1.4

15 июн 09, 12:18    [7299426]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MasterZiv

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


глупо ...
15 июн 09, 12:22    [7299460]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv


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



Волшебное слово тут НОРМАЛЬНО.. А в статье как раз "бестолково". И эти запросы - это всего лишь пример. Там много чего "оптимизировано".
15 июн 09, 13:10    [7299778]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

ОКТОГЕН wrote:

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

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


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

В постгресе у них :
    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:

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 гиг?
15 июн 09, 14:29    [7300349]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен wrote:

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

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

Posted via ActualForum NNTP Server 1.4

15 июн 09, 15:01    [7300586]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
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! "
16 июн 09, 21:58    [7307430]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
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, то я бы с осторожностью относился к этим тестом. И к старым и к новым.
16 июн 09, 22:15    [7307474]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
vasilis
Member

Откуда: Украина, Киев
Сообщений: 2205
Хрен
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, например.
19 июн 09, 11:56    [7319798]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
в этом db_STRESS 5 табличек, 2 тупых селекта которые нарушая логику читают без блокировок и 3 модифицирующих запроса. никаких транзакций (autocomit) + аффтар все эту нехитрую конструкцию загнал в память.
имхо сделать какие-либо выводы о субд по такому тесту не представляется возможным, зато об умственных способностях аффтора - имхо легко.
19 июн 09, 12:34    [7320038]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Amnesyac
Member

Откуда:
Сообщений: 5
Здесь http://madjack.ru/developer/2009/08/mysql-vs-postgresql.html подробно все рассовано по полочкам. Советую почитать. Можно сделать выбор основываясь на прочитанном. Я допустим его уже сделал.
6 авг 09, 12:36    [7505120]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Amnesyac
Member

Откуда:
Сообщений: 5
Выше не получилось ссылку дать. ЗДЕСЬ расположена статья, где субъективно основываясь на фактах рассмотрены все сильные и слабые стороны MySQL и PostgreSQL.
6 авг 09, 12:37    [7505125]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Amnesyac
Выше не получилось ссылку дать. ЗДЕСЬ расположена статья, где субъективно основываясь на фактах рассмотрены все сильные и слабые стороны MySQL и PostgreSQL.

Фигня какя-то.
6 авг 09, 14:54    [7506300]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Начало просто офигительное
Выбор между MySQL и PostgreSQL - это решение, которое должен принять каждый разработчик, который выбирает между различными Open-Source СУБД.
6 авг 09, 15:05    [7506367]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
zMakc
Member

Откуда: Киев
Сообщений: 35
Думаю в данном сравнении стоит рассматривать не только сравнение производительности.
Даже 10% в производительности это не принципиально.

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

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

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

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

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

С учетом текущей ситуации, преимущество(какое-то где-то) PostgreSQL не значительно и значимого экономического эффекта не даст.
6 авг 09, 15:20    [7506470]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
zMakc, если всё хорошо работает, то зачем переходить?
Если начинать новый проект, то зависит от потребностей.
6 авг 09, 15:59    [7506765]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
zMakc
Под MsSQL , MySQL, Oracle есть то что нам нужно. Под PostgreSQL нет.

А что вам нужно-то? Может, опишете?
6 авг 09, 16:07    [7506833]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

FreemanZAV пишет:

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

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

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

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

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

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

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

Есть и ещё, но иногда кажется, что автор, ещё раз, просто по-русски
не умеет писать, и пишет какую-то хрень.

Posted via ActualForum NNTP Server 1.4

6 авг 09, 19:34    [7507945]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

zMakc пишет:

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

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

Posted via ActualForum NNTP Server 1.4

6 авг 09, 19:43    [7507970]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Я могу рассказать в чем огромное преимущество MySQL перед PgSQL

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

MySQL же разрабатывается одной командой, с вменяемой (платной) техподдержкой и возможностью решить вопросы на любом уровне, включая патчи специально под твои нужды. Не так давно к примеру видел такой патч, который позоляет держать 20 - 30 тыщщ соединений.
13 авг 09, 21:05    [7536047]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Хрен

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

Это не пул соединений часом?
Про патч полнотекстового поиска для innoDB я краем уха слышал.
Как оно работает - не знаю. Почему эта сплочённая команда не протестировала этот насущно
необходимый код и не включила его в релиз - вопрос отдельный.
А вот не появилось ли там патча, реализующего CHECK'и и табличные функции хотя бы как в MSSQL?
Чтоб не писать для каждого случая свою процедуру, а использовать уже готовые, просто JOIN'я их?
Этот момент меня лично реально напрягал , когда я делал проекты на mysql.
Ещё реально напрягали нюансы с пятёркой. Например, комментарии в триггере на русском
языке приводили к нечитаемости(и дальнейшей порче при попытке изменить) кода триггера с
начала комментария. Поведение нигде не документировано. Моя попытка пообщаться с
разработчиками ни к чему вразумительному ни привела. Ответ , который мне был дан ,
примерно "учитесь настраивать систему".
Не говоря про залипуху с математикой(невдолбенные погрешности при операциях умножения)
в версиях до 5.0.20.
О волшебных преобразованиях нормального запроса в синтаксически неверный в
представлениях тоже говорить не будем, здесь про это тоже кто-то писал.
В PostgreSQL же это всё просто работает, работает давно, и так, как надо.
14 авг 09, 01:35    [7536666]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
MasterZiv
MySQL же -- это просто куча никчёмного
кода, который, к нещастью, работает.

Почему же к несчастью? Наоборот, к счастью.
Если это есть, значит кому-то нужно.
14 авг 09, 01:39    [7536677]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН

Ещё реально напрягали нюансы с пятёркой. Например, комментарии в триггере на русском
языке приводили к нечитаемости(и дальнейшей порче при попытке изменить) кода триггера с
начала комментария. Поведение нигде не документировано.


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 на нем, то ошибаетесь.
14 авг 09, 10:03    [7537316]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Хрен, славненько.
А теперь попробуйте вытащить код триггера из системы.
14 авг 09, 10:11    [7537365]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН,

А это что по вашему было?
14 авг 09, 10:24    [7537466]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
упс. Не заметил.
14 авг 09, 11:36    [7538061]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
А какая это версия?
Просто с такой проблемой сталкивался не я один.
14 авг 09, 11:37    [7538072]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Ух ты! 5.1.30-community проблемы нет, видимо, действительно, пофиксили.
Лучше поздно, чем никогда...
В версиях 5.0.20 - 5.0.30х я тестировал это под разными осями, под разными кодировками(и клиентов и серверов и осей) и разными либами. Дело было точно не в настройках,
потому, как перед созданием триггера в этом же сеансе создавалась процедура с комментарием, и там было всё в порядке. При этом русский текст отображался правильно.
14 авг 09, 13:05    [7538905]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

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

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

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.
MySQL -- использует многозадачность операционной сисстемы, на каждый
коннект создаёт поток. Это -- ОЧЕНЬ ПЛОХО по большому счёту, но дёшево
(попсово) в реализации.

Posted via ActualForum NNTP Server 1.4

17 авг 09, 13:29    [7546080]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

ОКТОГЕН пишет:

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

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


А использовали бы либо нормальные платные СУБД (дешёвых не так мало),
либо нормальные бесплатные СУБД.

Posted via ActualForum NNTP Server 1.4

17 авг 09, 13:32    [7546095]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
MasterZiv

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.

Не совсем. Слон использует процессы.
Под виндами в этом есть минусы, т.к. процессы тут тормозят.
Зато взаимодействие основанное на процессах значительно надёжнее,
чем на потоках.
Хрен
Если вы думаете, я никогда не видел sigsegv на нем, то ошибаетесь.

А я видел то же самое на oracle. Видел, как M$SQL умирает. Баги есть везде.
17 авг 09, 15:16    [7546934]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Кстати, на счёт соединений. PGSQL использует (вроде бы) свою многозадачность.
MySQL -- использует многозадачность операционной сисстемы, на каждый
коннект создаёт поток. Это -- ОЧЕНЬ ПЛОХО по большому счёту, но дёшево
(попсово) в реализации.


Во первых pgsql не использует "свою многозадачность". Он использует process per connect стратегию для соединений.
Во вторых "ОЧЕНЬ ПЛОХО" - нуждается в обосновании.
18 авг 09, 00:38    [7549061]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН

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


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

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

А drawbacks такой архитектуры - более ресурсоемкие соединения - они остаются, их никуда не денешь..
18 авг 09, 00:47    [7549074]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
2Хрен

меня терзают смутные сомнения. о каких семофорах идет речь, операционной системы ? что за ОСь такая у которой остаются болтаться семофоры ? но больше заинтриговало shared memory - что там такого может оставить юзерский процесс, чего там такого чего нет в оракле ?
18 авг 09, 01:31    [7549112]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Ёш
Member

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

Собственно - так и происходит в случае внезапной кончины одного из процессов в pgsql. В таком случае - семафоры и shared memory остаются в неопределенном состоянии, поэтому postmaster - управляющий процесс - просто убивает все остальные соединения, и ре-инициализирует семафоры и shared memory заново. То есть - pgsql просто не использует те advantages, которые дает архитектура process per connect.
Вы как-то сами себе противоречите, возможность отследить разрушение данных в общей памяти, падение процесса и произвести после этого корректный перезапуск как раз и есть то самое использование преимуществ раздельных процессов в pg.
18 авг 09, 01:35    [7549117]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Хрен, эксперимент показывает, что убийства процессов не происходит.
На остальных сеансах это не отражается(8.4)
18 авг 09, 10:22    [7549809]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
ОКТОГЕН,
а как именно ты заставил коннект умереть лютой смертью?
18 авг 09, 12:05    [7550522]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
dimitr
а как именно ты заставил коннект умереть лютой смертью?

кому-то известно более одного способа "убийства процессов" ?
18 авг 09, 12:19    [7550628]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН
Хрен, эксперимент показывает, что убийства процессов не происходит.
На остальных сеансах это не отражается(8.4)


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

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

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

$ 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.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

и во втором
$ 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.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

В логе:

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 надо будет обязательно попробовать, как только руки дойдут
18 авг 09, 12:28    [7550676]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
интересно, а если 8.3 именно убивать, kill -9 ?
18 авг 09, 12:42    [7550756]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Yo.!, под вендой завершались через диспетчер задач-завершение процесса.
И 8.3.7 и 8.4 другие клиентские процессы при этом не завершались.
Особенности системы?
18 авг 09, 12:56    [7550866]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
скорее segfault постгрес решает обрабатывать перегрузкой сервера, нужно под линуксом 8.3 попробовать прибить по -9, тогда можно будет делать выводы ...
18 авг 09, 13:08    [7550952]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
dimitr
Member

Откуда: PNZ
Сообщений: 7013
Yo.!
кому-то известно более одного способа "убийства процессов" ?

более интересна была бы реакция на AV/SEGV в одном из рабочих процессов
18 авг 09, 13:14    [7550982]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Yo.!
скорее segfault постгрес решает обрабатывать перегрузкой сервера, нужно под линуксом 8.3 попробовать прибить по -9, тогда можно будет делать выводы ...


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

Первое соединение:

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.
Соединение с сервером было потеряно. Попытка переустановить: Успешно.

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


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


в логе
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
18 авг 09, 14:40    [7551714]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

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

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

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

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

Posted via ActualForum NNTP Server 1.4

18 авг 09, 15:53    [7552275]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

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

Как процессы сервера БД могут не иметь общей памяти, скажи пожалуйста ?
Это что же, каждому коннекту свой кэш данных ?

Posted via ActualForum NNTP Server 1.4

18 авг 09, 15:55    [7552298]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Yo.! пишет:

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

Да гонит он. Чепуху какую-то сморозил.

Posted via ActualForum NNTP Server 1.4

18 авг 09, 15:56    [7552307]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Хрен пишет:

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

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


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

MasterZiv

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


Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.
18 авг 09, 17:50    [7553179]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
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?
18 авг 09, 17:54    [7553207]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Да гонит он. Чепуху какую-то сморозил.


Вы сами то понимаете, что выглядите клоуном, когда спорите против фактов? Легко же посмотреть/почитать документацию/проверить.
18 авг 09, 17:56    [7553216]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
ОКТОГЕН
Yo.!, под вендой завершались через диспетчер задач-завершение процесса.
И 8.3.7 и 8.4 другие клиентские процессы при этом не завершались.
Особенности системы?


Есть предположение, что диспетчер задач посылает то, что в юниксах называется SIGTERM. А он не рассматривается postgres-ом как ненормальное завершение, потому что не может быть в результате бага и используется к примеру при shutdown операционной системы. В постгресе по sigterm закрывается одно текущее соединение - с flush файлов и нормальным освобождением ресурсов..
18 авг 09, 18:16    [7553309]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Хрен, и всё-таки взаимодействие процессов поломать значительно сложнее, чем взаимодействие потоков. А отдельные буфера и у процессов постгреса есть(workmem, по моему).
18 авг 09, 18:26    [7553348]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 55225

Хрен

Есть предположение, что диспетчер задач посылает то, что в юниксах
называется SIGTERM. А он не рассматривается postgres-ом как ненормальное
завершение,

Скорее используется TerminateProcess и рассматривать его как нормальное
завершение чисто технически невозможно - убиваемый процесс никак не
оповещается и не имеет возможности отреагировать.

Posted via ActualForum NNTP Server 1.4

18 авг 09, 18:56    [7553444]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

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

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

Posted via ActualForum NNTP Server 1.4

18 авг 09, 23:30    [7554063]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

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

В отсутствии накладных расходов в ОС на создание множества безполезных
потоков. И в применении собственной диспечтеризации СУБД, а не
диспетчеризации операционной системы, которая понятия не имеет о состоянии
задач, выполняемых СУБД.

Posted via ActualForum NNTP Server 1.4

18 авг 09, 23:32    [7554065]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
MasterZiv

Хрен пишет:

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

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


mysqlManual
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 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
19 авг 09, 03:18    [7554216]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Хрен пишет:

> 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

19 авг 09, 11:51    [7555428]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Хрен

MasterZiv

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


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


Пока глупые пользователь pgsql вовсю используют пул соединений PgBouncer, написанный какими-то хренами с бугра из ....
Модератор: лексика кульных хацкеров здесь не приветствуется, вплоть до их забанивания


Сообщение было отредактировано: 8 сен 09, 11:39
8 сен 09, 11:03    [7630231]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Полемика затихла. А я вот как раз оказался перед выбором, что лучше предпочесть, MySQL или PostgreSQL?

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

Есть команда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему. Других доводов нет. И собственно для них мне и нужно спроектировать БД, обеспечить импорт данных и т.п.
Вот у меня и возникли сомнения. С PostgreSQL у меня только очень поверхностное знакомство: ставил, пробовал, "игрался". С MySQL вообще знакомство только понаслышке.
Но чтобы убедить ту команду web-разработчков сменить БД, нужны серьезные основания. А надо ли вообще переубеждать и менять?
31 окт 09, 12:12    [7866187]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Александр Гoлдун пишет:

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

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

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

Переубеждать кого-нибудь -- задача неблагодарная.

Posted via ActualForum NNTP Server 1.4

31 окт 09, 12:27    [7866217]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
zMakc
Member

Откуда: Киев
Сообщений: 35
Александр Г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, там есть много вкусностей :)
1 ноя 09, 00:34    [7867276]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
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 им привычнее.
1 ноя 09, 01:28    [7867330]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 55225

zMakc

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

Это вам показалось.

Posted via ActualForum NNTP Server 1.4

1 ноя 09, 01:43    [7867338]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
zMakc
Member

Откуда: Киев
Сообщений: 35
Александр Гoлдун,

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

При чем тут ключи?


автор
MyIsam таблицы использовать, если у меня нет серьезных доводов для InnoDB

Для большинства таблиц InnoDB однозначно. Где вы таких "специалистов" нашли? :)
1 ноя 09, 12:20    [7867532]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
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 щас --- его не купил Оракл, и поэтому больше шансов на дальнейшее развитие, бгыгыгы.
1 ноя 09, 15:07    [7867703]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
zMakc
Member

Откуда: Киев
Сообщений: 35
Sad Spirit,

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

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

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

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


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

автор
его не купил Оракл
Ларри Элисон заявил что денег на разработку MySQL будут тратить больше чем Sun, не думаю что он бросает слова на ветер. Гробить MySQL им не выгодно, наоборот.
1 ноя 09, 16:36    [7867833]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
zMakc
Sad 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 развивается.
1 ноя 09, 17:24    [7867907]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
zMakc

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

При чем тут ключи?

При том, что вы уже предложили вместо триггеров PHP использовать. Вот я и попытался экстраполировать направление полета вашей мысли до реализации ссылочной целостности и транзакций также средствами PHP.
1 ноя 09, 23:49    [7868692]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Sad Spirit

zMakc

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

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


А какие рабочие решения по репликации для pg предложили бы Вы?
2 ноя 09, 01:09    [7868781]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Александр Гoлдун

Есть команда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему. Других доводов нет.


А Ваша роль какая?
2 ноя 09, 01:12    [7868784]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
Sad Spirit

Пока глупые пользователь pgsql вовсю используют пул соединений PgBouncer, написанный какими-то хренами с бугра из ....


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

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

Тут тебе и пул коннекций, и переписывание запросов, и failover и load balancing. И разрабатывается в Сане.
2 ноя 09, 01:20    [7868789]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
Хрен
Александр Гoлдун

Есть команда web-разработчиков, linux-apache-php-mysql и т.п. Собственно они и хотят MySQL, т.к. привыкли к нему. Других доводов нет.

А Ваша роль какая?

Моя роль - спроектировать им базу. Кроме того, есть некая исходная база в MSSQL, откуда понадобятся данные, разово либо на регулярной основе.
2 ноя 09, 09:24    [7869085]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Хрен
Sad Spirit

zMakc

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

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


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

А почемы Вы отвечаете вопросом на вопрос?

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

Хрен

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

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

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

???
Это скорее аналог pl/proxy, чем обычный пул соединений.
2 ноя 09, 11:41    [7869751]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Хрен
Member

Откуда: Brisbane
Сообщений: 1455
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-а в том числе.
4 ноя 09, 12:42    [7880788]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Sad Spirit
Member

Откуда:
Сообщений: 569
Хрен
Sad Spirit

А почемы Вы отвечаете вопросом на вопрос?

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


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

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

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

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

так хоть можно в этой теме набрать материала будет.
4 ноя 09, 18:46    [7882107]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
В MySQL оптимизатор использует гистограммы распределения значений? А в PostgreSQL?
11 ноя 09, 13:55    [7913956]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Александр Гoлдун wrote:
> В MySQL оптимизатор использует гистограммы распределения значений?

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

А в
> PostgreSQL?

Вроде, использует.

Posted via ActualForum NNTP Server 1.4

11 ноя 09, 14:25    [7914219]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
Александр Гoлдун
... оптимизатор использует гистограммы распределения значений ... в PostgreSQL?

да

14.2. Statistics Used by the Planner
11 ноя 09, 15:28    [7914866]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
LeXa NalBat
Member

Откуда: Москва
Сообщений: 2892
Александр Гoлдун
... оптимизатор использует гистограммы распределения значений ... в PostgreSQL?

наткнулся на более подробное описание, последняя глава в документации :)

55.1. Row Estimation Examples
2 дек 09, 13:13    [8007870]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Васек Pg
Guest
Arpanx
под Postgres нет удобных инструментов для разработки


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

стандартный PgAdmin III
EMS PostgreSQL (Free или полная платная студия)
24 дек 09, 17:48    [8115276]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
А кто-нибудь может подсказать, как обстоят дела с анализом производительности живых баз в работе для MySQL и PostgreSQL? Нужно что-нибудь типа индекс консультанта в Sybase ASA: он позволяет собрать за какое-то время статистику посылаемых к серверу запросов, проанализировать их эффективность и даже выдает рекомендации по индексам, с указанием эффекта от их создания.
27 дек 09, 14:01    [8123510]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Александр Гoлдун, oracle, насколько можно верить моему склерозу, такую штуку имеет.
А pgSQL и MySQL - нет. Можно использовать стороннюю приблуду, но я таких не знаю.
В pgSQL с помощью статистики можно определить - используются ли индексы, или они
зря созданы, насчёт MySQL - не знаю.
Ну, и explain analyze рулит, конечно.
27 дек 09, 15:14    [8123664]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290
То что в оракле есть подобное - я и не сомневаюсь.
Получение плана единичного запроса - это не то, это уже инструмент для детального разбора конкретного запроса. Интересует общий анализ эффективности. Задал вопросы в соотв. форумах - может кто-то что-то подскажет.
27 дек 09, 22:38    [8124630]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
klip
Member

Откуда: Minsk
Сообщений: 44
Александр Гoлдун, для mysql есть query analyzer и maatkit
28 дек 09, 07:22    [8125181]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
JhonyBeGood
Member

Откуда:
Сообщений: 3
Интересует мнение какой выбор будет целесообразным при запуске интернет проекта социальной сети на Drupal
MySQL или PostgreSQL ?
и какие особенности (принципиальные различия) характерны для последующего поддержания такой базы данных (в первую очередь финансовые)?

если не затруднит то может кто то сможет привести конкретные примеры уже реализованных проектов
4 апр 10, 22:13    [8577244]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Бред
Guest
JhonyBeGood
Интересует мнение какой выбор будет целесообразным при запуске интернет проекта социальной сети на Drupal
MySQL или PostgreSQL ?
и какие особенности (принципиальные различия) характерны для последующего поддержания такой базы данных (в первую очередь финансовые)?

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


Оба будут тормозить при серьезных нагрузках. И плохо масштабироваться:) Целесообразным будет выбор couchdb или чего-то аналогичного.
4 апр 10, 22:21    [8577256]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
JhonyBeGood
Member

Откуда:
Сообщений: 3
Бред
JhonyBeGood
Интересует мнение какой выбор будет целесообразным при запуске интернет проекта социальной сети на Drupal
MySQL или PostgreSQL ?
и какие особенности (принципиальные различия) характерны для последующего поддержания такой базы данных (в первую очередь финансовые)?

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


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


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

P.S. "Налево пойдешь - коня потеряешь ... "
4 апр 10, 23:47    [8577368]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Бред
Guest
JhonyBeGood

Ребята, нужен дельный совет ...


А-а-а, дельный... Извините, не сообразил:) Забудьте то, что я сообщил:)
4 апр 10, 23:50    [8577370]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30358
автор
от этого сейчас может зависит моя жизнь

еще одна социальная сеть? подымаем бабло? По-моему, еще даже год назад было понятно, что социальные сети в тупике. Впрочем, не обращайте внимания, я риторически.
5 апр 10, 00:24    [8577428]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
JhonyBeGood
Member

Откуда:
Сообщений: 3
kdv
автор
от этого сейчас может зависит моя жизнь

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

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

P.S. Ведь существуют же и полезные сообщества, к примеру Хабр ...
5 апр 10, 01:24    [8577494]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
JhonyBeGood,

Тут
6 апр 10, 12:27    [8584977]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
Хрен
ОКТОГЕН,

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

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

Сейчас - да, вполне достойный сервер.

Я бы сказал на данный момент на небольших объемах the first ...
7 апр 10, 17:10    [8594103]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
JhonyBeGood


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

P.S. "Налево пойдешь - коня потеряешь ... "

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

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

Бред

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

Серьезные нагрузки - это приблизительно сколько?
И масштабирование ... не скажу за Мускул, а вот о Слоне откуда такая информация?
7 апр 10, 17:26    [8594220]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ОКТОГЕН
Member

Откуда:
Сообщений: 2498
Pure.....,
Ну, наверное, десяток терабайт данных, какой-нибудь портал с 10-20 тысячами пользователей одновременно, которые конкурентно читают и пишут.
7 апр 10, 18:00    [8594449]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
ОКТОГЕН,

Э-эээ.... Космос нашептывает Postgre :)
7 апр 10, 19:10    [8594824]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ОКТОГЕН
Pure.....,
Ну, наверное, десяток терабайт данных, какой-нибудь портал с 10-20 тысячами пользователей одновременно, которые конкурентно читают и пишут.


Хех. Если на указанной задаче у топикстартера затык будет исключительно в БД, это не страшно :-)
7 апр 10, 20:10    [8595064]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
MBG
ОКТОГЕН
Pure.....,
Ну, наверное, десяток терабайт данных, какой-нибудь портал с 10-20 тысячами пользователей одновременно, которые конкурентно читают и пишут.


Хех. Если на указанной задаче у топикстартера затык будет исключительно в БД, это не страшно :-)

Ну он-то по-любому будет считать. что БД виновата...
8 апр 10, 10:55    [8596939]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Pure.....

Ну он-то по-любому будет считать. что БД виновата...


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

Если серьезно, то любая современная СУБД - от постгреса до эскулайта - успешно работает с БД в десятки гигабайт в многопользовательском сценарии. Притом проблемы-то везде похожие, и только пути решения этих проблем совсем разные для каждой СУБД. И притом в инете множество примеров различных проектов приведено для самых разных СУБД... но чтобы создать свой большой проект, придется много поработать, а не просто почитать презентации.
8 апр 10, 12:31    [8597793]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
Если серьезно, то любая современная СУБД - от постгреса до эскулайта - успешно работает с БД в десятки гигабайт в многопользовательском сценарии.[/quot]
Вот слово "успешно" я бы убрал ...
12 апр 10, 10:29    [8613852]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Pure.....
Вот слово "успешно" я бы убрал ...


Есть опыт переноса систем с оракла и постгреса на эскулайт, архитектура при этом меняется, но функциональность остается идентичной. Так что с точки зрения конечного пользователя разницы нет. С точки зрения разработчика - чем проще СУБД, тем сложнее разработка, зато и проще администрирование (эскулайт администрирования вообще не требует, хотя временами нужно дописать требуемые в проекте модули, но при установке на нескольких хостах лучше уж один раз дописать, чем годами администрировать). Так что вполне себе успешно.
12 апр 10, 11:48    [8614529]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SERG1257
Member

Откуда:
Сообщений: 2957
MBG
С точки зрения разработчика - чем проще СУБД, тем сложнее разработка
Согласен. Просто изобретаем велосипед
MBG
зато и проще администрирование
С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?
MBG
скулайт администрирования вообще не требует
Это просто значит, что для данной задачи дефолтные настройки являются оптимальными.
MBG
хотя временами нужно дописать требуемые в проекте модули, но при установке на нескольких хостах лучше уж один раз дописать, чем годами администрировать
Согласен, только вероятность бага в вашем велосипеде куда выше, чем в фиче взрослой СУБД по причине лучшего тестирования последней
12 апр 10, 19:57    [8618391]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Saller
Member

Откуда: exUSSR
Сообщений: 1141
SERG1257
MBG
зато и проще администрирование
С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?

Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?
13 апр 10, 00:45    [8618909]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
SERG1257

С какой стати? Административные задачи сами собой испарились? Пользователи сами собой завелись с нужными правами, ресурсы (память/диск) сами собой эффективно распределились в зависимости от нагрузки?


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

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


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

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


Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..
13 апр 10, 00:50    [8618911]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Saller
SERG1257
...

Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?


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

Типичная задача - создать тестовое распределение, обучить планировщик БД на нужном наборе запросов, получить статистику, по которой строятся нужные планы запросов. Как теперь результат обучения тестовой БД перенести на рабочую? В эскулайте просто - сохранить статистику из тестовой и залить в рабочую. А в постгресе, мускуле, и многих других ответ один - никак, им нужен админ, постоянно занимающийся отслеживанием поведения БД и подстройкой. Вот это и входит в стоимость администрирования. Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД. И уж вовсе ни к чему дублировать названные функции в СУБД.
13 апр 10, 00:59    [8618917]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
MBG,


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


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

автор

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


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

Конечно, для запросов вида SELECT * FROM моя_телефонная_книжка SQLite, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...
13 апр 10, 01:00    [8618918]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SERG1257
Member

Откуда:
Сообщений: 2957
Saller
Судя по Вашему высказыванию все эти функции сами делаются в продвинутой СУБД, а в простой все надо делать руками админа?
Это был ответ на скулайт администрирования вообще не требует
MBG
Я говорил про то, что не требуется постоянно настраивать при изменении нагрузки/соотношения типов запросов/объема данных в БД/etc
То есть у вас one size fits all. Один размер на всех. При этом с необходимостью настройки вы согласны.
MBG
Пример - при изменении названных величин в постгресе съезжают все планы запросов, что требует периодической перенастройки
Если постгресс попытался подстроиться под изменившиеся условия и ошибся то это баг. По-вашему лучше было тупо закрутить все гайки?
MBG
Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)?
Да я верю, что в вашем велосипеде нечему ломаться.
MBG
Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД.
А мужики-то не знают.
Я допускаю, что в вашем случае действительно велосипед лучше, чем автомобиль или грузовик.
Я не согласен что велосипед всегда может их заменить но функциональность остается идентичной
13 апр 10, 02:06    [8618950]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
какой полет мысли, а никто не оценил

MBG
В эскулайте просто - сохранить статистику из тестовой и залить в рабочую.

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

MBG
Добавлю, что и распределением памяти, дискового IO и проч. намного эффективнее занимается ОС, нежели самые навороченные СУБД. И уж вовсе ни к чему дублировать названные функции в СУБД.

глубокая мысль, но к сожалению поражает не глубиной. если оптимизатор лишен знания того, что у него в кеше он тупо не может принять решение какой метод доступа применить к таблице/индексу. план запроса будет отличаться если оптимизатору известно, что в кеше менее 1% нужного индекса от того который будет при знании о том что 99% индекса уже в кеше. я не говорю уже о том, что взрослая субд управляет и дает пользователю управлять объектами в кеше. оракл, например, мелкие таблицы кеширует целиком и не позволяет им выпасть из кеша.
к стате, огромная проблема куцых субд с небогатым набором методов доступа - вымывание кеша. запрос в sqllite читающий большую таблицу тупо забьет кеш оси одной таблицей со всеми вытекающими...

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

в том то и дело, там где у взрослой без единого телодвижения дается из коробки в ФС приходится изобретать дорогие велосипеды: не дать пользователю просто скопировать файлы БД или записать мусор hex-редактором. до сих пор помню месяцами бегающих фокспро-гайз по этажам прочесывающих сотни компов и разыскивающих, что за гады ежедневно приносят вирус дописывающий свое тело без разбора во все сетевые файлы, в том числе dbf
13 апр 10, 03:11    [8618998]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Yo.!
какой полет мысли, а никто не оценил

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

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

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

Я не доктор, но товарисчу MGB пора лечиться.
Если это вообще лечится.
13 апр 10, 04:33    [8619022]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП

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


Если своей головой подумать не хотите, то посмотрите хотя бы, к примеру, зачем оракл использует вспомогательную СУБД (timesten). Будете утверждать, что это решение несуществующих проблем? Или решение проблем, которые запросто можно решить средствами оракл, только его разработчики о том не знают? Хинт: то, что проблема неразрешима средствами самой СУБД, отнюдь не означает неразрешимость в целом.
13 апр 10, 10:45    [8619801]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Vinny the POOH

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


Пожалуйста:

The "authorizer" method
The "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, атсос или фокспро - вне конкуренции, но для чего-то сложнее - нет. Иначе не было бы "навороченных" СУБД...


Вы пытаетесь доказать логичность и необходимость чего-то самим фактом его существования? Забавно, т.к. это догмат веры, а к логике отношения иметь не может, и обычно выражается как "что боженька пошлет". Задумайтесь хотя бы, сколько различных "навороченных" систем сгинуло за короткий век существования электронной вычислительной техники...
13 апр 10, 11:06    [8619979]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
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


Интересно, а что помешает вирусу "дописать свое тело без разбора во все сетевые файлы, в том числе" файлы данных СУБД? Вы открыли закон природы, по которому испортить файлы таблиц постгреса вирусам запрещено? :-) Если нет, то не давайте прямого доступа к файлам, и не будет их модификации, независимо от того, что это за файлы.
13 апр 10, 11:37    [8620319]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
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]

В том то и разница, что в клиент-сервере прямого доступа к файлам БД нет никогда. И даже с сервера, потомо что открыты эксклюзивно.
13 апр 10, 13:29    [8621372]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Там где-то в соседней ветке чел рассказывал, что у него база в пару терабайт и в пару сотен юзеров болтается на фокспро. Мне его даже как-то жалко стало... А скулайт от фоксбейса идеологически мало чем отличается, разве что к выньтузу гвоздями не прибит.
13 апр 10, 15:03    [8622119]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

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

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

MBG

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

о! а мусье случайно располагает данными сколько времени нужно средней субд, чтоб научится пользовать кеш ?
тут недавно Кайт приезжал, нужно было ему рассказать какие глупые в оракле, нет бы примитивный lru пользовать, нет блин напридумывали патентованых алгоритмов и стратегий удержания блоков. а вон sqllite гигабайтами ворочает, а мы не знали

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

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

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

ясно, как докуришь, идешь заменять блинг большой тройки на sqllite

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

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

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

так и встало перед глазами - тысяча пользователей одновременно третью неделю пытаются вытянуть с файл-сервер гигобайтовый индекс, чтоб достать три строки из 10 гб, звонят админу и тот предлагает заменить гигобайтовый свич на интеконект тогда вся тысяча сможет получить три строки всего за неделю

устал
но настроение на весь день, спасибо !
13 апр 10, 15:14    [8622195]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Siemargl

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

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

Siemargl

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


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

Siemargl

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


Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.
13 апр 10, 15:43    [8622408]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Vinny the POOH
А скулайт от фоксбейса идеологически мало чем отличается, разве что к выньтузу гвоздями не прибит.

Блин, а я то думаю, чего меня так и тянет этого аффтара назвать фокспрошником. Аж боялся обидеть человека.
А оно вона как.
13 апр 10, 15:43    [8622415]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!

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


У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...
13 апр 10, 15:49    [8622459]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

нет, лично у меня применение фс-субд в 21 веке тождественно умственной неполноценности применяющего, не зависимо какими интерфейсами пытаются прикрыть убогость этой фс-субд. упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...
13 апр 10, 16:01    [8622564]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Yo.!
упрятывание фс-субд за трехзвенкой решает некоторые из самых больших недостатков фс-субд, но простота как известно хуже воровства...

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

А так да, бегал тут помнится Sergey Ch, с криками "фокспро плюс веб-сервисы - ничуть не хуже, а может быть даже и лучше, чем всё остальное вместе взятое"
13 апр 10, 16:37    [8622856]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
MBG


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


Странное утверждение. Есть понятие полноты тестового покрытия, а "лучшее тестирование" - это вы что, верите в исчерпывающее тестирование методом тыка (вручную)? Например, тест модуля работы с ip-адресами:
http://sqlite.mobigroup.ru/artifact/b0c8fcc099
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)
13 апр 10, 18:08    [8623696]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Pure.....
MBG

...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)


Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.
13 апр 10, 19:21    [8624087]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!
MBG

У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

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


Бедный оракл - не посоветовался с вами, покупая файловую СУБД BerkeleyDB, а теперь тратится на ее развитие. А в последней версии еще и движок эскулайта интегрировали для поддержки SQL. Срочно звоните Ларри Эллисону - сообщить, что вы с ним не согласны... Заодно предложите in-memory СУБД TimesTen выкинуть, которую они тоже купили, не посоветовавшись с вами.
13 апр 10, 19:24    [8624108]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
MBG
Pure.....
MBG

...
Вы готовы на основе своих знаний о "взрослых СУБД" предложить свой комплект тестов?..

Э-эээ, не понял в чем вопрос. Это предложение помериться у кого тесты лучше? :)


Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.

Добро пожаловать на tpc.org
13 апр 10, 19:33    [8624142]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
MBG
Yo.!
MBG

У вас веб-интерфейс и прочие сервисы тождественно равняются полному доступу к серверу? Меняйте профессию...

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


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

ваще дурак
BerkeleyDB назвать ФС.
in-memory database приплести.
срочно санитаров

чего еще там в списке "файловых субд"?
ржунимагу
13 апр 10, 19:38    [8624158]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

Предложение подтвердить свои утверждения доказательствами. Утверждение, что СУБД лучше, потому что она "взрослая" - это детский сад какой-то.


http://www.sqlite.org/whentouse.html
SQLite 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, значит именно он заменит все субды оракла разом
13 апр 10, 19:55    [8624232]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
MBG
Siemargl

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

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

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

MBG

Siemargl

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

Дайте мне рутовый доступ к вашему серверу, и посмотрим, сколько секунд мне понадобится, чтобы прибить все ваши "эксклюзивно открытые" файлы БД.

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

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

Йо! К сожалению, Оракл в каждую дырку не засунешь - не пролезет, как тот Винни-Пух =) Файловые БД имеют свою нишу в эмбеддед ~
13 апр 10, 23:36    [8624916]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Siemargl

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


Имея рутовый пароль к чему угодно, прибить процессы особо то никто и не мешает. Да и жизненно важные сервисы на венде никто не держит, разве что полные извращенцы. Идеология всей системы ущербна, сколько костылей на неё ни вешай.
14 апр 10, 00:38    [8625035]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
Vinny the POOH,

Может и ущербна. Но не так много людей точно знают места ущербности =) Особенно с серверной стороны. А скорость подтянули за 10 лет.
14 апр 10, 00:48    [8625049]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Vinny the POOH
Member

Откуда: Киев
Сообщений: 1525
Siemargl
Vinny the POOH,

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


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

А скорость подтянули за 10 лет.

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

Эх простите, если кого обидел, но просто не могу я, блин, читать весь этот гнусный пеар венды и вендорешений как "надёжных" и "недорогих" средств организации корпоративной инфраструктуры. Ложь и ересь, причем от начала и до конца. А я, блин, правду люблю.
14 апр 10, 01:21    [8625086]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
Vinny the POOH
А какая венда может похвастаться тем, что она управляет котлами, разводными мостами, авиационными диспетчерскими станциями, ядерными реакторами?

Можете смеяться, именно этим я и занимаюсь.
И кроме того, нет для этого систем, кроме винды. Для OS/2 последняя SCADA померла 3 года назад, для QNX домирает. Для остального и не было.
Не знаете, так не {звез}$%ъдите.
14 апр 10, 01:41    [8625105]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
А насчет недорогих соглашусь. Дорого тут все. Аппаратное резервирование только чего стоит. И перспективы удешевления пока нетути :)~
14 апр 10, 01:44    [8625108]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
2 Siemargl
2ЛП. А что же такое БерклиДБ, по Вашему ? )

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

К сожалению, Оракл в каждую дырку не засунешь - не пролезет, как тот Винни-Пух =) Файловые БД имеют свою нишу в эмбеддед ~

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

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

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

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

Линуксы со своими гламурными кедами и прочей эпидерсией по прожорливости обогнал уже даже висту. Чего, как мне казалось раньше, сделать невозможно в принципе.
А 2008R2 таки запускается и шустренько шуршит на весьма говённеньком железе.
Так что, как уже сказали - не знаете, так не {звез}$%ъдите.

Да блин, задолбали эти споры. Непригодна венда к серьёзным ТЕХНОЛОГИЧЕСКИМ задачам, и всё тут.

Вы абсолютно правы. Непригодна. И именно по этому на рынке серверов - решения на вындоузе в прошлом году схавали кажется этак процентов 75 продаж, если считать в штуках проданных серверов (в деньгах поменьше, ибо бесплатные линуксы дороже продаются, как ни странно).

Сидели бы M$ в своей нише игр и мультимедиа - всем бы щастье было, это у них хорошо выходит.

Сидели бы юнихи, линухи, и прочая занимательная педерастия в своей нише высокопроизводительных серверов - и всем щастье было бы. У них это хорошо получается. Нет же, лезут куда-то на десктопы, с криками "теперь и под линухом можно читать книжки, смотреть киношки, лазить по интернетам, читать почту, вах как круто, всё что нужно для домашнего пользования".
Тьфу на эту занимательную педерастию с пингвиньим лицом. Тьфу на неё еще раз.
14 апр 10, 04:03    [8625144]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП
2 Siemargl
2ЛП. А что же такое БерклиДБ, по Вашему ? )

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


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

P.S. А эмбеддед клиент-серверных не бывает, как упыря.
14 апр 10, 13:14    [8627848]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
MBG
С какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.

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

В принципе конечно под "файловыми СУБД" можно понимать СУБД-нашлёпки поверх файловых систем (здрасть, товарисч Siemargl со своей Кэтрин). Здравые мысли в таком подходе есть. Но к упомянутой BerkeleyDB оно опять таки никакого отношения не имеет.
14 апр 10, 13:28    [8628006]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Siemargl

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


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

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

Siemargl

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


И процессы прибьем. Любой мало-мальски современный вирус еще не то умеет - справляется с десятками антивирусов и файрволов, маскируется, прописывается в реестр и т.п. - и файлы ваших БД повредить сможет, не рассчитывайте его "напугать" блокировками.
14 апр 10, 13:42    [8628188]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП

Линуксы со своими гламурными кедами...


КДЕ и под винды давно работает (с версии 4.0), причем тут линукс? :-)
14 апр 10, 13:59    [8628400]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
MBG,

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

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

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

MBG
P.S. А эмбеддед клиент-серверных не бывает, как упыря.

А FB Embedded ? )))

Про проблемы в безопасности Windows можно начать забывать, особенно в серверах. Начиная с Висты/2008. Оставшаяся дыра в OLE эволюционно вытесняется вполне безопасным дотнетом.
14 апр 10, 14:07    [8628493]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
ЛП
MBG
С какого перепугу вы приравниваете файловые к файл-серверным? Файл-серверные и файловые эмбеддед - два разных подкласса файловых СУБД.

Ждал этого вопроса
И что же такое "файловые СУБД"?


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

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

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


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

Добавив к файловым СУБД сетевой интерфейс, получим клиент-серверные. Например, sqlite + sqlrelay - это уже клиент-серверная СУБД. Соответственно, используя свой сервер приложений плюс эмбеддед СУБД, мы получаем решение, полностью заменяющее клиент-серверные СУБД, а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.
14 апр 10, 14:30    [8628731]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
2 MBG
Под виндой есть существенная разница между доступом к локальным и удаленным файлам, потому и появился подкласс "файл-серверных" (когда файлы БД физически размещаются на удаленной машине), и подкласс эмбеддед (файлы БД доступны локально).

Чушь.
Файл-серверные СУБД появились задолго до винды.
Равно как и клиент-серверные.
Равно как и встраиваемые.
Идите хоть историю поучите, раз уж с информатикой не сложилось.

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

Чушь.
Какой-нибудь Filemaker бррр под MacOS при всём желании не назвать embedded. Самое что-ни на есть файл-серверное уродство.

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

Три раза чушь. Даже комментировать нечего.
14 апр 10, 14:47    [8628885]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG,

почитал блог, я правильно понял архитектуру ? я понял, что АТС пишет данные звонков в файлик на фс-сервере, параллельно по некому протоколу (tcp?) передает эти же данные в программу-коллектор. программа коллектор блокирует всю бд sqllite на любой доступ (в том числе и на чтение) и заливает пачку данных, после этого отпускает блокировку бд и бд "захватывает" следующий коллектор. так продолжается весь месяц, а с первого числа коллекторы начинают писать уже в новую бд, позволяя теперь "билинговать" старую бд, в которую уже ничего не пишется.
как-то не понятно как при таком раскладе хотя бы лимиты на звонки учитывать.
14 апр 10, 14:55    [8628939]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
roden
Member

Откуда:
Сообщений: 741
MBG
а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.

Типа SQlite на локальных машинах круче всех?
14 апр 10, 16:25    [8629769]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!
MBG,

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


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

В общем-то, такая технология шардинга аналогична использованию табличных пространств, но намного удобнее в администрировании. Администратор СУБД для описанной системы вовсе не нужен, все автоматизировано. Плюс скорость работы системы сохраняется, независимо от объема данных (т.к. данные разделены по месяцам, нет разницы, хранятся данные за 1 месяц или за 100).
14 апр 10, 16:33    [8629858]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
roden
MBG
а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.

Типа SQlite на локальных машинах круче всех?


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

В тех случаях, когда нужно предоставить клиентам веб-интерфейс, зачастую нет смысла лишний уровень городить, да еще через tcp/ip, когда можно прямо из application server получить доступ к данным с помощью встраиваемых СУБД. Разумеется, есть и свои проблемы у последних - скажем, сложно обеспечить поддержку длительных транзакций, но для веб-приложений, тем более, использующих ajax, это просто не требуется. Клиент-серверы хороши именно для тех задач, где пользователи подключаются к терминалам и вручную выполняют запросы, зачастую продолжительные, - но со времен мэйнфреймов такой сценарий работы стал весьма экзотическим (да и для клиент-серверов сейчас почти всегда для запросов, занимающих минуты/дни/часы, создают отдельное хранилище данных, доступное лишь в режиме рид-онли).
14 апр 10, 16:47    [8630056]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
MBG
Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов

что то это сильно мне напоминает это, только наоборот )))))))

Как дошло до тестов, проявляющих поведение в рабочих условиях, так сразу отступные речи...
14 апр 10, 18:34    [8630947]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Siemargl
MBG
Эскулайт, берклидб и подобные на порядки быстрее клиент-серверов

что то это сильно мне напоминает это, только наоборот )))))))

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


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

Также периодически напоминаю об ограничениях на размер индексов и т.п. И тесты публикую - как можно нарваться на проблемы на миллионе записей и как можно получить высокое быстродействие на миллиарде записей. Иначе и молотком можно лоб расшибить, если пользоваться не умеете.
14 апр 10, 19:15    [8631144]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
долго пытался воткнутся как с таким убожеством можно что-то онлайн провернуть, решил копнуть и наткнулся на чудесный документ с гордым названием "Техническое описание программы 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)


занавес.
14 апр 10, 22:12    [8631680]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6699
Yo.!,

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

ЗЫ. У нас биллинг с "мгновенным" перерасчетом дэдлочится (на Ора) периодически.
14 апр 10, 23:10    [8631769]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
навеяло
14 апр 10, 23:27    [8631786]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
Siemargl

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

в смысле шанс ? промышленные билинги бывают на чем то кроме оракла ?
14 апр 10, 23:31    [8631797]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
2 MBG
В тех случаях, когда нужно предоставить клиентам веб-интерфейс, зачастую нет смысла лишний уровень городить, да еще через tcp/ip, когда можно прямо из application server получить доступ к данным с помощью встраиваемых СУБД.

Хосспадя, зачем вам какой-то там аппликейшн сервер, если вы элементарных вещей не понимаете?
Смешались в кучу кони, люди...
Вам противопоказано выходить куда-либо за уровень однозвенных однослойных приложений "всё в одном".
ТелефоннаяКнижка.mdb - уровень встраиваемых субд. Ваш тоже.

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

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

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

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

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

Правда что-ли?
А мужики то и не знают.
14 апр 10, 23:39    [8631813]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
ЛП, извини, но такие посты я буду тереть - ни конкретики, ни юмора, одни обращения к личности

теряешь квалификацию :)
14 апр 10, 23:49    [8631838]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
SergSuper, ну как можно бред комментировать...
Какую конкретику тут можно ожидать, сам подумай.
На что конкретику? На вот это вот "для клиент-серверов сейчас почти всегда для запросов, занимающих минуты/дни/часы, создают отдельное хранилище данных, доступное лишь в режиме рид-онли" что-ли?
Хочешь тереть - твоё право.
Но лучше форум от этого бредогенератора очисти.
15 апр 10, 00:05    [8631878]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Ладно старые черепахи, прочитают, ужаснутся, посмеются.
А неопытные бойцы всю эту чухню прочитают и быть может даже поверят.
15 апр 10, 00:14    [8631904]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!
долго пытался воткнутся как с таким убожеством можно что-то онлайн провернуть, решил копнуть и наткнулся на чудесный документ с гордым названием "Техническое описание программы MBG Биллинг". данное ТЗ поражает не сколько проработанностью, сколько техническими решениями авторов.


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

P.S. А вы когда-нибудь живого заказчика видели? Если вас это ТЗ так пугает...
15 апр 10, 01:11    [8632019]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Yo.!
Guest
MBG

Что-то у вас со зрением - там написано Техническое задание.

а если присмотреться ? ;)
http://mobigroup.ru/billing.html
MBG

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

как говориться кому и кобыла невеста ...
15 апр 10, 02:10    [8632062]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
ЛП
Guest
Блин, я понял.

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

Это очередной виток TJ7.
15 апр 10, 02:51    [8632077]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
servit
Member

Откуда: г. Кишинёв, Республика Молдова
Сообщений: 3148
Блог
Yo.!
Siemargl

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

в смысле шанс ? промышленные билинги бывают на чем то кроме оракла ?

Биллинг на СУБД Caché.
15 апр 10, 09:10    [8632307]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Yo.!

а если присмотреться ? ;)
http://mobigroup.ru/billing.html


Файлик-то откройте :-) Если хотите увидеть результат работы - sudo aptitude install ... из нашего репозитория коллекторы и еще кое-что. Хотите поговорить предметно - делаете тесты, присылаете и мы их обсуждаем.
15 апр 10, 14:08    [8634344]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
roden
Member

Откуда:
Сообщений: 741
MBG
roden
MBG
а за счет отказа от большого количества "универсального" кода получаем выигрыш в эффективности системы.

Типа SQlite на локальных машинах круче всех?


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

И прямо таки есть соответствующие тесты? Реально sqlite работает быстрее любой СУБД с клиент-серверной архитектурой?
30 апр 10, 14:47    [8715312]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
roden

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


Ну канешна :)
Особенно на конкурентных update-ах
30 апр 10, 14:57    [8715378]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
roden
MBG
roden

Типа SQlite на локальных машинах круче всех?


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

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

Реально эскулайт может работать быстрее ... :)
А вот насчет сравнения с клиент-серверами .... ну скажем сомневаюсь я насчет всех (и то если мягко сказать)
30 апр 10, 16:10    [8715876]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
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 работает быстрее любой СУБД с клиент-серверной архитектурой?


Я вам не скажу за всю галактику - не в курсе насчет возможностей СУБД на Альдебаране :-)
30 апр 10, 18:58    [8716718]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
MBG
Guest
Gluk (Kazan)
roden

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


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


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

Давайте немного посчитаем: на винте 10 000 RPM мы запросто можем выполнять 100 модифицирующих транзакций в секунду, полагая каждую транзакцию добавляющей всего лишь 100 байт (включая служебные данные, т.е. рассматриваем занятое дисковое пространство), получаем скорость роста БД 10 килобайт в секунду или, при 8-ми часовом рабочем дне (берем по минимуму) с пиковой нагрузкой, в корень из двух раз превышающей среднюю, 100 МБ в сутки или 30 ГБ в год. Срок хранения данных обычно не менее 3-х лет, за это время БД вырастет до 100 ГБ. Это оценка для обычного жесткого диска, причем без потребности в конкурентных апдейтах. Разделяя БД, например, по регионам (коих в России почти сотня), можно работать и с терабайтными датасетами. Но разумеется, у вас все базы как минимум петабайтные, а серверов в вашем кластере больше, чем людей на планете, и эти цифры для вас слишком мелки.
30 апр 10, 19:09    [8716752]     Ответить | Цитировать Сообщить модератору
 Re: PostgreSQL vs MySQL  [new]
Pure.....
Member

Откуда:
Сообщений: 54
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.

Видимо мои тестеры с кривыми руками, но по их тестам постгрес как-то лучше выглядит :)
(точнее по стандартным тестам)
Задумался... может быть действительно будущее за скулайтом?!... Главное не всеми не задумываться ...
13 май 10, 11:52    [8766268]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8      [все]
Все форумы / Сравнение СУБД Ответить