Здравствуйте, Firstborn, Вы писали:
F> А вот в самом простом и общем случае, что предпочтительнее с точки зрения скорости выборки в БД MySQL — 1 таблица с 1,000,000 записей, или же 1,000 таблиц с 1,000 записей? Предположим, join-ов не будет, то есть в обоих сценариях выборка будет производится по одной таблице, вопрос только в том, как повлияет на производительность наличие большого кол-ва таблиц в базе?
Первое, если выборка по PK или по индексу с высокой селективностью + еще много тонокостей, но каков вопрос таков ответ.
Здравствуйте, Firstborn, Вы писали:
F>А вот в самом простом и общем случае, что предпочтительнее с точки зрения скорости выборки в БД MySQL — 1 таблица с 1,000,000 записей, или же 1,000 таблиц с 1,000 записей? Предположим, join-ов не будет, то есть в обоих сценариях выборка будет производится по одной таблице, вопрос только в том, как повлияет на производительность наличие большого кол-ва таблиц в базе?
Если поиск по индексу, то одна большая таблица однозначно выгодна (так как log(1000000) < 1000*log(1000)).
А вот в самом простом и общем случае, что предпочтительнее с точки зрения скорости выборки в БД MySQL — 1 таблица с 1,000,000 записей, или же 1,000 таблиц с 1,000 записей? Предположим, join-ов не будет, то есть в обоих сценариях выборка будет производится по одной таблице, вопрос только в том, как повлияет на производительность наличие большого кол-ва таблиц в базе?
И, кстати, ограничено ли как-то количество таблиц, что могут быть созданы в базе, скажем, 4.x?
Здравствуйте, mazurkin, Вы писали:
>> Если поиск по индексу, то одна большая таблица однозначно выгодна (так как log(1000000) < 1000*log(1000)). M>Если шардинг организован правильно, то такое отношение вряд ли может M>иметь место.
Пофиг на шардинг. Это отношение всегда верно. С шардингом просто может случится, что запросы будут выполняться параллельно на разных узлах.
Cyberax wrote:
>>> Если поиск по индексу, то одна большая таблица однозначно выгодна (так как log(1000000) < 1000*log(1000)).
> Пофиг на шардинг. Это отношение всегда верно. С шардингом просто может случится, что запросы будут выполняться параллельно на разных узлах.
Если параллельно — то общее время выполнения как раз и будет в среднем
составлять log(1000), а не 1000*log(1000)
Здравствуйте, mazurkin, Вы писали:
>> Пофиг на шардинг. Это отношение всегда верно. С шардингом просто может случится, что запросы будут выполняться параллельно на разных узлах. M>Если параллельно — то общее время выполнения как раз и будет в среднем M>составлять log(1000), а не 1000*log(1000)
Параллельно на тысяче хостов сразу? Там накладные издержки будут в десятки раз больше самого времени поиска.
Cyberax wrote:
>>> Пофиг на шардинг. Это отношение всегда верно. С шардингом просто может случится, что запросы будут выполняться параллельно на разных узлах. > M>Если параллельно — то общее время выполнения как раз и будет в среднем > M>составлять log(1000), а не 1000*log(1000)
> Параллельно на тысяче хостов сразу? Там накладные издержки будут в десятки раз больше самого времени поиска.
Вообще топикстартер имел в виду одну БД — я же думал про кластер. В
случае одной БД, смысла разбивать по таблицам, конечно же нет.
А что касается "тысячи хостов" — так гугль как-то так и делает, правда
это уже не совсем реляционная БД — и ничего, все весело работает
