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

Если данные влезают в ОЗУ, то никакие РСУБД и даром не нужны. Хватит сериализуемого на диск куска памяти ака массив.
РСУБД возникли (в том числе) для того, чтобы эффективно работать с данными, объём которых превышает не только доступное ОЗУ, но иногда и адресное пространство.


Попробуйте иногда и головой думать. А именно - подавляющее большинство существующих БД помещаются в оперативку, а РСУБД используются ради транзакционности, поддержки SQL прочего функцинала.
28 мар 10, 12:47    [8544453]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Толстый_Троль
Member [заблокирован]

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

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


Почитайте теорию что-ли. Очень хорошо чтобы индекс влазил в память (или его основные уровни в случае В+, R+ дерева). А данные это дело такое.
28 мар 10, 14:23    [8544591]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Толстый_Троль
Member [заблокирован]

Откуда:
Сообщений: 33
[quot Alex042]
Кстати никто не подскажет где их можно найти? на фрилансе что-то мало нормальных специалистов./quot]

Если интересно, могу взяться за модули эффективно функционирующие с бд(php) и саму БД. Но вот сам дизайн не моё.
28 мар 10, 14:28    [8544597]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Mysqladdictive
Guest
Alex042

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

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


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


MBG, вы понимаете что такое VDS?
И встречались-ли в вашей практике приложения сложнее списка пользователей?
28 мар 10, 16:40    [8544883]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
MBG
Guest
Mysqladdictive

MBG, вы понимаете что такое VDS?


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

Mysqladdictive

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


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


Каким местом _теория баз данных_ связана со _статистикой их использования_? А вот стандартное поведение популярных СУБД заточено именно на типичное их использование - когда вся БД помещается в ОЗУ (как пример - тот же постгрес - если БД не влазит в ОЗУ, сразу же оказывается необходимым настраивать параметры стоимости чтения страниц с диска и т.п., так это нетипичный сценарий использования).
28 мар 10, 18:30    [8545110]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Толстый_Троль
Member [заблокирован]

Откуда:
Сообщений: 33
MBG
Толстый_Троль
Почитайте теорию что-ли. Очень хорошо чтобы индекс влазил в память (или его основные уровни в случае В+, R+ дерева). А данные это дело такое.


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


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

Я DB-хакер?
28 мар 10, 19:54    [8545280]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
miksoft
Member

Откуда:
Сообщений: 38919
MBG
А вот стандартное поведение популярных СУБД заточено именно на типичное их использование - когда вся БД помещается в ОЗУ
Как раз точно наоборот. "стандартное поведение популярных СУБД заточено" именно на то, что объем данных будет многократно больше объема ОЗУ. Когда начиналось развитие большинства лидирующих СУБД и ОЗУ-то было крошечным.
28 мар 10, 19:56    [8545286]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
MBG
Guest
Толстый_Троль

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

Я DB-хакер?


А теперь запустите там же 5 конкурентных запросов, каждый из которых работает с выборкой 1 Гб, притом эти выборки не пересекаются.
28 мар 10, 21:42    [8545491]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
MBG
Guest
miksoft
Как раз точно наоборот. "стандартное поведение популярных СУБД заточено" именно на то, что объем данных будет многократно больше объема ОЗУ. Когда начиналось развитие большинства лидирующих СУБД и ОЗУ-то было крошечным.

Если бы дело обстояло так, как вы говорите, то СУБД обходились бы без кэша - какой смысл кэшировать то, что больше никогда не понадобится. Посмотрите на выделяемые постгресу или ораклу блоки shared memory - они нужны именно для того, чтобы хранить в них часто используемые данные, а если запросы постоянно "ворочают" объемами данных, не помещающимися в кэш, то происходит непрерывное вытеснение страниц из кэша и это весьма неоптимально.
28 мар 10, 21:47    [8545504]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
MBG
miksoft
Как раз точно наоборот. "стандартное поведение популярных СУБД заточено" именно на то, что объем данных будет многократно больше объема ОЗУ. Когда начиналось развитие большинства лидирующих СУБД и ОЗУ-то было крошечным.

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

не знаю, Вы какие-то странные вещи пишите
на мой взгляд 95% данных в базе не используется месяцами, какой смысл иметь такую большую оперативную память?
28 мар 10, 22:04    [8545539]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
MBG,

Вот не надо частные проблемы постгриса приписывать всем СУБД. И вообще, фуллсканы и им подобные запросы можно пускать мимо кэша.
28 мар 10, 22:27    [8545609]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
###
Member

Откуда: Курумоч
Сообщений: 658
MBG,

Вы уточните для своих оппонентов, что Вы имеете в виду не размер хранимых данных, а размер выбираемых (запросом) данных.
А то, сдается мне, все эти споры просто из-за неточных формулировок...
28 мар 10, 23:17    [8545726]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
MBG
Guest
###
MBG,

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


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

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

Зеркалу это скажи.

А именно - подавляющее большинство существующих БД помещаются в оперативку

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

а РСУБД используются ради транзакционности, поддержки SQL прочего функцинала.

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

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

2 ###
MBG,

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

Неважно совершенно.
29 мар 10, 01:36    [8545964]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Eugenkru10
Guest
Поставьте себе Visual Foxpro и не морочте людям голову!!!
29 мар 10, 09:29    [8546272]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Victor Metelitsa
Member

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


Верно-верно. Из этого следует, что стандартное поведение СУБД, "заточенное" на случай, когда не "вся БД помещается в ОЗУ", будет таким:
* сколько ОЗУ ни давай, ощутимой пользы не будет;
* "параметры стоимости чтения страниц с диска и т.п." их совершенно не интересуют и ни на что не влияют.
29 мар 10, 11:03    [8546813]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Толстый_Троль
Member [заблокирован]

Откуда:
Сообщений: 33
Victor Metelitsa

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


Не вся БД, а только выборка и индексы(или их часть) для выборки. А rows в память будут фетчится только если баран ДБА не создал нужных индексов.
29 мар 10, 12:41    [8547533]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6637
Толстый_Троль,

Не забываем еще второго потенциального барана - встроенный оптимизатор.
29 мар 10, 12:59    [8547640]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
Толстый_Троль
Victor Metelitsa

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


Не вся БД, а только выборка и индексы(или их часть) для выборки.

А пофиг. Абсурдность не уменьшается ни на сколько.
29 мар 10, 15:02    [8548566]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Alex042
Member

Откуда:
Сообщений: 22
Mysqladdictive
Alex042

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

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


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


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

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

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

Если кто может подсказать, что входит в объем бд. Я могу приблизительно подсчитать ее.
29 мар 10, 20:08    [8550313]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
MBG
Guest
Alex042

Если кто может подсказать, что входит в объем бд. Я могу приблизительно подсчитать ее.


А почему бы вам не написать скрипт, который создаст и заполнит тестовую базу согласно вашим ожиданиям за первые 2 года работы системы? Заодно подумаете и о распределении данных и протестировать сможете в разных СУБД, многое станет очевидным.
30 мар 10, 03:18    [8551011]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
MBG
Guest
Victor Metelitsa
MBG
...


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


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

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

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

Во избежание флейма добавлю, что и при корректных настройках зачастую при "тяжелых" конкурентных запросах СУБД берет памяти больше, чем предполагается настройками, что и приводит к интенсивному своппингу.
30 мар 10, 03:27    [8551013]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Victor Metelitsa
Member

Откуда: Тюмень
Сообщений: 2559
MBG
Victor Metelitsa
MBG
...


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


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

Именно. Я сказал ровно то же самое, что сказали вы, только другими словами. Выступил, так сказать, в роли зеркала.
30 мар 10, 09:10    [8551312]     Ответить | Цитировать Сообщить модератору
 Re: Выбор БД для нагруженного портала ( много поиска )  [new]
Alex042
Member

Откуда:
Сообщений: 22
MBG
[quot Alex042]


Если есть желание, свяжитесь со мной. по адресу newfax@mail.ru
30 мар 10, 11:52    [8552366]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить