Вопрос к знатокам. А что дает хранение почты в БД?

Не знаток я, но подозреваю, что:
1. Протокол IMAP, имеет возможность искать указанную пользователем строку в IMAP-папке на сервере (саму операцию выполняет сервер), а в СУБД есть готовые реализации контекстного поиска и индексации для его существенного ускорения.
2. Если почта хранится в СУБД, то такой почтовый сервер заведомо обречен на успех при желании разработчиков превратить его в groupware (объекты и/или отношения, индексация и пр. сильно способствуют этому).
3. А еще удобно удалять-заводить пользователей с синхронизацией практически с любым каталогом пользователей (~directory).

Прямо с сайта :)
- Scalability
Dbmail is as scalable as the database system that is used for the mail storage. In theory millions of accounts can be managed using dbmail. One could, for example, run 4 different servers with the pop3 daemon each connecting to the same database (cluster) server.
- Manageability
Dbmail is based upon a database. Dbmail can be managed by changing settings in the database (f.e. using PHP/Perl/SQL), without needing shell access.
- Speed
Dbmail uses very efficient, database specific queries for retrieving mail information. This is much faster then parsing a filesystem.
- Security
Dbmail has got nothing to do with the filesystem or interaction with other programs in the Unix environment which need special permissions. Dbmail is as secure as the database it's based upon.
- Flexibility.
Changes on a Dbmail system (adding of users, changing passwords etc.) are effective immediately.

Вопрос на вскидку: Есть SMTP авторизация ?

SMTP авторизация у IMAP сервера?

> Вопрос на вскидку: Есть SMTP авторизация ?

> Вопрос на вскидку: Есть SMTP авторизация ? Там только очень простенький SMTP транспорт! он прикручивается ко многим популярным SMTP серверам. в которых вот это и делается.

> Dbmail uses very efficient, database specific queries for retrieving mail information. This is much faster then parsing a filesystem.

Дундуки имхо. Свой код можно соптимизировать под необходимые запросы чтобы небыло никаких parsing a filesystem, и в бд лезть будет дороже, хотя может это и некритично.

> Dbmail is based upon a database. Dbmail can be managed by changing settings in the database (f.e. using PHP/Perl/SQL), without needing shell access.

Т.е. уже и настройки в базе данных хранятся? Вообще обленились..

> Dbmail is as secure as the database it's based upon.

Ага, а безопастность сервера при взаимодействии со внешним миром это так, мелочи.

<i>Дундуки имхо. Свой код можно соптимизировать под необходимые запросы чтобы небыло никаких parsing a filesystem, и в бд лезть будет дороже, хотя может это и некритично.</i>

Бред, ИМХО. Правильно спроектированная БД всегда будет на порядок быстрее работать в общем случае.

А мне очень цирус нравитца. :)

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

Еще бы к нему был админский интерфейс попрямее да sieve на общих папках и настало бы полное щасте.

На раздаче писем? никогда. :)

На поиске писем. На отслеживании истории писем. На сортировке писем. И для большого количество писем Вы что предлагаете: o mbox, o много-много файлов и каталогов o или что-то ещё?

Есть dovecot, который вполне сносен. Ну, допишут ему скоро хранение в базе. Но нахрена Козе боянъ? Миллион пользователей - круто. Помножим миллион на тысячу (а почему нет?) получим миллиард. Это я про кол-во записей. Чуем, да, к чему я? миллиард (уже хорошо) помножим на 500 байт - получим... это только на заголовках пысем. Покажите мне, дураку, какая БД из существующих будет разумно работать с таким объемом...

> Бред, ИМХО. Правильно спроектированная БД всегда будет на порядок быстрее работать в общем случае.

На порядок быстрее что чем что? Поиск чем в Файловой системе? Так с этим то понятно, только нормальный сервер не будет ничего "парсить" на каждый чих, а будет иметь в памяти нужные ему метаданные, индексы и т.д. По сути будет иметь функции подобные БД, но внутри процесса и заточеные под конкретные данные (универсальность кода на скорости сказывается негативно).

Ну, если заранее не знать всех способов как данные будут использоваться в будущем, то в БД их пихать конечно самое то :)

Ерундой какой-то занимаются.
Лучше б криптование содержимого ящиков прикрутили куда-нибудь.
Чтоб оно на сервере закриптованное валялось.

> Чуем, да, к чему я? миллиард (уже хорошо) помножим на 500 байт - получим... это только на заголовках пысем. Покажите мне, дураку, какая БД из существующих будет разумно работать с таким объемом...

С таким объемом (порядка терабайт) структурированных данных как раз БД и будет грамотно работать. В отличие от.

>На поиске писем. На сортировке писем.

индексы не являются экслюзивной фичей SQL серверов.

>На отслеживании истории писем.

Кто-то упамши?

>И для большого количество писем Вы что предлагаете: o mbox, o много-много файлов и каталогов o или что-то ещё?

наилучший для этого типа данных формат. SQL серверы общего назначения тут сливают.

Цирус, кстати, отлично справляется со своей maildir.

Собственно, все что угодно можно засунуть в мускул или постгре. Зачем вообще тогда файловые системы придумывать?

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

тут интересный пример про базу данных почтовой программы на русском
http://www.livejournal.com/users/vadim_kataev/

> Собственно, все что угодно можно засунуть в мускул или постгре. Зачем вообще тогда файловые системы придумывать?

Давным-давно, когда машины были болшими, а монитры зелеными, FS от DB не отличали. Но поскольку у этих болших машин вычислительные ресурсы были маленькие, с целью экономии оных эти понятия искуственно разделили. А потом машины стали уменьшаться, а вычислительные ресурсы - расти, и к FS стали добавлять функциональсти DB. И сейчас существует два типа DB - с ирархическим (древовидным) представлением данных, такие как FS & LDAP и табличным представлением (реляционные), такие как кучка различных реализаций SQL. А наиболее общий тип DB, кторый включает в себя два предыдущих как схемы-подмножества, это так называемые стевые DB (на основе графа данных), читаем про CODASIL. Так вот - наше светлове будующее это сетевая DB в качестве FS. Впрочем AS/400 использует в роли FS DB/2...

>>Кто-то упамши?

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

Во первых - полная история переписки, в том числе и с пересылкой - по всем юзерам. То есть, Вы например, засылаете, например, в хелпдеск запрос и видите, как он по сотрудникам форвадится и путешествует.

Во-вторых - всякие статистические данные - среднее время ответа на вопрос, среднее время жизни одной "ветки" переписки, и прочую ерунду.

Крупным корпорациям может понравится :).

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

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

Но в имапе такой информации не предусмотрено. А держать письма в БД - см выше.

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

Это уже есть на основе maildir. Надстройка в виде универсального sql только заметно мешает.

ЗЫ

Постфикс с аккаунтами, транспортами и алиасами в мускуле проигрывает постфиксу с той же информацией в обычных файлах в производительности в разы!

> А потом машины стали уменьшаться, а вычислительные ресурсы - расти, и к FS стали добавлять функциональсти DB.

ой, иди почитай интервью с Пайком на ./. И не перемешивай факты.

Когда машины были большими, было понятие - "хранилище данных". И DB оно не было - поскольку не было структурированным.

> Впрочем AS/400 использует в роли FS DB/2...

Тут ты наврал. Поверхностное прочтение Солтиса... ;)

И пошло и поехало...

Не надо путать универсальные sql серверы общего назначения и парадигму db вообще.

Любую ФС всегда можно было представить как структурированое хранилище с доступом по запросам. Назови ext2 FSБД и успокойся.

> наилучший для этого типа данных формат.

О! Браво! Искать в многогигабайтном ящике заголовки писем полным его сканированием! Давайте!

> Цирус, кстати, отлично справляется со своей maildir.

Еще лучше, на каждый заголовкок будем делать seek(). Или два. Или несколько.

> Постфикс с аккаунтами, транспортами и алиасами в мускуле проигрывает постфиксу с той же информацией в обычных файлах в производительности в разы!

Да? Если если imap используют сотни пользователей с максимальным размером ящика ~500 Mb, и ящики в формате mbox, то во сколько же обойдется система хранения, которая сможет справится с такой нагрузкой? :-)

Вот собственно передо мной сейчас эта проблема. Сервер на FreeBSD. Как-то пробовал перейти на Courier, с его maildir, но он просто валится от такой нагрузки.

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

У кого есть опыт использования серверов, хранящих письма в DB, при большой нагрзке. Поделитесь впечатлениями.

2 Irsi: А объектные базы данных уже существовать перестали?

2oxonian: На System/360 уже были оба этих понятия. А то что было до этого - не в счет.
И факты я не перемешиваю - понятия FS & DB были разделены именно из-за невозможности полноценной реализации их надмножества - сетевой модели, на машинах того времени. Кто такой Пайк я не знаю, а вот авторы CODASIL мне хорошо знакомы. :)
Да-да, на AS/400 нет FS, я в курсе. Там есть общее поле памяти и прочие навароты. Только я боюсь что если я начну вдаваться в подробнисти, 90% здешней публики не будет понять о чем я говорю в принципе, ибо кенцепция OS/400 сильно отличается от того, к чему привыкли красноглазые, ничего окромя писюка поганого в своей жизни не видевшие. :)

2eXOR: а их никогда и не было - было только новомодное название. Чем объектная модель отличается от сетевой? Да ни чем - тоже представление на основн графа и все.

У как все запущено :-(. Вы слишком вольно обращаетесь с определениями.

2eXOR: ок, расскажите мне чем сетевая модель отличается от объектной. Тем что в узлах графа могут быть не только данные и процедуры их обработки, но и данные+процедуры их обработки? :)

> с максимальным размером ящика ~500 Mb, и ящики в формате mbox
> пробовал перейти на Courier, с его maildir
не может быть. это противоречит здравому сымслу - обюработать Maildir намного проще и быстрее чем mbox.
что-то в консерватории было не того.
у нас при переезде с sendmail на qmail в качестве эксперимента были сотавлены несколько ящиков mbo - они при прочих равных (например, вирутальный alias на несколько физических ящиков) давали большую нагрузку чем Maildir ones.

> не может быть. это противоречит здравому сымслу - обюработать Maildir намного проще и быстрее чем mbox.
> что-то в консерватории было не того.

Да я прекрасно понимаю. И основная нагрузка идет на жесткие диски. К счастью мне есть на кого валисть вину, не я отвечаю за почтовый сервер :-)

Какое существует максимально стабильное решение?

Про qmail слышел много как положительных, так и отрицательных откликов. И чесно говоря в его сторону смотреть не хочется из-за отсутствия уверенности.

У меня порядка 50Gb почты, хранится в DB разумеется... Угадай сервер. :)

>- Speed >Dbmail uses very efficient, database specific queries for retrieving >mail information. This is much faster then parsing a filesystem.

О какой скорости по сравнению с файловой системой может идти речь, когда cвязь с БД осуществляется через один сокет или pipe? Для одного пользователя это может быть незаметно, но для многих этот фактор существеннен.

О какой скорости по сравнению с файловой системой может идти речь, когда cвязь с БД осуществляется через один сокет или pipe? Для одного пользователя это может быть незаметно, но для многих этот фактор существеннен.

Там один сокет/соединение с ДБ для одного/каждого пользователя своё. Ты б попробовал сначала. И не забудь логи вынести на другой/выделеный/свободный диск.

Один сокет соединения с ДБ на одно соединение IMAP - это ещё хуже, так как 1. Удваивается количество сокетов на сервере, 2. Прогон буферов через ядро

Короче, ни о каком сравнении по скорости с файловой системой не может быть и речи.

1 сокет на одного юзера?!

Базу-то не задрочат?

forward

> Какое существует максимально стабильное решение?
единственный почтовик за дыру в котором обещана награда в 500USD - qmail.:=D
скажем так - он тоже не без проблем.
если чо - в мыло.

Irsi, не позорился бы.

Быстро читать про Коада и реляционную алгебру :)

ARia

Один сокет соединения с ДБ на одно соединение IMAP - это ещё хуже, так как [skip]

Ну да. Плохо!
При mbox нужно читать + парсить весь mbox отсуда нагдузка на диск,процессор,буфера,io , проблемы при стирании письма в середине ... но зато у нас нету базы данных ....


При maildir большее количество маленьких файлов которые часто меньше "inode", в етом помогают некоторые файлухи с падением скорости ... но ни одна не даёт 100% сохранения данных ! при большом количестве пользователей огромный io на файлы и метаинформацию. зато никаких SQL

База управляе данными ... имеет гарантированые транзакции , online бекап, redologs, оптимизирована под изминения данных для большого количества пользователей, проста в управлении, в слежении (за происходящим), расширяема ! Но нет нам этого не надо ....

MfG
Konstantin

>При mbox нужно читать + парсить весь mbox отсуда нагдузка на >диск,процессор,буфера,io , проблемы при стирании письма в середине ... >но зато у нас нету базы данных .... >При maildir большее количество маленьких файлов которые часто меньше >"inode", в етом помогают некоторые файлухи с падением скорости ... но >ни одна не даёт 100% сохранения данных ! при большом количестве > >пользователей огромный io на файлы и метаинформацию. зато никаких SQL

Ну да, в этих случаях разработчики вынуждены решать реальные проблемы возникшие в задаче а не перекладывать ответственность на мифические СУБД, которые так же пользуются функциями системы и соответственно ходят по тем же inode и используют io, буфера и прочее.

Только при использовании только файловой системы количество компонентов системы и соответственно сложность решения уменьшаются, что замечательно.

А так получается что в решении осуществляется много работы для ничего- сначала IMAP запрос преобразуем в SQL, затем соединяемся через сеть с ДБ, которая преобразует SQL в запросы к таблицам, возвращает результат через сеть в сервер IMAP, который закатывает результат в IMAP-обёртку и т.д.

>База управляе данными ... имеет гарантированые транзакции , online >бекап, redologs, оптимизирована под изминения данных для большого > >количества пользователей, проста в управлении, в слежении (за >происходящим), расширяема ! Но нет нам этого не надо ....

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

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

Отлично сказано!

100 % поддерживаю.

Ирси, не позорься иди осведи память почитай кузнецова (БД ВМиК 3-ий курс) чтоли, да и пайка не знать и рассуждать о БД это просто смешно.

>Ну да, в этих случаях разработчики вынуждены решать реальные проблемы >возникшие в задаче а не перекладывать ответственность на мифические >СУБД, которые так же пользуются функциями системы и соответственно >ходят по тем же inode и используют io, буфера и прочее.

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

>Только при использовании только файловой системы количество >компонентов системы и соответственно сложность решения уменьшаются, >что замечательно.

Но тогда намного тяжелее получить "желаемый" результат !!! Смотри дальше!

[skip] >>База управляе данными ... имеет гарантированые транзакции , online >>бекап, redologs, оптимизирована под изминения данных для большого > >>количества пользователей, проста в управлении, в слежении (за >>происходящим), расширяема ! Но нет нам этого не надо ....

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

Конечно можно, но могут ли это потянуть средние/большие фирмы ? Будут ли они заморачиваться созданием кластеров и установкой кластерные ФС ? НЕТ! им проще/дешевле поставить всё на SQL и получить сразу ВСЁ !!!

Тут ведь не вопрос в том что лучше процедурный(С) или объектный(С++,Java) тут нужен результат.

ЗЫ Такие большие системы как mail.ru msn.* gmx.de freemail.* наверное хранят почту в файлах. Оно и понятно ведь у них работают разработчики того сервера который всё это обрабатывает .... которые и будут решать проблемы возникшие в задаче.

>>О! Браво! Искать в многогигабайтном ящике заголовки писем полным >>его сканированием! Давайте!

Кстати, а зачем хранить заголовок в реляционной БД в явном виде? В виде блока текста? Это не есть верно. Разбиваешь его на атрибуты и хранишь их в таблицах. Поиск будет быстрый и красивый.

>>О какой скорости по сравнению с файловой системой может идти речь, >>когда cвязь с БД осуществляется через один сокет или pipe? Для >>одного пользователя это может быть незаметно, но для многих этот >>фактор существеннен.

Только ты забыл про одну тонкость. Работа с СУБД идет по схеме: послать запрос - получить только то что нужно, а с ФС - лопатить все, пока не найдешь то что нужно ;)

2bbb: давай конкретно, по пунктам, а? Без общих фраз на тему "не позорься".

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

То есть ты думаешь, что программы разрабытываются "конструкторами", а не "разработчиками"? Я имел в виду именно разработчиков, а не тебя как пользователя или конструктора.

>Но тогда намного тяжелее получить "желаемый" результат !!! Смотри дальше!

Сформулируй "желаемый результат" для начала.

>Конечно можно, но могут ли это потянуть средние/большие фирмы ? Будут ли >они заморачиваться созданием кластеров и установкой кластерные ФС ? >НЕТ! им проще/дешевле поставить всё на SQL и получить сразу ВСЁ !!!

Что поставить на SQL? Что может быть проще использования обычной файловой системы в качестве хранилища сообщений? Что "ВСЁ"?

>ЗЫ Такие большие системы как mail.ru msn.* gmx.de freemail.* наверное >хранят почту в файлах. Оно и понятно ведь у них работают разработчики >того сервера который всё это обрабатывает .... которые и будут решать >проблемы возникшие в задаче.

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

>Только ты забыл про одну тонкость. Работа с СУБД идет по схеме: послать >запрос - получить только то что нужно, а с ФС - лопатить все, пока не > >найдешь то что нужно ;)

Может не надо сочинений на задданную тему?

>Только ты забыл про одну тонкость. Работа с СУБД идет по схеме: послать >запрос - получить только то что нужно, а с ФС - лопатить все, пока не >найдешь то что нужно ;)

Если имелось в виду пере-открытие компонентов директории, то в файловой системе существует такая очень хорошая вещь как "directory name lookup cache", которая не позволяет "лопатить всё пока не найдёшь".

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

ARia