Вопрос о производительности Mysql Casting Benchmark / Архитектура данных - PullRequest
1 голос
/ 21 апреля 2011

В настоящее время я работаю над набором данных, который является просто redicolus;простой файл от нескольких продавцов, который не имеет смысла или причины;и занимает около 200 столбцов. Есть 15, которые являются общими для этих 200, которые я вытащил в другую таблицу.

Из остальных 185 столбцов они представляют собой комбинацию varchar, int, datetime и нескольких строк.значения.

Сейчас я пытаюсь решить, как лучше хранить эти 185 столбцов;как в плоском столе в настоящее время это просто плохо масштабируется.У меня есть два решения, но я не знаю, какое из них лучше.

Один хранит метаданные для каждого из столбцов в отдельных таблицах (см. Изображение) Image architecture

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

Другой метод, о котором я подумал, - это выбросить все столбцы в таблицу с id, значением,типа данных, чем при выполнении запросов приведение значения к типу данных, т. е.:

 select * from foo where cast(col_to_query) as int < 5

, однако я не уверен, какова производительность при выполнении таких действий.

Вопрос:

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

Спасибо

1 Ответ

3 голосов
/ 21 апреля 2011

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

Я бы предложил использовать одну таблицу со всеми столбцами в качестве начального подхода. Вы сказали, что это плохо масштабируется, хотя. Что ты имеешь в виду? Как плохо масштабируется? Требуются ли для возврата много времени? Вы правильно проиндексировали таблицу для своих запросов? Количество столбцов не часто влияет на время значительного возврата запросов, за исключением случаев, когда они возвращают огромное количество данных. Если это так, то, как вы храните его под прикрытием, мало повлияет на время ответа на запрос, если все время тратится на передачу данных между mysql и клиентом. Убедитесь, что вы выбираете только те столбцы, которые вам интересны, если это так. Не делайте "выберите *".

Другой вариант - использовать стратегию наследования таблиц. В этом случае у вас будет одна родительская таблица, в которой хранятся 15 общих атрибутов, и «тип», который будет определять тип записей на основе файла, из которого они получены, или вы можете назвать его источником. Затем создайте таблицу расширений с отображением от 1 до 0-1 для каждого из различных файлов с настраиваемыми столбцами только для каждого конкретного файла. Это, скорее всего, не будет работать так же хорошо, как одна большая таблица, так как вам придется выполнять объединения, но это поможет уменьшить потребность в целой группе столбцов в одной таблице, которые часто бывают нулевыми.

Это будет выглядеть примерно так:

create table master (
  master_id int not null auto_increment primary key,
  type int,
  <field1> int,
  <field2> varchar(20),
  ...
);

create table file1_data (
  master_id int not null primary key,
  type int,
  <field16> int,
  <field17> varchar(20),
  ...
);

Запросите это так:

выберите,, ... от мастера внутреннее соединение file1_data на file1_data.master_id = master.master_id где ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...