Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
 Выбор СУБД  [new]
Opeg
Member

Откуда:
Сообщений: 6
Есть задача написать эфективное онлайн приложение с высокой доступностью(99.99% uptime) и масштабироуемостью до 1000 (и более если возможно) обращений в секунду.
Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб

Суть онлайн приложения

Аукцион
Магазин
Некоторое подобие платёжноей системы, с возможностью резервирования денег на счету платящего
Ведение акаунтов пользователей
некоторое подобие системы документооборота


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

Буду особо благодарен за отсутствие флейма и конструктивные предложения.
18 фев 07, 14:46    [3801732]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Серж
Member

Откуда:
Сообщений: 756
Opeg
приложение с высокой доступностью(99.99% uptime) и масштабироуемостью до 1000 (и более если возможно) обращений в секунду.
Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб

Как водится чем меньше денег будет стоить СУБД тем лучше.


Uptime будет определяться железом и каналами связи. Железом же будет определяться скорость работы системы. Как пример, что примерно апргрейдил Озон в 2004 году:
тынц

Берем самый недорогой из нормальных серверов и читаем его примеры внедрений (есть там примеры и похожих задач):
тынц

Сейчас придут ораклоиды, адепты дб2, мс скл и дадут аналогичные ссылки.

Что это будет доказывать? То, что на любом из серверов подобные задачи решались.
18 фев 07, 16:33    [3801877]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67469
Блог
Имхо тут стоит удариться в одну из крайностей. Если хочется думать о масштабировании и вообще о глобальном росте, гуглите на тему "на чем работают всякие amazon-ы с ebay-ями и почему". Если же оптимизироваться под цену и сегодняшнее состояние, вполне вероятно, лучшим выбором будет MySQL (если его лицензия позволит использовать его бесплатно). Почему: во-первых, на таких простых запросах он показывает отличное быстродействие, во-вторых, такие задачи легко и дешево можно масштабировать за счет shared nothing кластеризации на уровне аппсервера. При этом, разумеется, стоит понимать, что "стоимость лицензий" в этом случае в конце концов окажется выплаченной в виде зарплаты программистов, зато есть возможность с нуля написать крутую вещь, да и своим платить приятнее :)
18 фев 07, 16:34    [3801878]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Yo.!
Guest
softwarer
Имхо тут стоит удариться в одну из крайностей. Если хочется думать о масштабировании и вообще о глобальном росте, гуглите на тему "на чем работают всякие amazon-ы с ebay-ями и почему". Если же оптимизироваться под цену и сегодняшнее состояние, вполне вероятно, лучшим выбором будет MySQL (если его лицензия позволит использовать его бесплатно). Почему: во-первых, на таких простых запросах он показывает отличное быстродействие, во-вторых, такие задачи легко и дешево можно масштабировать за счет shared nothing кластеризации на уровне аппсервера. При этом, разумеется, стоит понимать, что "стоимость лицензий" в этом случае в конце концов окажется выплаченной в виде зарплаты программистов, зато есть возможность с нуля написать крутую вещь, да и своим платить приятнее :)


не согласен, 99%, 5-50Gb + workflow - это явно не стихия mysql. да и в аукционе не такие уж простые запросы получаются. 1-way xeon тянет 65К tpc-c транзакций, так что не думаю что есть смысл заморачиватся ему с кластеризацией субд в ближайшие годы :)
к стате сейчас смотрю на IBM x3950, вроде прикольно получается, их можно собирать в SMP частями, типа добавлять по 4 проца при необходимости, на 99% конечно не проканает но ...

ЗЫ. если нужна 99% то нужен standby хотябы, а это не так много кто умеет.
18 фев 07, 17:46    [3801980]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Opeg
Есть задача написать эфективное онлайн приложение с высокой доступностью(99.99% uptime) и масштабироуемостью до 1000 (и более если возможно) обращений в секунду.
Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб

Смотрим tpc.org, tpc-c тесты, и видим что вообще-то 1000 запросов в секунду не так уж и много и любая БД из тройки MSSQL/DB2/Oracle это тянет. 99.99% доступность (полчаса простоя в год) - на MS SQL обеспечить можно - но это требует соответствующего подхода к проектированию приложения и к проектированию развертывания приложения/применения хотфиксов.
У нас 1000 запросов в секунду нет, есть 700 в секунду при 1500 одновременных пользователях. Приложение 24x6, в течение этих шести дней в неделю 99.99% выдерживается.
18 фев 07, 18:04    [3802015]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Opeg
Member

Откуда:
Сообщений: 6
Прошу обратить внимание на одну маленькую деталь, я использовал слово обращение а не запрос. Сколько запросов будет в обращении?- может 15, может 60. Думаю сложно сказать при наличии ТЗ, а без его наличия практически невозможно. А мне нужны цыфры для БП, можно ли для этого использовать что-то из опенсорса или нужен оракл или дб2.

Судя по цифрам которые я нарыл в инете соответствующий аптайм можно получить только при помощи кластеризации. Причём как я понял нужна кластеризация мульти-мастер.
18 фев 07, 18:32    [3802072]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Opeg
Судя по цифрам которые я нарыл в инете соответствующий аптайм можно получить только при помощи кластеризации. Причём как я понял нужна кластеризация мульти-мастер.
Чет я не понял... Тебе деньги пристроить или работать?...
Если первое - хлястер на 2, а потом каженный год + 2 сервера.
Ни и ПО Ораклю и не парится...
Если второе:
1. Где сейчас база и где ты через 10 лет?..
2. Начинай с чего знаешь, ту БД и ставь. Потом все равно 5 раз переделывать...
3. По желеу - уже высказались.
Как-така Аптайма 99,99%??? Чего в сервер-то смотреть, если искричества нету?
Ты прикинь, что это даже собственная дизель-генераторная НЕ дает!...
По армеским нормам при 100% ГОРЧЕМ резерве. Наличии 200% холодного резерва.
18 фев 07, 18:54    [3802096]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Opeg
Прошу обратить внимание на одну маленькую деталь, я использовал слово обращение а не запрос. Сколько запросов будет в обращении?- может 15, может 60. Думаю сложно сказать при наличии ТЗ, а без его наличия практически невозможно. А мне нужны цыфры для БП, можно ли для этого использовать что-то из опенсорса или нужен оракл или дб2.

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

Судя по цифрам которые я нарыл в инете соответствующий аптайм можно получить только при помощи кластеризации. Причём как я понял нужна кластеризация мульти-мастер.

Кластер необходим. Что такое мультимастер не знаю. Если под этим подразумевается RAC - не знаю чем он лучше safeguard в плане обеспечения доступности. Главное в обеспечении доступности - разработка с учетом требований к доступности.
18 фев 07, 19:34    [3802163]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Opeg
Member

Откуда:
Сообщений: 6
Di_LIne
Как-така Аптайма 99,99%??? Чего в сервер-то смотреть, если искричества нету? 8

На это мне расказали об оптическом кольце, и площадках разнесённых на 20 км с независимым питанием, и пулемётчиках за колючей проволокой по периметру :)
18 фев 07, 19:39    [3802170]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Ап_Тайму 99,9% я дам только на... кулер CPU.
18 фев 07, 19:53    [3802190]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Серж
Member

Откуда:
Сообщений: 756
Еще в тему по амазону и по е-баю. Наверное два самых больших в мире инет-магазина.
19 фев 07, 06:25    [3802971]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
guest_20040621
Guest
> онлайн приложение с высокой доступностью(99.99% uptime)

У stack.net (это далеко не самый последний дата-центр в России), например, гарантированный uptime каналов порядка 99,95%. Вы понимаете, что четыре девятки - это дорогое удовольствие?

> и масштабироуемостью до 1000 (и более если возможно) обращений в секунду.

По сравнению с доступностью это так себе задача.

> Объём БД будет постоянно расти и скажем лет через 5 будет состалять 50Гб через 10лет 500Гб

Вряд ли понадобится 500 Гб оперативных данных.

> Мне нужна рекомендация на какой СУБД это будет эфективнее работать и почему.

Два варианта: либо снижайте требования к доступности, либо идите к интегратору, рисуйте схему приложения и формулируйте требования к СУБД нормальным образом.
19 фев 07, 09:10    [3803149]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
1000 обращений в секунду? Назовите мне широко известный _российский_ web-портал с таким количеством обращений в секунду. А особенно какой-нибудь аукцион, или магазин.
и чтобы не растопыривать пальцы :-) советую сравнить эту 1000 обращений с числом заходов на anekdot.ru
19 фев 07, 09:46    [3803269]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Opeg
Member

Откуда:
Сообщений: 6
Проект даже не предназначен для России, в России он будет не жизнеспособен ещё очень долго. Если придёт в Россию, то лет через 10 не раньше.

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

Также неплохо бы перечислить параметры, по чему их рекомендуете.
19 фев 07, 10:10    [3803381]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30261
ну не для России, фиг с ней. Пользователей сколько в системе будет.
19 фев 07, 10:54    [3803707]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
kdv
1000 обращений в секунду? Назовите мне широко известный _российский_ web-портал с таким количеством обращений в секунду.
- ЯНДЕКС со всеми сервисами. Потянет?
19 фев 07, 11:09    [3803780]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Opeg
Member

Откуда:
Сообщений: 6
Предположительно
Черезполгода после реализации около 300 в день, при этом около 100 из них будет находиться в онлайн в течении рабочего дня, регулярно обращайсь к сайту (возможно это будет AJAX). Остальные 200 это люди периодически обращающиеся ~раз в 15 минут

пользователей которые просто заходят и уходят я несчитаю тк они практически не создают нагрузки хотя их может быть ещё 1000-5000

за 5 лет эксплуатации предполагаю увеличение до тех что 300 до 5000, тех что 1000 до 40000-80000

думаю всё будет не так, но это то из чего я пока исхожу при расчётах, возможно мои колеги подойдут по позже и меня существенно по правят.

Сообщение было отредактировано: 19 фев 07, 11:37
19 фев 07, 11:14    [3803820]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
а можно спросить что это такое? хотя бы из какой области?
19 фев 07, 11:38    [3803993]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
guest_20040621
Guest
> По поводу интеграторов, посоветуйте плиз ведущих, лучших, и наиболее рациональных
> с вашей точки зрения.
> Также неплохо бы перечислить параметры, по чему их рекомендуете.

Это называется консалтинг и стоит денег.

P.S. У меня стойкое убеждение, что Вы занимаетесь не своим делом. Ничего личного.
19 фев 07, 13:50    [3804879]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
мнение
Guest
Opeg
Предположительно
Черезполгода после реализации около 300 в день, при этом около 100 из них будет находиться в онлайн в течении рабочего дня, регулярно обращайсь к сайту (возможно это будет AJAX). Остальные 200 это люди периодически обращающиеся ~раз в 15 минут

пользователей которые просто заходят и уходят я несчитаю тк они практически не создают нагрузки хотя их может быть ещё 1000-5000

за 5 лет эксплуатации предполагаю увеличение до тех что 300 до 5000, тех что 1000 до 40000-80000

думаю всё будет не так, но это то из чего я пока исхожу при расчётах, возможно мои колеги подойдут по позже и меня существенно по правят.


ИМХО Глобальные критерии выбора СУБД
в порядке убывания приоритета исходя из 1000 операций ( транзакций , запросов) в сек
и доступности 99.99%:

1. Возможность иметь горячий standby. И архиваровать логические журналы.

2. Поддержака кластерной конфигурации.

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

3. Поддержка репликации таблиц ( опреративная история должна быть короткой).
Или другой простой механизм переноса данных с OLTP в DWH.
Нет сейчас железа способного обрабатывать и одновременно хранить историю по
1000 операций в секунду за 5 лет.
19 фев 07, 15:28    [3805580]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Opeg
Member

Откуда:
Сообщений: 6
guest_20040621
> По поводу интеграторов, посоветуйте плиз ведущих, лучших, и наиболее рациональных
> с вашей точки зрения.
> Также неплохо бы перечислить параметры, по чему их рекомендуете.

Это называется консалтинг и стоит денег.

P.S. У меня стойкое убеждение, что Вы занимаетесь не своим делом. Ничего личного.


:)
Что же тогда моё дело, если не разобраться на рынке и выбрать оптимальное решение.
Если бы это было моё дело, я бы наверное уже написал приложение, и не задавал глупых вопросов.

зы: Это называется не консалтинг, а изучение рынка, что по сути маркетинговое исследование
imho
20 фев 07, 19:00    [3812598]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Opeg
Это называется не консалтинг, а изучение рынка, что по сути маркетинговое исследование
imho

- А чё? Я сам путаю: - Где левое, а где низ....
Или где у меня Front- и End-сервера... сегодня.
- Правда, ДокОлл?
20 фев 07, 20:51    [3812900]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Изопропил
Member

Откуда:
Сообщений: 31629
Di_LIne
Opeg
Это называется не консалтинг, а изучение рынка, что по сути маркетинговое исследование
imho

- А чё? Я сам путаю: - Где левое, а где низ....
Или где у меня Front- и End-сервера... сегодня.
- Правда, ДокОлл?

Главное - мягкое с тёплым не путай :)
20 фев 07, 23:46    [3813235]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
Di_LIne
Member

Откуда: Тропик Скорпиона
Сообщений: 32554
Изопропил
Главное - мягкое с тёплым не путай :)

Был б Кат2, я б каментов наделал. Не только Изо, но и бутыль б пропили.
А сейсас - воздержусь...
21 фев 07, 03:02    [3813372]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД  [new]
10046
Member

Откуда: oraus.msg
Сообщений: 877
мнение
Opeg
Предположительно
Черезполгода после реализации около 300 в день, при этом около 100 из них будет находиться в онлайн в течении рабочего дня, регулярно обращайсь к сайту (возможно это будет AJAX). Остальные 200 это люди периодически обращающиеся ~раз в 15 минут

пользователей которые просто заходят и уходят я несчитаю тк они практически не создают нагрузки хотя их может быть ещё 1000-5000

за 5 лет эксплуатации предполагаю увеличение до тех что 300 до 5000, тех что 1000 до 40000-80000

думаю всё будет не так, но это то из чего я пока исхожу при расчётах, возможно мои колеги подойдут по позже и меня существенно по правят.


ИМХО Глобальные критерии выбора СУБД
в порядке убывания приоритета исходя из 1000 операций ( транзакций , запросов) в сек
и доступности 99.99%:

1. Возможность иметь горячий standby. И архиваровать логические журналы.

2. Поддержака кластерной конфигурации.

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

3. Поддержка репликации таблиц ( опреративная история должна быть короткой).
Или другой простой механизм переноса данных с OLTP в DWH.
Нет сейчас железа способного обрабатывать и одновременно хранить историю по
1000 операций в секунду за 5 лет.

С такими требованиями выбор сужается до одной СУБД :)
21 фев 07, 08:46    [3813637]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить