Форум пользователей MySQL

frutty · 24.11.2010 14:24:14

сейчас таблица такая:

CREATE TABLE `sensor_data_avg` (

  `id` bigint(20) unsigned NOT NULL auto_increment COMMENT 'индекс записи',

  `monitor_id` smallint(5) unsigned NOT NULL COMMENT 'ID монитора',

  `sensor_id` smallint(5) unsigned NOT NULL COMMENT 'ID сенсора',

  `normal_flag` set('normal','minimum','maximum') NOT NULL default 'normal' COMMENT 'Флаг пикового значения',

  `sensor_value` double NOT NULL COMMENT 'Значение сенсора',

  `insert_timestamp` timestamp NOT NULL default CURRENT_TIMESTAMP COMMENT 'Время записи',

  PRIMARY KEY  (`id`),

  KEY `monitor_id` (`monitor_id`),

  KEY `sensor_id` (`sensor_id`),

  KEY `normal_flag` (`normal_flag`),

  KEY `insert_timestamp` USING BTREE (`insert_timestamp`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

в эту таблицу будут записываться данные с различных датчиков (температурных, давления и т.д.)
скорость поступления данных ~1500 значений в секунду, хранить данные надо 5 лет, т.е. в итоге 236,5 миллиарда записей за 5 лет
данные изменять не будут, только INSERT и SELECT (по monitor_id, sensor_id, normal_flag и insert_timestamp)
что бы Вы посоветовали, как лучше настроить сервер и саму баз?

paulus · 24.11.2010 16:54:26

1. Не делайте одну таблицу, сделайте несколько (например, разные датчики в разных
таблицах).
2. Сделайте шардирование.
3. Индекс по normal_flag, наверное, будет бесполезным.

frutty · 24.11.2010 20:28:47

paulus написал:
1. Не делайте одну таблицу, сделайте несколько (например, разные датчики в разных
таблицах).
2. Сделайте шардирование.
3. Индекс по normal_flag, наверное, будет бесполезным.

1 и 2-ой пункт чем поможет? и обязательны ли они?
3-ий почему нет? ведь выборка будет осуществляться и по нему тоже!

paulus · 24.11.2010 20:51:16

Помогут поддерживать это безобразие пять лет

Если сервер будет выбирать треть таблицы по индексу — это будет
выполняться медленнее, чем полное сканирование таблицы последо-
вательно.

frutty · 24.11.2010 20:59:37

paulus написал:
Помогут поддерживать это безобразие пять лет

Если сервер будет выбирать треть таблицы по индексу — это будет
выполняться медленнее, чем полное сканирование таблицы последо-
вательно.

логично и я думаю поле id убрать, т.к. оно никогда не пригодиться
А что можете посоветовать по настройке сервера? конфигурации железа? MyISAM или InnoDB?

Отредактированно frutty (24.11.2010 21:01:45)

paulus · 25.11.2010 14:33:04

Зависит от количества шардов, таблиц, требований к доступности данных и т.п.

Например, если Вы пишете новую таблицу каждый час, и при этом не используете
данные на чтение за последний час — вполне можно использовать MyISAM, который
будет занимать меньше места на диске. Если же данные нужны сразу — при таком
количестве записей InnoDB безусловно лучше.

frutty · 25.11.2010 15:20:39

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

paulus · 25.11.2010 19:01:46

Можно и кластером с репликацией. Мне было бы жалко настраивать кластер для хранения
логов, но если у Вас много ресурсов — можете попробовать.

Я бы начал с просто хорошо шардированных машинок.

Форум пользователей MySQL

#1 24.11.2010 14:24:14

Нужна помощь в создании базы данных с огромным количеством данных

#2 24.11.2010 16:54:26

Re: Нужна помощь в создании базы данных с огромным количеством данных

#3 24.11.2010 20:28:47

Re: Нужна помощь в создании базы данных с огромным количеством данных

paulus написал:

#4 24.11.2010 20:51:16

Re: Нужна помощь в создании базы данных с огромным количеством данных

#5 24.11.2010 20:59:37

Re: Нужна помощь в создании базы данных с огромным количеством данных

paulus написал:

#6 25.11.2010 14:33:04

Re: Нужна помощь в создании базы данных с огромным количеством данных

#7 25.11.2010 15:20:39

Re: Нужна помощь в создании базы данных с огромным количеством данных

#8 25.11.2010 19:01:46

Re: Нужна помощь в создании базы данных с огромным количеством данных

Board footer