The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Почтовый сервер на основе реляционной СУБД.

05.07.2006 12:46

Редакция журнала "Системный администратор" предоставила возможность разместить статью про использование реляционной СУБД PostgreSQL в качестве серверного хранилища почтовых сообщений на почтовом сервере на базе Postfix.

  1. Главная ссылка к новости (http://www.opennet.me/docs/RUS...)
  2. Создание почтовой системы на базе exim с хранением ящиков в БД.
  3. Почтовый сервер на базе Exim с использованием DbMail для аккаунтов пользователей.
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/7839-dbmail
Ключевые слова: dbmail, mail, postfix
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (28) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, sergei_vasilyev (ok), 13:31, 05/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эдак кто-нибудь придумает и кэш прокси-сервера в СУБД завернуть С подходом Всё... большой текст свёрнут, показать
     
     
  • 2.3, proger (?), 14:20, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Это правильно каждому инструменту - свое место Насколько я знаю postfix хранит... большой текст свёрнут, показать
     
     
  • 3.6, pazke (?), 14:37, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на
    >>чём основано такое спорное, точнее сказать, неверное, утверждение?
    >Насколько я знаю postfix хранит данные в plain text, тогда
    >SQL-server более производителен при массовых операциях (поиск, массовое обновление,  резервное копирование
    >в бинарном формате), и менее при еденичных операциях.

    С какого перепугу SQL хранилище будет быстрее файловой системы ? Особенно если учесть что серверу электронной почты сложные SQL запросы ИМХО нафиг не  нужны.

    >>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить
    >>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump
    >>или tar ПОВРЕЖДАЛА почтовые сообщения?
    >Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап.

    Каким образом при использовании Maildir'ов можно получить неконсистентный бэкап ?
    Могу себе представить что в бэкап попадет уже удаленное письмо, но не вижу в этом большой проблемы.

    >SQL-серверов хорошо работает как средство хранения и обработки большого количества СТРУКТУРИРОВАННОЙ информации.

    Данные в случае электронной почты практически неструктурированны !! Просто куча блобов, которые надо вывалить клиенту.

     
  • 3.7, sergei_vasilyev (ok), 14:52, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/

    >>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить
    >>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump
    >>или tar ПОВРЕЖДАЛА почтовые сообщения?
    >Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап.

    Сорри, не успел отредактировать пост. Я хотел написать - "когда это команда dump ПОВРЕЖДАЛА хранилище сообщений, например, раздел /var ?"


    >>Я видел парсер письма, написанный как хранимая процедура на языке SQL, который
    >>при получении неправильно  отформатированного письма намерво вешал сервер БД и
    >>при этом губил базу. И не говорите про руки программистов -
    >>они были ровные, но инструмент не тот! А perl они не
    >>владели.
    >Чинить руки тому, кто делает это на SQL без ОСОБЫХ причин.

    Чинить руки было уже не кому - программист, написавший ЭТО, уже там не работал, а проблема проявилась через несколько лет.
    Я его не ругаю за то, что он так сделал, но мне жаль, что он не знал тогда других средств, кроме любимого диалекта SQL.


    >Надо научиться думать на языке задачи, а не реализации.

    Прекрасная формулировка.

     
  • 2.4, pazke (?), 14:22, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Если бы дело одной скоростью ограничивалось... Есть еще потенциальная возможность для SQL инъекций. В общем нафиг такое счастье.
     

  • 1.5, scamp (??), 14:23, 05/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Красиво отстаиваешь свою точку зрения. Это 5!
    На мой взгляд, когда пользователей более 50 и идет интенсивный обмен почтой, единое хранилище писем вполне зравое решение. тот же Exchange хранит все письма в одной базе, да, это не MS SQL, а что-то более простое. Когда писем несколько десятков тысяч у одного пользователя, и всего их тысячи полторы (не у всех такие большие ящики, пусть у 10%), то производительность файловой системы и системы SCSI - это узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение?

    Отчасти есть здравый смысл - маниакальное увлечение интеграцией всего в sql. Но в большом количестве их оно оправдано.

     
     
  • 2.9, pazke (?), 15:01, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Красиво отстаиваешь свою точку зрения. Это 5!
    >На мой взгляд, когда пользователей более 50 и идет интенсивный обмен почтой,
    >единое хранилище писем вполне зравое решение. тот же Exchange хранит все
    >письма в одной базе, да, это не MS SQL, а что-то
    >более простое.

    Брр, нашли на что равняться.

    А технически возражу так, при попытке изобрести собственное хранилище вы немедленно столкнетесь с теми же проблемами что и при разработке ФС:
    1) система хранения метаданных и связанные с ней чудеса, разграничение доступа, блокировки...
    2) фрагментация области хранения данных
    3) и это только то что сразу приходит в голову :)

    Уверены что решите все эти проблемы лучше разработчиков ext3 или XFS ?

    А SQL сервера обладают совершенно избыточной (для хранилища электронной почты) функциональностью.

    > Когда писем несколько десятков тысяч у одного пользователя, и
    >всего их тысячи полторы (не у всех такие большие ящики, пусть
    >у 10%), то производительность файловой системы и системы SCSI - это
    >узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение?

    Неправильно. Мое частное решение - RAID 10 с аппаратным RAID контроллером и приличные ФС (ext3 c dir_index например) ну и памяти чем больше тем лучше. Юзеров ~10000, почтовые ящики у них самого различного размера в том числе и с многими тысячами сообщений. Что я делаю не так и чем мне поможет SQL ?

     
     
  • 3.13, Bacek (?), 15:58, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда и вспомните про SQL...
     
     
  • 4.15, sergei_vasilyev (ok), 18:00, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда

    Не у всех такое счастье.
    Всё равно, спасибо за пожелание!

     
     
  • 5.22, don_oles (??), 09:07, 06/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда
    >Не у всех такое счастье.
    10000 * 1000 = 10 000 000 - 10 лимонов.
    при таком количестве и "база" не спасёт, а решения аля гугл ;)
     
  • 4.25, deskpot (?), 10:58, 06/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда
    >и вспомните про SQL...

    у вас серьезно 10000000 пользователей? и из них хотя бы треть активна? на одном хосте? что же это за хост, позвольте полюбопытствовать?

    а то тут года три лет назад Шарун (которому у меня нет оснований не верить как постмастеру) рассказывал в ru.unix, что SQL-решения терпимы только если пользователей не больше 1000.

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

    сей тред можно посмотреть тут, например: <http://groups.google.com/group/fido7.ru.unix/browse_frm/thread/73b05d83aa7839

     
  • 3.16, proger (?), 19:24, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Брр, нашли на что равняться.
    Согласен.

    >А технически возражу так, при попытке изобрести собственное хранилище вы немедленно столкнетесь
    >с теми же проблемами что и при разработке ФС:
    >1) система хранения метаданных и связанные с ней чудеса, разграничение доступа, блокировки...
    >2) фрагментация области хранения данных
    >3) и это только то что сразу приходит в голову :)

    А зачем мне нужны мета-данные, разграничение доступа и т.п. у меня ведь только одна программа лезет в хранилище, она и разграничевает доступ.
    Значит - это не нужная функциональность.
    + я могу построить индексы по нужным мне для анализа полям.
    а можно ли построить ускорить поиск по данным from: в maildir.

    >Уверены что решите все эти проблемы лучше разработчиков ext3 или XFS ?
    нет, поскольку не стоит задачи разработать ФС, нужно лишь хранить информацию о почте.
    И наверняка можно сделать частное решение которе будет лучше/ быстрее для данной задачи, чем общее.
    А рэйзер4, как я понял, использует что-то типа БД внутри себя для ускорения доступа.

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


    >Неправильно. Мое частное решение - RAID 10 с аппаратным RAID контроллером и
    >приличные ФС (ext3 c dir_index например) ну и памяти чем больше
    >тем лучше. Юзеров ~10000, почтовые ящики у них самого различного размера
    >в том числе и с многими тысячами сообщений. Что я делаю
    >не так и чем мне поможет SQL?

    ЗЫ насколько помню после какого-то количества файлов в директории под ext3 система начинает тормозить при работе в этой директории.

     
  • 2.10, sergei_vasilyev (ok), 15:15, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >Красиво отстаиваешь свою точку зрения. Это 5!

    >Когда писем несколько десятков тысяч у одного пользователя, и
    >всего их тысячи полторы (не у всех такие большие ящики, пусть
    >у 10%), то производительность файловой системы и системы SCSI - это
    >узкое место. Да, есть выход - поставить винты на FC. Это
    >Ваше решение?


    решение хранить почту в СУБД имеет право на жизнь. Потому и существует продукт DBMail, и он востребован, потому что есть среды, где это необходимо. Я благодарен автору, что он сообщил мне о его существовании.

    Но я возразил против вводной части статьи, которая IMHO описывает мнимые, надуманные преимущества такого решения. И представляет такое решение как панацею.

     
  • 2.14, GR (??), 16:52, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >то производительность файловой системы и системы SCSI - это
    >узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение?

    А-ха ... :-)

    А базы вашего SQL-я не живут на FS лежаших на "узкоместных" SCSI ? :-)

    Про бакап тоже смешно - юзая dump на FreeBSD и Solaris обычно юзают и snapshot :) О какой неконсистентности речь?

    Ну а теперь реальный плюс решения на DB. Не упомянутый, но на мое IMHO _самый_ значительный. Это универсальность доступа. Любой скрипт на любом языке может манипулировать почтой ч/з SQL. Это _гораздо_ проще программируется чем доступ ч/з "родные" методы. Кроме того если повезет вы можете полностью заменить "бэкэнд" (почтовую систему) - не меняя скрипты вообше :)


    GR.

     

  • 1.8, Аноним (-), 14:55, 05/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    IBM has already made such a system - AS400 ;))
    this system is just one big database
     
     
  • 2.12, sergei_vasilyev (ok), 15:21, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >IBM has already made such a system - AS400 ;))
    >this system is just one big database

    ;)))))
    AS400 мало где применяется.
    НО! в тех областях, где она задействована, она рвёт на куски задачи, с которыми другие архитектуры просто не способны справиться.

     
     
  • 3.27, Pasha (??), 20:45, 07/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>IBM has already made such a system - AS400 ;))
    >>this system is just one big database
    >
    >;)))))
    >AS400 мало где применяется.

    Lotus Domino.


     

  • 1.11, sergei_vasilyev (ok), 15:17, 05/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    "Похоже на голубую мечту сисадмина." (цитата из статьи).
    Для меня это кошмарный сон. Я пойду на это, только если этого будет требовать задача.

    Плохо автор знает сисадминов. А пишет в журнал с таким названием.

    Впрочем, если выкинуть вводную часть, статья вменяемая.

     
     
  • 2.17, AlexDaos (ok), 20:32, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >"Похоже на голубую мечту сисадмина." (цитата из статьи).
    >Для меня это кошмарный сон. Я пойду на это, только если этого
    >будет требовать задача.
    >
    >Плохо автор знает сисадминов. А пишет в журнал с таким названием.
    >
    >Впрочем, если выкинуть вводную часть, статья вменяемая.

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


     
     
  • 3.18, икбля (?), 20:43, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    афтарам желаю не останавливаться на почте: хостинг целиком положить в sql.
    одна база = много сервисов + много точек обмена контента + намного упрощается админский тяжёлый однообразный труд.
     
  • 3.21, mike_t (?), 08:38, 06/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    функционал корпоративных монстров типа Exchange не ограничивается только почтой...
     
     
  • 4.23, AlexDaos (??), 10:50, 06/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Вот поэтому sql или что похожее здесь смысл, возможно, и имеет. Но все же часто Ексч работает именно почтой, а остальным никто не пользуется...
     

  • 1.19, Salrod (?), 20:47, 05/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А может все дружно и вежливо спросят у Google, как они в Gmail хранят десятки тысяч почтовых ящиков по 2.7 Гб каждый ?

    Велосипед уже изобретен... (c)

     
     
  • 2.20, Аноним (-), 21:39, 05/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Тут есть еще момент разделения обязанностей, сисадмин поддерживает штатное состояние BD + MTU, а всякие перцы которые занимаются базами данных уже делают бекапы и все остальное ибо все это уже есть. Одна из болезней сисадминов - это как раз "делаю все сам" - не дословно но иногда не избежно.


     
  • 2.24, mail (?), 10:52, 06/07/2006 [^] [^^] [^^^] [ответить]  
  • +/
    > А может все дружно и вежливо спросят у Google, как они в Gmail хранят десятки тысяч почтовых ящиков по 2.7 Гб каждый ?
    А что спрашивать... Неужели непонятно что это маркетинговый ход??
    из десятков тысяч -- 100 максимум ради интереса держат в 2.7Гб.. и то за счет других :)))
     

  • 1.28, Аноним (-), 08:09, 19/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нелюбителям хранения писем в DB - идите нафиг, а?Хранить письма прямо в файловой системе есть смысл только если у вас рейзерфс и т.п. файловая система которая сама нечто типа БД и есть.Иначе это редкостный идиотизм.Кроме того, бэкапать одну БД как-то сподручнее чем кучу мелочи.В общем технологии прошлого века - нафиг.Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)
     
  • 1.29, Eniiw (?), 11:05, 23/07/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)

    Действительно непонятно, почему internet messagers ещё не задушили почту.
    У Вас есть какие-нибуть соображения?

     
     
  • 2.30, Аноним (-), 22:43, 01/08/2006 [^] [^^] [^^^] [ответить]  
  • +/
    >>Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)
    >
    >Действительно непонятно, почему internet messagers ещё не задушили почту.
    >У Вас есть какие-нибуть соображения?
    1) Неподдержка оффлайн сообщений в МСН протоколе как минимум до недавних времен.
    2) Убогие 450-символьные оффлайн соообщения в айсикью которые иногда не доставляются.
    3) Кривой жаббер в котором вообще сроду ломаешь голову нал тем что поддерживает а что нет получатель и получит ли он твое сообщение вообще и если да то в каком виде... а уж если сообщение юзеру в асе\мсне через шлюз, там вообще лотерея сплошная...

    А так - я почти не использую емайл, кому надо пообщаться со мной используют интернет мессенгеры :)

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру