Много данных в одной БД или много БД

[clevel]

Да почему не сходится.
Есть сайты. Для каждого из них нужно доставать из словаря слов ID по первоформе/произвольной форме. Чтобы поисковый индекс строить. Если такого слова нет - он добавляется в словарь.

Теперь добавляем воторой сервер. Копируем туда уже собранный словарь слов. Он будет добавляться данными для некоторых сайтов, которые только на это второй сервер БД и завязаны. Таким же макаром можно добавить третий сервер БД и т.д. По факту получается разделение юзеров по серверам.

Так что никто обратно эти данные соединять не собирается.

-~{}~ 20.10.08 01:54:

у них у всех не сходится. хайлоад в мечтах.

Ну почему же. У меня сейчас в месяц практически полтерабайта траффика проходит, причем это на 90% - запросы с сайтов (обычне бизнес сайты, не музыка и не видеохостинг). Почта и фтп - весьма скромны по сравнению с этим. Кол-во уников в день - от 20 тысяч в общей сложности.
Живет все это на 2 машинках.

Просто можно делать репликацию в будуем базы, типа мастер/слейв, либо ставить mysql кластер. Но у меня мало связанные сайты - какой смысл?

 

[Ярослав]

clevel

после highload конференции еще больше убедился - что InnoDB - зло.

Извините что поднимаю этот топик но хотелось бы узнать почему все-таки зло.
Было б идеально если есть видео на конференцию.

 

[pilot911]

я бы все таки посмотрел на возможности мускуля новой версии 5.1, которая уже имеется в состоянии бета-релиза


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

каждый раздел можно хранить на разных дисках, компутерах и тп


тут немного об этом есть http://phpclub.ru/talk/showthread.php?s=&threadid=111036&rand=7

 

[флоппик]

pilot911, ты вообще о чем?

 

[pilot911]

Автор оригинала: флоппик
pilot911, ты вообще о чем?

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

 

[флоппик]

и что?

 

[pilot911]

производительность обработки больших таблиц повысится в разы

ты тему топика читал ?

 

[флоппик]

А ты _кроме_ темы топика что нибудь читал?
Хотя бы последнее сообщение в теме?

Хватит ляпать глупости уже.

 

[pilot911]

повторяем для флоппика:

Основное - будет множество пользователей, у каждого свой набор данных.

Как правильно - хранить все данные в одной бд, указывая ид пользователя в каждой таблице или для каждого пользователя создавать отдельную БД?

теперь смотрим возможность PARTITIONS в мускуле 5.1

Попробуем описать каждый из них более-менее подробно
[B]RANGE[/B] - позволяет при записи в качестве разделяющего фактора использовать поле или выражение над полем. При этом таким фактором может быть только лишь поле или операция над полем, возвращающие integer или NULL
Например, нам нужно указать - бить таблицу по идентификатору user_id на части

    CREATE TABLE tbl (
         id INT AUTO_INCREMENT PRIMARY KEY,
         user_id int(11)
    ) ENGINE = MYISAM
    PARTITION BY RANGE(user_id) (
    PARTITION p0 VALUES LESS THAN(100),
    PARTITION p1 VALUES LESS THAN(200),
    ......
    );

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

флоппик, ты не прав

 

[флоппик]

Мальчик, про RANGE я написал спустя несколько сообщений от вопроса. С тех пор тема обсуждения изменилась.

Молчал бы уже, если читать не умеешь.
Как связан твой пост с _последним_ вопросом?

 

[pilot911]

а ты RANGE от MERGE отличаешь ?

Автор оригинала: флоппик
А если тебе нужны сводные данные по всем пользователям — есть MERGE, который и нужен для таких задач.

MERGE были новшеством версии 3.23... старые технологии юзаешь и другим советуешь