Re: [sisyphus] Выбор СУБД

Re: [sisyphus] Выбор СУБД

[Ivan Fedorov]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

Vladimir Lettiev пишет:
> Добрый день.
> 
> Для одной задачи встала проблема выбора реляционной базы данных. Пишу в
> sisyphus@, поскольку обкат СУБД буду производить на машинке с sisyphus.
> 
> Особенность задачи в том, что потребуется высокая скорость записи
> (удовлетворительным показателем будет считаться не менее 3000 записей в
> секунду), при этом иметь возможность делать достаточно сложные выборки.
> Возможность кластеризации и/или ha.
> 
> Также пробовал PostgreSQL(8.1.3), но она ушла не дальше Oracle с
> показателем 2100 зап/сек. Хотя знанием тюнинга PostgreSQL я похвастаться
> не могу и, очевидно, что проблема в настройках, поскольку обнаруживается
> высокая нагрузка на дисковую подсистему, какой нет при работе MySQL.
> 
> Может ли кто-нибудь посоветовать что-нибудь ещё для рассмотрения или как
> улучшить показатели, рассмотренных выше СУБД.

Ну например можно делать вставки блоками:

BEGIN;
INSERT 1
INSERT 2
...
INSERT n
COMMIT;

Это даст неплохой прирост производительности. Также в постгрессе много
настроек, которые надо подбирать исходя из задач и конфигруации машины.
Я к сожалению не знаю, в какую сторону крутить ручки для быстрой
вставки, ибо я вседа использовал блочный метод и мне хватало его
производительности.

Так же можно попробовать поглядеть bizgres(это СУБД на основе
PostgreSQL, http://bizgres.org/) - они вроде что-то делали для больших
объемов.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[sisyphus] Выбор СУБД

[Vladimir Lettiev]

Добрый день.

Для одной задачи встала проблема выбора реляционной базы данных. Пишу в
sisyphus@, поскольку обкат СУБД буду производить на машинке с sisyphus.

Особенность задачи в том, что потребуется высокая скорость записи
(удовлетворительным показателем будет считаться не менее 3000 записей в
секунду), при этом иметь возможность делать достаточно сложные выборки.
Возможность кластеризации и/или ha.

Пока склоняюсь к выбору MySQL (5.0.18).
Взяв образец данных (одна запись) мне удалось достигнуть средней
скорости 7200 зап/cек на таблицах формата MyISAM и 8100 зап/сек для
таблиц хранимых в памяти.
Также пробовал PostgreSQL(8.1.3), но она ушла не дальше Oracle с
показателем 2100 зап/сек. Хотя знанием тюнинга PostgreSQL я похвастаться
не могу и, очевидно, что проблема в настройках, поскольку обнаруживается
высокая нагрузка на дисковую подсистему, какой нет при работе MySQL.

Может ли кто-нибудь посоветовать что-нибудь ещё для рассмотрения или как
улучшить показатели, рассмотренных выше СУБД.

p.s. индексация в таблицах с высокой скорости записи естественно
использоваться не будет.

-- 
WBR, Vladimir Lettiev aka crux [theCrux at gmail dot com]

Re: [sisyphus] Выбор СУБД

[Alexei Takaseev]

On Sat, 08 Apr 2006 17:23:04 +0400 Vladimir Lettiev wrote:

> Ivan Fedorov пишет:
> > Vladimir Lettiev пишет:
> >> Может ли кто-нибудь посоветовать что-нибудь ещё для рассмотрения
> >или как > улучшить показатели, рассмотренных выше СУБД.
> > 
> > Ну например можно делать вставки блоками:
> ...
> > Это даст неплохой прирост производительности. Также в постгрессе
> > много настроек, которые надо подбирать исходя из задач и
> > конфигруации машины.
> 
> Спасибо, попробую проверить эффективность блочной ставки.

По скорости записи все же PG будет всегда менее шустрым. В виду того,
что в PG приложены все усилия на надежное хранение данных, когда
делается множество операций, гарантирующих помещение данных на носители
из памяти.

Re: [sisyphus] Выбор СУБД

[Vladimir Lettiev]

Ivan Fedorov пишет:
> Vladimir Lettiev пишет:
>> Может ли кто-нибудь посоветовать что-нибудь ещё для рассмотрения или как
>> улучшить показатели, рассмотренных выше СУБД.
> 
> Ну например можно делать вставки блоками:
...
> Это даст неплохой прирост производительности. Также в постгрессе много
> настроек, которые надо подбирать исходя из задач и конфигруации машины.

Спасибо, попробую проверить эффективность блочной ставки.

> Так же можно попробовать поглядеть bizgres(это СУБД на основе
> PostgreSQL, http://bizgres.org/) - они вроде что-то делали для больших
> объемов.

Посмотрел, но как сказано в документации большинство их фич попало в
postgreSQL 8.1.3. Утилита по загрузке огромных объёмов данных вроде не
совсем то. Необработанные бинарные данные будут поступать непрерывным
потоком, а не лежать где-то в виде конечного файла в формате пригодном
для загрузки.

-- 
WBR, Vladimir Lettiev aka crux [theCrux at gmail dot com]

Re: [sisyphus] Выбор СУБД

[Alexei Takaseev]

On Sat, 08 Apr 2006 19:24:38 +0400 Vladimir Lettiev wrote:

> Alexei Takaseev пишет:
> > On Sat, 08 Apr 2006 17:23:04 +0400 Vladimir Lettiev wrote:
> > 
> >> Ivan Fedorov пишет:
> >>> Vladimir Lettiev пишет:
> >>>> Может ли кто-нибудь посоветовать что-нибудь ещё для рассмотрения
> >>> или как > улучшить показатели, рассмотренных выше СУБД.
> >>>
> >>> Ну например можно делать вставки блоками:
> >> ...
> >>> Это даст неплохой прирост производительности. Также в постгрессе
> >>> много настроек, которые надо подбирать исходя из задач и
> >>> конфигруации машины.
> >> Спасибо, попробую проверить эффективность блочной ставки.
> > 
> > По скорости записи все же PG будет всегда менее шустрым. В виду
> > того, что в PG приложены все усилия на надежное хранение данных,
> > когда делается множество операций, гарантирующих помещение данных на
> > носители из памяти.
> 
> Да, вы правы.
> 
> Только что поставил эксперимент на домашнем компе с блочной записью.
> 
> Исходные соотношения (1 запись в 1 запрос):
> MySQL: 2020 зап/сек
> PgSQL: 930  зап/сек
> Блочная запись (32768 записей в 1 запрос):
> MySQL: 37427 (!) зап/сек
> PgSQL: 3610 зап/сек
> 
> Выводы очевидны...

Именно - жертвование надежностью в погоне за скоростью. В чем не
единожды пришлось убедиться, когда база на MySQL благополучно рушилась.
В то время как база на PG остается рабочей вплоть до момента разрушения
ФС.

А может все же имеет смысл подумать над задачей, и поискать другие
методы? Ведь мыскль при всей своей шустрости просто не сможет при таком
тепме записи еще и обслуживать выборку.

Re: [sisyphus] Выбор СУБД

[Vladimir Lettiev]

Alexei Takaseev пишет:
> On Sat, 08 Apr 2006 17:23:04 +0400 Vladimir Lettiev wrote:
> 
>> Ivan Fedorov пишет:
>>> Vladimir Lettiev пишет:
>>>> Может ли кто-нибудь посоветовать что-нибудь ещё для рассмотрения
>>> или как > улучшить показатели, рассмотренных выше СУБД.
>>>
>>> Ну например можно делать вставки блоками:
>> ...
>>> Это даст неплохой прирост производительности. Также в постгрессе
>>> много настроек, которые надо подбирать исходя из задач и
>>> конфигруации машины.
>> Спасибо, попробую проверить эффективность блочной ставки.
> 
> По скорости записи все же PG будет всегда менее шустрым. В виду того,
> что в PG приложены все усилия на надежное хранение данных, когда
> делается множество операций, гарантирующих помещение данных на носители
> из памяти.

Да, вы правы.

Только что поставил эксперимент на домашнем компе с блочной записью.

Исходные соотношения (1 запись в 1 запрос):
MySQL: 2020 зап/сек
PgSQL: 930  зап/сек
Блочная запись (32768 записей в 1 запрос):
MySQL: 37427 (!) зап/сек
PgSQL: 3610 зап/сек

Выводы очевидны...

-- 
WBR, Vladimir Lettiev aka crux [theCrux at gmail dot com]

Re: [sisyphus] Выбор СУБД

[Pyatnitskich Evgeniy]

On Sat, Apr 08, 2006 at 20:12:57 +0900
Ivan Fedorov wrote:

> > Также пробовал PostgreSQL(8.1.3), но она ушла не дальше Oracle с
> > показателем 2100 зап/сек. Хотя знанием тюнинга PostgreSQL я похвастаться
> > не могу и, очевидно, что проблема в настройках, поскольку обнаруживается
> > высокая нагрузка на дисковую подсистему, какой нет при работе MySQL.
> 
> Ну например можно делать вставки блоками:
> 
> BEGIN;
> INSERT 1
> INSERT 2
> ...
> INSERT n
> COMMIT;

можно ещё использовать prepared queries.

PREPARE planname (...) AS ...
EXECUTE planname (...)

-- 
  -- Regards, P.E.M. <pem at nm dot ru>

Re: [sisyphus] Выбор СУБД

[Alex Gorbachenko]

[-- Attachment #1: Type: text/plain, Size: 291 bytes --]

On Sat, 08 Apr 2006 19:24:38 +0400
Vladimir wrote:

>Блочная запись (32768 записей в 1 запрос):
>MySQL: 37427 (!) зап/сек
>PgSQL: 3610 зап/сек

в pgsql вы делали copy from stdin, надеюсь ? и wal_sync_method =
fdatasync или вообще fsync=false ? 

-- 
np: Arch Enemy - Silent Wars

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]