| |
| 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) Кривой жаббер в котором вообще сроду ломаешь голову нал тем что поддерживает а что нет получатель и получит ли он твое сообщение вообще и если да то в каком виде... а уж если сообщение юзеру в асе\мсне через шлюз, там вообще лотерея сплошная...
А так - я почти не использую емайл, кому надо пообщаться со мной используют интернет мессенгеры :) | | |
|
|
