ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор БД для нагруженного портала ( много поиска )
25 сообщений из 52, страница 2 из 3
  2  все
Выбор БД для нагруженного портала ( много поиска )
    #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
| Ответить | Цитировать | Написать  
25 сообщений из 52, страница 2 из 3
  2  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / Выбор БД для нагруженного портала ( много поиска )
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=35&msg=36546806&tid=1552818]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 35ms
get topic data:
 10ms
get forum data:
 2ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 11ms
total:  146ms
созд. / загр.: 146ms
x
x
Закрыть


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