Что есть действительно большая таблица?

[Wingely Dog]

Что есть действительно большая таблица?

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

конкретно стоит задача создания некого прайса простейшего вида

id
parent
артикул - varchar(63)
название - varchar( 255 )
цена - int

при этом позиций планируется иметь в нем порядка нескольких дестков тысяч. база данных mysql или pgsql ( скорее всего второе )

соответственно вопрос о том, стоит ли разделять прайс на несколько таблиц по какму нить признаку или 10-100 тысяч позиции это вполне нормально?

 

[Serguitar]

Разработчики Mysql пишут, что их база может содержать таблицы с несколькими десятками миллионов строк. Правда-нет-мне неизвестно.
У меня в базе порядка 120000 строк, никаких проблем! Может, пока...

 

[Wingely Dog]

и что приосходит, когда пытаешься сделать LEFT JOIN оного с другой таблицей?

 

[neko]

Wingely Dog
ты когда-нибудь научишся самостоятельно тестировать скорость или так и будешь сюда бегать за "а что если.."?

 

[Wingely Dog]

neko

канешна научусь! еще пару раз отругаешь меня и я научусь. 8)
у меня просто негде потестировать большую базу на больших нагрузках, а самому смоделировать пока слабо.
Это канешна отговорки все, но на самом деле знание общественного мнения хороший ориентир, для личных оценок. И вообще человеку необходимо общатся с другими людьми для того чтобы рости.

Вот например я в другой раз и правда попробую нагрузить базу данных прежде чем спрошу что будет 8)

PS: может у вас таки найдется работа для морально-профессионального роста?

 

[neko]

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

соответственно вопрос о том, стоит ли разделять прайс на несколько таблиц по какму нить признаку или 10-100 тысяч позиции это вполне нормально?

этот вопрос раз в неделю задают на форуме по mysql
какое еще общественное мнение тебе нужно?

 

[Wingely Dog]

к своему стыду ли, радости ли, ни разу не был на местном форуме по mysql...
и не тянет ежли честно... 8/
хотя это к слову, намек понял.

кстати говоря, вас из дас относительная сокрость базы данных?
"нутром чую литр, а математически выразить не могу" (ц)

 

[neko]

короче в след. раз ты береш
делаешь сначала нормальную таблицу
потом делаешь это идиотское (партиционирование по 100тыс / таблицы в файлах / другая гениальная идея...)
и меряешь скорость <своей любимой операции> в обоих случаях
потом большее делиш на меньшее и получаешь некий результат

так вот при аналогичных настройках промышленного сервера с промышленными же объемами данных у тебе отношение скорости обоих методов будет точно таким же
за исключением полярных случаев
чтобы ответить на 99% процентов собственных вопросов никакие "моделирования нагрузок" ненужны

не понимаю, что тут может быть неочевидного...

 

[confguru]

Wingely Dog

Сделай тестовое заполнение миллионом записей
и проверь.

 

[Wingely Dog]

2 neko.
все, дошло. сам теперь не понимаю, что там неочевидного было? 8)
с отношениями шыкарная мысля, отбила половину вертевшихся в голове вопросов. Вот что значит позитивное общение!

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

но терь neko мне все объяснил, терь брезжет свет в конце тонеля вопросов "а что быстрее будет .... "

 

[RST. Angellab]

Конечно правильно проводить перфтесты, а не спрашивать ;-)

Из своего опыта могу сказать - таблица, с фиксированными записями - 2 миллиона записей, 100 запросов в секунду (поиск, апдейт, инсерт)- без проблем. Обработка запроса меньше секунды.
с динамическими записями - 800к записей (сериализованные объекты) - 50 запросов в секунду - поиск , апдейт сериализованных данных - без проблем.

сервер - Dual Xeon, 2GHz, 2Gig RAM. SCSI диски. LA - 10.
OS - RH 9, Mysql, Apache (тестировалось на Zeus - он начинал загибаться).
Траффика - около 1.5 миллиона посетителей в сутки .

-~{}~ 14.12.04 14:57:

Originally posted by neko
короче в след. раз ты береш
делаешь сначала нормальную таблицу
потом делаешь это идиотское (партиционирование по 100тыс / таблицы в файлах / другая гениальная идея...)
и меряешь скорость <своей любимой операции> в обоих случаях
потом большее делиш на меньшее и получаешь некий результат

так вот при аналогичных настройках промышленного сервера с промышленными же объемами данных у тебе отношение скорости обоих методов будет точно таким же
за исключением полярных случаев
чтобы ответить на 99% процентов собственных вопросов никакие "моделирования нагрузок" ненужны

не понимаю, что тут может быть неочевидного...

Не соглашусь почти ни разу.
Вопрос в объеме установленной памяти. В посте, что я написал выше - машина ложилась в LA=300 за 5 минут, когда памяти там было 1Gig. Поставили 2 Gig - все зашуршало. Посему аппроксимация далеко не всегда выход. Простой пример - база сконструирована так, что на 1гиге памяти она работает нормально в тестовом режиме, но когда пойдет Production, то окажется, что нужно гигов 10 памяти. А сервер для таких задач стоит около $50000 (HP Proliant). И соответсвенно получается бутылочное горлышко.

собственно резюме - нужно всегда помнить про память. (извините за каламбур )

 

[neko]

RST. Angellab
да я именно такие полярные случаи и имел в виду
память...

есть еще кое какие

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

кластеризация которую возможна на некоторых субд, тоже вносит некоторые особенности

а теперь перечитай первый пост, и подумай, имеет ли все это смысл для спрашиваюшего ;-)

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