|
|
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте уважаемые пользователи форума! Помогите советом. Проектирую базу данных на MySQL, задался простым, но очень важным вопросом - что лучше, одна большая таблица или много маленьких? (с точки зрения дальнейшей обработки и пр.). Допустим есть данные их можно поместить в 1 таблицу 100 000 записей или в 100 по 1000 или в 10 по 10000. Будет стандартная работа с базой: добавление, удаление, несложный поиск в ней. И еще, скажите пожалуйста сколько записей в таблице в MySQL максимально допустимо? Спасибо большое, жду ответов от знающих людей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 15:15 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
почитай про нормализацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 15:24 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Konst_Oneпочитай про нормализацию а если не отправлять к "мануалам", а просто сказать свое экспертное мнение? ведь для этого и существуют форумы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 15:34 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Про MySQL отправляйся в соответствующий форум. ИМХО, нормализация тут не при чём. Речь идёт о секционировании таблиц. Размер таблицы должен быть таким, чтобы таблицей можно было пользоваться (манипулировать записями, обслуживать, резервировать и пр.) в установленные регламентом сроки. Ну и естественно таблица должна отвечать ограничениям платформы и СУБД. Положим, если для резервирования данных ты используешь Blu-Ray, то делать таблицу которая займёт больше 50GB неразумно. Ты не сможешь создать её резервную копию на одном диске. Если данных больше 50GB, нужно разложить их в несколько таблиц размером по 50GB и резервировать их поочереди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 15:39 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Смысл в том что есть однотипные записи их можно хранить в одной таблице или в нескольких, потому что логически записи будут большими группами. есть ли смысл эти записи делить на таблицы по этим группам, простой пример есть записи допустим по городам, стоит ли делать для каждого города отдельную таблицу если для каждого такого города будет по 10 000 записей. То есть для 10 городов 100 000записай, но вобще городов может быть больше 10 например 40 или 50. Более всего важна именно выборка из таблиц, поиск второстепенная задача и не особо важен Или все записи в том числе из разных городов слоить в одну кучу, или раскидать по отдельным таблицам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 15:58 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
хотел еще добавить, что про нормализацию речи не идет, меня интересует вопрос именно с физической точки зрения - скорость выборки главное . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 16:05 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
freelander...логически записи будут большими группами... вот и подумайте над этим. а то сразу секционирование и тд и тп ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 16:07 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Города я просто так привел, как бы логически если делить. но смысл не в том. Есть объем данных которому не нужна нормализация и так далее. Добавление новых данных и прочее мы сейчас не рассматриваем. Есть объем данных, положим он не меняется. мне нужно выбирать массивы данных из этого набора. где это быстрее будет происходить из таблицы размерностью 100 000 записей, или из 10 таблиц размерностью 10 000 записей. Важное замечание: выборка всегда только из ОДНОЙ таблицы. То есть если я делю на 10 то выбирать мне нужно будет только из одной, мне известной таблицы. А не из нескольких. По сути вопрос сводиться к тому откуда будет выборка быстрее из большой или из маленькой таблицы. Ответ очевиден, из маленькой, но мне важна именно разница скоростей, на сколько она будет существенна, или наоборот пренебрежительно мала. Интересует именно если таблица будет довольно таки большой в 300 000 тыщ записей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 16:41 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
нарушение 3нф - один из смертных грехов. оправдания не существует ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 17:10 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
freelander, На ваш вопрос нельзя однозначно ответить. Ответ зависит от многого, например, от характера данных, от SQL-запроса, от объема выборки, от имеющихся индексов, от системных ресурсов. Вобщем-то, даже ваше "откуда будет выборка быстрее из большой или из маленькой таблицы. Ответ очевиден, из маленькой" не всегда верно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 17:18 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
freelander wrote: > а если не отправлять к "мануалам", а просто сказать свое экспертное > мнение? ведь для этого и существуют форумы. Говорю тебе своё экспертное мнение: Если ты задаёшь такие вопросы, то ты ничерта не смыслиш в проектировании реляционных баз данных. А если ты ничерта не смыслиш в проектировании реляционных баз данных, то тебе либо нужно не заниматься их проектированием, и не задавать глупых вопросов, либо учиться их проектировать. Как делать второе -- тебе уже подсказали. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 18:24 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
freelander wrote: > Смысл в том что есть однотипные записи их можно хранить в одной таблице > или в нескольких, потому что логически записи будут большими группами. > есть ли смысл эти записи делить на таблицы по этим группам, простой > пример есть записи допустим по городам, стоит ли делать для каждого > города отдельную таблицу если для каждого такого города будет по 10 000 > записей. То есть для 10 городов 100 000записай, но вобще городов может > быть больше 10 например 40 или 50. Это -- уже гораздо более другой вопрос. Нет, не стоит, если ты не делаешь VLDB. А если ты делаешь VLDB, то её не стоит делать на MySQL и там уже этого не нужно делать по другим причинам: там поддерживается партицирование таблиц. Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 18:27 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
freelanderно мне важна именно разница скоростей, на сколько она будет существенна, или наоборот пренебрежительно мала. Ну вот тебе пример. Если выбирать из 100000 записей одну полным перебором, то скорость такого запроса будет пропорционально уменьшаться по мере увеличения количества записей в таблице и будет небольшой. Но если для поиска использовать индекс, положим BTree, то скорость такого запроса будет очень слабо зависеть от числа записей - хоть 10, хоть 10000000 - скорость уменьшается на 1 при увеличении числа записей в 10 раз. Такой запрос выполняется за доли секунды. Если использовать хэш, то скорость от числа записей вообще почти не зависит. Но как бы заявленные цифры порядка 100000 это совсем не много и что то партиционировать скорее всего не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2009, 18:42 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
вопрос мой прост и краток, промолвил носорог: что лучше - сорок пяток или пяток сорок ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2009, 11:14 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
freelanderПроектирую базу данных на MySQL, задался простым, но очень важным вопросом - что лучше, одна большая таблица или много маленьких? 100 тыс. записей - это маленькая таблица. Поэтому Вам без разницы. А вообще конкретно для MySQL это сильно зависит от. Если по таблице идут обновления, то несколько таблиц будут работать быстрее, чем одна из-за особенностей записи. В других СУБД и в InnoDB размер таблицы без разницы до тех пор, пока у Вас нет 100 запросов в секунду. При б о льших нагрузках несколько таблиц можно разнести на разные диски или разные сервера, одна же таблица приведёт к перегрузке сервера или покупке гораздо большего сервера. Помните: один большой сервер обычно значительно дороже четырёх равных ему по мощности маленьких. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2009, 20:42 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
GrayStrannikПомните: один большой сервер обычно значительно дороже четырёх равных ему по мощности маленьких. Только заставить четыре маленьких работать вместе так же быстро, как работает один большой практически нереально даже тчательно затачивая приложение на работу с кластером. Так что в пересчёте на пресловутый TFLOPS или TPS за K$, включая расходы на разработку кластерного приложения один большой может оказаться дешевле. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.12.2009, 22:47 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
mcureenabТолько заставить четыре маленьких работать вместе так же быстро, как работает один большой практически нереально даже тчательно затачивая приложение на работу с кластером. Так что в пересчёте на пресловутый TFLOPS или TPS за K$, включая расходы на разработку кластерного приложения один большой может оказаться дешевле.При условиях, означенных ТС (для каждого запроса точно изчестно, из какой таблицы нужно выбирать данные), вполне реально. А о кластере ни у ТС, ни у GrayStrannik разговора не было - понятно, что такие решения совсем не оптимальные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2009, 09:36 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
mcureenabТолько заставить четыре маленьких работать вместе так же быстро, как работает один большой практически нереально даже тчательно затачивая приложение на работу с кластером. Так что в пересчёте на пресловутый TFLOPS или TPS за K$, включая расходы на разработку кластерного приложения один большой может оказаться дешевле.Про кластер речи даже не шло - кластер хорош именно для больших таблиц и в качестве fileover. Речь про распределённую систему обработки данных. Но согласен - дополнительные расходы на маршрутизацию запросов чуть производительности съедят. Кроме того, всё хорошо до тех пор, пока не появляется запрос, которому нужны данные с двух машинок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.12.2009, 15:49 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Ну если те объемы что указаны в примере того же порядка что и в продакшн то я бы не думал по поводу разбиения. Но это абстрактно... В большинстве случаев так, возможно у вас какой-то уникальный ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.01.2010, 15:03 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
Ок, в поддержку автора чуть более конкретный пример... было 3 таблицы по 35, 47, и 25 млн записей соответственно. Все на mySQL. выборка по полю дата + id. Таблицы не обновляются, по сути - это архив данных. Поля для выборки проиндексированны. выборка всегда за конкретный день или период. Разбил все на 30 таблиц примерно по 2-3 млн записей. И вот сижу смотрю на хостинге графики нагрузки на БД и понимаю, что она стала больше(как мне кажется) хотя я ожидал, что будет меньше. Количество запросов тоже, таблицы меньше, по-моему должно стать меньше... или я чет не понимаю.. есть ли смысл их дробить вообще?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2017, 11:35 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
есть ли смысл их дробить вообще?.. Дробление должно снизить нагрузку на диск и проц. По идее. Но все сильно зависит от ситуации. Ожидаемого эффекта (ускорение отклика) может и не быть. Сильное дробление усложняет подготовку запроса, т.к. надо решить, откуда запрашивать. Переделка логики может потребовать переразбивки по другим правилам. И вообще изменение структуры таблиц из-за смены бизнес-логики - штука нежелательная. Разбивка сильно усложняет репликацию данных (любыми средствами). Кароч идеального рецепта нет и не будет. Только интуиция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2017, 12:48 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
AALLXXбыло 3 таблицы по 35, 47, и 25 млн записей соответственно. Все на mySQL. выборка по полю дата + id. Таблицы не обновляются, по сути - это архив данных. Поля для выборки проиндексированны. Исходя из логики - смысла дробить не было никакого. Размеры небольшие. Учитывая индекс все должно шуршать быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.05.2017, 17:47 |
|
||
|
Что лучше, несколько мелких таблиц или одна крупная?
|
|||
|---|---|---|---|
|
#18+
AALLXX ...Разбил все на 30 таблиц примерно по 2-3 млн записей. ... смотрю на хостинге графики нагрузки на БД и понимаю, что она стала больше... Запросы к 30 таблицам, скорее всего динамические, т.к. надо включить в select название нужной таблицы. Добавляются затраты на компиляцию запроса. К одной таблице можно использовать предварительно откомпилированный запрос (параметризованный или ХП). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.05.2017, 11:19 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=11&tid=1540179]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
52ms |
get tp. blocked users: |
2ms |
| others: | 239ms |
| total: | 376ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...