форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Разговоры, обсуждение новостей (Public)
Изначальное сообщение		[Проследить за развитием треда]

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

Сообщение от opennews on 05-Июл-06, 13:30

Редакция журнала "Системный администратор (http://www.samag.ru)" предоставила возможность разместить статью (http://www.opennet.dev/docs/RUS/dbmail_postfix/) про использование реляционной СУБД PostgreSQL в качестве серверного хранилища почтовых сообщений на почтовом сервере на базе Postfix. URL: http://www.opennet.dev/docs/RUS/dbmail_postfix/ Новость: http://www.opennet.dev/opennews/art.shtml?num=7839

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Сообщения по теме

[Сортировка по времени, UBB]

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

Сообщение от sergei_vasilyev (ok) on 05-Июл-06, 13:31

Эдак кто-нибудь придумает и кэш прокси-сервера в СУБД завернуть. С подходом "Всё в БД!" я не согласен. Как, впрочем, не согласен со всеми вводными статьи, которые обосновывают хранение почты в реляционной СУБД. Они надуманны, натянуты. Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на чём основано такое спорное, точнее сказать, неверное, утверждение? Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump или tar ПОВРЕЖДАЛА почтовые сообщения? Большей гибкости при обработке и анализе корреспонденции - НЕ согласен! - гибкость языка Perl для обработки текста превосходит возможности языка SQL. плюс немеренная туча уже написанных ГОТОВЫХ программ для "обработки и анализа корреспонденции". Триггеры, представления... ещё можно добавить "хранимые процедуры" Я видел парсер письма, написанный как хранимая процедура на языке SQL, который при получении неправильно  отформатированного письма намерво вешал сервер БД и при этом губил базу. И не говорите про руки программистов - они были ровные, но инструмент не тот! А perl они не владели. "Кластеризация, репликация, фрагментирование, отказоустойчивость" - похоже на мантру продавцов SQL-серверов. Отказоустойчивость, производительность, масштабирование не обязательно должны обеспечиваться установкой сервера БД. возможности SQL-серверов как хранилищ данных весьма преувеличены рекламой   производителей. SQL-сервера - это не серебрянная пуля и не killer application, а довольно сложная и громоздкая вещь, которая всё же необходима для некоторых классов задач. Товарищи прикладные программисты! Переходя в область системного администрирования, помните, что это другая среда и не следует мерить её своим аршином и применять к ней другой устав! Нужно отучиться думать на языке SQL и FoxPRO ! Однажды на моё предложение рестартонуть squid один человек, исполнявший обязанности сисадмина, воскликнул: "Ты что! там же пользователи!" Нда. Ещё хотел бы добавить, что после чтения такой статьи на журнал samag.ru никогда не подпишусь. Лучше уж читать англоязычные ресурсы или журнальчик "Ксакеп" как замену Мурзилке.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	3. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от proger on 05-Июл-06, 14:20
	>Эдак кто-нибудь придумает и кэш прокси-сервера в СУБД завернуть. >С подходом "Всё в БД!" я не согласен. Это правильно. каждому инструменту - свое место. >Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на >чём основано такое спорное, точнее сказать, неверное, утверждение? Насколько я знаю postfix хранит данные в plain text, тогда SQL-server более производителен при массовых операциях (поиск, массовое обновление,  резервное копирование в бинарном формате), и менее при еденичных операциях. >Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить >поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump >или tar ПОВРЕЖДАЛА почтовые сообщения? Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап. >Большей гибкости при обработке и анализе корреспонденции - НЕ согласен! - гибкость >языка Perl для обработки текста превосходит возможности языка SQL. плюс немеренная >туча уже написанных ГОТОВЫХ программ для "обработки и анализа корреспонденции". Согласен. для анализа текстов возможностей SQL маловато. да он не для того и создан. >Триггеры, представления... ещё можно добавить "хранимые процедуры" >Я видел парсер письма, написанный как хранимая процедура на языке SQL, который >при получении неправильно  отформатированного письма намерво вешал сервер БД и >при этом губил базу. И не говорите про руки программистов - >они были ровные, но инструмент не тот! А perl они не >владели. Чинить руки тому, кто делает это на SQL без ОСОБЫХ причин. >"Кластеризация, репликация, фрагментирование, отказоустойчивость" - похоже на мантру продавцов SQL-серверов. Отказоустойчивость, производительность, >масштабирование не обязательно должны обеспечиваться установкой сервера БД. При использовании SQL-серверов этого можно добиться прозрачно для приложения и ОС. Нужно ли это - зависит от задач. >возможности SQL-серверов как хранилищ данных весьма преувеличены рекламой   производителей. SQL-сервера >- это не серебрянная пуля и не killer application, а довольно >сложная и громоздкая вещь, которая всё же необходима для некоторых классов >задач. SQL-серверов хорошо работает как средство хранения и обработки большого количества СТРУКТУРИРОВАННОЙ информации. >Нужно отучиться думать на языке SQL и FoxPRO ! Надо научиться думать на языке задачи, а не реализации.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	6. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от pazke on 05-Июл-06, 14:37
	>>Более высокой производительности по сравнению с файловыми хранилищами - не согласен, на >>чём основано такое спорное, точнее сказать, неверное, утверждение? >Насколько я знаю postfix хранит данные в plain text, тогда >SQL-server более производителен при массовых операциях (поиск, массовое обновление,  резервное копирование >в бинарном формате), и менее при еденичных операциях. С какого перепугу SQL хранилище будет быстрее файловой системы ? Особенно если учесть что серверу электронной почты сложные SQL запросы ИМХО нафиг не  нужны. >>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить >>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump >>или tar ПОВРЕЖДАЛА почтовые сообщения? >Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап. Каким образом при использовании Maildir'ов можно получить неконсистентный бэкап ? Могу себе представить что в бэкап попадет уже удаленное письмо, но не вижу в этом большой проблемы. >SQL-серверов хорошо работает как средство хранения и обработки большого количества СТРУКТУРИРОВАННОЙ информации. Данные в случае электронной почты практически неструктурированны !! Просто куча блобов, которые надо вывалить клиенту.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	7. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от sergei_vasilyev (ok) on 05-Июл-06, 14:52
	>>Резервное копирование - горячее (без необходимости останавливать почтовый сервер, чтобы не получить >>поврежденное хранилище сообщений) - бред сивой кобылы! когда это команда dump >>или tar ПОВРЕЖДАЛА почтовые сообщения? >Говорится не о повреждении самих сообщений, а о возможности получить неконсистентный бэкап. Сорри, не успел отредактировать пост. Я хотел написать - "когда это команда dump ПОВРЕЖДАЛА хранилище сообщений, например, раздел /var ?" >>Я видел парсер письма, написанный как хранимая процедура на языке SQL, который >>при получении неправильно  отформатированного письма намерво вешал сервер БД и >>при этом губил базу. И не говорите про руки программистов - >>они были ровные, но инструмент не тот! А perl они не >>владели. >Чинить руки тому, кто делает это на SQL без ОСОБЫХ причин. Чинить руки было уже не кому - программист, написавший ЭТО, уже там не работал, а проблема проявилась через несколько лет. Я его не ругаю за то, что он так сделал, но мне жаль, что он не знал тогда других средств, кроме любимого диалекта SQL. >Надо научиться думать на языке задачи, а не реализации. Прекрасная формулировка.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	4. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от pazke on 05-Июл-06, 14:22
	Если бы дело одной скоростью ограничивалось... Есть еще потенциальная возможность для SQL инъекций. В общем нафиг такое счастье.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

Сообщение от scamp (??) on 05-Июл-06, 14:23

Красиво отстаиваешь свою точку зрения. Это 5! На мой взгляд, когда пользователей более 50 и идет интенсивный обмен почтой, единое хранилище писем вполне зравое решение. тот же Exchange хранит все письма в одной базе, да, это не MS SQL, а что-то более простое. Когда писем несколько десятков тысяч у одного пользователя, и всего их тысячи полторы (не у всех такие большие ящики, пусть у 10%), то производительность файловой системы и системы SCSI - это узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение? Отчасти есть здравый смысл - маниакальное увлечение интеграцией всего в sql. Но в большом количестве их оно оправдано.

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	9. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от pazke on 05-Июл-06, 15:01
	>Красиво отстаиваешь свою точку зрения. Это 5! >На мой взгляд, когда пользователей более 50 и идет интенсивный обмен почтой, >единое хранилище писем вполне зравое решение. тот же Exchange хранит все >письма в одной базе, да, это не MS SQL, а что-то >более простое. Брр, нашли на что равняться. А технически возражу так, при попытке изобрести собственное хранилище вы немедленно столкнетесь с теми же проблемами что и при разработке ФС: 1) система хранения метаданных и связанные с ней чудеса, разграничение доступа, блокировки... 2) фрагментация области хранения данных 3) и это только то что сразу приходит в голову :) Уверены что решите все эти проблемы лучше разработчиков ext3 или XFS ? А SQL сервера обладают совершенно избыточной (для хранилища электронной почты) функциональностью. > Когда писем несколько десятков тысяч у одного пользователя, и >всего их тысячи полторы (не у всех такие большие ящики, пусть >у 10%), то производительность файловой системы и системы SCSI - это >узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение? Неправильно. Мое частное решение - RAID 10 с аппаратным RAID контроллером и приличные ФС (ext3 c dir_index например) ну и памяти чем больше тем лучше. Юзеров ~10000, почтовые ящики у них самого различного размера в том числе и с многими тысячами сообщений. Что я делаю не так и чем мне поможет SQL ?
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	13. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от Bacek on 05-Июл-06, 15:58
	Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда и вспомните про SQL...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	15. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от sergei_vasilyev (ok) on 05-Июл-06, 18:00
	>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда Не у всех такое счастье. Всё равно, спасибо за пожелание!
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	22. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от don_oles (??) on 06-Июл-06, 09:07
	>>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда >Не у всех такое счастье. 10000 * 1000 = 10 000 000 - 10 лимонов. при таком количестве и "база" не спасёт, а решения аля гугл ;)
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	25. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от deskpot on 06-Июл-06, 10:58
	>Хе-хе. Вот когда у Вас пользователей будет на 3 порядка больше, тогда >и вспомните про SQL... у вас серьезно 10000000 пользователей? и из них хотя бы треть активна? на одном хосте? что же это за хост, позвольте полюбопытствовать? а то тут года три лет назад Шарун (которому у меня нет оснований не верить как постмастеру) рассказывал в ru.unix, что SQL-решения терпимы только если пользователей не больше 1000. и тогда же Нечаев (который тоже весьма компетентен как постмастер) рассказывал слезную историю про freemail.ru и то, что тамошний админ серьезно задумался о взглядах на жизнь после первой попытки починить что-то в базе почты, которая хранилась в MySQL с помощью myisamchk. сей тред можно посмотреть тут, например: <http://groups.google.com/group/fido7.ru.unix/browse_frm/thread/73b05d83aa7839b9/e7fa610d3324c607>.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	16. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от proger on 05-Июл-06, 19:24
	>Брр, нашли на что равняться. Согласен. >А технически возражу так, при попытке изобрести собственное хранилище вы немедленно столкнетесь >с теми же проблемами что и при разработке ФС: >1) система хранения метаданных и связанные с ней чудеса, разграничение доступа, блокировки... >2) фрагментация области хранения данных >3) и это только то что сразу приходит в голову :) А зачем мне нужны мета-данные, разграничение доступа и т.п. у меня ведь только одна программа лезет в хранилище, она и разграничевает доступ. Значит - это не нужная функциональность. + я могу построить индексы по нужным мне для анализа полям. а можно ли построить ускорить поиск по данным from: в maildir. >Уверены что решите все эти проблемы лучше разработчиков ext3 или XFS ? нет, поскольку не стоит задачи разработать ФС, нужно лишь хранить информацию о почте. И наверняка можно сделать частное решение которе будет лучше/ быстрее для данной задачи, чем общее. А рэйзер4, как я понял, использует что-то типа БД внутри себя для ускорения доступа. >А SQL сервера обладают совершенно избыточной (для хранилища электронной почты) функциональностью. ФС тоже (см. выше) >Неправильно. Мое частное решение - RAID 10 с аппаратным RAID контроллером и >приличные ФС (ext3 c dir_index например) ну и памяти чем больше >тем лучше. Юзеров ~10000, почтовые ящики у них самого различного размера >в том числе и с многими тысячами сообщений. Что я делаю >не так и чем мне поможет SQL? ЗЫ насколько помню после какого-то количества файлов в директории под ext3 система начинает тормозить при работе в этой директории.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	10. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от sergei_vasilyev (ok) on 05-Июл-06, 15:15
	>Красиво отстаиваешь свою точку зрения. Это 5! >Когда писем несколько десятков тысяч у одного пользователя, и >всего их тысячи полторы (не у всех такие большие ящики, пусть >у 10%), то производительность файловой системы и системы SCSI - это >узкое место. Да, есть выход - поставить винты на FC. Это >Ваше решение? решение хранить почту в СУБД имеет право на жизнь. Потому и существует продукт DBMail, и он востребован, потому что есть среды, где это необходимо. Я благодарен автору, что он сообщил мне о его существовании. Но я возразил против вводной части статьи, которая IMHO описывает мнимые, надуманные преимущества такого решения. И представляет такое решение как панацею.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	14. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от GR (??) on 05-Июл-06, 16:52
	>то производительность файловой системы и системы SCSI - это >узкое место. Да, есть выход - поставить винты на FC. Это Ваше решение? А-ха ... :-) А базы вашего SQL-я не живут на FS лежаших на "узкоместных" SCSI ? :-) Про бакап тоже смешно - юзая dump на FreeBSD и Solaris обычно юзают и snapshot :) О какой неконсистентности речь? Ну а теперь реальный плюс решения на DB. Не упомянутый, но на мое IMHO _самый_ значительный. Это универсальность доступа. Любой скрипт на любом языке может манипулировать почтой ч/з SQL. Это _гораздо_ проще программируется чем доступ ч/з "родные" методы. Кроме того если повезет вы можете полностью заменить "бэкэнд" (почтовую систему) - не меняя скрипты вообше :) GR.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

Сообщение от Аноним on 05-Июл-06, 14:55

IBM has already made such a system - AS400 ;)) this system is just one big database

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	12. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от sergei_vasilyev (ok) on 05-Июл-06, 15:21
	>IBM has already made such a system - AS400 ;)) >this system is just one big database ;))))) AS400 мало где применяется. НО! в тех областях, где она задействована, она рвёт на куски задачи, с которыми другие архитектуры просто не способны справиться.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	27. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от Pasha (??) on 07-Июл-06, 20:45
	>>IBM has already made such a system - AS400 ;)) >>this system is just one big database > >;))))) >AS400 мало где применяется. Lotus Domino.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

Сообщение от sergei_vasilyev (ok) on 05-Июл-06, 15:17

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	17. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от AlexDaos (ok) on 05-Июл-06, 20:32
	>"Похоже на голубую мечту сисадмина." (цитата из статьи). >Для меня это кошмарный сон. Я пойду на это, только если этого >будет требовать задача. > >Плохо автор знает сисадминов. А пишет в журнал с таким названием. > >Впрочем, если выкинуть вводную часть, статья вменяемая. Угу. Для замены корпоративных монстров типа Exchange вполне сойдет, если доведут все обещанные усовершенствования и обезопасят. Но это надо... если очень надо иметь на сервере гигабайтные ящики для толпы юзеров. Для чисто почтовой системы без долговременного хранения громадных объемов корреспонденции классические решения просто надежней и проще.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	18. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от икбля on 05-Июл-06, 20:43
	афтарам желаю не останавливаться на почте: хостинг целиком положить в sql. одна база = много сервисов + много точек обмена контента + намного упрощается админский тяжёлый однообразный труд.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	21. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от mike_t on 06-Июл-06, 08:38
	функционал корпоративных монстров типа Exchange не ограничивается только почтой...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	23. "OpenNews: Почтовый сервер на основе реляционной СУБД."
	Сообщение от AlexDaos (??) on 06-Июл-06, 10:50
	Вот поэтому sql или что похожее здесь смысл, возможно, и имеет. Но все же часто Ексч работает именно почтой, а остальным никто не пользуется...
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

Сообщение от Salrod on 05-Июл-06, 20:47

А может все дружно и вежливо спросят у Google, как они в Gmail хранят десятки тысяч почтовых ящиков по 2.7 Гб каждый ? Велосипед уже изобретен... (c)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	20. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от Аноним on 05-Июл-06, 21:39
	Тут есть еще момент разделения обязанностей, сисадмин поддерживает штатное состояние BD + MTU, а всякие перцы которые занимаются базами данных уже делают бекапы и все остальное ибо все это уже есть. Одна из болезней сисадминов - это как раз "делаю все сам" - не дословно но иногда не избежно.
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	24. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от mail on 06-Июл-06, 10:52
	> А может все дружно и вежливо спросят у Google, как они в Gmail хранят десятки тысяч почтовых ящиков по 2.7 Гб каждый ? А что спрашивать... Неужели непонятно что это маркетинговый ход?? из десятков тысяч -- 100 максимум ради интереса держат в 2.7Гб.. и то за счет других :)))
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

Сообщение от Аноним on 19-Июл-06, 08:09

Нелюбителям хранения писем в DB - идите нафиг, а?Хранить письма прямо в файловой системе есть смысл только если у вас рейзерфс и т.п. файловая система которая сама нечто типа БД и есть.Иначе это редкостный идиотизм.Кроме того, бэкапать одну БД как-то сподручнее чем кучу мелочи.В общем технологии прошлого века - нафиг.Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;)

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

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

Сообщение от Eniiw on 23-Июл-06, 11:05

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

Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

	30. "Почтовый сервер на основе реляционной СУБД."
	Сообщение от Аноним on 01-Авг-06, 22:43
	>>Хотя вообще-то хорошо бы похоронить SMTP целиком - дурной протокол созданный для спамеров ;) > >Действительно непонятно, почему internet messagers ещё не задушили почту. >У Вас есть какие-нибуть соображения? 1) Неподдержка оффлайн сообщений в МСН протоколе как минимум до недавних времен. 2) Убогие 450-символьные оффлайн соообщения в айсикью которые иногда не доставляются. 3) Кривой жаббер в котором вообще сроду ломаешь голову нал тем что поддерживает а что нет получатель и получит ли он твое сообщение вообще и если да то в каком виде... а уж если сообщение юзеру в асе\мсне через шлюз, там вообще лотерея сплошная... А так - я почти не использую емайл, кому надо пообщаться со мной используют интернет мессенгеры :)
	Правка | Высказать мнение | Ответить | Cообщить модератору | Наверх

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]