разработка индекса mySql и первичного ключа для повышения эффективности - PullRequest
Новая
       10

разработка индекса mySql и первичного ключа для повышения эффективности

0 голосов
/ 27 ноября 2009

У меня есть коллекция записей среднего размера - около 20 миллионов, - которую мне нужно загрузить в mySQL для использования в анализе данных. Это записи людей, посещающих места. Они однозначно идентифицируются тремя элементами данных:

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

Я не имею никакого контроля над человеком и содержимым поля посещения, так как оно предоставляется разными местами, и каждое место делает свое дело.

Я могу найти все записи о человеке, сопоставив и место и человека, и индивидуальную запись, сопоставив все три.

Я могу сделать это нормально в mySql, создав такую ​​таблицу: 

CREATE TABLE ENCOUNTER (
  PLACE int(11) NOT NULL,
  PERSON varchar(255) NOT NULL,
  VISIT varchar(255) NOT NULL,
  ARRIVAL_TIME datetime DEFAULT NULL,
  DEPARTURE_TIME datetime DEFAULT NULL,
  EVENT varchar(255) NOT NULL,
  PRIMARY KEY (PLACE,PERSON,VISIT)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 ROW_FORMAT=DYNAMIC;

Я пошел с MyISAM, потому что мне не нужна ACID целостность транзакций для этой таблицы; он используется для статистической отчетности, поэтому, если он устарел на одну или две строки, это не проблема.

В таблицу часто попадают UPDATE, которые просто меняют одно из полей, например DEPARTURE_TIME. Эти ОБНОВЛЕНИЯ, скорее всего, будут примерно в два раза чаще, чем ВСТАВКИ новых строк. Нет необходимости обновлять идентификаторы места, человека или посещения.

Вот несколько вопросов:

Будет ли мне лучше работать с одним индексом и ключевым столбцом, объединяющим информацию о месте / человеке / посещении?

Какую долю попадания я получу для индексов varchar? Стоит ли пытаться ограничить их полем фиксированной длины?

Какие-нибудь еще советы из собранной мудрости?

Спасибо.

Ответы [ 2 ]

0 голосов
/ 27 ноября 2009

Я могу найти все записи о человеке, сопоставив и место и человека, и индивидуальную запись, сопоставив все три.

Если вы собираетесь искать все места, которые посетил человек, вам нужно будет добавить дополнительный индекс на (person, place).

Какую долю попадания я получу для индексов varchar? Стоит ли пытаться ограничить их полем фиксированной длины?

Нажатие клавиши занимает одинаковое время для записей INT и VARCHAR.

Отсутствие ключа дороже для VARCHAR полей.

0 голосов
/ 27 ноября 2009

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

это прекрасная, неочевидная возможность использовать разделы.У меня есть ощущение, что весь ваш анализ будет основан на месте.если это так, то создайте хеш-раздел на основе столбца place, например, так: 

ALTER TABLE encounter PARTITION BY KEY(place) PARTITIONS 12;

это сделает ваши запросы намного быстрее, так как mysql знает, что может пропустить просмотр 1/12 строк при выполнениианализ для одного места.

...