Re: Re: Hardware configuration

Здравствуйте!

On Wed, Nov 12, 2003 at 01:34:41AM -0800, Vladimir A. Butenko wrote:

> >> Я не имею понятия о какой "конкретно" системе шла речь. 4000 доменов в
> >> секунду вы не прочтете, простите, ни на чем, потому что какая бы ни была
> >> файловая система, у Вас просто ОС не сможет выдать 40,000 файл-операций
> >в > секунду. Или может?
> >
> >А зачем ? :) Нормальная база данных :) хранит данные блоками и читает -
> >тоже блоками, а не оперирует мелкими файлами на файловой системе. Если
> >сделать нормальное хранение, то описанная проблема кол-ва операций в
> >секунду, которая даст операционка - отпадает полностью, думаю, в пределе
> >можно обойтись одним read() :)
> >
> >С моей точки зрения - надо говорить именно о такой "оптимизации"
> >"алгоритмов".

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

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

> Лучшее, что можно сделать с базами данных, это взять вместо настоящей базы 
> игрушку типа mySQL (где нет ни транзакций, ничего) - и получить почти 
> чистый ввод-вывод на файловой системе. Ну а в CGatePro - он чистый. То есть 
> даже mySQL проиграет.

Хм.

SQL> select fullname from zones;

FULLNAME

пятизначноечисло rows selected.

Elapsed: 00:00:04.63

И большинство времени - было затрачено на отображение результата в sqlplus ( oracle ).

Читает оно вполне быстро. Если cgp на пятизначноечисло доменов будет подниматься 5 сек, думаю, что все будут довольны :) Не только же mailboxes парсить со скоростью чтения с дисков :)))

Поэтому соображения об базах данных как о чем-то медленном etc - не верно, особенно, если сравнимать с "базой данной file per record on file system".

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

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

1) А причем тут "в процессе работы" ? Никто не мешает из той же базы на старте поднять все, что надо и далее в нее на select уже не лазить - не будем передергивать :)

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

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

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

Индексы ? :)

С уважением,
  Михаил Кулаков Получено Wed Nov 12 10:01:25 2003