Re: Re: Размерыпочтовогоящика

" (Vladimir A. Butenko)" wrote:
>
> On Fri, 12 Sep 2003 13:56:35 +0400
> <CGatePro@mx.ru> (Dmitry S. Rzhavin) wrote:
>
> > > У большинства открыто 2 майлбокса. Пусть среднее число мессажей в каждом
> > >-
> > > 100. Если мы будем хранить данные для mailbox view - то это 7*100 = 700
> > > об"ектов на узера, 5,600,000 об"ектов всего на систему. Плохо ей будет,
> > >уж
> > > поверьте.
> >
> > Охотно верю. У меня просто объемы на порядки меньше, и поэтому мне от CGP
> > требуется в первую очередь не способность жить хоть как-то при 100k+
> > users,
> > а быстрое обслуживание нескольких тысяч, причем по всем протоколам разом.
> > Возможно, есть смысл приделать рубильник с положениями "быстро"-"много"?
>
> Такой соблазн всегда есть. Но ведь тем, у кого не 5,000 юзеров, а 500,000 -
> еще больше нужно, "чтобы быстро". То есть - хорошее решение оно для всех
> хорошее. Если напрашивается решение, которое хорошо в ограниченных условиях
> - оно плохое.

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

> Потому что завтра (через год) Ваши 5,000 юзеров позаведут по
> 100 майлбоксов, и Вы попадете в ту же ситуацию, что и провайдер с 500,000
> юзеров сегодня.

если каждый mbox принесет мне по $10, я просто поставлю туда больше памяти, и буду доволен :)

>
> Это я не к тому, что "надо все оставить как есть". А к тому, что надо думать
> долго, а потом быстро написать, - rather then реализовывать "очевидные
> решения". Увы.

Конечно. У многих решений есть подводные камни. И подписчики этого листа верят, что Вы не будете реализовывать решения, не продумав и не взвесив все "за" и "против". Просто иногда очень хочется ;)

>
> > > > А можно сделать к mailbox index, и считывать только его, а не весь
> > >mbox?
> > >
> > > Можно. Как только расскажете, как. Чтобы после того, как Вы в момент
> > > модификации mailbox могли вырубить питание, и включив его опять -
> > >получили
> > > ЧИТАЕМЫЙ майлбокс. То есть - не требующий ручной правки. И чтобы индекс
> > > хранился в том же файле (могу об"яснить почему, но должно быть и так
> > > понятно).
> >
> > Честно говоря, не очень. Почему нельзя хранить на folder 2 файла - mbox и
> > index?
>
> Потому что как только у Вас есть два отдельных об"екта, управляемых не Вами
> (файлы управляются не программой, а OS, ее файловой систмой, ее падениями, и
> проч) - то тут же возникает проблема "синхронизованности данных". Вот есть у
> меня майлбокс и рядом - файл егойного индекса. Откуда я знаю, что они
> соответствуют друг другу? Речь не идет о том, что линухоман Вася взял, и
> ручками поправил один из этих файлов - пусть тогда все грохнется (хотя лучше
> бы, чтобы и тогда не грохалось). Но - система упала при последней
> модификации, диск переполнился, и так далее. То есть - надо хотя бы уметь
> проверять, что информация в обоих - "consistant". Причем проверять быстро,
> иначе индекс теряет смысл. Когда все в одном файле - то ЧАСТЬ таких проблем
> снимается. Но появляются другие...
>
> Я не к тому, что это нельзя сделать - я к тому, что пока мы не знаем как это
> сделать. Если кто-то знает - то с удовольствием (:-|) выслушаем.

Хорошо, решение 'в лоб'.
каждый mbox получает свой counter, записываемый в начало файла. При каждой операции с файлом ++counter (в смысле, сначала увеличиваем, потом работаем). Операция с mbox защищена всеми имеющимися на данный момент механизмами (Вы указывали, что у Вас есть механизмы защиты mbox от различных повреждений). Далее.
каждый mbox получает файл mbox.index, в котором лежит некоторый индекс по заголовкам (+- другие поля, наиболее часто запрашиваемые). Каждый index имеет counter, который нормально совпадает с counter mbox. При любых изменениях mbox соответственно изменяется index, причем counter++ (в смысле, что counter изменяется только после успешной записи в index). Все запросы по выборке почты обслуживаются из индекса, если это возможно (собсна, что должно принести выгоду).
При открытии ящика (а если есть возможность, то сразу после сбоя) сравниваются counters индекса и mbox. При несовпадении mbox читается полностью, при этом одновременно пересоздается index. Если сбои редки (как обычно и бывает), индекс пересоздается редко.
Если index хранит наиболее часто запрашиваемую выборку полей, то его использование должно повысить производительность и сэкономить ресурсы (кроме диска, ессно :) на самых распространенных запросах. Именно index кэшируется в памяти для еще большего ускорения обработки запросов.

Примерно так. Сильно не бить, я честно скажу, сам CGP писать не пробовал ;)
> > > Если расскажете в деталях, как это сделать - то начнем делать завтра.
> > >Если
> > > не расскажете - извините, подождите, пока мы сами придумаем.
> >
> > Страшно предлагать что-то таким профессионалам, они наверняка и сами такое
> > давно придумали, но если выслушают - предложим, что сможем :)
>
> Если бы "такие профессионалы" такое "давно придумали", то они бы давно и
> реализовали. Код писать - задача для обезьяны, это ремесло. Вот что этот код
> делать будет - это другое, тут мозги нужны. А с мозгами всегда и у всех
> проблемы.
>
> > > противоположная business model - они зарабатывают деньги на том, когда
> > >всё
> > > сыпется (на саппорте), мы зарабатываем их тогда, когда работает и мы не
> > > тратимся на саппорт.
> >
> > а кто покупает саппорт, если оно не сыпется? ;)
>
> О том и речь. Мы зарабатываем деньги на software. И если оно не работает, то
> мы вылетим в трубу, разорившись на саппорте. А "oупен соурсе" компании - на
> саппорте. И они вылетят в трубу, если оно будет работать само. Поэтому
> подходы к разработке весьма различные. Это опять же не к тому, что "оупен
> соурсе" - это плохо. Просто это другой бузинесс.
>
> Sincerely,
> Vladimir
> Получено Fri Sep 19 10:47:58 2003