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

Откуда:
Сообщений: 21
Cпасибо за ответ!

И еще не поскажет кто, какая должна быть "железка" под Oracle при такой нагрузке и объеме БД.
12 май 08, 18:46    [5652650]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8523
maximpr1111
Предполагается разрабатывать систему с нагрузкой 1000 concurrent requests per second.

Таблицы в БД могут достигать 50000000 записей.
...
И еще не поскажет кто, какая должна быть "железка" под Oracle при такой нагрузке и объеме БД.
А сколько денег выделено на "железку"?
12 май 08, 19:26    [5652809]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54784

SQL*Plus
А сколько денег выделено на "железку"?

Какие еще деньги? Это же типичный очередной мегапрожект, призванный
заткнуть за пояс гугль с ютьюбом одновременно.

Posted via ActualForum NNTP Server 1.4

12 май 08, 20:16    [5652906]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
У Microsoft есть бесплатный вариант SQL Server?

есть.

по вопросу топика - критерии оценки, особенно по Ораклу, выдвинуты конечно мощные. Каким образом приплетается в сравнении СУБД для веб OAS - непонятно. Тогда наберите пачку других серверов приложений, приклепайте их к другим СУБД, и тоже сравнивайте. Потом, еще важны сами средства разработки для веб, т.е. обеспечивают-ли они или их драйверы
а) пул коннектов
б) кэширование результатов повторяющихся запросов
и т.д.

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

И, наконец, веб-проекты бывают разные. Одно дело электронный магазин (php+mysql), другое дело какой-нибудь портал на сотни тысяч пользователей. Причем, не факт что для второго может потребоваться Оракл.
12 май 08, 20:33    [5652937]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
У Microsoft есть бесплатный вариант SQL Server?
есть.

какие-то глюки или с форумом, или у меня с браузером.
12 май 08, 23:24    [5653262]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
SQL*Plus
maximpr1111
Предполагается разрабатывать систему с нагрузкой 1000 concurrent requests per second.

Таблицы в БД могут достигать 50000000 записей.
...
И еще не поскажет кто, какая должна быть "железка" под Oracle при такой нагрузке и объеме БД.
А сколько денег выделено на "железку"?


Денег достаточно. Я рассматриваю построение системы на "брендовом" железе (HP?,IBM?,Sun?). Вполне отдаю себе отчет, что под подобную нагрузку под базой должен быть очень серьезный и дорогой сервер (планирую даже сделать кластер). Хотелось бы понять какой именно, при чем не хочется брать мощнее, чем необходимо. Если кто может подсказать, чтобы могло бы быть оптимальным, и если возможно в терминах модельного ряда приведенных брендов.
13 май 08, 09:59    [5653990]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Dimitry Sibiryakov

SQL*Plus
А сколько денег выделено на "железку"?

Какие еще деньги? Это же типичный очередной мегапрожект, призванный
заткнуть за пояс гугль с ютьюбом одновременно.
Posted via ActualForum NNTP Server 1.4


Почти. Но с YTube и Google не конкурирует. Совершенно другая область.
13 май 08, 10:40    [5654228]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8523
maximpr1111
SQL*Plus
maximpr1111
Предполагается разрабатывать систему с нагрузкой 1000 concurrent requests per second.

Таблицы в БД могут достигать 50000000 записей.
...
И еще не поскажет кто, какая должна быть "железка" под Oracle при такой нагрузке и объеме БД.
А сколько денег выделено на "железку"?
Денег достаточно. Я рассматриваю построение системы на "брендовом" железе (HP?,IBM?,Sun?). Вполне отдаю себе отчет, что под подобную нагрузку под базой должен быть очень серьезный и дорогой сервер (планирую даже сделать кластер). Хотелось бы понять какой именно, при чем не хочется брать мощнее, чем необходимо. Если кто может подсказать, чтобы могло бы быть оптимальным, и если возможно в терминах модельного ряда приведенных брендов.
Закажите сайзинг перечисленным вендорам
и/или одной-двум независимым специализированным компаниям.
Попытки решить такой вопрос на форуме несерьезны и забавны...
13 май 08, 11:36    [5654644]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
SQL*Plus
maximpr1111
SQL*Plus
maximpr1111
Предполагается разрабатывать систему с нагрузкой 1000 concurrent requests per second.

Таблицы в БД могут достигать 50000000 записей.
...
И еще не поскажет кто, какая должна быть "железка" под Oracle при такой нагрузке и объеме БД.
А сколько денег выделено на "железку"?
Денег достаточно. Я рассматриваю построение системы на "брендовом" железе (HP?,IBM?,Sun?). Вполне отдаю себе отчет, что под подобную нагрузку под базой должен быть очень серьезный и дорогой сервер (планирую даже сделать кластер). Хотелось бы понять какой именно, при чем не хочется брать мощнее, чем необходимо. Если кто может подсказать, чтобы могло бы быть оптимальным, и если возможно в терминах модельного ряда приведенных брендов.
Закажите сайзинг перечисленным вендорам
и/или одной-двум независимым специализированным компаниям.
Попытки решить такой вопрос на форуме несерьезны и забавны...


Попытка задать этот вопрос на форуме связана с попыткой получить одно-два независимых мнений от людей, кто может быть имел дело с подобными системами. Естественно, я не рассчитываю использовать данную информацию, как истину в последней инстанции. Естественно эти вопросы будут также задаваться вендорам, но хотелось бы иметь предварительное представление, поскольку предварительную архитектуру хотелось бы составить сейчас, при чем не начиная сразу тратить деньги на проведение экспертиз. В принципе, сейчас пытаюсь составить предварительное представление, что это за проект. Думаю, что лучше будет перед разговором с вендором иметь еще какую-то информацию.
13 май 08, 12:05    [5654926]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
SQL*Plus
Member

Откуда: Россия, Москва
Сообщений: 8523
Несколько Sun Fire E25K Server должны справиться...
+ Дисковые массивы от EMC
13 май 08, 12:46    [5655320]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
Z][ANSWER
Guest
SQL*Plus
Несколько Sun Fire E25K Server должны справиться...
+ Дисковые массивы от EMC

Не маловато, а вот если взять эти то в самый раз Sun SPARC Enterprise M9000 Server...:-P
13 май 08, 12:55    [5655403]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
maximpr1111
Народ!

А может кто-нибудь дать рекомендации по выбору между связкой:

1. PHP+Oracle
2. JSP+Oracle

Предполагается разрабатывать систему с нагрузкой 1000 concurrent requests per second.

Таблицы в БД могут достигать 50000000 записей.


Гм, если такую систему собираешься строить и такие вопросы задаешь - то найди кого-нибудь с опытом и обсуди архитектуру. Это будет дешевле ошибок, да и вообще немало сэкономишь.

А то подобная нагрузка уже вызывает некоторый интерес (особенно если все 1000 req per second - пишущие, а логика обработки - сложная), совсем от балды и дешево не сделать.

Впрочем, если это типичный Web, то можно все затраты на лицензии свести к нулю, разных вариантов решений дофига. Да и железо особо крутое тут не нужно, по идее. И много его тоже не нужно.
14 май 08, 12:41    [5660925]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
По нагрузке:
думаю, что это будет 800 - чтение, 200 - запись.

Логика элементарная.

Главная опасность это рост объема данных.

Вопросы, на самом деле, задаю, чтобы сверить мое понимание данного проекта с мнением сообщества, поскольку, к сожалению, очень мало материалов, чтобы оценить преимущества одного технического решения над другим, и не "перезаложиться" на архитектуру.

Имел до этого дело с простыми веб-системами(php+mysql) , системами уровня клиент-банк (WebSphere+Oracle), хранилищами данных(Oracle). К сожалению, ни одна из приведенных выше архитектур здесь не применима.

Точно знаю, что MySQL плохо тянет сложные запросы из многих таблиц+прогнозы по объемам данных, повидимому исключают его напрочь.

По поводу, middle-tier терзают сомнения, при чем не нашел ни одного подтверждения, что Java производительнее, чем PHP. Хотел узнать еще мнения. Самому ни разу не доводилось сравнивать Java и PHP на сопоставимых нагрузках.

То, что ни удастся решить легко и дешево, мне было понятно с самого начала. Сейчас узнаю мнения сообщества, чтобы убедиться или разубедиться в том насколько не легко и не дешево. Не сгущаю ли я где-то краски.
14 май 08, 13:53    [5661600]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
Попробую ответить на вопросы (и задать свои).

Ну, производительность Java как таковой заметно выше, чем у PHP.
Другое дело, что для Web приложений производительность одного сервера не существенна, проще поставить рядом еще один - если, конечно, все спроектировано по уму. Существенным, скорее, является количество поддерживаемых соединений на сервер, удобство использования всяческих frameworks для генерации html (а их выбор, в свою очередь, зависит от сложности логики на стороне клиента), возможность играть с stateless/statefull, простота поднятия кластера с разными стратегиями loadbalancing/ha.

Далее, что за тяжелые запросы?
Откуда они взялись, какая нужна по ним производительность, нужно ли их делать на уровне БД, а не сервера приложений, не стоит ли их делать на отдельной аналитической БД?

Планируется ли работать с БД напрямую или через какой-нибудь ORM?

Какая стратегия кэширования планируется (memcached, distributed hash, MySQL Cluster) или никакой? Кстати, разумный кэш (если бизнес-логика с ним совместима) может кардинально уменьшить нагрузку на БД и позволит обойтись чем-нибудь простым типа MySQL или DB2 Express C.

Ну и какие сроки проекта :)
14 май 08, 19:20    [5664243]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Абсолютно согласен с тем, что при Web-приложении производительность одного сервера не существенна.

Сложные запросы: система по предварительному ТЗ содержит достаточно большое количество сущностей (но может не очень, но штук 20 имеется), которые различными способами связаны друг с другом. На ряде страниц будет необходимость отражать сущности вместе со связанными. Можно конечно вытащить все несколькими запросами, но мне кажется, что это тоже не очень хорощо.

Учитывая, что система позицируется, как высоконагруженная с порядка 20000000 зарегистрированных пользователей, а может и выше. Я предполагаю, что хотя бы 20% из них запостят хотя бы одно сообщение в месяц. Таким образом минимальный объем основной таблицы сообщений составит через год 48000000 (а система планирует жить дольше). Архивировать сообщения не хотелось бы. Основным интерфейсом к системе, которым пользуется 100% из заявленных 1000 соединений в секунду будет поиск по этой самой таблице на основе ключевых слов. Ключевые слова для своих сообщений пользователи задют сами и в системе существует справочник этих ключевых слов, которые может расширяться пользователем (предположим 15000 на язык, языков несколько).Каждому сообщению соотвествует одно или несколько ключевых слов. Есть серьезное предположение, что запросы будут настолько разными, что кешировать результаты будет бесполезно. В принципе, кеш планируется по возможности, но как именно пока не думал. Кстати еще одна особенность - учитывая, что это веб-приложения пользователь не может ждать первых результатов дольше минуты.

Подробности системы рассказать не могу, поэтому даю только цифры нагрузки с некими абстрактными сущностями.


Необходимость Application Server в архитектуре. Не знаю, может быть.
14 май 08, 20:00    [5664379]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Сроки - 1,5 года с учетом тестирования и маркетинга.
14 май 08, 20:01    [5664389]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
1. Простые запросы почти всегда лучше, чем сложные, даже на БД с хорошим оптимизатором.
Точно стоит подумать, все ли объекты действительно независимы или некоторые можно хранить внутри их "родителей". Стоит подумать о хранении сложных объектов (вытаскиваемых обычно целиком) в сериализованном виде в блобах - так можно сэкономить много select/insert.

2. 48млн. сообщений, даже по килобайту - это всего 48 гигов. С учетом закона Парето (а в Web даже не 20/80, а все 10/90, для нормального кэша сообщений хватит двух memcached машинок с 4 гигами на каждой, что не дорого. Т.е. на вытаскивании сообщений из БД можно хорошо съэкономить.

Если сообщения независимы, то их не обязательно хранить в одной БД, а можно в нескольких с очевидным хэшем. Может дать немалое ускорение (за счет сложности администрирования).

3. Поиск, заметим, не столько по базе сообщений, сколько по базе ключевых слов. Тут многое зависит от количества ключевых слов, сложности запросов и т.п.
Посмотри на то, как устроены поисковые системы, может оказаться, что многоуровневый поиск (типа Яндекса) тут окажется востребован. Да и таблица ключевых слов может поместиться в память - тогда поиск будет быстрым. А уже потом вытаскивать сообщения по списку ключей (из кэша и БД).

Это только очевидные общие мысли, без знакомства с постановкой больше сказать сложно.

4. Если у нас веб, то время отклика больше 1 секунды - это уже плохо.

5. Без сервера приложений - не взлетит :)

6. Если времени всего полтора года, то если команда уже есть - то делать так, как она умеет. А если команды нет, то или искать бюджет на перекупку звезд (дорого) или понимать, что сроки сорвете. Найти команду с опытом высоконагруженных систем меньше, чем за полгода - или не реально или дорого.

7. И найди консультанта с опытом и головой.
14 май 08, 20:46    [5664510]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Кстати, насчет команды:

Я рассматриваю возможность аутсорсинга (не оффшор, т.е. люди в офисе) проектной команды.

Никто не подскажет приличную контору, у которой реально есть квалифицированные специалисты для разработки подобных систем и кому можно доверить подобную разработку, не опасаясь за качество и сроки. Плюс сохранение конфидициальности до запуска.
15 май 08, 10:15    [5665923]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
maximpr1111
Учитывая, что система позицируется, как высоконагруженная с порядка 20000000 зарегистрированных пользователей, а может и выше.

20 миллионов пользователей????
Вот это трава!!!!! Где берете? Сами выращиваете или аутсорс?

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

Кстати, передам чтоли в гугл, что тут конкурент появился, скоро гугл потеснят. При возможности, передам, на неделе :)

-- Tygra's --
Мои фотогалереи тут и тут
15 май 08, 11:11    [5666365]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
maximpr1111
Кстати, насчет команды:

Я рассматриваю возможность аутсорсинга (не оффшор, т.е. люди в офисе) проектной команды.

Никто не подскажет приличную контору, у которой реально есть квалифицированные специалисты для разработки подобных систем и кому можно доверить подобную разработку, не опасаясь за качество и сроки. Плюс сохранение конфидициальности до запуска.

И это в гугл передам - может им заняться щас нечем :)

=======

Кстати, по системе: тут нужен полнотекстовый поиск, на который отдать более мощный сервер, если конечно предполагается, что искать будут совершенно разные слова из очень большого числа этих слов и что на сообщение будут весить много слов, а не 2-3; и сервер чуть проще, который будет по результату поиска отдавать информацию, ибо это легче, чем искать.
Кэшируется тут все без проблем.

ЗЫ Уже пару лет как переделан наш поиск.

-- Tygra's --
Мои фотогалереи тут и тут
15 май 08, 11:22    [5666472]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Кстати, у гугла пользователей больше (при чем я говорю о зарегистрированных, а не о посетителях), и насколько я знаю, они где-то говорили, что система построена чуть ли не на "персоналках" (хотя не верится). У гугла вообще другая схема нагрузки и другие задачи.

Есть более близкие похожие (по нагрузке, не по сути) системы на просторах Рунета (угадайте кто).

А потеоретизировать в форумах о возможных архитектурных решениях для систем c подобной нагрузкой, почему нет!!! Кстати под описанную мною схему ложится практически любой высоконагруженный форум!!!. Вообщем, условно - форум с 20000000 пользователей и поиском по этому форуму.

Кстати, не могу понять почему сразу Гугл и YouTube. Почему например не mail.ru или sql.ru (более похоже).

Кстати, всем кто давал рекомендации в этой ветке форума - огромное спасибо. Ваши советы очень сильно помогли мне прояснить картину с направлениями поиска архитектурных решений.

Скорее всего сделаю прототипы нескольких вариантов и прогоню под нагрузкой. Там и решу.
15 май 08, 11:48    [5666694]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
maximpr1111
Member

Откуда:
Сообщений: 21
Кстати, кроме всего прочего мне нужно было подтверждение (для дальнейшего обсуждения), что заявляемые параметры нагрузки ведут к необходимости построения достаточно тяжелого и дорогого решения, и классический php+MySQL здесь не к месту. У меня эта мысль появилась сразу, но хотелось услышать другие мнения. Я вполне допускаю, что ожидаемая нагрузка завышена раз в 10-20, но нужно же с уверенностью объяснить заказчику, что подобные параметры нагрузки кардинально меняют бюджетные параметры. С другой стороны, если параметры не завышены и достигнут предполагаемых через 1-2 года, то архитектуру надо выбирать так, чтобы она могла быть быстро смасштабирована на более высокую нагрузку с помощью установки большего количества и более мощного оборудования.
15 май 08, 12:28    [5667075]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
tygra
Member

Откуда: Тверь (Иркутск, Край)
Сообщений: 9997
php+MySQL должен был отпасть сразу, прямо до рождения :)

IIS + asp.net + MS SQL - лично мое предложение. Из IIS и asp.net делаешь кластер, когда надо, добавляешь. Сервера БД 2 как выше, поиск + остальные данные

-- Tygra's --
Мои фотогалереи тут и тут
15 май 08, 17:24    [5669787]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
maximpr1111
Кстати, насчет команды:

Я рассматриваю возможность аутсорсинга (не оффшор, т.е. люди в офисе) проектной команды.

Никто не подскажет приличную контору, у которой реально есть квалифицированные специалисты для разработки подобных систем и кому можно доверить подобную разработку, не опасаясь за качество и сроки. Плюс сохранение конфидициальности до запуска.


Ну, есть Devexperts в Питере, они высоконагруженными системами на заказ занимаются. Ищи среди разработчиков биржевых систем - там обычно знают, как с нагрузкой обращаться.

Но сразу следует заметить, что качество в оффшоре появляется, только если с разработкой планируется покупать и сопровождение, причем сопровождение по fixed price. А это бывает не просто редко, а очень редко.

Но полтора года - это все равно очень мало.
16 май 08, 09:56    [5671563]     Ответить | Цитировать Сообщить модератору
 Re: Сравнение СУБД в сфере Web-приложений  [new]
DPH
Guest
tygra
[
И конечно же требования к такой мегасистеме нужно выяснять в форуме - ну типа вдруг кто делал уже такую, или может владелец гугла тут случайно объявится, расскажет, скока у них железа и почем.

Да ладно, что там такого крутого особенно.
Количество зарегестрированных - не сильно важный показатель, интереснее количество обращений в секунду. А 1000 запросов в секунду - это вполне себе средненько. Т.е. нужно думать и иметь подходящий опыт, но не более того.
16 май 08, 09:58    [5671592]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4] 5 6 7 8 9 10 .. 12   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить