[Comm] MySQL & Postgresql

[Comm] MySQL & Postgresql

[unix9]

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

Re: [Comm] MySQL & Postgresql

[Klimchev Konstantin]

On Mon, 12 Apr 2004 13:44:16 +0400 (MSD)
"unix9" <unix9@yandex.ru> wrote:

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

LDAP

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.ru)
ATK-Internet ISP, Arkhangelsk, Russia

Re[2]: [Comm] MySQL & Postgresql

[Alexander Leschinsky]

Hello Klimchev,

   On Mon, 12 Apr 2004 16:01:06 +0400 (12.04.2004 18:01 my local time),
   received Monday, April 12, 2004 at 20:30:44,
   you wrote about "[Comm] MySQL & Postgresql"
   at least in part:

> LDAP
Subject'ы принципиально не читаем??? И вообще-то ответ спорен, так что -
"обоснование в студию"
-- 
Best regards,
 Alexander Leschinsky

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Mon, Apr 12, 2004 at 08:55:54PM +0600, Alexander Leschinsky wrote:

 >> LDAP
 AL> Subject'ы принципиально не читаем??? И вообще-то ответ спорен, так что -
 AL> "обоснование в студию"

Что лучше ставить на роутер -- Sony PlayStation или Sony Clie?
"обоснование в студию".

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Денис,

   On Tue, 13 Apr 2004 01:29:15 +0400 (13.04.2004 3:29 my local time),
   received Tuesday, April 13, 2004 at 8:33:25,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

 AL>> Subject'ы принципиально не читаем??? И вообще-то ответ спорен, так что -
 AL>> "обоснование в студию"

> Что лучше ставить на роутер -- Sony PlayStation или Sony Clie?
> "обоснование в студию".

Сударь лезет в бутылку??? Ладно, это _Ваш_ выбор. Ответ у меня простой

"Sony PlayStation, потому что настоящий админ-хакер заставит, если
прижмет, работать так как ему надо _любую_ фуфень, а на PS он и играть
может в свою смену, потому что у него все _работает_, а не еле дышит"

А ткперь разберем Ваш оригинальный ответ... Вопрос был задан в предельно
узких рамках "MySQL или PostFix", и возможности расширительного
толкования такая формулировка не предполагает. Домысливать надо за
спрашивающего только в случае неполной|неточной формулировки вопроса,
что в данном случае не наблюдалось, только _неудачная форма_, но
расчет был на то, что отвечающие люди разумные и перед тем, как
отвечать, внимательно ознакомятся с сообщением _полностью_. Мои
поздравления - Вы "тест на разумность" не прошли... "Поспешность нужна
только при ловле блох" (с)

Чем же вреден Ваш совет, ктоме того, что он вообще "не в тему".
1. Статистика по репрезентативной выборке утверждает, что LDAP является
"в среднем по больнице" значительно более редким установленным и
работающим сервисом, чем какая-никакая RDBMS, которые входят де-факто в
состав "must have" служб, функционирующих практически у любого,
связанного с сетевыми услугами (я могу предмтавить ситуацию, где RDBMS
не используется, а все работает, но это - пограничные случаи, исключения
из правил)

2. В связи с пунктом 1 уместно вспонить о бритовке Оккама, и не заводить
еще одну дополнительную сущность, потому что, кромк всего прочего
"Простейшие не болеют" и "Чем тоньше - тем управляемее"

3. MySQL работает как правило _быстрее_ на выполнение аналогичных
запросов, чем LDAP, что в некоторых ситуациях может также быть
определяющим

4. Использование LDAP-транспорта в MTA началось позднее, чем SQL,
следовательно - потенциально граблей необнаруженных в кустах разбросано
больше

5. Администрирование и сопровождение LDAP является (опять же
"усредненно") более нетривиальной задачей, чем аналогичные функции в
случае RDBMS (элементарные в случае My, более сложные... но в
пределах... в случае PostgreSQL). И задача адаптации backend'а в случае
изменения "правил игры" може стать неподъемной задачей. Сколько
подписчиков _этого_ листа имеют собственные MTA и сколько из них при
необходимости могут подхатчить схему, если Гугль им ответа не даст???

Так что советую - думать (головой), прежде чем ляпнуть чушь, и уметь
признать неправоту, если запалился. Errare humanum est, а рогом в землю
упираются ЛАМЕРЫ
-- 
without regards,
 Alexander Leschinsky

Re[2]: [Comm] Re: MySQL & Postgresql

[Nikita Semenov]

Здравствуйте.


Tuesday, April 13, 2004, 12:56:17 PM, вы писали:
AL> 1. Статистика по репрезентативной выборке утверждает, что LDAP является
AL> "в среднем по больнице" значительно более редким установленным и
AL> работающим сервисом, чем какая-никакая RDBMS, которые входят де-факто в
AL> состав "must have" служб, функционирующих практически у любого,
AL> связанного с сетевыми услугами (я могу предмтавить ситуацию, где RDBMS
AL> не используется, а все работает, но это - пограничные случаи, исключения
AL> из правил)

AL> 2. В связи с пунктом 1 уместно вспонить о бритовке Оккама, и не заводить
AL> еще одну дополнительную сущность, потому что, кромк всего прочего
AL> "Простейшие не болеют" и "Чем тоньше - тем управляемее"

AL> 3. MySQL работает как правило _быстрее_ на выполнение аналогичных
AL> запросов, чем LDAP, что в некоторых ситуациях может также быть
AL> определяющим

AL> 4. Использование LDAP-транспорта в MTA началось позднее, чем SQL,
AL> следовательно - потенциально граблей необнаруженных в кустах разбросано
AL> больше

AL> 5. Администрирование и сопровождение LDAP является (опять же
AL> "усредненно") более нетривиальной задачей, чем аналогичные функции в
AL> случае RDBMS (элементарные в случае My, более сложные... но в
AL> пределах... в случае PostgreSQL). И задача адаптации backend'а в случае
AL> изменения "правил игры" може стать неподъемной задачей. Сколько
AL> подписчиков _этого_ листа имеют собственные MTA и сколько из них при
AL> необходимости могут подхатчить схему, если Гугль им ответа не даст???

Это все конечно верно, но есть один момент, который много чего
перевешивает - адресная книга LDAP. Можно конечно конвертить из sql в
ldap, но это напильник... По крайней мере для моего начальства - это
веский аргумент, что б заставить меня разбираться с ldap:)



-- 
Best regards,
Nikita Semenov
System Administer
InterStep
+7(812)324-8020
nikita@inter-step.ru
ICQ: 3939833

Re[3]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Nikita,

   On Wed, 14 Apr 2004 10:34:02 +0400 (14.04.2004 12:34 my local time),
   received Wednesday, April 14, 2004 at 15:09:20,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> Это все конечно верно, но есть один момент, который много чего
> перевешивает - адресная книга LDAP.
LDAP AB - это несколько совсем другой вопрос, чем "хранение локальных
пользователей и роутинга мыла в LDAP". Кроме этого - адресная книга
слабо корррелирует с сущностью "локальные пользователи данного хоста", и
даже с "локальные пользователи группы хостов". Адресбука поднимается "на
раз": схема inetorgperson + /dev/hands - и поехали

AdMinister - оисочка прямо по Фрейду :-)
-- 
Best regards,
 Alexander Leschinsky

Re: [Comm] Re: MySQL & Postgresql

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

В сообщении от Среда 14 Апрель 2004 09:34 Nikita Semenov написал(a):
> Здравствуйте.
>
>
> Tuesday, April 13, 2004, 12:56:17 PM, вы писали:
> AL> 1. Статистика по репрезентативной выборке утверждает, что LDAP является
> AL> "в среднем по больнице" значительно более редким установленным и
> AL> работающим сервисом, чем какая-никакая RDBMS, которые входят де-факто в
> AL> состав "must have" служб, функционирующих практически у любого,
> AL> связанного с сетевыми услугами (я могу предмтавить ситуацию, где RDBMS
> AL> не используется, а все работает, но это - пограничные случаи,
> исключения AL> из правил)
>
> AL> 2. В связи с пунктом 1 уместно вспонить о бритовке Оккама, и не
> заводить AL> еще одну дополнительную сущность, потому что, кромк всего
> прочего AL> "Простейшие не болеют" и "Чем тоньше - тем управляемее"

for me, выбор ldap для mta определялся тем что ldap все равно уже поднят для 
самбы, а в связи с пунктом 2 уместно использовать его и для остального, тем 
более что базы юзеров самбы и почты д.б. изоморфны.

-- 
-------------------------
WBR, Nick S. Grechukh

Refractory Trading House
network administrator

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re[2]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Nick,

   On Wed, 14 Apr 2004 15:03:22 +0300 (14.04.2004 18:03 my local time),
   received Wednesday, April 14, 2004 at 18:36:16,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> for me, выбор ldap для mta определялся тем что ldap все равно уже поднят для
> самбы, а в связи с пунктом 2 уместно использовать его и для остального,
Я не говорил, что "низзя использовать LDAP", а только лишь "что надо
думать и оценивать собственную ситуацию"
-- 
Best regards,
 Alexander Leschinsky

Re: [Comm] Re: MySQL & Postgresql

[Nick S. Grechukh]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

В сообщении от Среда 14 Апрель 2004 15:55 Alexander Leschinsky написал(a):
> Hello Nick,
>
>    On Wed, 14 Apr 2004 15:03:22 +0300 (14.04.2004 18:03 my local time),
>    received Wednesday, April 14, 2004 at 18:36:16,
>    you wrote about "[Comm] Re: MySQL & Postgresql"
>
>    at least in part:
> > for me, выбор ldap для mta определялся тем что ldap все равно уже поднят
> > для самбы, а в связи с пунктом 2 уместно использовать его и для
> > остального,
>
> Я не говорил, что "низзя использовать LDAP", а только лишь "что надо
> думать и оценивать собственную ситуацию"

экстраполируем мои рассуждения на случай dhcp, ... etc - в итоге получаем 
"LDAP паранойя" (c) ala MS AD

-------------------------
WBR, Nick S. Grechukh

Refractory Trading House
network administrator

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Re[2]: [Comm] Re: MySQL & Postgresql

[Gleb Kulikov]

В сообщении от Среда 14 Апрель 2004 13:34 Nikita Semenov написал:

> Это все конечно верно, но есть один момент, который много чего
> перевешивает - адресная книга LDAP. Можно конечно конвертить из sql в
> ldap, но это напильник... По крайней мере для моего начальства - это
> веский аргумент, что б заставить меня разбираться с ldap:)

О! Ты разбирался с возможностями типа адр. книги? Не поможешь ли с глупейшим 
вопросом -- а можно ли на ldap строить *индивидуальные* и независимые (для 
многих пользователей) адресные книги? Естественно, изменяемые самими 
пользователями, средствами почтовых клиентов?

-- 
			Салют, /GLeb

Re[4]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Gleb,

   On Thu, 15 Apr 2004 00:11:19 +0700 (14.04.2004 23:11 my local time),
   received Thursday, April 15, 2004 at 1:41:00,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> а можно ли на ldap строить *индивидуальные* и независимые (для 
> многих пользователей) адресные книги?
Можно... точнее - дерево-то всяко одно, но у каждого свой Base DN и
соответсвующим образом построенные ACL
-- 
Best regards,
 Alexander Leschinsky

Re: [Comm] Re: MySQL & Postgresql

[Eugene Prokopiev]

> 3. MySQL работает как правило _быстрее_ на выполнение аналогичных
> запросов, чем LDAP, что в некоторых ситуациях может также быть
> определяющим

_как правило_ наоборот :) ну по крайней мере по отношению к почте.

Кроме того, можно по пальцам пересчитать сервисы, для которых 
прикручивание ldap требует очень большого и толстого напильника, обычно 
обходимся маленьким :)

А для реляционных СУБД делать самому этот большой и толстый напильник 
придется чаще.

-- 
С уважением, Прокопьев Евгений

Re[2]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Eugene,

   On Wed, 14 Apr 2004 17:11:19 +0400 (14.04.2004 19:11 my local time),
   received Thursday, April 15, 2004 at 1:40:27,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> _как правило_ наоборот :) ну по крайней мере по отношению к почте.
"Цифры, сестра!!! Назови цифры"...
-- 
Best regards,
 Alexander Leschinsky

Re: [Comm] Re: MySQL & Postgresql

[Eugene Prokopiev]

Alexander Leschinsky пишет:
> Hello Eugene,
> 
>    On Wed, 14 Apr 2004 17:11:19 +0400 (14.04.2004 19:11 my local time),
>    received Thursday, April 15, 2004 at 1:40:27,
>    you wrote about "[Comm] Re: MySQL & Postgresql"
>    at least in part:
> 
> 
>>_как правило_ наоборот :) ну по крайней мере по отношению к почте.
> 
> "Цифры, сестра!!! Назови цифры"...

ну сошлемся на авторитеты :)

читать README.ALT из courier-imap-doc, там цифры есть

-- 
С уважением, Прокопьев Евгений

Re[2]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Eugene,

   On Thu, 15 Apr 2004 08:32:44 +0400 (15.04.2004 10:32 my local time),
   received Thursday, April 15, 2004 at 12:38:00,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> ну сошлемся на авторитеты :)
FYI - админ обязан иметь свое мнение, а не косить на авторитеты, потому
что за систему отвечает он, а не дядя-авторитет

> читать README.ALT из courier-imap-doc
Глубокоуважаемый джинн меня чрезвычайно обяжен, если процитирует -
Курьера у меня нет, и не будет... А тянуть ради доки - ломает, знаете
ли...
-- 
Best regards,
 Alexander Leschinsky

Re: [Comm] Re: MySQL & Postgresql

[Eugene Prokopiev]

Alexander Leschinsky пишет:

> Hello Eugene,
> 
>    On Thu, 15 Apr 2004 08:32:44 +0400 (15.04.2004 10:32 my local time),
>    received Thursday, April 15, 2004 at 12:38:00,
>    you wrote about "[Comm] Re: MySQL & Postgresql"
>    at least in part:
> 
> 
>>ну сошлемся на авторитеты :)
> 
> FYI - админ обязан иметь свое мнение, а не косить на авторитеты, потому
> что за систему отвечает он, а не дядя-авторитет

В принципе Вы правы, но проверять самому _все_, а не то, что не было 
проверено до меня более квалифицированными людьми (такими, как мантейнер 
maildrop и courier-imap, например), я смысла не вижу. Т.е. смысл все же 
есть, но времеми жалко.

Цитата к месту (из Литтлвуда):

...

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

Дарвин играл на трубе перед своими тюльпанами. Результат этого 
эксперимента оказался отрицательным.

...

>>читать README.ALT из courier-imap-doc
> 
> Глубокоуважаемый джинн меня чрезвычайно обяжен, если процитирует -
> Курьера у меня нет, и не будет... А тянуть ради доки - ломает, знаете
> ли...

less /usr/share/doc/maildrop-1.5.1/maildrop.README-ALT

...

Из собственных изысков на тему быстродействия:
----------------------------------------------
Не рекомендуется использовать данный MDA (maildrop-mysql) на достаточно
загруженных серверах все-в-одном (т.е. maildrop и MySQL-сервер на одной
машине), т.к. каждое доставляемое сообщение порождает новое соедиение с
MySQL-сервером. В такой конфигурации машина (PIII-866, 512Mb RAM, SCSI-
диски отдельно для SQL и отдельно для Mailserver'а) с sendmail'ом
отказывалась доставлять почту в почтовый ящик при потоке писем 50/70
сообщений (2-8кб каждое) в минуту на 10 почтовых ящиков в формате Maildir
и очень медленно реагировала на команды администратора. Почта скапливалась
в /var/spool/mqueue/.

Та же машина, но с maildrop-ldap, sendmail (плюс несколько проверок с
обращениями к LDAP-серверу) стабильно держала поток 600-700msg/min того
же размера, на те же ящики.

Sendmail(в стандартной конфигурации)+procmail(никаких фильтров, как local
MDA для sendmail) сваливался в "queue only" на потоке ~30msg/min.

...

-- 
С уважением, Прокопьев Евгений

Re[2]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Eugene,

   On Thu, 15 Apr 2004 13:12:30 +0400 (15.04.2004 15:12 my local time),
   received Thursday, April 15, 2004 at 15:59:48,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> В принципе Вы правы, но проверять самому _все_, а не то, что не было 
> проверено до меня более квалифицированными людьми (такими, как мантейнер
> maildrop и courier-imap, например), я смысла не вижу.
Очень жаль. Мои соболезнования Вашему работтодателю

> Т.е. смысл все же есть, но времеми жалко.
"Не понл..." Вы в игрушеи играетесь или работаете? "Времени жалко...",
ндя... А верить нельзя никому, потому что после этого

----->8-------------------------------------- from WinClipboard
Sendmail(в стандартной конфигурации)+procmail(никаких фильтров, как local
MDA для sendmail) сваливался в "queue only" на потоке ~30msg/min.
----->8--------------------------------------------------------
_я_ больше ни букве не поверю в исполнении автора... Я не знаю, как
суметь _так_ загнуть шлимыл... И про "стандартную конфигурацию" петь не
надо - мой шлимыл совсем не "стандартный", обшеван мильтерами "по
самое", но с такой нагрузкой справляется регулярно и не кашляет, потому
что это реально не нагрузка, а баловство

Statistics by Hour
-------------------------------------
Hour                 Spam         Ham
--------------   --------    --------
2004-04-14, 09        117          57
2004-04-14, 10         94         111
...
2004-04-13, 14        128         111
2004-04-13, 15         80         169
2004-04-13, 16         98         193
2004-04-13, 17         94         127
2004-04-13, 18        111          90
...
2004-04-12, 09        119          54
2004-04-12, 10        120          72
...
2004-04-12, 23        160         101
...
2004-04-10, 00         89         426
2004-04-10, 01        102          67
...
2004-04-10, 04         84         125
...
2004-04-10, 11        102          82
...
2004-04-10, 13        116         102
...
2004-04-09, 09        147         105
2004-04-09, 10        116         126
2004-04-09, 11        116         113
2004-04-09, 12        106         121
2004-04-09, 13        141         106
...
2004-04-09, 15        111         453
2004-04-09, 16        115          89
...
2004-04-08, 10        104          96
2004-04-08, 11         94         110
2004-04-08, 12        103         115
2004-04-08, 13        101         106

-- 
Best regards,
 Alexander Leschinsky

Re: Re[2]: [Comm] Re: MySQL & Postgresql

[Mike Lykov]

В сообщении от Четверг 15 Апрель 2004 16:16 Alexander Leschinsky написал:

> надо - мой шлимыл совсем не "стандартный", обшеван мильтерами "по
> самое", но с такой нагрузкой справляется регулярно и не кашляет, потому
> что это реально не нагрузка, а баловство
> Statistics by Hour
> 2004-04-14, 09        117          57
> 2004-04-14, 10         94         111

у вас тут 150 мессаг в час, а у него - 30 мессаг в минуту.
соотв, 30*60 = 1800 мессаг в час.

когда у вас тоже будет 1800, тогда приходите.
-- 
Mike

Re: [Comm] Re: MySQL & Postgresql

[Klimchev Konstantin]

On Thu, 15 Apr 2004 16:41:04 +0500
Mike Lykov <combr@vesna.ru> wrote:

> у вас тут 150 мессаг в час, а у него - 30 мессаг в минуту.
> соотв, 30*60 = 1800 мессаг в час.
> 
> когда у вас тоже будет 1800, тогда приходите.

у нас тут чистый sendmail (без maildrop'а)+drweb. Ради интереса посчитал - чуть больше 35 тыс. сообшений за сегодня (в среднем получилось 36 сообщений в минуту). Работает на 466 целерон с 512Мб памяти на FreeBSD, но видно что ооочень тяжело ему.

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.ru)
ATK-Internet ISP, Arkhangelsk, Russia

Re: [Comm] Re: MySQL & Postgresql

[Dmitry Lebkov]

On Thu, 15 Apr 2004 15:54:59 +0400
Klimchev Konstantin <koka@atvc.ru> wrote:

> On Thu, 15 Apr 2004 16:41:04 +0500
> Mike Lykov <combr@vesna.ru> wrote:
> 
> > у вас тут 150 мессаг в час, а у него - 30 мессаг в минуту.
> > соотв, 30*60 = 1800 мессаг в час.
> > 
> > когда у вас тоже будет 1800, тогда приходите.
> 
> у нас тут чистый sendmail (без maildrop'а)+drweb. Ради интереса
> посчитал - чуть больше 35 тыс. сообшений за сегодня (в среднем
> получилось 36 сообщений в минуту). Работает на 466 целерон с 512Мб
> памяти на FreeBSD, но видно что ооочень тяжело ему.

Интересна не "средняя темпиратура по больнице, включая морг", а
целенаправленное измерение с указанными условиями. "Термометр"
можно взять здесь - http://www.coker.com.au/postal/.

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


--
WBR, Dmitry Lebkov

Re: [Comm] Re: MySQL & Postgresql

[Klimchev Konstantin]

On Thu, 15 Apr 2004 23:24:15 +1100
Dmitry Lebkov <dima@sakhalin.ru> wrote:

> Интересна не "средняя темпиратура по больнице, включая морг", а
> целенаправленное измерение с указанными условиями. "Термометр"
> можно взять здесь - http://www.coker.com.au/postal/.

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

-- 
Best Regards, Konstantin Klimchev 
(mailto:koka@atvc.ru    jabber:koka@jabber.ru)
ATK-Internet ISP, Arkhangelsk, Russia

Re[4]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Mike,

   On Thu, 15 Apr 2004 16:41:04 +0500 (15.04.2004 17:41 my local time),
   received Thursday, April 15, 2004 at 19:28:27,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> соотв, 30*60 = 1800 мессаг в час.
Ну промахнулся на порядок, хотя и таких хостов найти не проблема...
-- 
Best regards,
 Alexander Leschinsky

Re: Re[2]: [Comm] Re: MySQL & Postgresql

[Dmitry Lebkov]

On Thu, 15 Apr 2004 17:16:47 +0600
Alexander Leschinsky <byyjrtnybq@ural.ru> wrote:

> Hello Eugene,
> 
>    On Thu, 15 Apr 2004 13:12:30 +0400 (15.04.2004 15:12 my local time),
>    received Thursday, April 15, 2004 at 15:59:48,
>    you wrote about "[Comm] Re: MySQL & Postgresql"
>    at least in part:

[skip]

> ----->8-------------------------------------- from WinClipboard
> Sendmail(в стандартной конфигурации)+procmail(никаких фильтров, как local
> MDA для sendmail) сваливался в "queue only" на потоке ~30msg/min.
> ----->8--------------------------------------------------------
> _я_ больше ни букве не поверю в исполнении автора... Я не знаю, как
> суметь _так_ загнуть шлимыл... И про "стандартную конфигурацию" петь не
> надо - мой шлимыл совсем не "стандартный", обшеван мильтерами "по
> самое", но с такой нагрузкой справляется регулярно и не кашляет, потому
> что это реально не нагрузка, а баловство

Уважаемый, ваше право - верить/не верить. Цифры указанные в README.ALT
были получены на ALT Linux Sisyphus'е декабря 2002 года и "стандартные
конфигурации" - конфигурации по-умолчанию для данных пакетов в Сизифе.

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


> Statistics by Hour
> -------------------------------------
> Hour                 Spam         Ham
> --------------   --------    --------

[skip]

А вот статистика, которую вы привели - действительно, "баловство", а
не нагрузка.

--
Dmitry Lebkov

Re[4]: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Dmitry,

   On Thu, 15 Apr 2004 22:56:56 +1100 (15.04.2004 17:56 my local time),
   received Thursday, April 15, 2004 at 19:28:27,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> Вы можете повторить эксперимент - железо и софт известны. Cомневаюсь,
> что цифры будут сильно отличаться.
Миль пардон, я на порядок обсчитался... Ладно, поставлю "шлимыло от
Netch" и проверю...
-- 
Best regards,
 Alexander Leschinsky

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Tue, Apr 13, 2004 at 02:56:17PM +0600, Alexander Leschinsky wrote:

 AL> Сударь лезет в бутылку??? Ладно, это _Ваш_ выбор. Ответ у меня простой
 AL> А ткперь разберем Ваш оригинальный ответ...

Сударь не умеет отматывать треды, или я окончательно свихнулся? Вроде бы
то было моё единственное письмо в этом треде.
 
 AL> Чем же вреден Ваш совет, ктоме того, что он вообще "не в тему".
 AL> 1. Статистика по репрезентативной выборке утверждает, что LDAP является
 AL> "в среднем по больнице" значительно более редким установленным и
 AL> работающим сервисом, чем какая-никакая RDBMS, которые входят де-факто в
 AL> состав "must have" служб, функционирующих практически у любого,
 AL> связанного с сетевыми услугами (я могу предмтавить ситуацию, где RDBMS
 AL> не используется, а все работает, но это - пограничные случаи, исключения
 AL> из правил)
 AL> 2. В связи с пунктом 1 уместно вспонить о бритовке Оккама, и не заводить
 AL> еще одну дополнительную сущность, потому что, кромк всего прочего
 AL> "Простейшие не болеют" и "Чем тоньше - тем управляемее"

OpenLDAP внутри явно проще, чем PostgreSQL :) Но второй при этом
управляемее (триггеры рулят).
 
 AL> 3. MySQL работает как правило _быстрее_ на выполнение аналогичных
 AL> запросов, чем LDAP, что в некоторых ситуациях может также быть
 AL> определяющим

Фишка в том, что далеко не все frontend'ы умеют держать пул установленых
соединений с SQL-сервером. В случае LDAP накладные расходы на установление
соединения меньше (AFAIR). Это и является определяющим фактором.
 
 AL> 4. Использование LDAP-транспорта в MTA началось позднее, чем SQL,
 AL> следовательно - потенциально граблей необнаруженных в кустах разбросано
 AL> больше

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

Пожалуйста, будьте осторожнее с применяемой логикой, дабы она была более
логичной :)
 
 AL> 5. Администрирование и сопровождение LDAP является (опять же
 AL> "усредненно") более нетривиальной задачей, чем аналогичные функции в
 AL> случае RDBMS (элементарные в случае My, более сложные... но в
 AL> пределах... в случае PostgreSQL). И задача адаптации backend'а в случае
 AL> изменения "правил игры" може стать неподъемной задачей. Сколько
 AL> подписчиков _этого_ листа имеют собственные MTA и сколько из них при
 AL> необходимости могут подхатчить схему, если Гугль им ответа не даст???

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

 AL> Так что советую - думать (головой), прежде чем ляпнуть чушь, и уметь
 AL> признать неправоту, если запалился. Errare humanum est, а рогом в землю
 AL> упираются ЛАМЕРЫ

Спорить с этим не буду, ибо правильно.
 
-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Денис,

   On Wed, 14 Apr 2004 17:45:14 +0400 (14.04.2004 19:45 my local time),
   received Thursday, April 15, 2004 at 1:40:41,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

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

>  Вроде бы
> то было моё единственное письмо в этом треде.
Mea Culpa

> OpenLDAP внутри явно проще, чем PostgreSQL :) Но второй при этом
> управляемее (триггеры рулят).
Я не рискну утверждать такое однозначно...

> В случае LDAP накладные расходы на установление
> соединения меньше (AFAIR). Это и является определяющим фактором.
Уточним - для Вас в Вашей ситуации и условиях... Мы же даже не знаем,
зачем и почему unix9 решил, что его классические методы хранения данных
не устраивают... Может ему небольшие задержки глубоко фиолетовы, а надо
что-то совсем вычурное???

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

> Пожалуйста, будьте осторожнее с применяемой логикой, дабы она была более
> логичной :)
У меня нет проблем с логикой... Если у Вас непонимание - то это не повод
пытаться уесть меня казуистическими вывертами. "Расслабьтесь и откиньтесь
на спинку стула" (или как это там звучит) - не получится... Я
иезуитствую дольше, чем Вы живете на этом свете (и я хорошо учился у
мастеров, и учусь)

> А вот это действительно ключевой параметр. И именно по нему в бою у меня
> сейчас машина на PostgreSQL.

С другой стороны - Постгресс медленнее My (и не знаю, как
там у семерки с масштабируемостью).
-- 
Best regards,
 Alexander Leschinsky

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Thu, Apr 15, 2004 at 02:18:34AM +0600, Alexander Leschinsky wrote:

>> В случае LDAP накладные расходы на установление
>> соединения меньше (AFAIR). Это и является определяющим фактором.
 AL> Уточним - для Вас в Вашей ситуации и условиях... Мы же даже не знаем,
 AL> зачем и почему unix9 решил, что его классические методы хранения данных
 AL> не устраивают... Может ему небольшие задержки глубоко фиолетовы, а надо
 AL> что-то совсем вычурное???

Принято.

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

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

Кроме того, можно добавить уточнение в стиле "sendmail vs postfix" (кто
больше оттестирован? а у кого дырки чаще находят?). Так что возраст сам по
себе ничего не значит.

 >> Пожалуйста, будьте осторожнее с применяемой логикой, дабы она была более
 >> логичной :)
 AL> У меня нет проблем с логикой... Если у Вас непонимание - то это не повод
 AL> пытаться уесть меня казуистическими вывертами. "Расслабьтесь и откиньтесь
 AL> на спинку стула" (или как это там звучит) - не получится... Я
 AL> иезуитствую дольше, чем Вы живете на этом свете (и я хорошо учился у
 AL> мастеров, и учусь)

:-)

 >> А вот это действительно ключевой параметр. И именно по нему в бою у меня
 >> сейчас машина на PostgreSQL.
 AL> С другой стороны - Постгресс медленнее My (и не знаю, как
 AL> там у семерки с масштабируемостью).

С масштабируемостью -- надо смотреть на какого рода задачах. Как раз
благодаря триггерам можно делать некоторые трюки, которые делают на
_некоторых конкретных задачах_ его несравнимо быстрее MySQL. В целом же,
если база простая но большая (как например в случае почтовки) MySQL,
_наверное_ будет быстрее, но я не тестировал. У меня не те объёмы чтобы
эта разница имела хоть какую-то роль.

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Денис,

   On Thu, 15 Apr 2004 01:59:48 +0400 (15.04.2004 3:59 my local time),
   received Thursday, April 15, 2004 at 7:44:48,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> Однако Вы почему-то пользуетесь именно электронной почтой. Я просто
> показал своей заменой слов, что ваше замечание само по себе не может быть
> аргументов в применённом виде.
Может... чтобы наш разговор не стал уж совсем полным оффтопиком:

"Инструменты выбираются в зависимости от весов приоритетов. И должны
выбираться _всегда_ так, а не на уровне ОБС, или 'это я знаю, и потому
это лучше'"

Если для меня наивысшим приоритетом является скорость, и всем остальным
я сознательно могу пожертвовать - выбирается e-mail
Если я не так заряжен на скорость, но нарантированность доставки мне
нужна - то в приличные места поедет обычная почта, или "заказное с
уведомлением о вручении"

Если мне нужно и быстро и гарантированно, и качественно, и без
головняков (а то вот посылочка из Питера месяц где-то гуляет), и
напревать на цену - я зайду в DHL

"See difference!"

> Кроме того, можно добавить уточнение в стиле "sendmail vs postfix" (кто
> больше оттестирован? а у кого дырки чаще находят?). Так что возраст сам по
> себе ничего не значит.
Ох, я Вас умоляю, какие страсти Вы за сендмыл говорите... CAN что-то там
публикует, что-то даже может быть (вроде как) выхакано... но токо вот
что-то после Морриса с сендмылом ничего не случалось... Сомневаетесь - я
выставлю 8.9.3 в Сеть, и он будет комфортно жить...

А про постфикс - лучше анеком
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Как-то вечером гуляли по полной русский инженер и "поручик от
инфантерии"... Проснулись утром в номерах - у анжинера похмелье, свет не
мил... А поручик вскочил  - и как огурчик, свеж и гладок.
Инженер: "Поручик, а голова у Вас не болит???"
Поручик: "Ха! А чему там болеть??? там же  к о с т ь !!!"


-- 
Best regards,
 Alexander Leschinsky

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Thu, Apr 15, 2004 at 01:17:11PM +0600, Alexander Leschinsky wrote:

 AL> "Инструменты выбираются в зависимости от весов приоритетов. И должны
 AL> выбираться _всегда_ так, а не на уровне ОБС, или 'это я знаю, и потому
 AL> это лучше'"

[skip]

Согласен.

>> Кроме того, можно добавить уточнение в стиле "sendmail vs postfix" (кто
>> больше оттестирован? а у кого дырки чаще находят?). Так что возраст сам по
>> себе ничего не значит.
 AL> Ох, я Вас умоляю, какие страсти Вы за сендмыл говорите... CAN что-то там
 AL> публикует, что-то даже может быть (вроде как) выхакано... но токо вот
 AL> что-то после Морриса с сендмылом ничего не случалось... Сомневаетесь - я
 AL> выставлю 8.9.3 в Сеть, и он будет комфортно жить...

Я не рассказывал страстей. Мало того, я даже не кричал что "постфикс
рулит" а "сендмыл сосёт", ибо видел пару раз как люди знающие сендмыл
вытворяли на нём такое...

Однако факт есть факт -- дыры в нём находят чаще чем в postfix, несмотря
на то, что postfix моложе. Вывод -- возраст ничего не говорит о
надёжности. Только возраст "без найденых дыр и глюков" может говорить
(например как в случае с TeX).
 
-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: MySQL & Postgresql

[Alexander Leschinsky]

Hello Денис,

   On Fri, 16 Apr 2004 02:41:10 +0400 (16.04.2004 4:41 my local time),
   received Friday, April 16, 2004 at 4:56:05,
   you wrote about "[Comm] Re: MySQL & Postgresql"
   at least in part:

> я даже не кричал что "постфикс рулит" а "сендмыл сосёт"
И это хорошо, а то бы я выкатил полковую артиллерию на прямую наводку
:-)

> Однако факт есть факт -- дыры в нём находят чаще чем в postfix, несмотря
> на то, что postfix моложе. Вывод -- возраст ничего не говорит о
> надёжности.
Пока люди пишут программы, в них будут ошибки

>  Только возраст "без найденых дыр и глюков" может говорить
> (например как в случае с TeX).
Анекдот про неуловимого Джо напомнить?
-- 
Best regards,
 Alexander Leschinsky

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Fri, Apr 16, 2004 at 05:29:06AM +0600, Alexander Leschinsky wrote:

 >> Однако факт есть факт -- дыры в нём находят чаще чем в postfix, несмотря
 >> на то, что postfix моложе. Вывод -- возраст ничего не говорит о
 >> надёжности.
 AL> Пока люди пишут программы, в них будут ошибки

Согласен. Вопрос лишь в том, насколько часто их находят и от чего это
зависит. От "долголетия" программы надёжность не зависит, кроме случая
когда программа не развивается а только фиксится (или даже не фиксится,
ибо нечему). Пример -- qmail.

Собственно это было сказано лишь как довод к тому, что длительность
существования какой-то технологии _никак_ не связана сама по себе с её
качеством.

 >>  Только возраст "без найденых дыр и глюков" может говорить
 >> (например как в случае с TeX).
 AL> Анекдот про неуловимого Джо напомнить?

Не надо :)

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: MySQL & Postgresql

[harlan]

> если база простая но большая (как например в случае почтовки) MySQL,
> _наверное_ будет быстрее, но я не тестировал. У меня не те объёмы чтобы
> эта разница имела хоть какую-то роль.

А тут, как обычно, мнения в сети разделились 50/50. Одни кричат что Мускул быстрее,
Другие, что Мускул после 100000 записей сдыхает. Правды и в тех и в других
выссказываниях, думаю, так же - 50/50.

Я уже давно зарёкся в форумах спрашивать у народа - "что лучше?"
ИМХО, что тебе самому по душе, тем и пользуйся...

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Thu, Apr 15, 2004 at 02:19:13PM +0700, harlan wrote:

 >> если база простая но большая (как например в случае почтовки) MySQL,
 >> _наверное_ будет быстрее, но я не тестировал. У меня не те объёмы чтобы
 >> эта разница имела хоть какую-то роль.
 h> А тут, как обычно, мнения в сети разделились 50/50. Одни кричат что Мускул быстрее,
 h> Другие, что Мускул после 100000 записей сдыхает. Правды и в тех и в других
 h> выссказываниях, думаю, так же - 50/50.
 h> Я уже давно зарёкся в форумах спрашивать у народа - "что лучше?"
 h> ИМХО, что тебе самому по душе, тем и пользуйся...

IMHO надо спрашивать не "что лучше", а "чем отличается" и "где грабли".

Скажем мне вообще sqlite понравился, и у меня есть уйма задач, которые я
буду решать им. И на них он по всем параметрам превосходит и PostgreSQL, и
MySQL, и IBM DB2 вместе взятые :) И ведь, собака такая, работает быстрее
:)

-- 
С уважением, Денис

http://freesource.info

Re: [Comm] Re: MySQL & Postgresql

[harlan]

> IMHO надо спрашивать не "что лучше", а "чем отличается" и "где грабли".
Согласен на все 100.

> Скажем мне вообще sqlite понравился, и у меня есть уйма задач, которые я
> буду решать им. 
Да ради Бога! Флаг тебе в руки, но навяливать, что sqlite - единственное 
возможное решение, я надеюсь, ты не собиравешься? Тогда готов пожать твою
руку.

> И на них он по всем параметрам превосходит и PostgreSQL, и
> MySQL, и IBM DB2 вместе взятые :) И ведь, собака такая, работает быстрее
> :)
М/б. Спорить не собираюсь, так как sqlite - не щупал. Но думаю, что и он подходит
для некоторого круга задачь, а в других случаях нужно что-нить более другое.

-- 
С уважением, Harlan.

[Comm] Re: MySQL & Postgresql

[Денис Смирнов]

On Fri, Apr 16, 2004 at 04:49:59PM +0700, harlan wrote:

 >> Скажем мне вообще sqlite понравился, и у меня есть уйма задач, которые я
 >> буду решать им. 
 h> Да ради Бога! Флаг тебе в руки, но навяливать, что sqlite - единственное 
 h> возможное решение, я надеюсь, ты не собиравешься? Тогда готов пожать твою
 h> руку.

:)

Я считаю что sqlite, так же как и MySQL, и PostgreSQL, и LDAP, и вообще
весь ныне существующий софт -- плохое решение. И если я сяду писать другое
решение, то оно тоже получится плохим. И вообще хороших решений нету. Есть
только решения, которые здесь и сейчас в той или иной степени _применимы_
и _полезны_. Бывает так, что из известных решений какое-то решение
_оптимально_. А вот в _хорошие_ (а тем более _единственно_ возможные) я не
верю.

 >> И на них он по всем параметрам превосходит и PostgreSQL, и
 >> MySQL, и IBM DB2 вместе взятые :) И ведь, собака такая, работает быстрее
 >> :)
 h> М/б. Спорить не собираюсь, так как sqlite - не щупал. Но думаю, что и он подходит
 h> для некоторого круга задачь, а в других случаях нужно что-нить более другое.

Именно так. Конкретно он идеально подходит под круг задач "очень простые
по структуре базы данных, не требующие клиент-серверной архитектуры, но
требующие максимальной производительности на простых запросах". Этот круг
очень узкий, но в своё время именно на этих задачах вылез вверх MySQL.

-- 
С уважением, Денис

http://freesource.info