Домен .org будет поддерживаться системами на основе PostgreSQL

грамотные мужики, mvcc рулез фарева

чего скажут mysql'щики?-)

Они молча повесятся от зависти ;)

Mysql'щики отвечают: нах$%^ нужен SQL там, где dbm'ки за глаза хватит.
Ваще непонятно, наверное люди сами себе геморрой выбирают. Ить здохнет их postgress и тысячи кастомеров будут сосать пока его не починят.
Мля, хотел домен поиметь в org... Теперь забью на это дело.

to: anonymous (*) (2002-10-15 17:43:59.152)

Правильно!! Berkeley DB-4 правильный выбор

Я плакал - нашли чем восхищятся - полумертвый ORG для разного рода образовательных учереждений которым и полежать не страшно. Более тогд База данных то там не для резолвинга в реальном времени используется - ничего тут и Постгрес пойдет ничего страшного что надо ковырять таблицы периодически

А насчет зависти - какой уж там RIPE использует MySQL например :)

Использует, и его более чем достаточно. Тот же whois 3 все равно все данные держит в пямяти, SQL используется только для хранения между сессиями...

IMHO, вообще привычка сувать SQL где надо и где не надо до добра не доведет :>

ISOC member 1348907

Postgres и mysql примерно одинаковые по классу БД. МайСКЛ более стабильна, Постгрес более удобна в использовании. Поэтому, флейм по этому поводу мне алоинтересен.

Интересно, под каким SQL сервере будут делигироватся .NET домены ;)) ?

to anonymous (*) (2002-10-16 02:57:25.095)

абсолютно не согласен. для начала вам следует почитать:
http://phd.pp.ru/Software/SQL/PostgreSQL-vs-MySQL.html
потом почитать спецификации SQL'92, попробовать в деле обе БД и только потом попытаться сравнить

> для начала вам следует почитать
для какого начала? я уже не помню, как 6.5 выглядел, да и мускул уже 4 вышел. бутор. лучше на phpbuilder статью Тома Пердью посмотрите.

Вы источник на англиЦком сайте прочитали, для чего и почему они выбрали именно Постгрес? Если нет, то почитайте и если вы, все еще, недовольны чем-то, то напишите им письмо, вот то-то то-то,.. откройте им глаза на другие СУБД, а то они, как тут многие считают, тупые - не выбрали эту БД, не выбрали ту БД!

2anonymous (*) (2002-10-16 07:58:35.48)
Читаем источник на английском:
Sustaining the high-availability infrastructure that delivers this performance is one of the most advanced open source relational database systems, PostgreSQL.

Смотрите, подчеркивают две вещи: high-availability и performance.
Но ведь именно по этим двум качествам postgres отстает от mysql!

Тут товарищ один привел таблицу http://phd.pp.ru/Software/SQL/PostgreSQL-vs-MySQL.html
Она хоть и безнадежно устарела (в mysql-4.1-alpha есть уже
subselects и т.д.), но тоже подтверждает преимущество mysql по части
надежности и скорости.

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

Большая победа Postgresa!!! Ура! Очень важный домен и без SQL здесь ну никак. BerkleyDB не прокатит. Может org на Оракл перевести?

Sustaining the high-availability infrastructure that delivers this performance is one of the most advanced open source relational database systems, PostgreSQL. === Какое к черту high-availability и performance? В этих продуктах хоть появилась система логирования транзакций, чтобы потом можно было восстановить данные или все так же старым дедовским способом холодный бэкап. Ах, да припоминаю кто-то говорил что можно сделать логический бэкап, однако насколько он будет консистентен чтобы потом с него восстановится в случае краха. Авторы могли хотя бы взглянуть например на SAPDB(Он тоже кстати свободно распространяемый), а то как то это все грустно и не серьезно. Попахивает непрофесионализмом.

Вот если взглянуть на http://www.sap.com/benchmark/sd3tier.asp, так вопрос про производительность тоже отпадет.

Как говорил один мой начальник учите матчасть.

Карлсон.

> Какое к черту high-availability и performance? В этих продуктах хоть появилась система логирования транзакций, чтобы потом можно было восстановить данные или все так же старым дедовским способом холодный бэкап.

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

Карлсон, вы сами туда посмотрите :-)
тама фактически тока четыре бд (оракл,сап,ДеБил2,баксскуль) под ТРЕМЯ ОСями (саляра,винда и аикс). Какое отношение имеют они к GPL опенсурсам БД?

Людям тыкающим таблицу сравнения pgsql версии 6.5 с mysql. Поставте себе тогда и mysql версии 2 :-)) Текущая 7.2 никаких нареканий не вызывает, а вот деградация производительности mysql на сложных (не вложенных, а сложных) запросах ощутимая.

Тем кто не читает инструкции по оптимизации сообщаю, используйте индексы и vacoom analize опосля длительной работы в нагрузке и ваши волосы будут.

Онанимусам, всем сразу. Г-да, ни п#здите, если на сайте MySQL написано, что MySQL быстрее, то это не значит, что так и есть на самом деле. Читайте бессмертную статью Tim Perdue на phpbuilder'е: http://www.phpbuilder.com/columns/tim20001112.php3

Что касается Oracle, то таки да, большая часть предложений по администрированию домена .org предполагала использование Oracle, одно --- MSSQL, ни про убогую поделку MySQL ни про свежевыброшенный SAP DB почему-то никто не вспомнил. Это ж не тесты писать для eweek или своего сайта, тут реальная работа будет делаться.

В Postgres'е естественно есть hot backup (который для MySQL с InnoDB денег, кстати стоит), а в версии 7.4 обещают архивацию логов и point in time recovery. А также родной win32 порт, чтобы последний онанимус смог сравнить базы на любимом win98, а не верить статьям от Мысклёвых маркетологов.

Карлсон, вы сами туда посмотрите :-) тама фактически тока четыре бд (оракл,сап,ДеБил2,баксскуль) под ТРЕМЯ ОСями (саляра,винда и аикс). Какое отношение имеют они к GPL опенсурсам БД?

Для тех кто в танке или не может читать. SAPDB сейчас распространяется под GPL http://www.sapdb.org/sap_db_gnu.htm К чему я привел предыдущую ссылку. К тому что если вы внимательно посмотрите на последний тест SAPDB http://www.sap.com/benchmark/pdf/cert5202.pdf был на Linux, к тому что может сможете увидеть что в тестах на железе (Fujitsu Siemens PRIMERGY BX300, 2-way SMP, PENTIUM III LV 800 MHz, 512 kB L2 cache) не всякая БД потянет 800 пользователей на таком железе. Сразу скажу что например Oracle на таком железе заставить держать 800 юзеров практически не реально.

Карлсон.

2maxcom > Какое к черту high-availability и performance? В этих продуктах хоть появилась система логирования транзакций, чтобы потом можно было восстановить данные или все так же старым дедовским способом холодный бэкап.

>PostgreSQL имеет возможность сделать backup базы не останавливая ее >работы, при этом backup будет целостным. Так же PostgreSQL >журналирует операции записи, благодаря чему данные созраняются в >случае краха при несброшенном кеше. Но полноценного журнала >транзакций пока нет.

>>>> Я конечно про это слышал. Скажу вам ка художник - художнику. Если идет активная работа с БД, то в момент логического бэкапа ( физического в PostgreSQL нет) могут произойти две ситуации. 1. Бэкап пудет стопорить работу БД, не давая делать транзакции. 2. Не будет возможности сделать бэкап консистентным и бэкап окажется не консистентным. Допускаю что на слабо загруженой БД и маленьких таблицах это работает, однако для нагруженной БД это не будет работать наверняка. Логический бэкап у Oracle например подвисает при попытке сделать его консистентным при активной работе с БД. Однако у Oracle есть механизм физического бэкапа который все проблемы решает ,чего нет у PostgreSQL.

Карлсон.

Открою маленькую тайну (для некоторых) в PostgreSQL несколько механизмов индексации, в том числе hash - плоский индекс (почти как в MySQL, BerkeleyDB), поэтому попробуйте его использовать на PostgreSQL и сравнить с MySQL тем же. Для LDAP-а hash - самое то ... Хотя сам PostgreSQL потяжелее будет (и на диске и в памяти), но можно и это сократить, правда perfomance ...

А почему Berkeley DB не покатит? Она вроде очень быстрая- быстрее всех постгресов и майскулов... Или не так?

> Если идет активная работа с БД, то в момент логического бэкапа ( физического в PostgreSQL нет) могут произойти две ситуации. 1. Бэкап пудет стопорить работу БД, не давая делать транзакции. 2. Не будет возможности сделать бэкап консистентным и бэкап окажется не консистентным. Допускаю что на слабо загруженой БД и маленьких таблицах это работает, однако для нагруженной БД это не будет работать наверняка.

Благодаря мультиверсионности бекап не тормозит транзакции и получается целостным. Другое дело, что от мультиверсионности постгресса половина его проблем.

To Карлсон. anonymous (*) (2002-10-16 16:41:58.051)
Какой версией PostgreSQL Вы пользовались (пользуетесь ?), если не секрет ?
И еще - дело ведь в том, что это версионник, а логический бекап в его случае не блокирует транзакции - идет просто select * и выбирается последняя валидная версия. Поправьте меня, если я не прав.
До версии 7.2 блокировалась база при выполнении vacuum (чистка от устаревших версий), в 7.2 от этого избавились

Кстати насчет бакапа - MySQL 4.0 + INNODB + Binary Log умеет делать Point in Time Recovery i Hot Backup причем это можно сделать вполне себе бесплатным MySQLDump - так как в Innodb используется версионность то никаких блокировок это не вызывает...

у нас sapdb несколько раз умирала под sap r/3, награзка небольшая, девелоперская контора, 4-5 юзверей одновременно... умирала так, что не поднималась никак, только из бэкапа восстанавливай...

а вообще по скорости как она - sapdb ?

   Благодаря мультиверсионности бекап не тормозит транзакции и получается
   целостным.  Другое дело, что от мультиверсионности постгресса половина
   его проблем.
А какие проблемы есть в постгресе? Сколько использую - никаких не замечал
кроме крайне плохого оптимизатора запроса от-но views.

   у  нас  sapdb  несколько  раз умирала под sap r/3, награзка небольшая,
   девелоперская контора, 4-5 юзверей одновременно... умирала так, что не
   поднималась никак, только из бэкапа восстанавливай...
Под чем критился sapdb - какая ОС? Если линукс - то какое ядро? Где лежала
БД - в FS or on raw device? Какая версия СУБД? Давно вообще это было?
А железо нормальное?

2maxcom [Ответить] Ответ на: Re: Домен .org будет поддерживаться системами на основе PostgreSQL от anonymous Re: Re: Домен .org будет поддерживаться системами на основе PostgreSQL > Если идет активная работа с БД, то в момент логического бэкапа ( физического в PostgreSQL нет) могут произойти две ситуации. 1. Бэкап пудет стопорить работу БД, не давая делать транзакции. 2. Не будет возможности сделать бэкап консистентным и бэкап окажется не консистентным. Допускаю что на слабо загруженой БД и маленьких таблицах это работает, однако для нагруженной БД это не будет работать наверняка.

Благодаря мультиверсионности бекап не тормозит транзакции и получается целостным. Другое дело, что от мультиверсионности постгресса половина его проблем. ======= Я ничего не имею против мультиверсионности. Oracle тоже мультиверсионик,вот только при большой интенсивности раздувается сегмент отката, и если таблица большая результат будет неудачным. Проведя паралель с PostgerSQL скажу что наверняка как то должен подерживатся механизм мультиверсионности, следовательно проблема будет по любому. Я думаю что если разработчики PostgreSQL сделают физический бэкап и подержку журналов транзакций, то только тогда можно будет говорить о том что база данных может претендовать на high-availability(конечно при соответствующем качестве исполнения).

Карлсон.

2Карлсон. По твоей логике получается, что Oracle не относится к high-availability хе-хе-хе. Журналы транзакций также не панацея, а если делать кластеризацию, то его реализация вообще получается очень ресурсоемкой.