распределение таблиц БД под разделы?
  • возникла мысль использовать для будующего сайта несколько таблиц под контент, тоесть 1 таблица на крупный раздел, 2-ая на другой раздел и так далее

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

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

    + свой поиск точно будет
  • ну вот поиск уже вносит корективы ...
    т.е. по сути , если просто выбирать одну строку ...то не суть важно ....
    а вот если по условию, и тем более если сортировки и т.д. ...
  • меня просто беспокоит пока вес бд, что столько придется серверу разом открывать (конечно беспокоит, в мускуле не особо шарю :) )

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

    ЮПД: кажись понял, видать я бурундук, тут поиск по будующему сайту решает :)
  • Отдача контента, как и редактирование по сути значения не имеет, это ж SQL. А вот поиск, групповые операции и сложные групповые запросы это да, чем больше записей в таблице, тем критичнее. С другой стороны, при поиске например, по всем разделам так и так делать union-запрос или последовательный поиск по таблицам, а это снизит скорость. Стоит обратить внимание на масштабируемость: с одной стороны разные таблицы под разделы позволяют допиливать детали _только_ нужных разделов, с другой - если разделов много, и пилить надо каждый, то править придется несколько таблиц вместо одной. В случае тотального расширения, разные таблицы проще разнести на разные сервера. Гигабайтная таблица... В принципе, это не так уж и много, но если планируется её "перебирать" тем же поиском, лучше распределить.
  • тут вообще надо более дельно рассматривать задачу ....
    всегда идут компромисы

    ПС: на пример, иногда можно выкрутится параллельными таблицами
  • Учитывая, что в таблице не будет ничего лишнего, то 1 гиг и более одного только контента, то фактически много, я сужу по размерам файлов самих баз

    спасибо, определился, да будет многотобличье, ди и не сложно их модернизировать

    да и резервное копирование по несколькими файлами удобнее, чем тащить с сервера нечто жирное

    всем спасибо :)

    ПС: на пример, иногда можно выкрутится параллельными таблицами

    тоесть?
  • например есть большая таблица ....и из нее иногда надо делать выборку, отсотрированную по опред полям .....тогда можно создать еще одну таблицу с такими же данными. но уже отсортированную, и выбирать из нее, но тут проигрыш в занимаемом размере диска

    потом еще структура таблиц, можно все основные поля держать в одной более легкой таблице, и по ней выбирать, а уже сам конт, брать из другой
  • ага, спасибо, благо место не волнует :) записал на заметку к исполнению
  • Гигабайтная таблица... В принципе, это не так уж и много, но если планируется её "перебирать" тем же поиском, лучше распределить.

    Интереснее размеры индексов. А вообще одной версией этой системы не отделаться, видимо :)
  • Есть такой опыт: 5 млн. записей на 400 метров в одной таблице (словоформы) плюс юнион на исходники при индексации работает достаточно быстро.
    Думаю тут стоит логировать запросы и смотреть время их исполнения, а уж потом принимать решение.
    Тот же кеш страниц вариант, ну а поиск, он всегда тяжелый и долгий...
  • Интереснее размеры индексов. А вообще одной версией этой системы не отделаться, видимо :)


    кто его знает, надеюсь не придется переделывать долго

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

    Есть такой опыт: 5 млн. записей на 400 метров в одной таблице (словоформы) плюс юнион на исходники при индексации работает достаточно быстро.
    Думаю тут стоит логировать запросы и смотреть время их исполнения, а уж потом принимать решение.
    Тот же кеш страниц вариант, ну а поиск, он всегда тяжелый и долгий...

    даже так, теперь весь в думках :))

    ЮПД: запросы поиска же тоже кешируются, только на больший срок по-идее

Привет, незнакомец!

Похоже, Вы новенький! Чтобы начать обсуждение, кликните на одну из кнопок ниже ;)

Войти с помощью OpenID

Категории

В этой теме: