Скажем база данных для начала планируется небольшая ну несколько мегобайт, в последствии объемы будут доходить до гигобайтов и очень много мелких транзакций одновременно. Нужна 100% отказоустойчивость в данном случае. Естественно распределенное хранение данных. В зависимости от нагрузки будет проводиться масштабируемость. База данных нужна простая и довольно стабильная - я вот пока подобрал MySQL и PostgreSQL - скажем при распределенном хранении больших обемов на производительности не должно скзааться - если все правильно сделать, интересует бесперебойность работы и пролстота обслуживания - что лучше?

Scott Tiger яб с удовольствием бы взял Оракл но мои финансы как говорится поют романсы, мне едва хватит на распределитель нагрузки и 4 сервера с коммутатороми и оптикой и пр. обородованием:)
И то блин думаю может на распределитель нагрузки не хватит(( дорогие они нынче хорошие - прийдется программно распределять:(

tygra вындовз мне никоим образом не катит, все дело располагаться будет под freebsd, так что получается покав только два кандидата((( и то PostgreSQL со своим VACUUM мне что то не очень нравится(((

Мне уже надо начинать писать проект а еще базу не выбрал, проект на пол года - затем внедрение.

Ведь в MySQL есть типа таблиц BDB или InnoDB которые потдерживают транзакции, база быстрая вроде как - хотя не это главное. Да и производительность ограниченна ресурсами.
Я вот думаю купить может лицензию для MySQL - через пол года уже думаю более надежный вариант выйдет.

А вы как считаете?

Мне для начала на 4 сервера надо все это сделать и чтоб потом можно было легко масштабировать вширь(наращивать не мощьность а кол-во) - 2 сервера - обработчики транзакций, остальные 2 хранилища базы данной(друг друга дублируют + raid массив), ну остальные это не относятся - скорее всего минимум 3-4 будут.

Есть конечно вариант что то свое написать но для этого не хватит и времени и знаний.

eNose незнаю незнаю, я тут пошарил по инету и что то мне MySQL нравится уж очень. У него вроде все есть для моего случая.
Тип таблиц InnoDB вот транзакции потдерживают,внешние ключи, любые размеры файлов, InnoDB Hot Backup на лету базу сохраняет(правда небесплатная версия)... все это дело свободно под FreeBSD работает.
Да плюс мне клиента писать самому надо на с++, и не хочу я через драйвер какой нить а в MySQL есть MySQL++ - очень простая библиотека.
Да вот вычитал тут из мануала по MySQL(где сравнивают с PostgreSQL):
...MySQL работает на высоконадежных промышленных системах 24/7 (включенных 24 часа в сутки 7 дней в неделю). В большинстве случаев никаких ``чисток'' в MySQL производить не требуется...
или же
...
Репликация MySQL отлично протестирована и используется в таких сайтах, как:
Yahoo Finance (http://finance.yahoo.com/)
Mobile.de (http://www.mobile.de/)
Slashdot (http://www.slashdot.org/)
...
Довольно серьздные утверждения, интересно так ли это. И где можно почитать про MySQL у независимых экспертах??
Вроде подходит MySQL, по функциональным возможностям точно. Но вот отказоустойчивость меня инетерсует - при InnoDB и 2х дублирующих серверах с RAID массивами - смогу ли я обеспечить отказоустойчивость???

Хотя я тут подумал, Oracle конечно круче, но нааамного сложнее в эксплуатации:)
Можно ли Oracle уменьшить до минимума? Сделать его можно так сказать размеров и требований MySQL, а Функциональности Oracle??
И какие сейчас версии Оракла и стоимость?? там вроде на пользователей ведется счет, а если у меня у всех базы скажем 1 админ и 1 юзер будет но сама база данных будет распределена на кучи компов и постоянно увеличивать кол-во компов будет??? Как высчитывается стоимость Оракла??
А то MySQL коммерческий плюс приблуды для него тоже не дешево обойдутся:)

Да только что вспомнил - мне ведь под FreeBSD надо ((( Oracle есть под это дело?

Scott Tiger а почему это freebsв придумана не для этого?? мне важна стабильность и безопасность, вон yandex ее использует для хранения данных и что?? стабильно и безопасно:) а почему бы не мне?
А что там про Оракл для фрибсд?? кто ставил то м?? что как где куда? моно поподробнее

Sad Spirit да вот сколько людей столько и мнений:) Я и не говорю что у меня сложная архитектура - у меня она наоборот - парные подключения серверов, и сама структура БД будет очень простая - ну там всего несколько таблиц я так думаю, НО между ними будет постоянный обмен мелкими данными идти и это будет мммнооого много мелких данных.. В начале хранится несколько мегобайт - потом гигобайты будут.
Мне не нужна 99% отказоустойчивости - мне нужно 100%, лично я доверяю Ораклу - для меня бы он идеальным вариантом был - если БЫ - она работал под FreeBSD, бла какая нить малюханькая версия - мне то надо всего ничего - Бэкапить в реальном времени:) транзакции, внешние ключи, мне даже не надо вложенные и сложные запросы - мне кучу всего не надо то что есть в Оракле:) и чтоб он занимал мало и быстро и легко устанавливался и не требовал сложного администрирования. Но это идеал:)
Из остальных вариантов - это PostgreSQL и MySQL/InnoDB
Мне не так важна уж скорость, мне важна стабильность!!! ОЧЕНЬ важна.
Чтоби никагда никаких сбоев:)

Scott Tiger скажем так, я для банковких систем ПО разрабатываю, при отсутствии финансирования, ну с своего кармана:) Самых два важных фактора - безопасность, отказоустойчивость. Остальное - уже имеет наименьший приоритет:)
Сравнил я страницы с дырами у кучи операционных систем и знаешь к чему пришел?? Наименьше всего было у FreeBSD, да и как то нравится она мне сама, и используется в довольно щипитильных местах, что делает ее одной из самых надежных ОS) несмотря на Solaris, хотя более старые версии этой операци онки тоже "неприступные крупости" при правильной настройке.
А для использования Firewall - скорее всего будет аппаратный cisco + к нему отдельный компьютер для контроля "вторжений" - подключается парралельно к firewall.
На безопасность влияет все - начиная от ПО и ОС и заканчивая руками своими:)

Как говорится в споре рождается Истина.
Я тут еще немного обмозговал и еще одну идейку набросил - если Оракл для Linux всеж будет хорошая обрезання версия то может быть это дело по Linux забабахать, так как хорошего ПО для FreeBSD в организации кластера - нету:( хотя в месте с тем настораживает очень хорошая организация почтовой системы Яндекс на FreeBSD - у них там всего ничего 56 серверов то:) в отличае от поисковой системы Google у которой 54000 их .... а я не думаю что разница в объеме хранимой информации у них в 1000 где то(( меньше конечно, все дело в правильной организации хранения, ведь на Яндексе сделали же как то - и стабильно, даже осуществили безболезненную репликацию когда полностью переезжали в другой офис:)

Scott Tiger если ведь на рабочем продукте что то выйдет из строя я повешусь на подтяжках от своих носков тогда:(

Scott Tiger обязательно:) да и не только - сейчас только проблема выбора, правильного выбора... Думаю Оракл пока не в состоянии себе позволить, правда апосля если будут деньги первым делом затарюсь...

killedОбрисовываю:
Есть БД клиентов, счетов, паролей и ну и мелочных данных.
Доступ к БД осуществляется удаленно через web интерфейс .
Клиенты могут снимать, добавлять деньги на счет, и пересылать их между друг другом. Предположительно самих операций единоверменно будет очень много, но сами они буду пеерсылать небольшие данные...
Один клиент может ессесно хоть мульены счетов иметь и бла бла бла и манипулировать ессесно.
Ну в начале всего будем мало:)
При такому случае(удаленном) производительность обратна пропорциональна расстоянию, поэтому ессесно мощность прийдется постоянно наращивать. Наращивать кол-вом серверов а не их обородованием. Использовать распределенное хранение, кластер.
Время простоя должно быть минимальное - в идеале вообще отсуствует(такого не бывает); ну там скажем пару минут в год.
Под 100% отказоустойчивостью я понимаю следующее, при выходе какого-либо звена на кластере это не влияет на функциональность работы его вцелом, может только сказаться на производительности.
Если грохнулась где то база данных или сбой любой призошел тоже самое.
Если во время перевода денег они где то потеряются или произойдет какая нить ошибка - то лучше откатиться назад.
Вообщем 100% исключена потеря или коверкание данных. С деньгами не шутят.
Со стороны оборудования это делается с помошью дублирования сервера хранилища как минимум 1 раз. Плюс дисковые массивы.
Избыточность - главный фактор отказоустойчивости.
Плюс нужны небольшие возможности расширения - клиенты будут разделятся на группы , для управления группами там отдельные клиенты( возможно браузеры+что то свое) и с каждого перевода взымается скажем малюханький процент а при некоторых не взымается - все зависит от ситуации. Плюс конвертировать данные на лету прийдется ( разные валюты ).
Ессесно для таких решений Oracle я считаю приемлимым, но так как проект не коммерческий то денег нету на него:) Поэтому на начальном этапе вот думаю меньше загонятся с базой( взять PostgreSQL -я тут почитал ссылочку которую мне дали, у нее все вроде что нужно есть).
Как только появятся деньги первым делом перейти на Oracle(Если к тому времени в нем будет нужда)

killed
>Так все же как пример: падает ваша база, как в этом случае вы представляете работу системы? Как она должна справляться с такой ситуацией?

Ну первым делом она вообще не должна падать:)
По сути при каком либо сбое - ну например при переводе денег грохнулся винт скажем или по како-либо причине база данных. Действие во-первых не должно возыметь место а просто осуществиться откат и при этом клинет не теряеет денег со счета но и у другого не прибавляется от этого(как будто этого и небыло) и у клиента скажем появляется сообщение - повторите, и при повторении все действия будут происходить со следующим кластером или винчестером(там точно такая же база данных - дублируемая, но только целая).А еще лучше если произошел сбой то запрос клиента перенаправляется на другую(точно такую же) базу данных и выполняется там. Если сбой в базе произошел по вине оборудования - то быстренько ликвидировать этот сбой вплоть до замены оборудования.
Вообщем повторение действий это крайний случай.
Сама база данных будет находиться в одном месте(вначале, а потом скорее всего будет в разных местах находится).
Она будет распределенная и каждый узел будет являться кластером(минимум 2 хранилища и 2 нода)
Собственно хочу чтоб для клиента база данных работала безотказно, а внутри при проишествии какого-либо сбоя в базе данных она автоматом переправляла запрос на работающую базу. Скажем одна запись(грубо говоря) будет хранитсья минимум в 4х экземлярах - она будет на 2х серверах(хранилищах) дублирующих и в каждом сервере будет raid массив из 2х дисков для хранения именно). Операционка и ПО свое будет отдельно.
Эти 2 сервера хранения + 2 нода - буду составлять малюханький кластер - и являться узлом, следующий узел уже другое будет хранить.
Вот мне нужно рассмотреть ВСЕ случаи падания базы данных по вине ПО. И как она будет автоматически с этим справляться.
Вроде того. У меня всегда были плохие способности к объяснению:)

чингиз скажем так - на хорошее дело денег найдем, но только не 20000 с чем долларов и даже больше на Oracle:)
А что это еще за sybase aca(yflt.cm правильно написал с ваших слов) - что то я не слышал о такой(( доверия к ней нетю(((
вот про транзакции я тоже так подумал - в postgresql лано есть и отлаженны, но если там журнал транзакци?? и возможность перенаправлять запросы - вот что еще интересует:)

Да да - что это за Sybase ASE он то чем хорош?