Re: Re: Hardware configuration

On Wed, 12 Nov 2003 13:01:21 +0300
  <CGatePro@mx.ru> (Michael Kulakov) wrote:

> > Угу. Зато потом, когда начинается реальная работа, "нормальная база
> >данных"
> > (типа Оракла) просто тихо умирает, не успев даже передать поздравление
> >г-ну
> > Эллисону с приобретением тех денег, которые Вы заплатили за "базу данных"
> > нужную для хотя бы средненького провайдера.
>
> Тихо оно не падает.

Оно падает громко. Не забывайте, что тут Оракловские башенки - рядышком через водичку. И народу там работает много, включая тех, с кем я пересекаюсь в нерабочее время. Поверьте, когда оно падает, оно падает ОЧЕНЬ громко, особенно если это достаточно крупный клиент. Вся задача в том, чтобы СНАРУЖИ было очень тихо. Ибо это не нужно ни Ораклу, ни клиенту.

> >базы
> > игрушку типа mySQL (где нет ни транзакций, ничего) - и получить почти
> > чистый ввод-вывод на файловой системе. Ну а в CGatePro - он чистый. То
> >есть
> > даже mySQL проиграет.
>
> Хм.
>
> SQL> select fullname from zones;
>
> FULLNAME
> -------------------------
> ....
>
> пятизначноечисло rows selected.
>
> Elapsed: 00:00:04.63
>
> И большинство времени - было затрачено на отображение результата в sqlplus
> ( oracle ).

И что? Ну, а CGatePro Directory выдаст пробежит Вам за 4 секунды по 100,000 записям (это шестизначное число), плюс, в отличие от Оракла, сможет делать по 10,000 изменений записей в секунду на дешевом писюке. Какое это отношение имеет к вопросу? Вам же надо не ОДИН раз считать. Вам потом с этим надо РАБОТАТЬ. Да, один раз считать - так даже Оракле сделает быстрее, чем делает это CGatePro сейчас. Фишка в том, что потом с этим надо работать - много быстрее, чем может делать это Оракле. И надо сделать так, чтобы оно и читало на старте быстро, но не ценой downgrade до Оракла всей работы.   

> Читает оно вполне быстро. Если cgp на пятизначноечисло доменов будет
> подниматься 5 сек, думаю, что все будут довольны :) Не только же mailboxes
> парсить со скоростью чтения с дисков :)))
>
> Поэтому соображения об базах данных как о чем-то медленном etc - не верно,
> особенно, если сравнимать с "базой данной file per record on file system".

Базы данных не "медленные". Они - универсальные. Вы же понимаете, что можно просто сделать один террабайтный файл (или 1000 GB, если в ОС ограничение на размер файла), или просто партицию монтировать в raw mode, и сделать там свою файловую систему, заточенную под задачу. Как Вы понимаете, она будет много быстрее не только Оракла или какой любой другой базы данных, но и CGatePro "на файлах". И сделать это не так сложно.

Проблема в том, что при этом полностью теряется managability. Любой сбой - и кранты всему. У Вас же уже был "всего один" сбой rollback area? Файловая система - это другой экстрим. Максимальная манажебилити - но ценой потерь производительности на накладные расходы файловой системы, встроенной в ОС.

Задача - найти оптимальный компромис. Оракл (и подобные) зады банных НИКАК не являются таким компромиссом, так как они дают еще более худшую managability, чем "самопальная, но заточная" файловая система, встроенная в продукт ("restore tools" в такой самопальной системе будут всегда лучшими, чем в любой базе данных, потому что не нужна универсальность). То есть - если уж базу данных, то это значит - черный ящик, а тогда - уж лучше свой.   

> Для того, чтобы быстро работать - потребуется какой-то другой, более
> "плоский" механизм хранения.

Да, безусловно. И он уже "в проектах". Но это, конечно, не "универсальная БД".   

> > Другое дело, что не рассчитано оно было на 100,000 доменов изначально.
> > Потом стало рассчитано - но во время работы. А во время старта - надо
> > прочитать 10 файлов на домен. Что плохо. Зато очень хорошо, когда они уже
> > прочитаны, и надо с ними работать - много эффективнее, чем любая "база
> > данных".
>
> 1) А причем тут "в процессе работы" ? Никто не мешает из той же базы на
> старте
> поднять все, что надо и далее в нее на select уже не лазить - не будем
> передергивать :)

Как это? Лазить-то мы не будет - все закэшировано. А обновлять? Да, там не такой большой траффик, и Оракл легко выдержит - если только сеттинги доменов, но для этого не нужен Оракл. Для этого, например, уже есть встроенная "базка данных" в виде Directory server local Units. Он всё не то что на раз, он на полплевка все это считает. Но не очень будет manageable.   

> 2) Текущая жизнь cgp, когда для изменения одного attribute какого-либо
> объекта - на диске overwrite ВЕСЬ файл объекта - тоже ничего хорошего,
> так как повышает требования к скорости io на пустом месте.
>
> Понятно, что текущий метод хранения данных об объектах ( meta ) в cgp -
> прост, расширяем и нагляден, но все хорошо не бывает - зато он тормозной
> на сколько-нибудь больших объемах.

Это обсуждаемо. "Весь об"ект" переписывается отнюдь не каждый раз, когда атрибут меняется. В терминах баз данных там есть commit() - и только в критических местах, одним из которых является закрытие аккаунта. Оракл на этот коммит пишет тоже минимум один блок на диск (на самом деле - больше). Попробуйте заставить Оракл делать хотя бы 1000 коммитов в секунду при изменении таблицы в 2,000,000 записей, в 300 открытых сессиях, каждая делает 3-4 изменения, потом - commit(), и так в цикле. Оцените размер Оракловой системы, которая это потянет.

То есть - для хранения мета-об"ектов Оракл будет, мягко скажем, не очень пригоден. Опять же, тот же Local Unit в CGatePro directory сделает это гораздо более эффективно, чем Оракл (потому как много более прост, не имеет транзакций - а они тут и не нужны, поддерживает только один индекс - а больше и не нужно, и незаморачивается с хранением этих индексов - мы не в 20-ом веке).   

> > Осталось сделать "быстрый старт", что не так сложно технически, но
> >хочется
> > при этом не упасть с скорости до Оракла и не упасть в надежности до
> >mySQL.
>
> Индексы ? :)

Почти. Еще раз, речь в любом случае не идет о "Оракл или не Оракл". ORACLE - out of the picture. База данных - может быть, потому как много более быстрая и manageable база данных в CGatePro уже есть. Но она не кажется достаточно manageable. Поэтому пока есть желание сделать "на файликах", но более "умно".   

> С уважением,
> Михаил Кулаков

Sincerely,
Vladimir Получено Wed Nov 12 10:29:24 2003