Выбор СУБД для больших нагрузок

[redlaber]

Значит задача:
База данных с огромным количеством записей. Т.е. таблиц в базе будет немного, но вот записей в таблицах - очень много. Также база должна обрабатывать большое количество запросов. Понятно, что это будет зависить и от канала связи и от оборудования, но все же, какую СУБД лучше выбрать для создания очень объемной базы (ну например база жителей одной области страны с адресами, телефонами и пр. доп. информацией)?

[wl]

Oracle

[Y.dMiTrIy]

mysql ?

[redlaber]

Ну хорошо. Сколько людей - столько мнений. Обоснуйте пожалуйста, почему именно Оракл или MySQL.
Я знаю, что Oracle - замечательно подходит для больших пректов, но сложна в администрировании.
Так же MySQL - проста в администрировании, но не для быстрой обработки огромного числа запросов.

[wl]

Ну хорошо. Сколько людей - столько мнений. Обоснуйте пожалуйста, почему именно Оракл или MySQL.

Ответ в вашем же сообщении.

MySQL - проста в администрировании, но не для быстрой обработки огромного числа запросов.

Раз предполагается большая нагрузка, mysql будет тормозить.

И на закуску.
http://www.google.com/search?client=opera&rls=en&q=Oracle+vs+MySQL&sourceid=opera&ie=utf-8&oe=utf-8

[Y.dMiTrIy]

Я думаю, что та доля секунды для обработки запроса для MySQL которую она проиграет Oracle вполне может компенсировать более простая форма(интерфейс) доступа (практически из всех скриптов и программ) и легкость в администрировании...
P.S. Как по мне, если задачи сверх сложные, с огромной вероятностью (или опасностью) к потери данных то Oracle имеет неоспоримое преимущество перед  MySQL. Хотя более легковесной считаю MySQL.

[wl]

Какая доля секунды?
35 секунд против 2 секунд при идентичных данных и запросах.

[redlaber]

Давайте не будем разжигать спор, я в принципе все понял. Спасибо за столь быстрые ответы. Почитал об Oracle, посмотрел сравнение - это то, что нужно. Спасибо еще раз.

[fwhr]

А самая большая база данных в мире (>2 петабайт) работает на PostgreSQL
http://habrahabr.ru/blogs/postgresql/26289/

[bujhm666]

Около года как перешли на PostgreSQL, до этого была MS SQL. Мне нравится, работает шустро, админится довольно легко.

[burgua]

PostrgeSQL

[Lifewalker]

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

Был у меня случай. Лет 10 тому назад сдал один небольшой проект, который был основан на СУБД не скажу какой, чтобы тень на неё не бросать. Программа вполне успешно работала и вполне благополучно хранила множество записей. Как и в Вашем случае, структура была несложной, но число записей велико. Но, по прошествии времени, пользователи стали жаловаться на падение производительности, причём падение было нелинейным. Как будто по достижении определённого числа записей в таблицах кто-то внутри системы включал ручник. В последствии (после снятия системы с эксплуатации) выяснилось наличие архитектурного косяка. Иными словами тормоза были мной "запрограммированы" в саму логику программы, но тогда-то я этого не знал. Проверь я комплекс перед сдачей в эксплуатацию на проектном наборе данных - эта проблема всплыла бы ещё при разработке. Но...

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

[redlaber]

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

Был у меня случай. Лет 10 тому назад сдал один небольшой проект, который был основан на СУБД не скажу какой, чтобы тень на неё не бросать. Программа вполне успешно работала и вполне благополучно хранила множество записей. Как и в Вашем случае, структура была несложной, но число записей велико. Но, по прошествии времени, пользователи стали жаловаться на падение производительности, причём падение было нелинейным. Как будто по достижении определённого числа записей в таблицах кто-то внутри системы включал ручник. В последствии (после снятия системы с эксплуатации) выяснилось наличие архитектурного косяка. Иными словами тормоза были мной "запрограммированы" в саму логику программы, но тогда-то я этого не знал. Проверь я комплекс перед сдачей в эксплуатацию на проектном наборе данных - эта проблема всплыла бы ещё при разработке. Но...

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

Огромное спасибо.

[Александръ]

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

А какого рода косяк можно поинтересоваться? Интерес не праздный, а профессиональный, чтобы в своей практике избежать такого.

[Lifewalker]

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

А какого рода косяк можно поинтересоваться? Интерес не праздный, а профессиональный, чтобы в своей практике избежать такого.

Многолетний опыт работы с FoxPro был тупо перенесён на клиент-серверную архитектуру. Не до конца нормализовал таблицы, злоупотреблял частыми мелкими запросами на выбор кусков данных (повёлся на абстрактное представление об удобстве пользователя) вместо создания нормальных представлений и хранимых процедур, с индексами вообще был швах полный ну и так далее. В общем один большой косяк

Всё это, отлично работая на локальном девелоперском "стенде", будучи перенесено в реальную жизнь с множеством клиентов и относительно медленной локальной сеть породило тормоза. Ну а добило ситуацию окончательно разрастание базы до определённого размера. Примерно через полгода реальной работы число записей о клиентах превысило некий "порог вменяемости" и тогда стало захлёбываться всё: и СУБД тыркалась постоянно от попыток удовлетворить тучу мелких неэффективных выборок, и сеть ложилась потому что туда-сюда данные гонялись и клиенты ложились, потому что получив баааальшую пачку данных впадали в задумчивость.

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