Добрый день всем!
Мне бы хотелось узнать Ваши мнения по поводу надежности PostgreSQL.
Задача примерно такая, имеется сайт с большим кол-вом пользователей в сутки, ну, например, 1000000. Пользователи могут на свои аккаунты перечислять финансовые средства, например, через PayPal и производить некоторые операции со средствами, например, оплачивать услуги сайта.
Вопрос в том, на сколько надежен Postgre для работы в таких условиях, т.е. можно ли хранить такой объем данных, какова будет производительность (по сравнению с MySQL или MaxDB или другими бесплатнымы БД), а самое главное - надежно ли хранить данные о финансовых операциях, или лучше для таких целей посмотреть в сторону коммерческих БД, например, Oracle.

Заранее благодарю всех за ответы.

Jelis Dmitry ZhukovДобрый день всем!
Мне бы хотелось узнать Ваши мнения по поводу надежности PostgreSQL.
Задача примерно такая, имеется сайт с большим кол-вом пользователей в сутки, ну, например, 1000000. Пользователи могут на свои аккаунты перечислять финансовые средства, например, через PayPal и производить некоторые операции со средствами, например, оплачивать услуги сайта.
Вопрос в том, на сколько надежен Postgre для работы в таких условиях, т.е. можно ли хранить такой объем данных, какова будет производительность (по сравнению с MySQL или MaxDB или другими бесплатнымы БД), а самое главное - надежно ли хранить данные о финансовых операциях, или лучше для таких целей посмотреть в сторону коммерческих БД, например, Oracle.

Заранее благодарю всех за ответы.

Вполне надежен. Имхо, тут все дело упираеться в железо. Если у вас каждый час будет сервер падать по питанию, например, а через месяц умрет единственный хард - то тут ни какой оракл не поможет! Так что хорошее серверное железо, мощный упс, райд, регулярные бекапы, и можно в сторону кластера (БД) посмотреть, ну ко всему к этому адекватный админ. Короче, работаете с деньгами, так и вкладывайте их сначала :-) (Хотя, если деньги вкладывают - то вопросов обычно не возникает, нужен ли оракл, или можно его мускулом заменить).
Непосредственно про надежность постгреса - у меня далеко не самый обширный опыт работы с ним, но за 4 года, данные по вине постгреса не терялись. Даже намека не было :-)
А нагрузку постгрес держит лучше чем мускул. Судя по тестам.... Хотя я тестам не верю - все от приложения зависит (от программистов)! А рафинированные запросы ... они и есть рафинированные :-) По моемму опыту, если вы уперлись в производетельность БД, то сменой СУБД делу не поможеш - кривые запросы и ущербная архитектура приложения не будет работать ни где!
ну деньги пока вкладывать не хочется, т.к. это просто идея, и не ясно, заработает она когда-либо или нет. А за то, что поделилсь опытом - спасибо! Ваша информация для меня почти бесценна :)

PostgreSQL начинающий>
Странная задача. Вы хотите сервис запустить или просто PostgreSQL попользовать? Выбор компонентов программно-аппаратного комплекса определяется требованиями к этому комплексу. Надежность, производительность, масштабируемость, стоимость обслуживания и пр. Вы хотите начать выбор компонентов с конца. Так не бывает.
Я хочу сделать сервис, мне нужны простые, мощные и надежные средства для этого.
Пока что выбрал Ruby (и Ruby on Rails) как технологию для создания сайта. Осталось выбрать БД и ОС (из Unix-овых).
Причем, сам имею дело по долгу службы с Oracle и PL/SQL. И поэтому присматриваюсь, можно ли найти достойную (во всех смыслах) замену дорого Oracle ПО с открытым кодом. Ну из MySQL и PostgreSQL ближе всего по производительности и надежности, а так же структурой организации к Oracle всех ближе PostgreSQL. Поэтому и спрашиваю про него. Хотя есть еще MaxDB от MySQL, но что это за зверек, пока что не знаю. Может кто знает? (В смысле его сравнение с PostgreSQL).

PostgreSQL начинающий> Пока что выбрал Ruby (и Ruby on Rails) как технологию для создания сайта.
> Осталось выбрать БД и ОС

Дмитрий, не обижайтесь, пожалуйста, но для меня результат очевиден; напрасно потратите время в лучшем случае.

А не могли бы Вы более аргументированно объяснить свою мысль?

PostgreSQL начинающий> А не могли бы Вы более аргументированно объяснить свою мысль?

Миллион пользователей в день - это высоконагруженный ресурс. Посчитайте пиковое количество транзакций в секунду, допустимое время простоя и сформулируйте требования к серверу приложений, СУБД и hardware.

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

Спасибо за Ваше мнение, но тогда, возможно, Вы сможете подсказать, какую конфигурацию выбрать для решения столь не простой задачи. (Ведь работают же и Yandex, и MailRu, и Google).
Вопрос с железом остро не стоит, т.к. это относительно дешевый вопрос. А вот с технологиями все намного хуже.

Чувствую, меня не очень понимают.
Я бы хотел построить этот сервис на ОС plan 9 (к стати, google работает на нечто подобном).
Опыта работы с этой ОС пока у меня крайне мало, но есть огромное желание и довольно много времени.
Если использовать ее, то вопросы с архитектурой железа в принципе отпадают сами собой (уж так хорошо эта система продумана).
На счет производительности ROR в связке с БД не знаю (если кто посоветует нечто лучшее и столь же простое для изучения и использования - ОГРОМНОЕ СПАСИБО!!!).
Только вот портировать Oracle на plan 9 не представляется возможным, т.к. нужно перекомпилить все программы в среде этой системы. Если кто с ней работал, может подскажет, какой софт для нее есть (в смысле БД).
Поэтому выбор падает на Postgre, как наиболее близкую по возможностям к Oracle. В банке, где я тружусь, используется тоже Oracle на Solaris. Веременем проверено, что он надежен.
Будет ли так же надежен Postgre в описаных жестких условиях - это и пытаюсь выяснить.
И как понял из обсуждения, то он будет вполне надежен.

PostgreSQL начинающий> с технологиями все намного хуже

Я бы разбил задачу на три части. Первая: общая архитектура, включая требования к аппаратной части. На самом деле это не такая простая задача, как может показаться; возможно, проще будет сразу строить распределенное приложение (с учетом геотаргетинга, например). Критерий: прогнозируемая нагрузка + 50% (на стоимость глобально это не повлияет, но некоторый запас в случае успеха будет). Из ответа на первый вопрос будет следовать ответ на второй вопрос: масштабируемый сервер приложений (вариант: балансирование нагрузки для сервера приложений). Решения могут быть как аппаратные, так и программные. И из ответов на первые два вопроса сложатся требования к СУБД.

К сожалению, у меня не было задач такого масштаба, но imho мой примерный план был бы таким.

По поводу google: по-моему, общее описание архитектуры было на labs.google.com.

Вы сказали, что ни ROR, ни Postgre использовать не стали бы. А что бы Вы использовали для такой задачи?

235 Dmitry ZhukovЧувствую, меня не очень понимают.
Я бы хотел построить этот сервис на ОС plan 9 (к стати, google работает на нечто подобном).

нет, гугл работает на линукс - у них собственная файловая система для работы с блоками, и по сути в ядро вшита функциональность поддержки ихнего кластера. Слухи о plan9 на гугле пошли после того, как Роб Пайк ушел к ним на роботу, но этот миф уже пытались развенчать несколько раз.

Dmitry Zhukov
Опыта работы с этой ОС пока у меня крайне мало, но есть огромное желание и довольно много времени.

прекрасно - она поддерживает Xen и при желании возможно с ней играться и работать сколько угодно. Если из-под Xen в гостевом режиме, то и думать про драйвера не нужно особо.

если бы... а так жизнь сурова и поэтому нужно работать и я сижу на Debian.

Dmitry Zhukov
Если использовать ее, то вопросы с архитектурой железа в принципе отпадают сами собой (уж так хорошо эта система продумана).

миф. драйвера все равно надо. Или тогда уж железо под нее искать. Или немного попортировать самому.

Dmitry Zhukov
На счет производительности ROR в связке с БД не знаю (если кто посоветует нечто лучшее и столь же простое для изучения и использования - ОГРОМНОЕ СПАСИБО!!!).

стоит обратить внимание в таком случае на python - самое оно для всех применений. Postgres его встаивает как язык, на связке Postgres+Python стоит весь Skype из 8млн подключений одновременно.

Dmitry Zhukov
И как понял из обсуждения, то он будет вполне надежен.
вполне. чего бы не сказал полностью о руби (но даже он очень хорош по сравнению с пхп)

Спасибо за Ваше мнение, у меня к Вам просьба:
чувчтвую, Вы не плохо разбираетесь в делах Unix и internet-технологий.
Возможно ли задать Вам некоторые вопросы в личной беседе?
Если согласитесь, мой e-mail godima@gmail.com