Дизайн / архитектура таблицы MySQL, таблица слишком велика

У меня есть база данных MySQL, содержащая много текста, я беру данные с веб-сайта и вставляю их в таблицу.

Я использую SSD HD (100 ГБ) для БД, и мне не хватает места, я думаю, что что-то в структуре таблицы сделало ее слишком большой, я не могу предсказать размер всех столбцов, поэтому я использую varchar \ text \ medium text для большинства полей. когда я вставляю все данные в БД, я отслеживаю ошибки, и когда я вижу, что определенное поле слишком мало для данных, которые я пытаюсь вставить, я увеличиваю размер поля (например, с varchar (1000) до varchar (2000)).

до сих пор у меня около 1,8 млн ~ строк, я думаю, что что-то делаю не так.

вот структура моей таблицы -

CREATE TABLE `PT` (
  `patID` int(11) NOT NULL,
  `Title` varchar(450) DEFAULT NULL,
  `IssueDate` date DEFAULT NULL,
  `NoFullText` tinyint(1) DEFAULT NULL,
  `Abstract` text,
  `ForeignReferences` varchar(15000) DEFAULT NULL,
  `CurrentUSClass` varchar(2200) DEFAULT NULL,
  `OtherReferences` mediumtext,
  `ForeignPrio` varchar(900) DEFAULT NULL,
  `CurrentIntlClass` varchar(3000) DEFAULT NULL,
  `AppNum` varchar(45) DEFAULT NULL,
  `AppDate` date DEFAULT NULL,
  `Assignee` varchar(300) DEFAULT NULL,
  `Inventors` varchar(1500) DEFAULT NULL,
  `RelatedUSAppData` text,
  `PrimaryExaminer` varchar(100) DEFAULT NULL,
  `AssistantExaminer` varchar(100) DEFAULT NULL,
  `AttorneyOrAgent` varchar(300) DEFAULT NULL,
  `ReferencedBy` text,
  `AssigneeName` varchar(150) DEFAULT NULL,
  `AssigneeState` varchar(80) DEFAULT NULL,
  `AssigneeCity` varchar(150) DEFAULT NULL,
  `InventorsName` varchar(800) DEFAULT NULL,
  `InventorsState` varchar(300) DEFAULT NULL,
  `InventorsCity` varchar(800) DEFAULT NULL,
  `Claims` mediumtext,
  `Description` mediumtext,
  `InsertionTime` datetime NOT NULL,
  `LastUpdatedOn` datetime NOT NULL,
  PRIMARY KEY (`patID`),
  UNIQUE KEY `patID_UNIQUE` (`patID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

что я должен делать? У меня около 20% данных (что означает, что мне понадобится 350 ГБ ~ места), как это влияет на производительность? мне следует разделить таблицу на несколько таблиц по нескольким HD? Я собираюсь использовать sphinx для индексации и запроса данных в конце.


mysql database-design sphinx
person YSY    schedule 12.07.2012    source источник
comment
Дело не в структуре таблицы, а в количестве имеющихся у вас данных. В вашей структуре таблицы в основном используются символы varchars и текстовые столбцы, они работают, сохраняя текст и используя 1 байт (или 2 байта), добавленный в конце, чтобы отметить размер текста. Это означает, что varchar (1500) совпадает с использованием столбца mediumtext. Другая проблема, которая может быть проблемой, - это то, как MyISAM обрабатывает хранилище данных и как он фрагментирует табличное пространство - я в этом не эксперт, но структуру вашей таблицы нельзя оптимизировать, если вам нужно сохранить такой объем текста.   -  person N.B.    schedule 12.07.2012
comment
большинство больших фрагментов текста хранятся в столбцах mediumtext \ text, где я могу увидеть файлы, в которых сохраняется текст \ mediumtext? я должен рассмотреть возможность использования другого движка БД?   -  person YSY    schedule 12.07.2012
comment
Обратитесь к внутреннему устройству MyISAM.   -  person N.B.    schedule 12.07.2012
comment
Вы можете попробовать и проверить движок TokuDB MySQL, который имеет гораздо более высокое сжатие данных.   -  person N.B.    schedule 12.07.2012

Ответы (1)


arrow_upward
1
arrow_downward

Все значения столбца, отличные от ТЕКСТА, хранятся в одной записи размером 8 КБ (неразделенная единица пространства на жестком диске). Значения столбца TEXT хранятся как указатели на внешние блоки данных.

Такие структуры (очень ориентированные на текст) лучше обрабатываются базами данных NOSQL (не только SQL), такими как MongoDB.

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

Процесс структурирования базы данных, позволяющий избежать повторяющейся информации и позволяющий легко обновлять (обновление в одном месте - видимое повсюду), называется нормализацией.

Если данные, которые вы храните в этих больших VARCHAR (например, длина изобретателей 1500), структурированы как несколько элементов данных (например, имена изобретателей, разделенные запятой), вы можете реструктурировать свою таблицу БД, создав таблицу изобретателей. и ссылаясь на него.

person Mihai Stancu    schedule 12.07.2012