Re: IMAP сервер на базах данных с прибабахами...
Pavel Ammosov wrote:
On Thu, Feb 17, 2005 at 10:57:28AM +0100, Sergey Spiridonov wrote:
В DBMail письмо не храниться одним большим блобом. Они режут тело письма
на куски по сколько-то килобайт.
http://www.dbmail.org/dokuwiki/media/dbmail-er-model.png
Разделять письмо на какие-то бессмысленные килобайты на мой взгляд
решено разума. СУБД вроде как должна абстрагировать от каких-то там
блоков, дисков, байтов и др. низкоуровневой фигни.
Я думаю это связано с обработкой. Видимо при извлечении из БД
извлекается целиком значение поля, а оно может быть большим -
ограничений то на размер письма нет. И хочется видимо быстро извлекать
хедеры. Первым блоком они вставляют хедеры.
Тоже самое при записи - нужно выделять память для всего письма целиком,
а это накладно - вот они и побили на блоки.
Например, когда письмо читается из сокета по lmtp, можно начать запись в
БД не дожидаясь получения письма целиком и обойтись при этом без
промежуточных хранилищ в виде временных файлов.
Я в принципе тоже изначально был твёрдо уверен, что раз уж хранить в
СУБД, то текст надо ковертить в Юникод и хранить в Юникоде, чтобы потом
его можно было бы удобно обрабатывать. Сейчас у меня уже нет такой
твёрой уверенности. Есть ведь ещё письма с неправильно указанной
кодировкой... То есть это нужно делать, но видимо это не простая задача.
Хранение письма MIME-частями было бы гораздо понятнее (заголовки, тело,
аттачменты). Любопытно, авторы сделали IMAP-флаги (seen, answered,
recent,...) явными полями, а сабжекты сообщений зачем-то находу
выдёргивают.
Сделают... Но лучше пусть LDAP прикрутят сначала.
Было бы интересно что ты видишь там преимуществами.
Подавляющее большинство практических задач получения сообщений по
критерию решают команды [UID] SEARCH, FETCH протокола IMAP. Как
выбирать нужные письма из DBmail я вообще не понимаю. Руками писать
SQL, в котором конкатенировать их килобайты письма и глазами парсить?
Я читать даже QP не умею, не говоря уже о BASE64.
Смотря с какой целью их выбирать. Читать всё же лучше в почточиталке :)
Недостатки mbox известны и очевидны, они породили maildir. Недостатки у
maildir тоже есть и тоже довольно очевидны. Например для получения
списка заголовков нужно открыть кучу файлов и прочитать их, в sql это
один select.
В SQL это ещё специальный клиент или транслятор imap(pop) <-> sql.
Текущие реализации всяких imap работают и так.
И как?
Самопальные форматы храненения отдыхают тоже по очевидным
причинам.
Я вот таких "очевидных" причин не знаю. Более того, gmail -- наглядный
пример почему собственные форматы работают.
Самопальные форматы работают. Более того, будучи заточенными под
конкретную задачу они могут дать даже лучшие результаты. Но чтобы
добиться той же надёжности и гибкости, как в СУБД, нужно потратить не
меньше времени и усилий на разработку чем было потрачено на разработку
СУБД.
Имея почту в СУБД, я могу использовать всю мощь СУБД для работы с
почтой, использовать её возможности для масштабирования. Использовать
преимущества транзакционности. Выбрать именно ту СУБД, которая наиболее
полно отвечает текущим потребностям. Использовать репликации,
распределение нагрузки и прочие вкусности.
Сам imap сервер при этом упрощается. Он, как ты правильно выразился,
превращается просто в транслятор imap->sql. Низкоуровневая работа
возлагается на СУБД.
--
Best regards, Sergey Spiridonov
Reply to: