ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор БД для нагруженного портала ( много поиска )
52 сообщений из 52, показаны все 3 страниц
  все  
Выбор БД для нагруженного портала ( много поиска )
    #36545987
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Сам я очень слабо разбираюсь в различных бд. Необходимо разработать портал со следующими возможностями:

Основная функция портала это поиск и добавление заявок.
Каждая заявка имеет ~ 35 параметров ( например – параметр: год выпуска ), 18 из них поисковые. Заявки будут добавляться ~ по 1 в сек, в пиковые часы до ~ 10 в сек
Все добавленные заявки должны сразу быть доступны для поиска.
~ 30 пользователей ежесекундно ( в пиковые ~ 100) будут искать заявки по нужным им параметрам.
Общее количество заявок в системе 200-300’000

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

Вопрос: какие базы данных для этого более приспособлены?

P.S. Очень важна сохранность информации и отказоустойчивость. А так же не маловажным фактором, популярность бд, так как на узкоспециализированные бд сложнее найти программистов.
...
Рейтинг: 0 / 0
27.03.2010, 10:14
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36545995
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Можно начинать выбирать по любым другим параметрам (цена, удобство,..)

Современные СУБД и железо даже на ноутбуке! обеспечивают скорость в тысячи и десятки тысяч транзакций.

Почитайте по форуму по скорость, по функционалу.
...
Рейтинг: 0 / 0
27.03.2010, 10:36
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546132
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Siemargl
Можно начинать выбирать по любым другим параметрам (цена, удобство,..)

+1.

Только начать всё-же со стандартного списка:
1) уже используется заказчиком
2) знакома разработчику

100 запросов в секунду в пике это не "нагруженный портал", а "мало кому
интересная дребедень".
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
27.03.2010, 13:45
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546181
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Dimitry Sibiryakov,

Или портал в интрасети. Тогда можно смотреть Sharepoint (но может выйти дорого по лицензиям)
...
Рейтинг: 0 / 0
27.03.2010, 14:45
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546228
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Siemargl - спасибо, я сам не очень разбираюсь в нагрузках, но знаком не с одним программистом ( видимо с плохими ), у которых порталы при 100 000 хитах виснут, хотя все говорят что 100 000 хитов это не нагрузка вовсе. Сколько там запросом на каждую страницу я не знаю, но это обычные информационные порталы.
.
Dimitry Sibiryakov - заказчиком, еще только мысль используется
возможно не нагруженный, уж извиииините, если не к той градации отнес, пусть будет сайт визитка с поиском :) от этого его параметры не изменяются
дребедень или нет - пусть будут решать пользователи.
.
Siemargl - контора в которой мы делали ТЗ рекомендовала нам разрабатывать в PostgreSQL или Microsoft SQL Server.
...
Рейтинг: 0 / 0
27.03.2010, 15:52
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546276
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
Alex042Сам я очень слабо разбираюсь в различных бд. Необходимо разработать портал со следующими возможностями:

Основная функция портала это поиск и добавление заявок.
Каждая заявка имеет ~ 35 параметров ( например – параметр: год выпуска ), 18 из них поисковые. Заявки будут добавляться ~ по 1 в сек, в пиковые часы до ~ 10 в сек
Все добавленные заявки должны сразу быть доступны для поиска.
~ 30 пользователей ежесекундно ( в пиковые ~ 100) будут искать заявки по нужным им параметрам.
Общее количество заявок в системе 200-300’000

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

Вопрос: какие базы данных для этого более приспособлены?

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

Firebird Classic или SuperClassic (но не Superserver). Машинка можно двухядерная, но лучше 4-рёх. Память, рейды чем больше и быстрее тем лучше. Для пользователей память считаем мин 64Мб для сервера +8мб для каждого одновременно работающего пользователя. Можно меньше, но будет медленнее.

>>35 параметров
для каждого параметра который используется в условиях поиска по индексу, +несколько составных индексов для самых распространённых наборов поиска (лучше добавить во время эксплуатации).

Разработка портала(это вроде web) php но лучше java/jsp (выше производительность). Если выберете .NET могут быть проблемы.
...
Рейтинг: 0 / 0
27.03.2010, 16:55
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546283
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
Alex042
Siemargl - контора в которой мы делали ТЗ рекомендовала нам разрабатывать в PostgreSQL или Microsoft SQL Server.

В PostgreSQL можно, даже удобнее и мощнее(это де-факто бесплатный оракл), но разработка сложнее чем с FB.
Microsoft SQL Server - ограничиваете себя Windows и довольно дорогой лицензией(на процессор).

>>SQL Svr Standard Edtn Win32 Russian Lic/SA Pack OLP NL Processor License
http://www.softkey.ua/catalog/program_ver.php?ID=5087#o8224
~5500$
...
Рейтинг: 0 / 0
27.03.2010, 17:03
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546289
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Alex042
я сам не очень разбираюсь в нагрузках, но знаком не с одним
программистом ( видимо с плохими ), у которых порталы при 100 000 хитах
виснут, хотя все говорят что 100 000 хитов это не нагрузка вовсе.

А теперь сравни их 100 тысяч хитов и свои 100 (без тысяч).
Разница на три порядка.

Alex042заказчиком, еще только мысль используется
Тогда естественно возникают вопросы:
1) где эта мысль потом будет хоститься. У провайдера, на выделенном
сервере (который опять же на площадке провайдера или у Васи Пупкина под
кроватью), или заказчик будет свой датацентр городить.
2) Какая требуется степень надёжности.
3) Насколько критична скорость отклика и чем она будет лимитироваться.

Firebird, конечно, потянет, но ей нужен будет соответствующий
разработчик и DBA.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
27.03.2010, 17:09
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546296
Yo.!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo.!
Гость
если это сайт, значит повесить его захочется на хостинг, отсюда и плясать. хостеры предлагают mysql, postgres, реже mssql, oracle единицы ...
если постгрес вытягивает, я бы остановился на нем.
...
Рейтинг: 0 / 0
27.03.2010, 17:14
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546366
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Alex042Siemargl - контора в которой мы делали ТЗ рекомендовала нам разрабатывать в PostgreSQL или Microsoft SQL Server.
Ну так разработчик пусть и командует. Ну и хостера подыщите. Бюджет проекта пока сверстаете, раз ТЗ есть.

Толстый_Троль идет в свое болото, учить лицензирование. Лицензия на MSSQL Web Edition почти вдвое дешевле и SA лишнее.
...
Рейтинг: 0 / 0
27.03.2010, 19:14
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546385
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
SiemarglAlex042Siemargl - контора в которой мы делали ТЗ рекомендовала нам разрабатывать в PostgreSQL или Microsoft SQL Server.
Толстый_Троль идет в свое болото, учить лицензирование. Лицензия на MSSQL Web Edition почти вдвое дешевле и SA лишнее.

3272.50$
http://xn--b1aficwgpgex.com/soft/microsoft/olp/sql-server-web-edition.html?side=right

Хотя проект тоже там в бюджет от 20000$, так что нормально.
...
Рейтинг: 0 / 0
27.03.2010, 19:57
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546387
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Толстый_Троль - спасибо за информацию

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

лицензию там подешевле предлагали, но все равно. Как я понимаю, особой разницы с Microsoft SQL Server для нашего портала не будет, а тогда зачем платить лишнее, я лучше эти деньги разработчикам добавлю.

Dimitry Sibiryakov –

1. конечно же, на выделенном или 2, 3 ( надеюсь не более)
2. да чтобы кому не лень не ломали )
3. Так как у нас нет своих программистом, мы подходим с точки зрения пользователя, а для пользователя важно – как быстро появится то, что он запросил. Чем быстрее – тем лучше.

Не пояснил – у знакомого программиста 100’000 в сутки.
Наш же портал преполагает: 2-2’500’000 хитов в сутки (~ 30 запросов поиска в секунду), причем более половины из них это поиск по базе, и как я понимаю раз заявки постоянно доб/удал в течении дня, как-либо кэшировать это не получится.

Siemargl – наше сотрудничество на ТЗ и закончилось. Мы тогда окончательно решили, что надо искать на постоянную.
...
Рейтинг: 0 / 0
27.03.2010, 20:05
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546403
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Alex0422. да чтобы кому не лень не ломали )
3. Так как у нас нет своих программистом, мы подходим с точки зрения
пользователя, а для пользователя важно – как быстро появится то, что он
запросил. Чем быстрее – тем лучше.

Под "надёжностью" я имел ввиду "доступность". Сколько времени в году
ресурс может быть недоступен?
"Чем быстрее - тем лучше" это сколько? В секундах. Вон, недавно один
кретин в firebird-support настаивал, что в примерно аналогичной системе
(только у него данных на два порядка больше) любой запрос не должен
выполняться дольше 100 миллисекунд. И что характерно, в них укладывался,
хоть и через задницу, не слушая добрых советов.
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
27.03.2010, 20:32
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546421
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Dimitry Sibiryakov,

желательно "24/7" - возможно отключение на до 3 мин ночью и то не желательно.

сколько миллисекунд не знаю, но желательно при нормальном канале, что то, что запрашивает поселитель загружалось не более 2 сек.
вот такая скорость загрузки меня более чем удовлетворит http://www.e1.ru/auto/sale/index.php?m=1659
...
Рейтинг: 0 / 0
27.03.2010, 20:46
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546425
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Alex042
желательно "24/7" - возможно отключение на до 3 мин ночью и то не
желательно.

Это потребует кластер и хорошего админа...
Posted via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
27.03.2010, 20:50
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546435
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Dimitry Sibiryakov
Alex042
желательно "24/7" - возможно отключение на до 3 мин ночью и то не
желательно.

Это потребует кластер и хорошего админа...


спасибо за совет, будет иметь ввиду. я надеюсь это уже растолкуют нам разработчики.
...
Рейтинг: 0 / 0
27.03.2010, 21:00
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546458
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Alex042,

Вы вдаетесь в детали, без общей картины. Пишите "кластер" в ТЗ =)

Хм, кластер на PG. Не в курсе. Отклоняюсь. Хотя в вебе кластер делается и без кластера БД.
...
Рейтинг: 0 / 0
27.03.2010, 21:33
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546473
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Alex042
~ 30 пользователей ежесекундно ( в пиковые ~ 100) будут искать заявки по нужным им параметрам.

Так не бывает. Если средняя нагрузка 30 TPS, то пиковая не меньше 200, а то и 1000, зависит от проекта. Еще момент - вы про полнотекстовый поиск или поиск по параметрам? Это очень сильно влияет на выбор.
...
Рейтинг: 0 / 0
27.03.2010, 21:53
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546478
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Да, еще момент - если размер БД превысит размер ОЗУ, на большинстве СУБД вы получите огромные, часто нерешаемые, проблемы. Так что лучше назовите предполагаемый размер БД (за три года обычно) и ОЗУ на сервере, чтобы более предметно можно было оценить задачу.
...
Рейтинг: 0 / 0
27.03.2010, 21:56
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546480
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Siemargl,

меня спросили - я ответил )

Спасибо всем за участие и помощь, я думаю следует теперь сосредоточиться на поиске этих самых разработчиков:

Кстати никто не подскажет где их можно найти? на фрилансе что-то мало нормальных специалистов.
...
Рейтинг: 0 / 0
27.03.2010, 21:58
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546484
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
MBGAlex042
~ 30 пользователей ежесекундно ( в пиковые ~ 100) будут искать заявки по нужным им параметрам.

Так не бывает. Если средняя нагрузка 30 TPS, то пиковая не меньше 200, а то и 1000, зависит от проекта. Еще момент - вы про полнотекстовый поиск или поиск по параметрам? Это очень сильно влияет на выбор.

к сожалению оценить реальную нагрузку мы не можем, так как оценивать еще не на чем.

поиско по параметрам
...
Рейтинг: 0 / 0
27.03.2010, 22:03
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546488
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
MBGДа, еще момент - если размер БД превысит размер ОЗУ, на большинстве СУБД вы получите огромные, часто нерешаемые, проблемы. Так что лучше назовите предполагаемый размер БД (за три года обычно) и ОЗУ на сервере, чтобы более предметно можно было оценить задачу.

Первое время сервер будет арендоваться, это точно - так что ОЗУ будет стоять столько, сколько потребудется.
...
Рейтинг: 0 / 0
27.03.2010, 22:07
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546532
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
MBGДа, еще момент - если размер БД превысит размер ОЗУ, на большинстве СУБД вы получите огромные, часто нерешаемые, проблемы.
Вы глупость несусветную сказанули. Чушь чушовую.

Если данные влезают в ОЗУ, то никакие РСУБД и даром не нужны. Хватит сериализуемого на диск куска памяти ака массив.
РСУБД возникли (в том числе) для того, чтобы эффективно работать с данными, объём которых превышает не только доступное ОЗУ, но иногда и адресное пространство.
...
Рейтинг: 0 / 0
27.03.2010, 23:23
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546603
Mysqladdictive
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mysqladdictive
Гость
http://www.e1.ru/auto/sale/index.php?m=1659
вчера, 20:46 [8543323] Ответить | Цитировать Сообщить модератору

Прикольно, этот посредник при заказчике считает что приведённая ссылка - поиск
Дезайнер небось или, что более вероятно топменеджер супервебстудии.
...
Рейтинг: 0 / 0
28.03.2010, 03:20
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546709
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
Mysqladdictivehttp://www.e1.ru/auto/sale/index.php?m=1659
вчера, 20:46 [8543323] Ответить | Цитировать Сообщить модератору

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

А кто тут утверждал, что это поиск?

Мне сказали, какая скорость загрузки Вам нужна, я и отвечаю С ТОЧКИ ЗРЕНИЯ ПОЛЬЗОВАТЕЛЯ.
Я не имею понятия как отследить эти 100, 200 миллисекунд? ( ну если они не выводятся внизу страницы)
И для ПОЛЬЗОВАТЕЛЯ, нет ни какой разницы, поиск это или статика - его волнует, когда по его ЩЕЛЧКУ - появится то, что он запросил? Или я не прав?
...
Рейтинг: 0 / 0
28.03.2010, 12:17
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546729
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
ЛП
Если данные влезают в ОЗУ, то никакие РСУБД и даром не нужны. Хватит сериализуемого на диск куска памяти ака массив.
РСУБД возникли (в том числе) для того, чтобы эффективно работать с данными, объём которых превышает не только доступное ОЗУ, но иногда и адресное пространство.

Попробуйте иногда и головой думать. А именно - подавляющее большинство существующих БД помещаются в оперативку, а РСУБД используются ради транзакционности, поддержки SQL прочего функцинала.
...
Рейтинг: 0 / 0
28.03.2010, 12:47
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546806
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
MBG
Попробуйте иногда и головой думать. А именно - подавляющее большинство существующих БД помещаются в оперативку, а РСУБД используются ради транзакционности, поддержки SQL прочего функцинала.

Почитайте теорию что-ли. Очень хорошо чтобы индекс влазил в память (или его основные уровни в случае В+, R+ дерева). А данные это дело такое.
...
Рейтинг: 0 / 0
28.03.2010, 14:23
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546811
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
[quot Alex042]
Кстати никто не подскажет где их можно найти? на фрилансе что-то мало нормальных специалистов./quot]

Если интересно, могу взяться за модули эффективно функционирующие с бд(php) и саму БД. Но вот сам дизайн не моё.
...
Рейтинг: 0 / 0
28.03.2010, 14:28
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36546921
Mysqladdictive
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Mysqladdictive
Гость
Alex042
А кто тут утверждал, что это поиск?

Мне сказали, какая скорость загрузки Вам нужна, я и отвечаю С ТОЧКИ ЗРЕНИЯ ПОЛЬЗОВАТЕЛЯ.
Я не имею понятия как отследить эти 100, 200 миллисекунд? ( ну если они не выводятся внизу страницы)
И для ПОЛЬЗОВАТЕЛЯ, нет ни какой разницы, поиск это или статика - его волнует, когда по его ЩЕЛЧКУ - появится то, что он запросил? Или я не прав?

Дилетант вы чистой воды, или авантюрист.


MBG, вы понимаете что такое VDS?
И встречались-ли в вашей практике приложения сложнее списка пользователей?
...
Рейтинг: 0 / 0
28.03.2010, 16:40
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547008
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Mysqladdictive
MBG, вы понимаете что такое VDS?


Интересно, с какого перепугу вы про VDS вдруг заговорили? Топикстартер ясно сказал, что проект будет работать на нескольких (2,3) выделенных серверах.

Mysqladdictive
И встречались-ли в вашей практике приложения сложнее списка пользователей?

Переход на личности свидетельствует лишь об отсутствии у вас какой-либо квалификации. Если это не так, будьте любезны показать свои открытые проекты. Мои open source проекты легко посмотреть здесь (fossil-репозиторий, debian-репозиторий, блог): MBG SQLite
На сайт с коммерческими продуктами линк там же можно найти, к слову сказать.
...
Рейтинг: 0 / 0
28.03.2010, 18:24
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547012
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Толстый_ТрольПочитайте теорию что-ли. Очень хорошо чтобы индекс влазил в память (или его основные уровни в случае В+, R+ дерева). А данные это дело такое.

Каким местом _теория баз данных_ связана со _статистикой их использования_? А вот стандартное поведение популярных СУБД заточено именно на типичное их использование - когда вся БД помещается в ОЗУ (как пример - тот же постгрес - если БД не влазит в ОЗУ, сразу же оказывается необходимым настраивать параметры стоимости чтения страниц с диска и т.п., так это нетипичный сценарий использования).
...
Рейтинг: 0 / 0
28.03.2010, 18:30
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547092
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
MBGТолстый_ТрольПочитайте теорию что-ли. Очень хорошо чтобы индекс влазил в память (или его основные уровни в случае В+, R+ дерева). А данные это дело такое.

Каким местом _теория баз данных_ связана со _статистикой их использования_? А вот стандартное поведение популярных СУБД заточено именно на типичное их использование - когда вся БД помещается в ОЗУ (как пример - тот же постгрес - если БД не влазит в ОЗУ, сразу же оказывается необходимым настраивать параметры стоимости чтения страниц с диска и т.п., так это нетипичный сценарий использования).

Мне очень сложно с вами спорить, так как я не знаю о чём спорить. Я плотно не работал с MySql может там и всё так плохо, но firebird очень шустро делала выборки на P2 с 256 Мб, на котором стоял Windows 2000 AS, Домен, CVS, локальный фтп и веб-сервер и всё это еще использовалось в качестве прокси, маил-сервера и Nat. База была около 5Гб на NTFS. выборки строились по 30-40 мс.

Я DB-хакер?
...
Рейтинг: 0 / 0
28.03.2010, 19:54
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547094
miksoft
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miksoft
Участник
MBGА вот стандартное поведение популярных СУБД заточено именно на типичное их использование - когда вся БД помещается в ОЗУКак раз точно наоборот. "стандартное поведение популярных СУБД заточено" именно на то, что объем данных будет многократно больше объема ОЗУ. Когда начиналось развитие большинства лидирующих СУБД и ОЗУ-то было крошечным.
...
Рейтинг: 0 / 0
28.03.2010, 19:56
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547174
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Толстый_Троль
Мне очень сложно с вами спорить, так как я не знаю о чём спорить. Я плотно не работал с MySql может там и всё так плохо, но firebird очень шустро делала выборки на P2 с 256 Мб, на котором стоял Windows 2000 AS, Домен, CVS, локальный фтп и веб-сервер и всё это еще использовалось в качестве прокси, маил-сервера и Nat. База была около 5Гб на NTFS. выборки строились по 30-40 мс.

Я DB-хакер?

А теперь запустите там же 5 конкурентных запросов, каждый из которых работает с выборкой 1 Гб, притом эти выборки не пересекаются.
...
Рейтинг: 0 / 0
28.03.2010, 21:42
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547179
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
miksoftКак раз точно наоборот. "стандартное поведение популярных СУБД заточено" именно на то, что объем данных будет многократно больше объема ОЗУ. Когда начиналось развитие большинства лидирующих СУБД и ОЗУ-то было крошечным.
Если бы дело обстояло так, как вы говорите, то СУБД обходились бы без кэша - какой смысл кэшировать то, что больше никогда не понадобится. Посмотрите на выделяемые постгресу или ораклу блоки shared memory - они нужны именно для того, чтобы хранить в них часто используемые данные, а если запросы постоянно "ворочают" объемами данных, не помещающимися в кэш, то происходит непрерывное вытеснение страниц из кэша и это весьма неоптимально.
...
Рейтинг: 0 / 0
28.03.2010, 21:47
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547196
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
MBGmiksoftКак раз точно наоборот. "стандартное поведение популярных СУБД заточено" именно на то, что объем данных будет многократно больше объема ОЗУ. Когда начиналось развитие большинства лидирующих СУБД и ОЗУ-то было крошечным.
Если бы дело обстояло так, как вы говорите, то СУБД обходились бы без кэша - какой смысл кэшировать то, что больше никогда не понадобится. А зачем освобождать память, если прочитанные данные могут вскоре еще понадобиться?

не знаю, Вы какие-то странные вещи пишите
на мой взгляд 95% данных в базе не используется месяцами, какой смысл иметь такую большую оперативную память?
...
Рейтинг: 0 / 0
28.03.2010, 22:04
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547217
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
MBG,

Вот не надо частные проблемы постгриса приписывать всем СУБД. И вообще, фуллсканы и им подобные запросы можно пускать мимо кэша.
...
Рейтинг: 0 / 0
28.03.2010, 22:27
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547244
###
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
###
Участник
MBG,

Вы уточните для своих оппонентов, что Вы имеете в виду не размер хранимых данных, а размер выбираемых (запросом) данных.
А то, сдается мне, все эти споры просто из-за неточных формулировок...
...
Рейтинг: 0 / 0
28.03.2010, 23:17
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547280
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
###MBG,

Вы уточните для своих оппонентов, что Вы имеете в виду не размер хранимых данных, а размер выбираемых (запросом) данных.
А то, сдается мне, все эти споры просто из-за неточных формулировок...

Вы правы, стоит уточнить.

Рассмотрим ситуацию: БД содержит данные за 3 года, а построение месячных отчетов является типичной задачей. Тогда, если размер БД > 3*12*RAM, типичная выборка не влезает в кэш. На практике размер БД обычно изменяется нелинейно, например, удваивается за полгода - год (зависит от проекта, конечно, - может расти и намного быстрее). Тогда может оказаться, что актуальных данных за последний месяц в БД не 1/36, а 1/3, и соотношение примет вид БД > 3*RAM. Как пример, в проекте с 20 гиг БД в типичном отчете может строиться выборка 4-5 Гб размером (взято из вполне реального приложения). Но на самом деле не весь объем RAM можно отдать под кэш БД, обычно не больше 1/2, откуда следует БД > 1.5*RAM. Вот этот коэффициент 1.5 я откинул для простоты и назвал соотношение БД > RAM, подразумевая, что при этом размер типичной выборки превышает объем кэша СУБД.
...
Рейтинг: 0 / 0
29.03.2010, 00:22
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547304
ЛП
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ЛП
Участник
2 MBG
Попробуйте иногда и головой думать.
Зеркалу это скажи.

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

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

---------------------------

2 ###
MBG,

Вы уточните для своих оппонентов, что Вы имеете в виду не размер хранимых данных, а размер выбираемых (запросом) данных
Неважно совершенно.
...
Рейтинг: 0 / 0
29.03.2010, 01:36
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547463
Eugenkru10
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Eugenkru10
Гость
Поставьте себе Visual Foxpro и не морочте людям голову!!!
...
Рейтинг: 0 / 0
29.03.2010, 09:29
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547660
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
MBGА вот стандартное поведение популярных СУБД заточено именно на типичное их использование - когда вся БД помещается в ОЗУ (как пример - тот же постгрес - если БД не влазит в ОЗУ, сразу же оказывается необходимым настраивать параметры стоимости чтения страниц с диска и т.п., так это нетипичный сценарий использования).

Верно-верно. Из этого следует, что стандартное поведение СУБД, "заточенное" на случай, когда не "вся БД помещается в ОЗУ", будет таким:
* сколько ОЗУ ни давай, ощутимой пользы не будет;
* "параметры стоимости чтения страниц с диска и т.п." их совершенно не интересуют и ни на что не влияют.
...
Рейтинг: 0 / 0
29.03.2010, 11:03
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547898
Толстый_Троль
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Толстый_Троль
Участник
Victor Metelitsa
Верно-верно. Из этого следует, что стандартное поведение СУБД, "заточенное" на случай, когда не "вся БД помещается в ОЗУ", будет таким:
* сколько ОЗУ ни давай, ощутимой пользы не будет;
* "параметры стоимости чтения страниц с диска и т.п." их совершенно не интересуют и ни на что не влияют.

Не вся БД, а только выборка и индексы(или их часть) для выборки. А rows в память будут фетчится только если баран ДБА не создал нужных индексов.
...
Рейтинг: 0 / 0
29.03.2010, 12:41
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36547954
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Siemargl
Участник
Толстый_Троль,

Не забываем еще второго потенциального барана - встроенный оптимизатор.
...
Рейтинг: 0 / 0
29.03.2010, 12:59
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36548260
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
Толстый_ТрольVictor Metelitsa
Верно-верно. Из этого следует, что стандартное поведение СУБД, "заточенное" на случай, когда не "вся БД помещается в ОЗУ", будет таким:
* сколько ОЗУ ни давай, ощутимой пользы не будет;
* "параметры стоимости чтения страниц с диска и т.п." их совершенно не интересуют и ни на что не влияют.

Не вся БД, а только выборка и индексы(или их часть) для выборки.
А пофиг. Абсурдность не уменьшается ни на сколько.
...
Рейтинг: 0 / 0
29.03.2010, 15:02
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36549119
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
MysqladdictiveAlex042
А кто тут утверждал, что это поиск?

Мне сказали, какая скорость загрузки Вам нужна, я и отвечаю С ТОЧКИ ЗРЕНИЯ ПОЛЬЗОВАТЕЛЯ.
Я не имею понятия как отследить эти 100, 200 миллисекунд? ( ну если они не выводятся внизу страницы)
И для ПОЛЬЗОВАТЕЛЯ, нет ни какой разницы, поиск это или статика - его волнует, когда по его ЩЕЛЧКУ - появится то, что он запросил? Или я не прав?

Дилетант вы чистой воды, или авантюрист.


а предложение в топике на самом верху Alex042 Сам я очень слабо разбираюсь в различных бд

Вам ничего не говорит?
Я написал эту тему, чтобы мне подсказали какие бд лучше подходят для таких задач.

Да, видимо, я обишся назвав пиковые нагрузки. признаю и каюсь ) Средние же расчитывались, как и все среднестатистическое.

Если кто может подсказать, что входит в объем бд. Я могу приблизительно подсчитать ее.
...
Рейтинг: 0 / 0
29.03.2010, 20:08
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36549553
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Alex042
Если кто может подсказать, что входит в объем бд. Я могу приблизительно подсчитать ее.

А почему бы вам не написать скрипт, который создаст и заполнит тестовую базу согласно вашим ожиданиям за первые 2 года работы системы? Заодно подумаете и о распределении данных и протестировать сможете в разных СУБД, многое станет очевидным.
...
Рейтинг: 0 / 0
30.03.2010, 03:18
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36549555
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Victor MetelitsaMBG...

Верно-верно. Из этого следует, что стандартное поведение СУБД, "заточенное" на случай, когда не "вся БД помещается в ОЗУ", будет таким:
* сколько ОЗУ ни давай, ощутимой пользы не будет;
* "параметры стоимости чтения страниц с диска и т.п." их совершенно не интересуют и ни на что не влияют.

Вы сами поняли, что сказали?

* Если физически ОЗУ мало, например, 1 гиг, а вы указываете СУБД, что ОЗУ 100 гиг, какая от этого может быть польза - в своп залезете. Виртуальная-то память будет выделяться, но результат окажется плачевен.

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

Во избежание флейма добавлю, что и при корректных настройках зачастую при "тяжелых" конкурентных запросах СУБД берет памяти больше, чем предполагается настройками, что и приводит к интенсивному своппингу.
...
Рейтинг: 0 / 0
30.03.2010, 03:27
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36549675
Victor Metelitsa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Victor Metelitsa
Участник
MBGVictor MetelitsaMBG...

Верно-верно. Из этого следует, что стандартное поведение СУБД, "заточенное" на случай, когда не "вся БД помещается в ОЗУ", будет таким:
* сколько ОЗУ ни давай, ощутимой пользы не будет;
* "параметры стоимости чтения страниц с диска и т.п." их совершенно не интересуют и ни на что не влияют.

Вы сами поняли, что сказали?
Именно. Я сказал ровно то же самое, что сказали вы, только другими словами. Выступил, так сказать, в роли зеркала.
...
Рейтинг: 0 / 0
30.03.2010, 09:10
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36550102
Alex042
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alex042
Гость
MBG[quot Alex042]


Если есть желание, свяжитесь со мной. по адресу newfax@mail.ru
...
Рейтинг: 0 / 0
30.03.2010, 11:52
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36550473
MBG
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MBG
Гость
Victor Metelitsa
Именно. Я сказал ровно то же самое, что сказали вы, только другими словами. Выступил, так сказать, в роли зеркала.

Извиняюсь, мне показалось, что вы хотели сказать то, что этого не может быть, поскольку такое поведение абсурдно :-)
...
Рейтинг: 0 / 0
30.03.2010, 13:50
| Ответить | Цитировать | Написать  
Выбор БД для нагруженного портала ( много поиска )
    #36555266
Фотография roden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
roden
Участник
Alex042
Очень важна сохранность информации и отказоустойчивость.
Будет храниться какая-либо персональная информация? Соответственно, нужно ли соответствием закону № 152-ФЗ «О персональных данных»?
...
Рейтинг: 0 / 0
01.04.2010, 13:08
| Ответить | Цитировать | Написать  
52 сообщений из 52, показаны все 3 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор БД для нагруженного портала ( много поиска )
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=35&tid=1552818]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 38ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 74ms
get tp. blocked users:
 1ms
others: 258ms
total:  412ms
созд. / загр.: 412ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]