Редакция журнала "Системный администратор (http://www.samag.ru)"
предоставила возможность разместить статью (http://www.opennet.me/docs/RUS/dbmail_postfix/) про использование реляционной СУБД PostgreSQL в качестве серверного хранилища почтовых сообщений на почтовом сервере на базе Postfix.URL: http://www.opennet.me/docs/RUS/dbmail_postfix/
Новость: http://www.opennet.me/opennews/art.shtml?num=7839
Эдак кто-нибудь придумает и кэш прокси-сервера в СУБД завернуть.
С подходом "Всё в БД!" я не согласен.
Как, впрочем, не согласен со всеми вводными статьи, которые обосновывают хранение почты в реляционной СУБД. Они надуманны, натянуты.Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на чём основано такое спорное, точнее сказать, неверное, утверждение?
Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump или tar ПОВРЕЖДАЛА почтовые сообщения?
Большей гибкости при обработке и анализе корреспонденции - НЕ согласен! - гибкость языка Perl для обработки текста превосходит возможности языка SQL. плюс немеренная туча уже написанных ГОТОВЫХ программ для "обработки и анализа корреспонденции".
Триггеры, представления... ещё можно добавить "хранимые процедуры"
Я видел парсер письма, написанный как хранимая процедура на языке SQL, который при получении неправильно отформатированного письма намерво вешал сервер БД и при этом губил базу. И не говорите про руки программистов - они были ровные, но инструмент не тот! А perl они не владели."Кластеризация, репликация, фрагментирование, отказоустойчивость" - похоже на мантру продавцов SQL-серверов. Отказоустойчивость, производительность, масштабирование не обязательно должны обеспечиваться установкой сервера БД.
возможности SQL-серверов как хранилищ данных весьма преувеличены рекламой производителей. SQL-сервера - это не серебрянная пуля и не killer application, а довольно сложная и громоздкая вещь, которая всё же необходима для некоторых классов задач.
Товарищи прикладные программисты!
Переходя в область системного администрирования, помните, что это другая среда и не следует мерить её своим аршином и применять к ней другой устав!
Нужно отучиться думать на языке SQL и FoxPRO !Однажды на моё предложение рестартонуть squid один человек, исполнявший обязанности сисадмина, воскликнул: "Ты что! там же пользователи!" Нда.
Ещё хотел бы добавить, что после чтения такой статьи на журнал samag.ru никогда не подпишусь. Лучше уж читать англоязычные ресурсы или журнальчик "Ксакеп" как замену Мурзилке.
>Эдак кто-нибудь придумает и кэш прокси-сервера в СУБД завернуть.
>С подходом "Всё в БД!" я не согласен.
Это правильно. каждому инструменту - свое место.>Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на
>чём основано такое спорное, точнее сказать, неверное, утверждение?
Насколько я знаю postfix хранит данные в plain text, тогда
SQL-server более производителен при массовых операциях (поиск, массовое обновление, резервное копирование в бинарном формате), и менее при еденичных операциях.>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить
>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump
>или tar ПОВРЕЖДАЛА почтовые сообщения?
Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап.>Большей гибкости при обработке и анализе корреспонденции - НЕ согласен! - гибкость
>языка Perl для обработки текста превосходит возможности языка SQL. плюс немеренная
>туча уже написанных ГОТОВЫХ программ для "обработки и анализа корреспонденции".
Согласен. для анализа текстов возможностей SQL маловато. да он не для того и создан.>Триггеры, представления... ещё можно добавить "хранимые процедуры"
>Я видел парсер письма, написанный как хранимая процедура на языке SQL, который
>при получении неправильно отформатированного письма намерво вешал сервер БД и
>при этом губил базу. И не говорите про руки программистов -
>они были ровные, но инструмент не тот! А perl они не
>владели.
Чинить руки тому, кто делает это на SQL без ОСОБЫХ причин.>"Кластеризация, репликация, фрагментирование, отказоустойчивость" - похоже на мантру продавцов SQL-серверов. Отказоустойчивость, производительность,
>масштабирование не обязательно должны обеспечиваться установкой сервера БД.
При использовании SQL-серверов этого можно добиться прозрачно для приложения и ОС.Нужно ли это - зависит от задач.
>возможности SQL-серверов как хранилищ данных весьма преувеличены рекламой производителей. SQL-сервера
>- это не серебрянная пуля и не killer application, а довольно
>сложная и громоздкая вещь, которая всё же необходима для некоторых классов
>задач.
SQL-серверов хорошо работает как средство хранения и обработки большого количества СТРУКТУРИРОВАННОЙ информации.
>Нужно отучиться думать на языке SQL и FoxPRO !
Надо научиться думать на языке задачи, а не реализации.
>>Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на
>>чём основано такое спорное, точнее сказать, неверное, утверждение?
>Насколько я знаю postfix хранит данные в plain text, тогда
>SQL-server более производителен при массовых операциях (поиск, массовое обновление, резервное копирование
>в бинарном формате), и менее при еденичных операциях.С какого перепугу SQL хранилище будет быстрее файловой системы ? Особенно если учесть что серверу электронной почты сложные SQL запросы ИМХО нафиг не нужны.
>>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить
>>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump
>>или tar ПОВРЕЖДАЛА почтовые сообщения?
>Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап.Каким образом при использовании Maildir'ов можно получить неконсистентный бэкап ?
Могу себе представить что в бэкап попадет уже удаленное письмо, но не вижу в этом большой проблемы.>SQL-серверов хорошо работает как средство хранения и обработки большого количества СТРУКТУРИРОВАННОЙ информации.
Данные в случае электронной почты практически неструктурированны !! Просто куча блобов, которые надо вывалить клиенту.
>>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить
>>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump
>>или tar ПОВРЕЖДАЛА почтовые сообщения?
>Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап.Сорри, не успел отредактировать пост. Я хотел написать - "когда это команда dump ПОВРЕЖДАЛА хранилище сообщений, например, раздел /var ?"
>>Я видел парсер письма, написанный как хранимая процедура на языке SQL, который
>>при получении неправильно отформатированного письма намерво вешал сервер БД и
>>при этом губил базу. И не говорите про руки программистов -
>>они были ровные, но инструмент не тот! А perl они не
>>владели.
>Чинить руки тому, кто делает это на SQL без ОСОБЫХ причин.Чинить руки было уже не кому - программист, написавший ЭТО, уже там не работал, а проблема проявилась через несколько лет.
Я его не ругаю за то, что он так сделал, но мне жаль, что он не знал тогда других средств, кроме любимого диалекта SQL.
>Надо научиться думать на языке задачи, а не реализации.Прекрасная формулировка.
Если бы дело одной скоростью ограничивалось... Есть еще потенциальная возможность для SQL инъекций. В общем нафиг такое счастье.
Красиво отстаиваешь свою точку зрения. Это 5!
На мой взгляд, когда пользователей более 50 и идет интенсивный обмен почтой, единое хранилище писем вполне зравое решение. тот же Exchange хранит все письма в одной базе, да, это не MS SQL, а что-то более простое. Когда писем несколько десятков тысяч у одного пользователя, и всего их тысячи полторы (не у всех такие большие ящики, пусть у 10%), то производительность файловой системы и системы SCSI - это узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение?Отчасти есть здравый смысл - маниакальное увлечение интеграцией всего в sql. Но в большом количестве их оно оправдано.
>Красиво отстаиваешь свою точку зрения. Это 5!
>На мой взгляд, когда пользователей более 50 и идет интенсивный обмен почтой,
>единое хранилище писем вполне зравое решение. тот же Exchange хранит все
>письма в одной базе, да, это не MS SQL, а что-то
>более простое.Брр, нашли на что равняться.
А технически возражу так, при попытке изобрести собственное хранилище вы немедленно столкнетесь с теми же проблемами что и при разработке ФС:
1) система хранения метаданных и связанные с ней чудеса, разграничение доступа, блокировки...
2) фрагментация области хранения данных
3) и это только то что сразу приходит в голову :)Уверены что решите все эти проблемы лучше разработчиков ext3 или XFS ?
А SQL сервера обладают совершенно избыточной (для хранилища электронной почты) функциональностью.
> Когда писем несколько десятков тысяч у одного пользователя, и
>всего их тысячи полторы (не у всех такие большие ящики, пусть
>у 10%), то производительность файловой системы и системы SCSI - это
>узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение?Неправильно. Мое частное решение - RAID 10 с аппаратным RAID контроллером и приличные ФС (ext3 c dir_index например) ну и памяти чем больше тем лучше. Юзеров ~10000, почтовые ящики у них самого различного размера в том числе и с многими тысячами сообщений. Что я делаю не так и чем мне поможет SQL ?
Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда и вспомните про SQL...
>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогдаНе у всех такое счастье.
Всё равно, спасибо за пожелание!
>>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда
>Не у всех такое счастье.
10000 * 1000 = 10 000 000 - 10 лимонов.
при таком количестве и "база" не спасёт, а решения аля гугл ;)
>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда
>и вспомните про SQL...у вас серьезно 10000000 пользователей? и из них хотя бы треть активна? на одном хосте? что же это за хост, позвольте полюбопытствовать?
а то тут года три лет назад Шарун (которому у меня нет оснований не верить как постмастеру) рассказывал в ru.unix, что SQL-решения терпимы только если пользователей не больше 1000.
и тогда же Нечаев (который тоже весьма компетентен как постмастер) рассказывал слезную историю про freemail.ru и то, что тамошний админ серьезно задумался о взглядах на жизнь после первой попытки починить что-то в базе почты, которая хранилась в MySQL с помощью myisamchk.
сей тред можно посмотреть тут, например: <http://groups.google.com/group/fido7.ru.unix/browse_frm/thre...
>Брр, нашли на что равняться.
Согласен.>А технически возражу так, при попытке изобрести собственное хранилище вы немедленно столкнетесь
>с теми же проблемами что и при разработке ФС:
>1) система хранения метаданных и связанные с ней чудеса, разграничение доступа, блокировки...
>2) фрагментация области хранения данных
>3) и это только то что сразу приходит в голову :)А зачем мне нужны мета-данные, разграничение доступа и т.п. у меня ведь только одна программа лезет в хранилище, она и разграничевает доступ.
Значит - это не нужная функциональность.
+ я могу построить индексы по нужным мне для анализа полям.
а можно ли построить ускорить поиск по данным from: в maildir.>Уверены что решите все эти проблемы лучше разработчиков ext3 или XFS ?
нет, поскольку не стоит задачи разработать ФС, нужно лишь хранить информацию о почте.
И наверняка можно сделать частное решение которе будет лучше/ быстрее для данной задачи, чем общее.
А рэйзер4, как я понял, использует что-то типа БД внутри себя для ускорения доступа.>А SQL сервера обладают совершенно избыточной (для хранилища электронной почты) функциональностью.
ФС тоже (см. выше)
>Неправильно. Мое частное решение - RAID 10 с аппаратным RAID контроллером и
>приличные ФС (ext3 c dir_index например) ну и памяти чем больше
>тем лучше. Юзеров ~10000, почтовые ящики у них самого различного размера
>в том числе и с многими тысячами сообщений. Что я делаю
>не так и чем мне поможет SQL?ЗЫ насколько помню после какого-то количества файлов в директории под ext3 система начинает тормозить при работе в этой директории.
>Красиво отстаиваешь свою точку зрения. Это 5!>Когда писем несколько десятков тысяч у одного пользователя, и
>всего их тысячи полторы (не у всех такие большие ящики, пусть
>у 10%), то производительность файловой системы и системы SCSI - это
>узкое место. Да, есть выход - поставить винты на FC. Это
>Ваше решение?
решение хранить почту в СУБД имеет право на жизнь. Потому и существует продукт DBMail, и он востребован, потому что есть среды, где это необходимо. Я благодарен автору, что он сообщил мне о его существовании.Но я возразил против вводной части статьи, которая IMHO описывает мнимые, надуманные преимущества такого решения. И представляет такое решение как панацею.
>то производительность файловой системы и системы SCSI - это
>узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение?А-ха ... :-)
А базы вашего SQL-я не живут на FS лежаших на "узкоместных" SCSI ? :-)
Про бакап тоже смешно - юзая dump на FreeBSD и Solaris обычно юзают и snapshot :) О какой неконсистентности речь?
Ну а теперь реальный плюс решения на DB. Не упомянутый, но на мое IMHO _самый_ значительный. Это универсальность доступа. Любой скрипт на любом языке может манипулировать почтой ч/з SQL. Это _гораздо_ проще программируется чем доступ ч/з "родные" методы. Кроме того если повезет вы можете полностью заменить "бэкэнд" (почтовую систему) - не меняя скрипты вообше :)
GR.
IBM has already made such a system - AS400 ;))
this system is just one big database
>IBM has already made such a system - AS400 ;))
>this system is just one big database;)))))
AS400 мало где применяется.
НО! в тех областях, где она задействована, она рвёт на куски задачи, с которыми другие архитектуры просто не способны справиться.
>>IBM has already made such a system - AS400 ;))
>>this system is just one big database
>
>;)))))
>AS400 мало где применяется.Lotus Domino.
"Похоже на голубую мечту сисадмина." (цитата из статьи).
Для меня это кошмарный сон. Я пойду на это, только если этого будет требовать задача.Плохо автор знает сисадминов. А пишет в журнал с таким названием.
Впрочем, если выкинуть вводную часть, статья вменяемая.
>"Похоже на голубую мечту сисадмина." (цитата из статьи).
>Для меня это кошмарный сон. Я пойду на это, только если этого
>будет требовать задача.
>
>Плохо автор знает сисадминов. А пишет в журнал с таким названием.
>
>Впрочем, если выкинуть вводную часть, статья вменяемая.Угу. Для замены корпоративных монстров типа Exchange вполне сойдет, если доведут все обещанные усовершенствования и обезопасят. Но это надо... если очень надо иметь на сервере гигабайтные ящики для толпы юзеров. Для чисто почтовой системы без долговременного хранения громадных объемов корреспонденции классические решения просто надежней и проще.
афтарам желаю не останавливаться на почте: хостинг целиком положить в sql.
одна база = много сервисов + много точек обмена контента + намного упрощается админский тяжёлый однообразный труд.
функционал корпоративных монстров типа Exchange не ограничивается только почтой...
Вот поэтому sql или что похожее здесь смысл, возможно, и имеет. Но все же часто Ексч работает именно почтой, а остальным никто не пользуется...
А может все дружно и вежливо спросят у Google, как они в Gmail хранят десятки тысяч почтовых ящиков по 2.7 Гб каждый ?Велосипед уже изобретен... (c)
Тут есть еще момент разделения обязанностей, сисадмин поддерживает штатное состояние BD + MTU, а всякие перцы которые занимаются базами данных уже делают бекапы и все остальное ибо все это уже есть. Одна из болезней сисадминов - это как раз "делаю все сам" - не дословно но иногда не избежно.
> А может все дружно и вежливо спросят у Google, как они в Gmail хранят десятки тысяч почтовых ящиков по 2.7 Гб каждый ?
А что спрашивать... Неужели непонятно что это маркетинговый ход??
из десятков тысяч -- 100 максимум ради интереса держат в 2.7Гб.. и то за счет других :)))
Нелюбителям хранения писем в DB - идите нафиг, а?Хранить письма прямо в файловой системе есть смысл только если у вас рейзерфс и т.п. файловая система которая сама нечто типа БД и есть.Иначе это редкостный идиотизм.Кроме того, бэкапать одну БД как-то сподручнее чем кучу мелочи.В общем технологии прошлого века - нафиг.Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)
>Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)Действительно непонятно, почему internet messagers ещё не задушили почту.
У Вас есть какие-нибуть соображения?
>>Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)
>
>Действительно непонятно, почему internet messagers ещё не задушили почту.
>У Вас есть какие-нибуть соображения?
1) Неподдержка оффлайн сообщений в МСН протоколе как минимум до недавних времен.
2) Убогие 450-символьные оффлайн соообщения в айсикью которые иногда не доставляются.
3) Кривой жаббер в котором вообще сроду ломаешь голову нал тем что поддерживает а что нет получатель и получит ли он твое сообщение вообще и если да то в каком виде... а уж если сообщение юзеру в асе\мсне через шлюз, там вообще лотерея сплошная...А так - я почти не использую емайл, кому надо пообщаться со мной используют интернет мессенгеры :)